UNIVERSIDAD AUTONOMA METROPOLITANA

PROYECTO DE INVESTIGACIONO

/ SISTEMAS EXPERTOS Y LENGUAJES ORIENTADOS A

OBJETOS i

POR

'AARON OCTAVIO /ZARATE PEÑA

MARTHA LORENA VALLEJO CASTILLO

ASESOR: L.C. RENE MAC KINNEY

' . I. . - .. , , ."""(. ~ .

/ 4992" ROMERO

Trimestre 92-1

1 4 5 9 0 3

El presente articulo, establece la asociacidn "natural" que existe entre los lenguajes de programacidn orientados a objetos y los sistemas expertos basados en el conocimiento.

Pretende justificar desde el punto de vista de cada una de las partes que intervienen para este fin, éI porque puede asociarse y/o ser útil para las otras y se dB esta "naturalidad".

u\ P Es necesario que el lector tenga conocimientos y experiencia en lenguaks de programacidn procedimental o funcional.

INTRODUCCION

En la actualidad existen infinidad de lenguajes y herramientas para programar computadoras. Las necesidades de crear sistemas cada vez m6s especializados, ha motivado que desde hace años los investigadores desarrollen tecnicas mas avanzadas para satisfacer dichas necesidades, uno de estos resultados ha sido la creaci6n de los sistemas expertos.

Los sistemas expertos se han abierto camino utilizando mecanismos de representacidn del conocimiento que van desde los m6s antiguos en la 16gica formal hasta los mas abstractos.

En la construccidn de los sistemas expertos el entorno de programacidn es muy importante debido a las constantes modificaciones que deben realizarse a &tos, que de no ser así los harían inviables. Para la construccidn de un sistema experto, se puede partir de diferentes niveles entre otros: de un lenguaje de programacidn imperativo y orientado a los procedimientos (Fortran, Basic, Pasca, C, etc.), en los que la solucidn a un problema se obtiene mediante la aplicaci6n de un conjunto de secuencias o procedimientos; o de un lenguaje de programacicin funcional y orientado a las estructuras de datos en los que la soluci6n se obtiene gracias a las potentes estructuras de datos que poseen y que engloban el control; o de un lenguaje de programaci6n declarativo y orientado a los objetos, en los que se llega a la solucidn mediante la definici6n de los objetos y los mensajes que los relacionan.

En nuestro caso, el entorno de programaci6n que se mostrar6 para desarrollar un sistema experto es el lenguaje orientado a objetos.

En la primera parte se mencionan las necesidades que originaron el desarrollo de nuevos lenguajes que soportan una mejor abstraccidn de datos. Los lenguajes que surgieron en respuesta a lo anterior son los lenguajes orientados a objetos, de estos se menciona sus características y tecnicas de programaci6n.

En la segunda parte, se describe que es un sistema orientado a objetos así como el h f a s i s entre los datos y procedimientos, indicando que los datos vienen a ser los objetos primarios y los procedimientos los objetos secundarios. Haciendo notar que este es un buen principio de diseño en sistemas usado para hacer sistemas mas modulares y robustos.

En la tercera parte, se definen a los sistemas expertos detall6ndose sus características y su estructura. Adern&, se menciona la necesidad de una forma de representacidn del conocimiento usando el concepto marcos como punto de partida para desarrollar sistemas expertos.

Esta estructura que se le ha dado al artículo, tiene la intenci6n de definir y observar a cada una de las partes que intervienen asocisndolas o "direccionandolas" hacia las otras, esto es, que los lenguajes orientados a objetos no se observan como "entes independientes" a los sistemas expertos, sino que son observados como el lenguaje y forma de programacidn que aporta posibles beneficios y perjuicios en la realizacidn de sistemas expertos basados en el conocimiento. Los sistemas expertos, de igual manera, no son vistos en general; sino que únicamente son observados con una orientacidn a su posible desarrollo con lenguajes de programaci6n orientados a objetos y con una representacidn del conocimiento que mejor se facilite para este fin.

Esto se hizo así con la intenci6n de no tocar subtemas o subpartes que no vengan al caso y llegar a una conclusih final que puede perder al lector, o hacerlo creer que las cosas "salieron de la manga". Por esto es que no existen conclusiones, todas la conclusiones, asociaciones o relaciones entre las partes que intervienen est6n en el mismo artículo.

1 4 5 9 0 3

LENGUAJES ORIENTADOS A OBJETOS Y PROGRAMACION

Antecedentes.

Por muchos años, los grandes proyectos de programaci6n han destinado equipos para desarrollo muy grandes, y la necesidad de desarrollar partes diferentes e independientes del mismo sistema.

Como respuesta a esta necesidad se hizo una compilacidn separada de los mddulos, la cutil se conceptualiz6 mas pequeña que una caja arbitraria para datos, y subprogramas. Los m6dulos fueron reconocidos rara vez como un mecanismo importante de abstracci6n; en la practica estos se usaron simplemente para agrupar subprogramas relacionados I6gicamente. La mayoría de los lenguajes (de la tercera generaci6n) soportan estructura modular y tienen algunas reglas que requieren consistencia semtintica entre las interfaces de los m6dulos. Un desarrollador escribe un subprograma para un m6dulo que puede suponer que Bste pudiera ser llamado con tres partimetros diferentes: un número de punto flotante, un arreglo de diez elementos, y un entero representando una bandera booleana. En otro m6dulo, una llamada a este subprograma quiztis utilice incorrectamente partimetros actuales que violan estas suposiciones: un entero, un arreglo de cinco elementos, y un número negativo. Desafortunadamente, debido a que la mayoría de estos lenguajes tuvieron un mal soporte para la abstraccidn de datos y una fuerte definicidn de tipos, tales errores solo pueden ser detectados durante la ejecución de un programa.

La importancia de la abstracci6n de datos para dominar complejidad es claramente expuesta por Shankar: "La naturaleza de abstracciones que tal vez se consigui6 a traves de del uso de procedimientos est6 bien adaptada a la descripci6n de objetos abstractos. Este es un serio inconveniente, en muchas aplicaciones, la complejidad de los objetos a ser manipulados contribuye substancialmente en toda la complejidad del problema". Esta comprensi6n tuvo dos consecuencias importantes. Primero, se diseñaron metodos para el manejo de datos, que aportaron una buena aproximaci6n a los problemas de realizar la abstraccibn de datos en lenguajes orientados a algoritmos. Segundos, las teorías relativas al concepto de la creacidn de un tipo, encontraron eventualmente su realizaci6n en lenguajes tales como Pascal.

La conclusi6n natural de estas ideas aparecid primero en el lenguaje Simula 67 [Simula 671 y fue mejorado durante el intervalo de tiempo de la generación de estos lenguajes, resultando en el desarrollo relativamente reciente de varios lenguajes tales como Smalltalk [Goldberg 19833, Object Pascal [Hansen 19751, C + + [Stroustrup 19861, CLOS, Ada y Eiffel [Meyer 19891, entre otros. Estos lenguajes son llamados algunos basados en objetos y otros orientados a objetos. La construccidn física de un bloque en estos lenguajes es el mddulo, el cual representa una cotecci6n I6gica de clases y objetos en lugar de subprogramas, como en lenguajes mas recientes. Dicho de otra manera, "Si los procedimientos y funciones son verbos y los datos son sustantivos, un programa orientado a procedimientos es organizado alrededor de verbos; mientas que un programa orientado a objetos es organizado alrededor de sustantivos". Por esta razdn, la estructura física de una pequeña aplicaci6n orientada a objetos aparece como un grafo, no como un tirbol, el cutil es típico de lenguajes orientados a algoritmos. Ademas hay pequeños datos 6 datos no globales. En lugar de ello, los datos y operaciones son unidos en forma tal

que la construcci6n 16gica fundamental de bloques en nuestros sistemas no son algoritmos m& largos, peros son clases y objetos.

Para sistemas muy grandes, se encuentra que las clases, objetos y m6dulos proveen aún insuficientes medios de descomposici6n. Afortunadamente, los objetos crecen; tambien se encuentran grupos de abstracciones construidas en capas sobre algún otro grupo. En cualquier nivel de abstracci6n, se encuentran colecciones significativas de objetos que cooperan para conseguir algún nivel de comportamiento mas alto. Dentro de la implementaci6n de cualquier grupo de abstracciones, se descubre otro conjunto de abstracciones cooperativas.

Elementos del Lenguaje.

Clases. Una clase representa la implantaci6n de un tipo de datos abstracto, ademas es la base para la reusabilidad. Una clase contiene todo lo necesario para el uso de un tipo de datos, sus caracterlsticas y las operaciones que se pueden realizar con 61. Se utiliza la herencia como mecanismo para compartir características y operaciones entre tipos de datos similares. Existen clases predefinidas en el lenguaje para facilitar el trabajo de programaci6n.

Objetos. Los objetos son el objetivo principal de la programaci6n orientada a objetos. Todas las entidades excepto los mensajes, comentarios, y algunos símbolos de puntuaci6n son objetos. Un objeto consiste de una cantidad limitada de memoria; la cual contiene otros objetos (datos y procedimientos). Estos son encapsulados como una unidad y son accesibles para ese objeto únicamente. Los objetos estan caracterizados por atributos y por la manera en que proceden cuando les son enviados mensajes. Todos los objetos pertenecen a alguna clase. Los objetos son creados al declararlos corno instancias de una clase existente y automsticamente instancias variables.

Es importante recalcar la distincidn entre objetos y clases: los objetos son elementos a tiempo de ejecucidn que seran creados durante la ejecuci6n de un sistema; las clases son simplemente una descripci6n eststica de un conjunto de posibles objetos - de instancias de las clases. A tiempo de ejecucidn, solo se tienen objetos; en el programa solo se ven clases.

Tipos de Datos Abstractos. Los tipos estsn representados por clases y existen otros denominados tipos expandidos. A diferencia de las clases los tipos expandidos representan objetos y no referencias a objetos de tal manera que el tipo expandido INTEGER permite que una entidad declarada de ese tipo sea un entero y no una referencia a un entero.

Asemiunes. Las aserciones son mecanismos que nos permiten vigilar el comportamiento de los objetos a tiempo de ejecuci6n por medio de precondiciones, postcondiciones e invariantes. En un esquema que nos recuerda al de Hoare para la prueba de la calidad de correcci6n de un programa.

Excepciones. El manejo de las excepciones es bastante natural en la mayoría de estos lenguajes, ya que se define que una rutina tiene &xito o falla. Esto se mide con base en un contrato y puede que la rutina cumpla o no con 61. Existen clausulas de salvamento para intentar corregir la situaci6n por la que se falla, se define dentro de la rutina y se cuentan con

instrucciones para reintentar ejecutar la rutina si se logra la correccibn del error.

Clases Gendricas y Herencia Múltiple. Se permite el uso de tipos como parametro de clases lo que permite representar tipos mas complejos de caracter general como son listas, arreglos, arboles, etc. Ademds se permite que las clases hereden propiedades de otras clases y renombrar elementos de la especificaci6n en una forma muy similar a las especificaciones algebraicas de tipos de datos abstractos teniendose gran versatilidad en la definicidn y uso de 180s tipos.

Polimorfismos, amarre dindmico y clases diferidas. Todos estos elementos se refiere a la facilidad para que se haga el uso de rutinas de manera inteligente. El polimorfismo permite tener rutinas con el mismo nombre para distintos objetos y se logra a traves del amarre dinamico, asocidndoles distintos significados. Las clases diferidas contienen rutinas diferidas para ser especificados por los descendientes.

Programacidn Orientada a Objetos

"La programacidn orientada a objetos es un mhtodo de implernentacidn en el cual los programas est& organizados como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de algunas clases, y dichas clases son miembros de una jerarquizacidn de clases unidas a travbs de relaciones hereditarias.

Hay tres partes importantes en esta definicidn: La programaci6n orientada a objetos (1 1 utiliza objetos, no algoritmos, sus bloques estdn construidos de una manera fundamentalmente Ibgica; (2) cada objeto es una instancia de alguna clase; y (3) las clases se encuentran relacionadas una a otra a través de relaciones de herencia. Un programa puede parecer orientado a objetos, pero si alguno de sus elementos se pierde, entonces no es un programa orientado a objetos. Puntualizando, si se programa sin herencia entonces definitivamente ya no es orientado a objetos; es llamada programacidn con tipos de datos abstractos.

Con esta definici6n, algunos lenguajes son orientados a objetos, y algunos no. Se sugiere que si el termino lenguaje orientado a objetos significa cualquier cosa, debe suponer un lenguaje que tiene mecanismos que soportan adecuadamente el estilo de programacibn orientada a objetos. Un lenguaje soporta adecuadamente un estilo de programaci6n si provee facilidades que hacen conveniente el uso de ese estilo. Un lenguaje no soporta una tecnica si le toma un esfuerzo excepcional 6 se debe recurrir a la maña o pericia para escribir programas; en este caso, el lenguaje simplemente permite a los programadores hacer uso de tecnicas. Desde una perspectiva tebrica, se puede fingir una programaci6n orientada a objetos en lenguajes que no son orientados a objetos como Pascal, Cobol, o lenguaje ensamblador, pero sería horrible llegar a realizarla. Cardelli y Wagner dicen los siguiente: "Un lenguaje es orientado a objetos si y solo si satisface los siguientes requerimientos: O Soporta objetos los cuales son abstracciones de datos con una interfaz

de operaciones y un estado local oculto. O Los objetos tienen un tipo asociado (clase). O Los tipos (clases) pueden heredar atributos de supertipos (superclases)."

Para un lenguaje que soporta herencia significa que le es posible expresar tipo de relaciones entre tipos, como una rosa roja es un tipo de flor , y una flor es un tipo de planta. Si un lenguaje no provee un soporte

directo para la herencia, entonces no es orientado a objetos. Cardelli y Wagner distinguen a dichos lenguajes llam6ndolos basados en objetos en lugar de orientados a objetos. Bajo esta definicidn, Smalltalk, Object Pascal, C+ +, CLOS, y Eiffel son orientados a objetos, y Ada es basado en objetos. No obstante, como los objetos y las clases son elementos de ambos tipos de lenguajes, es posible y sumamente conveniente utilizar tecnicas de diseño orientadas a objetos en lenguajes de programaci6n basados en objetos y lenguajes de programacidn orientados a objetos.

En la programacidn orientada a objetos solo se tiene un antecesor directo y por tanto cada clase de un nivel inferior tiene un concepto cada vez mas especializado de algún cierto tipo de datos. Ademds, en la programaci6n orientada a objetos cada clase es autosuficiente y no se tiene ningún esquema que acceda externamente a los objetos.

Los programas compuestos de objetos son mas poderosos y flexibles debido a que por construcci6n tienen capacidad para cambiar. Cualquier programa aún con modesta complejidad se presta al cambio o evoluci6n. Anticipar el cambio es un proceso natural en esta forma de programacibn; los cambios son de dos formas:

Un cambio externo es un cambio en el mundo exterior que requiere un cambio en el sistema para que este sistema continúe modelando el mundo externo actual. La mayoría de los sistemas de programaci6n (particularmente sistemas estructurados) suponen que todos los cambios son externos.

Un cambio interno es un cambio en la manera en que entendemos un problema. En este caso, nada necesita cambiar en el mundo exterior. La percepci6n del problema son los cambios. Entonces se reconceptualiza el problema o modelo usando el sistema a traves de investigaci6n, por ponderacidn, etc.

Los lenguajes de programacibn orientados a objetos proveen las tecnicas para crear sistemas que pueden adaptarse fdcilmente a cambios externos o internos. Un diseño de programaci6n orientado a objetos utiliza estas tecnicas, y permite a los diseñadores (y sus ideas) crecer con el sistema. Los diseñadores no necesitan saber todo acerca del sistema antes de comenzar a codificarlo.

Los proyectos de inteligencia artificial son por naturaleza exploratívos, creativos, dindmicos, experimentales. Los lenguajes orientados a objetos se prestan al mantener esos cuatro requerimientos.

Una observaci6n que se debe hacer para estos lenguajes es que muchas veces uno programa de manera imperativa o funcional, logrando que el c6digo se vuelva obscuro e ineficierlte. Pero, a fin de cuentas, no es tan fscil quitarse de la cabeza los años que se tienen de programar en estas formas.

SISTEMAS ORIENTADOS A OBJETOS

La idea bdsica de los sistemas orientados a objetos es la noci6n de clases de objetos interactuando unos con otros para completar algún tipo

I 4 5 9 0 3

de tarea. Los objetos estan bien definidos en sus comportamientos. Ellos interactúan con cada uno de los otros a través del uso de mensajes.

Los sistemas orientados a objetos son útiles en la modelacidn de muchas situaciones del mundo real en las cuales los objetos reales pueden ser puestos en una correspondencia de uno a uno con clases de programas y objetos. En los sistemas orientados a objetos todas la entidades son objetos, y los objetos estan protegidos de otras entidades. Ellos interactúan con otros objetos a traves de una interfaz la cual reconoce un conjunto de mensajes llamado el protocolo de la clase. Cada clase en un sistema orientado a objetos tendrs sus propias características únicas las cuales son gobernadas por un conjunto de métodos llamados clases. Estos metodos (clases) y sus instancias (objetos) pueden ser creadas por una clase de objetos de su predecesor o superclase. El caso de múltiples herencias es soportado por muchos sistemas.

Los lenguajes orientados a objetos son bien estructurados para ciertos tipos de sistemas en problemas de simulaci6nI de una manera natural, en la cual los sistemas orientados a objetos modelan sistemas reales.

En un sistema orientado a objetos el enfasis entre los datos y los procedimientos es recíproco. En el universo de los sistemas orientados a objetos todo es un objeto, y los objetos son inaccesibles hacia los procedimientos; esta forma de estructura es llamada "encapsulacidn" (o dato oculto). Con encapsulacicin, los objetos son asociados a sus propios procedimientos y, con esto, son responsables de sus propias acciones. Los objetos son individuales, contienen sus propias unidades que exhiben un cierto comportamiento de su propiedad e interactúan con otros objetos s610 a traves del uso de mensajes (protocolo de la clase). Cuando una tarea necesita ser ejecutada, un objeto pasa un mensaje el cual especifica los requerimientos de la tarea. El objeto que recibe entonces ejecuta las acciones adecuadas en respuesta al. mensaje y, responde regresando un mensaje al objeto que le envid. En respuesta a la tarea requerida, el objeto que recibe puede necesitar asistencia de otros objetos, teniendo que generar futuros mensajes a ser enviados. Ademss, todos los detalles de la tarea son totalmente ocultos para otros objetos.

Un importante sistema del mundo real que se presta así mismo para el uso de tecnicas de programaci6n orientada a objetos es el "Sistema Experto".

SISTEMAS EXPERTOS BASADOS EN EL CONOCIMIENTO

Antecedentes.

La resolucicin de problemas es una de las constantes que han acompañado al hombre desde sus origenes. Desde estudios realizados con problemas de resolución geométrica, la resolucidn de problemas en las primeras computadoras, problemas en la representacidn de los conocimientos en la memoria de esta; inclusive la simulaci6n de mecanismos generales de resoluci6n de la mente humana para campos muy concretos del conocimiento. El manejo eficaz de los conocimientos dio entonces sus primeros exitos: los sistemas expertos.

I

El precursor de los sistemas expertos actuales es el sistema DENTRAL (Universidad de Standford, 1967), que utilizaba para la representacidn del conocimiento las reglas de produccicSn, y despues se construy6 el sistema experto MYCIN [Shortliffe 19761, de diagnostico que contaba con aproximadamente 400 reglas. Despues se empiezan a construir las primeras computadoras simb6licas DARPA. En la decada de los ochenta, existen dos grandes lineas de investiyaci6n y desarrollo que son:

- Divulgaci6n o popularizaci6n de los sistemas expertos como una metodologia que puede resolver de una forma adecuada múltiples problemas.

- Generalización de los sistemas expertos que permitan ampliar el campo de conocimientos.

Definicibn y características de un Sistema Experto.

Un sistemas experto es un programa que se comporta como un experto humano para algún problema. Este debe ser habil para explicar sus decisiones y subrayar el razonamiento. Frecuentemente un sistema experto debe ser capaz de tratar con informaci6n incierta e incompleta.

La adquisici6n de conocimientos se introduce primero, pues los sistemas expertos actuales en general no son capaces de obtener el conocimiento por si solos mediante la practica.

La fiabilidad de un sistema experto se demuestra por sus explicaciones y por SUS éxitos en la resoluci6n brillante de las tareas que se le encomiendan.

El dominio de conocimientos en un sistema experto tiene por razones físicas una limitaci6n (no solamente por el tamaño de la memoria en la que se almacena, sino t a m b i h por el tiempo para su procesamiento) por lo que un sistema experto es solo experto en un campo muy reducido del saber. En un sistema experto es el mismo conocimiento el que resuelve y el que explica.

En un sistema experto la estrategia de resoluci6n de problemas es realmente el control del sistema, que se denomina "Mdquina de Inferencia If.

Tecnicamente, el conocimiento en un sistema experto tiene que estar en forma de unidades elementales del mismo que puedan relacionarse unas con otras y que le permitan conocer cual de ellas ha actuado, cuando, y por que.

Los sistemas expertos tienen que ser flexibles, es decir poder modificar el conocimiento que tienen almacenado de una forma sencilla y sin que ello afecte al resto del sistema. Esto hace que las funciones de control (mAquina de inferencia) y el conocimiento (base de conocimiento) sean completamente independientes.

Un sistema experto tiene que ser capaz de resolver cualquier problema que se plantee dentro de su campo, y como no puede tener almacenadas todas las soluciones a todos los posibles problemas, un sistema experto es por naturaleza declarativo, es decir, que no es necesario especificar el procedimiento que ha de seguir en cada paso para obtener la solucibn.

Representacibn del Conocimiento.

El proceso de conocer o aprender se basa en la adquisicidn de una imagen o representacidn de la realidad, ya sea un objeto o un proceso que siga dicho objeto.

En la actualidad las formas mas importantes de representacibn del conocimiento son: las reglas de produccidn o reglas ("ru/es"), los marcos o tramas ( "frames "), las redes semsnticas ( "nets "1 y los objetos ( "Objects

La representacidn del conocimiento en forma de reglas de produccidn fue propuesta por Post en 1943. La regla es la forma mas común de representar el conocimiento, debido a su gran sencillez y a ser la formulacidn mas inmediata del principio de causalidad (causa - efecto).

Las redes semsnticas o redes asociativas representan el conocimiento mediante nudos o nodos (elementos del conocimiento o conceptos) y ramas y arcos (relaciones entre los nodos, estas relaciones pueden ser de herencia o de descripcibn). Fueron propuestas por William y Collins en 1968. Su concepcibn se basa en la asociacidn de conocimientos que realiza la memoria humana.

Los marcos fueron propuestos por Marvin L. Minsky [Minsky 19751. Estos combinan las características de las reglas y de redes semanticas, son modulares por naturaleza y admiten la representacidn del conocimiento en forma declarativa o procedimental.

Describe a los marcos como una estructura de datos para representar situaciones estereotipo, unido a cada marco hay varias clases de informacidn acerca de como usar el marco, que situaciones se pueden esperar a que ocurran y que hacer si no suceden. Esta forma de ver el conocimiento al tener una coleccidn de todas las ideas de una manera m6s holgada dirigida hacia un lenguaje iormal para representar conocimiento, considersndolo como una alternativa a redes semanticas o c3lculo de predicados.

Este modelo encapsula en uria sola estructura el conocimiento declarativo y fundamental sobre las cosas. Los marcos esthn formados por un nombre y por una serie de ranuras ("s/ots") o casilleros o campos de informacidn o variables, las cuales pueden guardar otras expresiones ("fi//ers") que pueden ser tambien marcos o simples nombres O identificadores. Una de las ranuras guarda el nombre de la estructura que representa al marco, ademas guardan ciertas relaciones de herencia entre ellas y pueden contener valores, procedimientos para calcular estos valores o reglas para inferirlos.

Un marco permite describir un concepto según un modelo, que visto desde esta perspectiva es como una plantilla. Un marco puede pensarse como una red jerarquizada de nodos y relaciones. Si un marco es referenciado por una ranura de otro marco superior, hereda algunos de los valores de las ranuras de su antecesor, que puede no ser uno sino varios. La idea general es que existen marcos en los niveles superiores que son fijos y representan objetos que son siempre verdad en relacidn a una situaci6n. Los niveles inferiores tienen ranuras que deben contener instancias o datos específicos condicionados por señales o marcas al asignarse a una persona, un objeto de suficiente valor u otro marco de un cierto tipo. Existen tambien valores tomados por omisidn dentro de los

.. ... I. I

marcos, los cuales nos permiten dar ciertos atributos generales a los conceptos.

Un marco puede representar uno de los dos estados siguientes: - Modelo, prototipo, marco general o vacío, que contiene la estructura del marco y los valores por omisi6n.

- Particularizando, instanciado o lleno, en el cual se han sustituido algunos valores por omisi6n, por valores particulares. Estos marcos deben incluir una referencia al modelo del cual procede.

A partir de estos conceptos se diseñaron varios lenguajes para representar el conocimiento, como KRL [Bobrow 19791. El uso de estas ideas se extendid mucho durante la segunda decada de los setenta en aplicaciones como visi6n artificial, manejo de lenguaje natural, etc. Con la aparici6n de estos sistemas expertos se han desarrollado algunos ambientes de trabajo con marcos como KEE [Intellicorp 19841, que es un sistema integral de desarrollo de sistemas expertos.

Un marco pude llenarse por omisidn, es decir, que para aquellos valores que no se definen de forma explícita se toma el valor de la ranura del modelo. Tambikn, se pueden definir los valores de la ranura con relaci6n a otros marcos (P.e. herencia), de reglas o de procedimientos. Existen dos formas de aplicar las reglas, bien cuando el valor de una variable no est6 definido de forma explicita o cuando lo esta.

El uso de marcos est$ bien definido para la representacidn de estereotipos, los cuales se van rellenando con informaci6n que distingue a cada caso. Los marcos pueden emplearse fdcilmente para bases de datos relacionales.

Se ha debatido mucho respecto a la utilidad de los marcos y el poder de expresividad que tienen. Patrick Hayes [Hayes 19791, critic6 duramente este enfoque diciendo que no aportaba nada nuevo a la representacidn del conocimiento ya que lo mismo que se expresa con los marcos se puede expresar utilizando cSlculos de primer orden. Esto, en esencia es verdad ya que en la actualidad se utiliza Prolog para representar marcos dentro de sistemas expertos.

Por otra parte, los conceptos que desembocaron en los lenguajes orientados a objetos tienen sus origenes en Simula 67 que fue un lenguaje pensado para modelar el comportamiento de sistemas reales. El paradigma de la programaci6n orientada a objetos se parece bastante al concepto de marcos expuestos anteriormente. Los objetos, son similares a los marcos con la diferencia de que la relaci6n entre los objetos viene definida por los mensajes.

AI igual que en los marcos se mantienen los conceptos de ranuras y relaciones de herencias, las propiedades describen a los objetos. Se tiene a la clase como elemento donde se encapsulan las características de los datos que se van a procesar y las operaciones que se pueden realizar sobre ellos. Dentro de una clase se tienen una serie de atributos, como las ranuras, que permiten definir como son las entidades y sus operaciones. Aquí los atributos deben ser elementos de otras clases antes definidas, o algunos definidos en bibliotecas como los enteros y las cadenas, y se especifica un lenguaje para declarar las operaciones de los objetos.

Los objetos se agrupan en clases y subclases, y estas pueden relacionarse mediante mensajes y herencias. El mecanismo de herencia es

el medio por el cual la clase adquiere las características de su antecesor y se pueden definir otras mas. Una diferencia esencial con respecto a los marcos es que en ellos se pueden tener varios antecesores y tomar características de todos ellos.

Se utiliza el paso de mensajes, o algún esquema similar, para pedirle a los objetos que nos permitan ver alguno de sus valores actuales o bien que efectúen una operacidn. En la arquitectura de marcos se tiene un manejo externo de la estructura completa para poder llegar a una solucidn del problema. En los sistemas orientados a objetos cada uno realiza una operacidn que ayuda a resolver el problemla, pero los objetos son islas que no saben lo que hacen los demas objetos a excepcidn de su ascendente directo.

El manejo de objetos ofrece ventajas. Permite explotar conocimiento que tenga alguna estructura definida y dan libertad al diseñador para definir las características de operaciones necesarias para resolver los problemas. Dentro de un sistema basado en reglas resulta muy sencillo definir la estrategia necesaria para alcanzar una meta especifica. Tampoco resulta sencillo definir la jerarquía de clases de los objetos involucrados mientras que en los sistemas por reglas no es necesario hacerlo. Esto ha ocasionado que se tomen esquemas intermedios para la definicidn de sistemas expertos. Este esquema intermedio ha demostrado ser bastante Ctil ya que si el enfoque de objetos resulta muy complicado se puede utilizar en el último de los casos como la representacidn por reglas de deduccidn utilizando objetos "planos", sin características ni operaciones. De no encontrarse metodos generales para la extraccidn del conocimiento a partir de objetos es probable que este tipo de esquemas se vuelvan cada vez mas populares ya que permiten conjuntar lo mejor de dos mundos.

Estructura de un Sistema Experto.

Por lo general en un sistema experto se utilizan sistemas de representacidn del conocimiento de tipo declarativo tal que, forman la Base de Conocimientos, el control es independiente y se le llama Motor de Inferencia, y la entrada y salida de datos es la lnterfaz con el Usuario.

Una base de conocimientos abarca el conocimiento específico del dominio de aplicación, incluye cosas como hechos simples acerca del dominio, marcos que describen relaciones y fendmenos en el dominio, y posiblemente tambien contenga metodos, heurísticos e ideas para solucionar problemas en el dominio. La base de conocimientos debe ser, ademas, desde un punto de vista Idgico completa y coherente, y desde el punto de vista funcional debe ser rapida, modular, fhcil de desarrollar y mantener. En una base de conocimientos es importante su capacidad.

La necesidad de guardar información de manera mas eficiente que la tabular ha demostrado que el esquema de base de datos relacionales es útil para las aplicaciones tradicionales de una empresa (contabilidad, ndmina, etc.). Con las aparicidn de aplicaciones donde se manejan datos complejos, se ha intentado definir bases de dat:os capaces de manejar la complejidad de objetos sin hacer demasiado costosa su operación.

Son muchas las características necesarias para que a un sistema de base de datos se le puede considerar orientado a objetos [Atkinson 19901, debido a la complejidad adjunta al manejo de datos. Por esto existen actualmente muchos investigadores que buscan tecnicas que permitan el manejo de grandes volúmenes de objetos en tiempos adecuados.

1

Ej 3r

3r

Por el momento, la solución generalmente aceptada es la de establecer una interfaz entre una base de datos relaciona1 y el usuario de tal forma que la operación sea lo m6s transparente posible.

Existen algunos intentos de manejar via hardware los objetos, pero no hay aún resultados muy satisfactorios.

sistema experto que construye de una forma din6mica las soluciones.

Una mhquina de inferencia debe ser capaz de extraer conclusiones del conocimiento con el que cuenta, asi como explicar el razonamiento que sigue. Así, en un sistema basado en reglas esto es muy sencillo, se utiliza la resolución como metodo para extraer conclusiones y el razonamiento es la concatenaci6n de todas las reglas que se siguieron para llegar a alguna conclusi6n. En la representación por objetos, esto no es muy f6cil.

Una m6quina de inferencia es realmente el sistema de control de un

Si cada objeto representa un pedazo de conocimiento entonces al crear un objeto estaremos obteniendo alguna conclusión. Si modificamos a un objeto, estaremos de alguna manera modificando el conocimiento con el que se cuenta.

Los m6todos que contiene cada objeto son por lo tanto la herramienta para modificar el conocimiento con el que se cuenta. En los lenguajes orientados a objetos existe un procedimiento especial que crea instancias del objeto. En un sistema experto deberemos por tanto pedir que se creen objetos solo cuando son resultado de un razonamiento, o bien, cuando es informaci6n que proporciona el usuario.

Esto hace que la maquina de inferencia de los sistemas orientados a objetos sean realmente poderosa, pueden hacer lo que se les pida que hagan sin estar restringidas por el cSlculo de predicados de primer orden, pero muy difíciles de escribir. No existen lineamientos en los cuales basarse para escribir la m6quina de inferencia. La aproximación por marcos, tiene una estructura externa que permite controlar el razonamiento y buscar las metas de una manera mas tradicional.

Existen varias tecnicas en la programación que nos permiten buscar en espacios de soluciones de manera mas sencilla. Tal es el caso del BackTrack (retroceso) que utiliza Prolog para encontrar soluciones a las metas buscadas. En Prolog el uso de esta tecnica es transparente para el usuario, lo que permite escribir programas claros y sencillos. En la programación orientada a objetos se debe hacer un uso explicito de esta y otras t6cnicas haciendo la escritura de los procedimientos difícil y poco confiable. Estas razones hacen que en la literatura se tenga escrito poco acerca de estas msquinas de inferencia. Desgraciadamente no se dan siquiera ejemplos de como realizar un sistema experto basado en conocimiento orientado a objetos lo que a su vez dificulta que la gente se interese en investigar al respecto. Es claro que en cierto tipo de sistemas expertos, como los de diagnóstico, el manejo de clases permite definir una estructura que casi no necesita código para poder escribir resultados.

Una vez escritos los procedimientos de cada objeto, es necesario encontrar la forma de explicar el razonamiento que se siguió. Esto se pude lograr pasando un parsmetro llamado razones en el que se vaya acumulando el razonamiento efectuado hasta el momento. En un sistema que maneje preguntas ¿por qu6? y ¿cómo? este parsmetro debera poder

I

ser interpretado para satisfacer las preguntas. Si el parametro razones es una lista ligada de los hechos que se han juntado hasta el momento se podrd responder a ¿por que? diciendo "debido al hechol y al hecho2 ... y al hechoN te pregunto Pregunta para decir si X es de tal Clase". De manera similar la respuesta al ¿cómo? ser6 "dados hechol y hecho2 ... y hechoN se ha concluido X de acuerdo al conocimiento que se tiene". Es claro que para lograr explicaciones mas elaboradas es necesario dar mas detalles dentro de razones y se puedan interpretar de manera adecuada.

El uso de incertidumbres se logra tambien por el paso de parametro a funciones. Si ese parsmetro alcanza cierto umbral significar4 que el procedimiento se puede ejecutar o bien que el objeto se puede crear.

Se puede decir entonces que las rutinas en los objetos continuaran con varios parBmetros, conocimiento requerido por el objeto, razones que condujeron allí e incertidumbre del conocimiento proporcionado.

Queda definir la estructura de clases que gobierna el sistema experto. Se debe tomar en cuenta que al definir una clase, al intentar ejecutar un metodo de una clase, esta se intentará ejecutar primero en la clase que define al objeto y de no ser posible se intentar6 ejecutar la de alguno de sus descendientes. Por esto se debe ser cuidadoso con el orden en que se declaran los procedimientos que pertenecen a las distintas clases.

Ante lo expuesto, la regla para la creacidn de msquinas de inferencia en un sistema experto basado en conocimientos es "no hay reglas".

Se puede observar ciertos criterios al escribir las rutinas de los objetos, que representan los engranes de la maquinaria. Se deben tener pardmetros en cada rutina que permitan manejar el flujo de conocimiento, el razonamiento realizado hasta entonces, así como el manejo de incertidumbre. Se debe tener especial atención al definir las clases de objetos y mas importante aún el orden de los procedimientos definidos para ellos. Por lo anterior, es recomendable tener la mayor experiencia posible en lenguajes de programacidn orientados a objetos; a fin de poder escribir de una manera mas eficiente las rutinas necesarias.

Se debe tomar en cuenta que en caso de utilizar a una base de datos como base de conocimiento, es conveniente agrupar a las clases dentro de la base de acuerdo a las necesidades de cómputo que se necesiten utilizar; &to para lograr la mayor eficiencia en la lectura del conocimiento.

La interfaz con el usuario debe permitir el diálogo de forma sencilla entre el usuario y el sistema experto, aproximándose lo más posible al lenguaje natural. Además, provee a l usuario de una comprensión en el proceso de solución de un problema realizado por la m6quina de inferencia; adapta el nivel de las explicaciones y justificaciones al nivel del usuario, de otra forma la relaci6n del usuario con el sistema experto puede ser pesada si da m6s explicaciones de las necesarias o incomprensibles si da menos.

CONCLUSIONES

Combinar programaci6n orientada a objetos con tecnología basada en el conocimiento es una innovaci6n reciente y poderosa. Individualmente, cada una de estas tecnologías tiene muchas ventajas sobre las tecnicas de programacidn tradicional; cuando se usan juntas sus ventajas se realzan aún m%. Aunque, el manejo de objetos utiliza a los marcos para definir a los conceptos involucrados con el sistema y reglas de deducci6n para obtener la estructura generada, y dentro de un sistema basado en reglas resulta muy sencillo el definir la estrategia necesaria para alcanzar una meta específica.

Un ambiente de programacicin orientada a objetos provee soporte para la abstraccidn de datos, encapsulaci6n del conocimiento, polimorfismo, representacidn jerfirquica, clases, instancias, ranuras 6 casilleros, expresiones, mecanismo de herencia, paso de mensajes, y extendibilidad; la programacidn orientada a objetos es útil para el desarrollo en inteligencia artificial, bases de datos,sistemas expertos, simulaci6n, y cualquier otra aplicación donde los elementos "forman clases de objetos de manera natural" .Los marcos como representacidn del conocimiento proveen soporte para definici6n de clases, mecanismo de herencia y paso de mensajes.

Por lo anterior, las características que brinda el paradigma de la programaci6n orientada a objetos para desarrollar un sistema experto por medio de un lenguaje orientado a objetos, permite que el sistema experto mantenga su naturaleza explorativa, creativa, din6mica y experimental.

REFERENCIAS

- [Atkinson 19901. Atkinson, M. 1990. The Object-Oriented Database System Manifesto.

- [Bobrow 19791. Bobrow, D.G. y Wonograd, T. 1979. An Overview of KRL, a Knowledge Representation Languaje. Cognotive Science, Número l.

- [Booch 19911. Booch, Grady. 1991. Object Oriented Design With Applications. The Benjamin/Cummings Publishing Company, Inc.

- [Bourbaki 19911. Bourbaki, Nick. Octubre 1991. Metaobject Protocol Generic Functions and Methods. Al Expert. Volumen 6, Número IO, pp. 1 7-25.

- [Entsminger 19901. Entsminger, Gary. Noviembre 1990. Class Acts in C + +. (Object Oriented Techniques Apply well to Expert Systems Technologyn; Expert's Toolbox). Al Expert. Volumen 5, Número 1 1 , pp. 21 (5).

- [Goldberg 19831. Goldberg, A. y Robson, D. 1983. Smalltalk-80: The Languaje and its Implementation. Addison - Wesley.

- [Goldstein 19901. Goldstein, David G. Febrero 1990. Object-Oriented Programming. (Includes related article on trends in computer-aided software engineering packages). DEC Professional. Volumen 9, Número 2, PP. 46(5).

- [Intellicorp 19841. Intellicorp. 1984. The Knowledge Engineering Environment. Mountain View CA. Intellicorp.

- [Hayes 19791. Hayes, Patrick J. 1979. The logic of Frames. Appeared in Frame Conceptions and Text Understanding. D Metzing, berlin: Walter de Gruyter and Co. pp. 46-61

- [Khoshafian 19911. Khoshafian, Setrag. Octubre 1991, Modeling With Object-Oriented Data Bases. Al Expert. Volumen 6, Número IO, pp. 27-33.

- [Kowalski 19901. Kowalski, Bernadette., Sttip, Lori. Octubre 1990. Object Processing for Knowledge - Based Systems. Al Expert. Volumen 5, Número IO, pp. 34(8).

- [Marcellus 19891. Marcellus, H. Daniel. 1989. Expert Systems Programming in Turbo Prolog. Prentice Hall.

- [Meyer 19881. Meyer, Bertrand. 1988. Object Oriented Software Construction. Prentice Hall.

- [Meyer 19891. Meyer, Bertrand. 1989. EIFFEL: The Languaje. TR-EI- 7 7/RM. Interactive Software Engineering Inc.

- [Meyer 19921. Meyer, Bertrand. 1992. EIFFEL The Languaje. Prentice Hall.

- [Minsky 19751. Minsky, Marvin. 1975. A Framework for Representing Knowledge. Winston 1975, pp. 21 1-277.

- [Minsky 19811. Minsky, Marvin. 1981. A Framework for Representing Knowledge. Haugeland 1981, pp.95-128.

- [Patterson 19901. Patterson, Dan W. 1990. Introduction to Artificial Intelligence and Expert Sistems. Prentice Hall.

- [Ssnchez 19901. S6nchez y BeltrBn, Juan Pablo. 1990. SISTEMAS EXPERTOS. Una Metodologia de Proqramacibn. Macro Bit.

- [Shortliffe 19761. Shortliffe, J.C. 1976. Computer - Based Medical Consultations: MYCIN, New York: Elsevier.

I

I

- [Stroustrup 19861. Stroustrup, B. 1986. The C+ + Programming Languaje. Addison - Wesley.