Ministerio de Educación Superior Universidad Central ...

Ministerio de Educación Superior

Universidad Central “Marta Abreu” de Las Villas

Facultad de Matemática, Física y Computación

Licenciatura en Ciencia de la Computación

UCShell versión 2.1, un ambiente para la construcci ón de Sistemas Expertos

Autora: Isis Nelly Salazar Acosta.

Tutores: Dr. Mateo G. Lezcano Brito.

Lic. Lissett Fundora Fernández.

Santa Clara

2012

Hago constar que el presente trabajo: “UCShell versión 2.1, un ambiente para la

construcción de Sistemas Expertos”, para optar por Título de Licenciada en Ciencia de

la Computación ha sido realizado en la facultad de Matemática, Física y Computación

de la Universidad Central Marta Abreu de Las Villas, como parte de la culminación de

los estudios de la especialidad de Ciencia de la Computación, autorizando a que el

mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de

forma parcial como total y que además no podrá ser presentado en eventos ni

publicado sin la autorización de la Universidad.

______________________________

Firma del Autor

Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según

acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que

debe tener un trabajo de esta envergadura referido a la temática señalada.

__________________________ __________________________

Firma del tutor Firma del jefe del

Laboratorio

Pensamiento

Todo conocimiento comienza con los sentimientos

Leonardo Da Vinci

Dedicatoria

A mi mami, mi papi, cha y a mis dos hermanos

Agradecimientos

A mi mamá y mi papá por ser los motores impulsores de todos mis logros

A cha por lo especial y tolerante que siempre ha sido conmigo

A Migue por estar presente en todo momento y comprenderme, sin él no

hubiera llegado hasta aquí

A Lisy y Sergi por ser los mejores hermanos del mundo

A mis abuelos por el amor y la ternura que siempre me han dado

A todos mis tíos, tías y primos

A Diana, Yanet, Giselle por ser amigas incondicionales y a sus padres por

ayudarnos siempre

A mis tutores Mateo y Lissett por ayudarme, comprenderme y sobre todo

por estar presentes en todo momento

A Dairon y Yamit por ayudarme tanto en la tesis

A Eddy y macho, por su comprensión y ayuda

A todos mis amigos, profesores, compañeros de aula y a todos los que de

una forma u otra han estado presentes

Resumen

En este trabajo se presenta una nueva versión del ambiente integrado para el

desarrollo de sistemas expertos UCShell. La nueva versión (2.1), mantiene las

funcionalidades de la versión anterior y presenta mejoras en la interfaz visual.

La versión 2.1 también agrega dos nuevas funcionalidades: una traza de ejecución con

un mecanismo de visualización de los atributos que intervienen en el proceso de

inferencia, aunque este mecanismo no es totalmente nuevo, presenta una forma

novedosa de visualización; además se incluye un árbol de decisión. Todos estos

mecanismos ayudan a la puesta a punto de las bases de conocimientos y sirven de

apoyo al proceso de enseñanza-aprendizaje de la materia.

UCShell 2.1, también adiciona al sistema una ayuda para que los ingenieros del

conocimiento puedan consultar de forma interactiva.

Abstract

This work presents a new version of the integrated environment for developing expert

systems UCShell. The new version (2.1) maintains the functionality of the previous

version and it has improvements the visual interface.

Version 2.1 also adds new features: an execution trace with a display mechanism of the

attributes that intervene in the inference process, although this mechanism is not

entirety new, has a novel way to display, also includes a decision tree. All these

mechanisms help the development of knowledge bases and facilities to support

teaching-learning of the subject.

UCShell 2.1, also added to the system a help to the knowledge engineers can consult

interactively way.

Tabla de Contenido

1

Introducción ............................................................................................ 1

Capítulo I. Procesos de inferencias ........................................................... 3

I.1 Tipos de inferencia ..................................................................................................................... 3

I.1.1 Inferencia deductiva ............................................................................................................ 3

I.1.2 Inferencia inductiva ............................................................................................................. 3

I.1.3 Inferencia analógica ............................................................................................................ 4

I.1.4 Inferencia difusa .................................................................................................................. 4

I.1.5 Inferencia probabilística ...................................................................................................... 4

I.1.6 Otras inferencias ................................................................................................................. 5

I.2 Formas de representación del conocimiento ............................................................................. 6

I.2.1 Clasificación de las formas de representación del conocimiento ....................................... 6

I.2.1.1 Lógica ........................................................................................................................... 7

I.2.1.2 Redes semánticas ........................................................................................................ 8

I.2.1.3 Marcos o armazones (Frames) .................................................................................. 8

I.2.1.4 Guiones (Scripts) ........................................................................................................ 9

I.2.1.5 Reglas de producción ............................................................................................... 10

I.3 Máquinas de Inferencia ........................................................................................................... 12

I.3.1 Formas de trabajo de las máquinas de inferencia ............................................................ 13

I.3.1.1 Razonamiento hacia delante .................................................................................... 13

I.3.1.2 Razonamiento hacia atrás ........................................................................................ 16

I.3.2 Tipos de máquinas de inferencia ...................................................................................... 18

I.3.2.1 La máquina de inferencia del lenguaje Prolog ....................................................... 18

I.3.2.2 Máquina de Inferencia para Sistemas de Enseñanza (MISE) ................................ 20

I.4 Conclusiones del capítulo ......................................................................................................... 21

Capítulo II. UCShell por dentro ............................................................... 22

II.1 Módulos que componen el sistema ........................................................................................ 22

II.2 Actores y casos de uso ............................................................................................................ 22

II.2.1 Consultar ayuda................................................................................................................ 25

II.2.2 Poner a punto la base de conocimiento .......................................................................... 26

II.2.3 Personalizar la interfaz visual ........................................................................................... 28

II.2.3.1 Número de líneas ..................................................................................................... 28

II.2.3.2 Control de errores ................................................................................................... 29

II.2.4 Añadir nuevas funcionalidades ........................................................................................ 29

II.3 Generalidades internas de UCShell ......................................................................................... 32

II.3.1 Paquete compiler ............................................................................................................. 32

II.3.1.1 Los operadores ........................................................................................................ 32

II.3.1.2 Las acciones ............................................................................................................. 33

Tabla de Contenido

2

II.3.1.3 Las funciones ........................................................................................................... 34

II.3.1.4 Gramática y generación de código ......................................................................... 35

II.3.1.4.1 Análisis Lexicológico (Scanner) .......................................................................... 36

II.3.1.4.2 Análisis sintáctico (Parser) ................................................................................. 37

II.3.1.4.3 Ejemplo para agregar cláusulas al lenguaje de UCShell ................................... 39

II.4 Conclusiones del capítulo ........................................................................................................ 42

Capítulo III. Entorno de programación UCShell ....................................... 43

III.1. Base de Conocimientos ........................................................................................................ 43

III.1.1 Atributos externos........................................................................................................... 44

III.1.2 Atributos preguntables .................................................................................................. 45

III.1.2.1 Definición de ASK ................................................................................................... 45

III.1.2.1.1 Conjunto de selección ....................................................................................... 46

III.1.2.1.2 Dominio de definición ...................................................................................... 47

III.1.2.1.3 Ejemplos de declaraciones de ASKS ................................................................. 48

III.1.3 Definición del conocimiento. Bloque de reglas .............................................................. 50

III.1.3.1 Definición de reglas ............................................................................................... 50

III.1.3.1.1 Definición de la parte <condición> .................................................................. 51

III.1.3.1.2 Definición de la parte <conclusión> ................................................................. 53

III.1.4 Bloque de acciones .......................................................................................................... 55

III.1.4.1 Cláusula DISPLAY ................................................................................................... 56

III.1.4.2 Cláusula ASSUME ................................................................................................... 56

III.1.4.3 Cláusula FIND y FINDFORWARD .......................................................................... 57

III.1.4.4 Cláusula FINDALL .................................................................................................. 58

III.1.4.5 Cláusula REPEAT .................................................................................................... 59

III.1.4.6 Cláusula RESET....................................................................................................... 59

III.1.4.7 Cláusula SAVEFACT................................................................................................ 60

III.1.4.8 Cláusula CHAIN ...................................................................................................... 61

III.1.5 Otras elementos de una base de conocimiento ............................................................. 62

III.1.5.1 Definición de imagen ............................................................................................. 62

III.1.5.2 Definición de explicación ....................................................................................... 63

III.1.5.3 Definición de elemento visible .............................................................................. 63

III.1.5.4 Definición de literal ................................................................................................ 64

III.1.5.5 Definición de Expresión ......................................................................................... 64

III.1.5.6 Definición de Funciones ........................................................................................ 65

III.2 Conclusiones del capítulo ....................................................................................................... 67

Conclusiones generales .......................................................................... 68

Recomendaciones ................................................................................... 69

Tabla de Contenido

3

Bibliografía ............................................................................................ 70

Introducción

1

Introducción

Los sistemas basados en el conocimiento son sistemas computarizados que usan

conocimiento sobre un dominio para arribar a la solución de un problema. Esta solución

es, esencialmente, la misma que la obtenida por una persona experimentada en esa

área del saber cuando se enfrenta al mismo problema. Elucidar y reproducir la

experticia de personas altamente especializadas es la tarea central en la construcción

de sistemas basados en el conocimiento.

El grupo de Informática Educativa de la UCLV ha creado diferentes herramientas para

construir sistemas basados en el conocimiento, en particular se han desarrollado

diversos software para la creación de sistemas expertos. Una de esas herramientas es

un ambiente integrado para el desarrollo y puesta a punto de sistemas expertos que se

denominan UCShell.

Hasta la fecha existen tres versiones de UCShell:

� La primera, implementada en el lenguaje Borland Pascal fue concebida para el

Sistema Operativo MS-DOS y se caracterizaba por usar una dirección de

búsqueda dirigida por objetivos con el método primero en profundidad.

� La segunda versión, denominada WUCShell, se implementó sobre el sistema

operativo Windows en el lenguaje Object Pascal y seguía la misma dirección y

método de búsqueda de la anterior aunque el compilador se instrumentó de

forma manual, a diferencia de la primera en la que se usó el generador de parser

YACC.

� La tercera versión retoma el nombre original, UCShell, para significar el hecho

de no estar sujeta a ningún sistema operativo. Su desarrollo se hizo sobre el

lenguaje Java e incorpora la búsqueda dirigida por datos a la vez que mantiene

la dirigida por objetivos.

La versión anterior del sistema dio un salto en calidad pero sus principales problema

son: no constar con mecanismos que ayuden a la puesta a punto de las bases de

conocimiento y no brindar apoyo a los procesos de aprendizaje. En este último aspecto

debe señalarse que el sistema es parte de la producción del Laboratorio de Informática

Introducción

2

Educativa y de ahí que la herramienta, a la vez que cumple un rol asociado a la

producción, deba ayudar al proceso de enseñanza-aprendizaje en alguna medida.

Objetivo general

� Obtener una nueva versión del sistema UCShell que resuelva las falencias

detectadas en las anteriores.

Objetivos Específicos

� Mejorar la interfaz visual.

� Incorporar algoritmos de depuración de código.

� Incorporar herramientas que auxilien el proceso de enseñanza – aprendizaje.

Preguntas de investigación

1. ¿Es posible mejorar la interfaz de usuario del sistema UCShell de forma que sea

más fácil usarla?

2. ¿La ejecución paso a paso del sistema ayudará a la puesta a punto de los

sistemas expertos y a comprender los mecanismos internos de la máquina de

inferencia?

Justificación de la investigación

Aunque la última versión de UCShell está totalmente funcional se debe perfeccionar

para introducir mejoras que permitan poder usarla de forma más fácil, entre ellas cabe

citar: hacer la interfaz más amigable, incorporar herramientas de depuración, incluir

otros formatos de visualización, etc.

Hipótesis

� Las mejoras introducidas al sistema facilitan la puesta a punto de las bases de

conocimientos.

� El módulo árbol de decisión ayuda a comprender el funcionamiento de los

sistemas expertos.

Capitulo l. Procesos de inferencia

3

Capítulo I. Procesos de inferencias

Este capítulo tiene como objetivo ilustrar qué son los procesos de inferencia,

destacando su importancia y utilización en diferentes esferas de la sociedad. Se

describen algunos conceptos esenciales, que son de gran importancia en el ámbito

computacional en general y en la Inteligencia Artificial (IA) en particular.

I.1 Tipos de inferencia

Dado que la palabra inferencia significa derivar nuevas sentencias de las antiguas, los

acápites I.1.x presentan varios tipos que son importantes cuando se estudia IA.

I.1.1 Inferencia deductiva

La inferencia deductiva, conocida también como razonamiento deductivo, es un

proceso en el cual las premisas generales se usan para obtener una inferencia

específica. El razonamiento va desde un principio general a una conclusión específica.

La conclusión debe ser válida si las premisas son verdaderas, desarrollando nuevos

conocimientos a partir del conocimiento previo (Césari, 1990).

I.1.2 Inferencia inductiva

Inferencia inductiva o razonamiento inductivo utiliza una cantidad establecida de

hechos o premisas para demostrar alguna conclusión general, la conclusión puede

cambiar si se descubren hechos nuevos. Siempre existe una incertidumbre a menos

que se incluyan todos lo hechos en las premisas, aspecto que raramente se tiene, lo

que da por resultado que en el proceso de inferencia inductiva siempre se tenga alguna

medida de incertidumbre (Turban, 1995).

Tanto el razonamiento inductivo como el deductivo se usan en la lógica, en los

sistemas basados en reglas y en los sistemas basados en marcos.


4

I.1.3 Inferencia analógica

Este tipo de inferencia es natural a los humanos pero difícil de lograr mecánicamente,

asume que cuando se hace una pregunta, la respuesta se puede obtener por analogía.

El razonamiento analógico según Tuthill (Tuthill, 1990), es un tipo de verbalización de

un proceso de aprendizaje interno.

Es un proceso que necesita la habilidad de reconocer experiencias previas, para

aplicarlas al caso que se está resolviendo buscando semejanzas entre la experiencia

vivida y el caso que se trata. Debido a que el razonamiento analógico relaciona el

presente con el pasado, en un esfuerzo por relacionar objetos o conceptos no

relacionados, el razonamiento analógico es similar al razonamiento común. El uso de

este acercamiento no se ha explotado todavía en el campo de la IA (Turban, 1995).

I.1.4 Inferencia difusa

La inferencia difusa describe todos los casos multivaluados con exactitud y precisión.

Los sistemas de inferencia difusa pueden tomar valores certeros o difusos,

considerando a los valores certeros como singlentons (impulsos), las salidas son

variables difusas: Para el control de estas variables, se requieren valores certeros por

lo que se hace necesario defusificar.

Estructura de un sistema de inferencia difuso.

1. Base de reglas (reglas difusas).

2. Diccionario: Una base de datos de las funciones de membrecía.

3. Mecanismo de razonamiento.

I.1.5 Inferencia probabilística

Una inducción permite establecer una verdad con mayor índice de probabilidad que las

demás.


5

Las redes Bayesianas son modelos gráficos probabilísticos utilizados en la toma de

decisiones. Una red Bayesiana representa una función de distribución conjunta sobre

un conjunto finito de variables.

Una red Bayesiana proporciona un sistema de inferencia, donde una vez encontradas

nuevas evidencias sobre el estado de ciertos nodos, se modifican sus tablas de

probabilidad; y a su vez, las nuevas probabilidades se propagan al resto de los nodos.

La propagación de probabilidades se conoce como inferencia probabilística, es decir, la

probabilidad de algunas variables, puede ser calculada dadas evidencias en otras

variables. Las probabilidades que se tengan antes de introducir evidencias se conocen

como probabilidades a priori; una vez que se han introducido evidencias, las nuevas

evidencias propagadas se llaman probabilidades a posteriori (Huang and Darwiche,

1996).

I.1.6 Otras inferencias

Existen otras formas de inferencias entre las que cabe mencionar las siguientes:

� La inferencia numérica procedural que usa modelos matemáticos o simulaciones

en la solución de problemas, por ejemplo el razonamiento basado en modelos.

� La inferencia formal que involucra la manipulación sintáctica de las estructuras

de datos para deducir nuevos hechos, siguiendo reglas de inferencia escritas

con anterioridad.

� En la inferencia por lógica clásica, solo se admiten dos valores: verdadero o

falso. En las lógicas clásicas cada sentencia debe ser o bien verdadera o bien

falsa, en cada mundo posible no puede ser lo uno y lo otro a la vez (Russell and

Norvig, 1995).

� Inferencia multivaluada. Una inferencia de este estilo da múltiples valores como

posibles resultados, la inferencia trivaluada es un caso particular de este tipo de

inferencia.


6

I.2 Formas de representación del conocimiento

Desde los primeros intentos de escritura de programas que permitían interfaces en

lenguaje natural, surgió la necesidad de la existencia de alguna forma para representar

colecciones de hechos estructurados de forma compleja.

La notación que se usa para representar el conocimiento se conoce genéricamente

como Forma de Representación del Conocimiento (FRC).

Ante un problema de dominio específico se tiene que realizar una selección de la FRC

más adecuada para dicho problema, ya que no existe una capaz de usarse en

cualquier tipo de aplicación (Bello, 2000).

Para realizar esta selección es necesario tener en cuenta los siguientes criterios:

� Se deben describir los hechos importantes acerca del dominio del problema y

exponer las restricciones con naturalidad.

� El conocimiento almacenado debe ser completo y conciso.

� Deben suprimirse detalles, manteniendo solo los hechos necesarios.

� El conocimiento almacenado se debe comprender con facilidad.

� Se debe poder almacenar y recuperar información rápidamente.

� El conocimiento debe ser manipulable por una computadora.

� Se debe aceptar conocimiento empírico, teórico o heurístico, y combinar el

conocimiento declarativo con el procedural.

I.2.1 Clasificación de las formas de representación del conocimiento

Las FRC pueden clasificarse en:

Declarativas: donde la mayor parte del conocimiento se representa como una colección

estática de hechos, junto con un pequeño conjunto de procedimientos generales para

manipularlos. Se pueden citar los siguientes ejemplos:

� Lógica (proposicional, cálculo de predicados, no monotónica, etc.).


7

� Redes semánticas.

� Marcos o armazones.

� Guiones.

Procedurales: Estos modelos y sus esquemas de representación almacenan

conocimiento en la forma de cómo hacer las cosas. Pueden estar caracterizados por

gramáticas formales, usualmente implantadas por sistemas o lenguajes

procedimentales y sistemas basados en reglas, por ejemplo:

� Reglas de producción.

� Strips.

I.2.1.1 Lógica

La FRC más antigua es la lógica. El formalismo lógico es muy atractivo, ofrece un

mecanismo potente para derivar nuevos conocimientos a partir de hechos conocidos: la

deducción matemática.

La lógica proposicional, el cálculo de predicados y la lógica no monotónica son formas

de representar la clase del conocimiento acerca del mundo real, que puede necesitar

un sistema de IA.

Existen diversas clasificaciones de la lógica que se basan en aspectos disímiles y se

apoyan en mecanismos diversos: lógica de clases múltiples, lógica de situación, lógica

de valores múltiples, lógica borrosa, lógica modal, lógica temporal, lógica

epistemológica, lógica de orden superior, lógica intencional. La mayoría de estas

lógicas se formularon para superar ciertas deficiencias de la lógica clásica, un análisis

detallado de estos aspectos está fuera del alcance del presente trabajo y para ello se

pueden usar diversas fuentes bibliográficas (Frost, 1991).

Los métodos para representar el conocimiento usando los formalismos lógicos, son

muy útiles para representar hechos simples. Su principal ventaja es que pueden

combinarse con mecanismos de inferencia potentes y sencillos, tales como la

deducción y resolución, que facilitan el razonamiento con los hechos. Pero los objetos


8

de esas representaciones son tan simples que no pueden describir con facilidad la

mayor parte de la compleja estructura del mundo. En la resolución de problemas cuya

naturaleza es deductiva, es aconsejable usar la lógica simbólica. Sin embargo, la

mayoría de los problemas reales son de naturaleza inductiva (García and Lemagne,

1990).

I.2.1.2 Redes semánticas

Las redes semánticas fueron introducidas por Ross Quillian (1968) en su tesis de

doctorado. Se diseñaron originalmente como una forma de representar los significados

de las palabras en idioma inglés (Quillan, 1968).

En sus inicios las redes semánticas se utilizaron en sistemas de traducción automática,

además, en la programación y aprendizaje automáticos, para sintetizar respuestas, en

la comprensión del lenguaje natural, entre otras (Hill, 1984).

Las relaciones establecidas entre los conceptos de un tipo dado son heredadas a

través de la jerarquía por todos los subtipos (Bello, 2000).

La representación del conocimiento usando redes semánticas presenta el problema de

cómo manejar la cuantificación. Una forma de resolverlo es particionar la red semántica

en espacios, cada uno de los cuales se corresponde con el ambiente de una o varias

variables.

Las redes semánticas han sido propuestas como un mecanismo para simular algunas

de las propiedades asociativas de la memoria humana.

I.2.1.3 Marcos o armazones (Frames)

La representación del conocimiento mediante marcos fue propuesta por Marvin Minsky

en 1974 en su artículo “A framework for representing knowledge” (Minsky and Issue,

1974).

Un marco es una estructura de datos que contiene información acerca de un objeto. La

información almacenada en el marco se distribuye en diferentes campos llamados


9

ranuras o aspectos y cada una de ellas contiene la información sobre un atributo del

objeto o un apuntador a otro marco (Hill, 1984).

Los marcos son útiles para:

� Inferir hechos no observados sobre situaciones nuevas.

� Verificación de inconsistencias y omisiones en un cuerpo de conocimiento.

� Realizar inferencias por analogía.

Tienen la desventaja de que no existe una teoría formal de marcos, lo que trae como

consecuencia que los mecanismos para la inferencia y verificación de consistencia no

se basan en una semántica bien definida.

Esta FRC ha sido utilizada en tareas de predicción y monitoreo, ha dado buenos

resultados en problemas de tipo constructivo, tales como el diseño. Los sistemas de

marcos se han utilizado como componentes de sistemas de reconocimiento de

patrones.

I.2.1.4 Guiones (Scripts)

Los guiones fueron desarrollados por Schank y Abelson en 1977 (Schank and Abelson,

1977).

Un guión es una FRC similar a un marco, pero en lugar de describir un objeto, el guión

describe una secuencia de eventos o acontecimientos que ocurren comúnmente.

Los guiones están compuestos por un conjunto de ranuras que contienen toda la

información necesaria sobre las acciones que describen.

Un guión puede activarse emparejando su nombre, sus condiciones, objetos, sitio o

alguna combinación de ellos. A los guiones que sirven para invocar a otros guiones se

les llama guiones iniciadores. Existen cuatro tipos de guiones iniciadores:


10

i. Invocación por precondición: cuando se menciona una de sus condiciones.

ii. Invocación como instrumento: cuando puede ser interpretado como instrumento

para invocar a otros guiones.

iii. Invocación como local: cuando se menciona el sitio donde ocurren sus

acontecimientos.

iv. Invocación directa: se hace una alusión directa a un guión concreto. Es la

primera que se chequea si ocurre.

Al implementar las invocaciones es útil exigir que una situación concreta tenga, al

menos, dos guiones iniciadores, con esto se evitan invocaciones innecesarias.

Ellos son útiles para:

� Predecir acontecimientos que no se han observado explícitamente.

� Proporcionar una forma de construir una interpretación única y coherente a partir

de una colección de observaciones.

� Centrar la atención sobre acontecimientos inusuales.

Esta FRC ha sido utilizada en aplicaciones para el procesamiento del lenguaje natural y

en la representación, procesamiento y generación de historietas.

I.2.1.5 Reglas de producción

Las reglas de producción fueron introducidas en 1943 por Post (Post, 1943).

Una regla de producción está formada por un par ordenado (A, B), representado en el

cálculo proposicional como A ⇒ B, donde A representa el antecedente y B el

consecuente de la regla.

Una regla de producción se interpreta de la siguiente manera: si se satisface el

antecedente, entonces se cumple el consecuente. Esta manera de interpretar una regla

permite considerarla como una unidad relativamente independiente de conocimiento.


11

Las reglas de producción pueden adoptar varias formas:

i. Si condición P entonces conclusión C.

ii. Si situación S entonces acción A.

iii. Si condición C1 entonces no condición C2.

Los antecedentes de las reglas, independientemente de la forma que estas adopten,

pueden ser simples o compuestos.

Para la manipulación del conocimiento representado en reglas de producción se usan

los llamados Sistemas de Producción (SP).

Un SP consta de tres componentes básicos:

i. Base de datos (BD): Se utiliza como memoria de trabajo.

ii. Conjunto de reglas: Operan sobre la memoria de trabajo

iii. Intérprete: Lleva a cabo el proceso de inferencia.

Este último comprende las siguientes tareas:

i. Seleccionar las reglas a aplicar.

ii. Verificar cuáles reglas se satisfacen.

iii. Ejecutar las acciones especificadas por estas reglas.

Según Mateo (Lezcano, 2000) existen básicamente dos técnicas para implementar los

mecanismos de inferencia: dirigidos a objetivos (backward chaining) y razonamiento

orientado a datos (forward chaining).

En un esquema clásico se recorren todas las reglas buscando una para aplicarla.

Cuando se encuentra tal regla se aplica, lo cual en muchos casos provoca cambios en

la BD. El conjunto de reglas se sigue recorriendo hasta que se alcanza el objetivo, o no

es posible invocar más reglas, constituyendo esa la condición de terminación.


12

Una dificultad con esta FRC es: que si bien a medida que crece la cantidad de reglas

crece el conocimiento del sistema, también se hace más difícil la búsqueda. Las reglas

de producción son la FRC más popular, para ellas se han desarrollado muchas

herramientas comerciales.

Como FRC, las reglas de producción han sido utilizadas exitosamente en tareas como:

el diagnóstico médico, la planificación, el diseño, la solución de problemas de

pronóstico, configuración de computadoras, entre otras.

Sin embargo, las reglas de producción son inadecuadas para la definición de términos,

la descripción de objetos, así como para hacer relaciones estáticas entre ellos.

I.3 Máquinas de Inferencia

Una máquina de inferencia, también denominada “shell”, es la herramienta encargada

de obtener nuevos conocimientos a partir de un conjunto inicial de hechos y reglas que

definen el conocimiento establecido (Gálvez, 1998).

Las máquinas de inferencia implementan métodos de solución de problemas que

manipulan el conocimiento almacenado en la base de conocimiento e informaciones

sobre estados iniciales, estados actuales de la solución del problema, entre otras, las

cuales se procesan dinámicamente en una estructura que se le llama base de batos o

memoria de trabajo (Bello, 2000).

Todos los medios necesarios para manipular el conocimiento y usarlo con efectividad

forman la máquina de inferencia, las cuales están compuestas por:

� Método de solución de problemas.

� Principios de control “ad hoc”.

� Mecanismo de explicación.

� Técnicas de procesamiento de la información con incertidumbre.


13

I.3.1 Formas de trabajo de las máquinas de inferencia

La máquina de inferencia, es el módulo de un sistema experto encargado de encontrar

la solución a un problema dado, a partir del conocimiento almacenado en la base de

conocimientos y los datos iniciales del problema. La implementación de esta depende

de la forma de representación elegida para almacenar el conocimiento (lógica, redes

semánticas, guiones, reglas de producción, etc.), del método de solución de problemas

(primero en profundidad, primero a lo ancho, búsqueda ordenada, etc.) y de la dirección

de búsqueda seleccionada (Bello et al., 2002):

I.3.1.1 Razonamiento hacia delante

La búsqueda con encadenamiento hacia delante o proceso de inferencia dirigida por

datos (forward chaining) consiste en realizar la búsqueda desde el estado inicial a un

estado final, o sea, de los hechos conocidos (literales positivos) de la base de

conocimiento a la conclusión. Si todas las premisas de una implicación se conocen,

entonces dicha conclusión se añade al conjunto de hechos conocidos (Russell and

Norvig, 1995).

En la búsqueda dirigida por datos se comienza a construir el árbol situando como raíz

el estado inicial. El siguiente nivel del árbol se genera encontrando todas las reglas

cuyas partes izquierdas concuerden con el nodo raíz y usando sus partes derechas

para crear los nuevos estados. De esta manera el proceso continúa hasta generar un

estado que satisfaga o no las condiciones.

La figura I.1 muestra el algoritmo que sigue la búsqueda con razonamiento hacia

delante. En el método se han usado algunas funciones que se describen en la tabla I.1.

La búsqueda con encadenamiento hacia delante tiene las siguientes ventajas:

� Simplicidad

� Puede utilizarse para proporcionar todas las soluciones a un problema.

� Presenta un buen enfoque en la resolución de problemas de planificación,

monitorización e interpretación.


14

Esta búsqueda, a pesar de sus ventajas, tiende a demorarse mucho y a probar hechos

que no interesan para el objetivo que se persigue.

Función Objetivo

NO-USADA (i) Responde verdadero si la i-ésima regla no se ha usado,

falso en caso contrario.

EXTRAE-ATRIBUTOS (EXP, A) Crea la lista A con los atributos que aparecen como

operandos en la expresión EXP.

TODOS-ATRIB-VALOR (A) Responde verdadero si todos los atributos de la lista A

tienen valor, falso en caso contrario.

EVALUA (EXP) Evalúa la expresión EXP.

EXTRAE-ATRIB(EXP, C) Coloca en C el atributo que se evalúa en la expresión

EXP.

PONE-VALOR-EN-MT (V, C) Actualiza la memoria de trabajo asignando el valor V al

atributo C.

MARCA-REGLA (i) Marca la i-ésima regla como usada.

DET-ATRIB (i, C) Determina el atributo a evaluar en la i-ésima regla y lo

coloca en C.

BC (i, 1) Indica la conclusión de la i-ésima regla.

BC (i, 2) Es la condición de la i-ésima regla.

NR La variable NR indica la cantidad de reglas del sistema

de producción.

Tabla I.1. Funciones auxiliares para el algoritmo d e la figura I.1


15

Procedure Forward

{

LEER-VALORES-INICIALES()

FIN1 := 0 while not FIN1

{

FIN2 := 0

i := 1

while not FIN2

{

if NO-USADA(i)

then {

EXTRAE-ATRIB(BC(i, 1) + BC(i, 2), A)

if TODOS-ATRIB-VALOR(A)

then

{

if EVALUA(BC(i,2))

then

{

DET-ATRIB (i, C)

PONE-VALOR-EN-MT(EVALUA(BC (i,1) ), C)

MARCA-REGLA (i)

FIN2 := 1

}

}

}

if not FIN2 then

{

i := i+1

if i > NR

then

{

FIN1 := 1

FIN2 := 1 }

}

}

}

}

Figura I.1. Algoritmo general para la búsqueda diri gida por datos


16

I.3.1.2 Razonamiento hacia atrás

La búsqueda con encadenamiento hacia atrás o proceso de inferencia dirigida por

objetivos (backward chaining) se realiza comenzando desde el estado objetivo y

terminando en un estado inicial, o sea, el razonamiento se realiza desde una hipótesis

(objetivo) hasta las evidencias primarias necesarias para refutar o confirmar dicha

hipótesis.

En el encadenamiento hacia atrás se comienza a construir el árbol situando como raíz

al estado objetivo. El siguiente nivel del árbol se genera encontrando todas las reglas

cuyas partes derechas concuerden con el nodo raíz y usando las partes izquierdas

para crear los nuevos estados. Este proceso continúa hasta generar un estado que

concuerde con el estado inicial (Bello, 2000).

Las estructuras de datos y funciones de la búsqueda con encadenamiento hacia

delante son útiles para este tipo de búsqueda, además son necesarias las siguientes:

LEE-OBJ(C): Procedimiento que lee el nombre del atributo objetivo y lo coloca en C.

NOT-VALOR(C): Función que responde verdadero si el atributo C no tiene valor, falso

en caso contrario.

INSERTA-EN-PILA(C): Procedimiento que inserta el atributo C en la pila.

LEER-VALOR-A(C, V): Procedimiento que lee el valor V para el atributo C.

PILA: es la matriz en la cual se colocan el objetivo inicial y los subobjetivos que se

generan durante la búsqueda.

La variable TOP indica la posición del último atributo insertado en la pila.

La figura I.2 muestra el algoritmo general que sigue la dirección de búsqueda dirigida

por datos.


17

Procedure Backward

{

LEE-OBJ(C)

INSERTA-EN-PILA(C)

while (TOP != 0)

{i := 1

FIN := 0

while not FIN

{ DET-ATRIB(i, C)

if C = PILA(TOP)

then

{ EXTRAE-ATRIB(BC (i, 1) + BC (i, 2), A)

if TODOS-ATRIB-VALOR(A)

then

{if EVALUA(BC (i,2))

then

{ PONE-VALOR-EN-MT(EVALUA (BC (i,1) ), C) FIN := 1

}

}

else

{for i = 1 to N do

if NOT-VALOR (A (i) )

then

{ INSERTA-EN-PILA (A (i))

FIN := 1 }

}

}

else

{i := i+1

if not FIN

then

{if i > NR then

{ LEER-VALOR-A(C,V)

PONER-VALOR-EN-MT (V,C)

FIN := 1

}

}

}

}

TOP := TOP – 1

}

}

Figura I.2. Algoritmo general para la búsqueda diri gida por objetivos


18

Entre las ventajas de esta dirección de búsqueda se pueden enumerar las siguientes:

� No se utilizan reglas que no estén relacionadas con el problema que se está

resolviendo.

� Son adecuados para resolver problemas que comienzan con el planteamiento de

la hipótesis.

� Presenta un buen enfoque en las tareas de diagnóstico y en el depurado de

errores.

La búsqueda dirigida por objetivos puede tardar mucho cuando trata de probar

objetivos que no se pueden detectar.

En la búsqueda bidireccional se realizan dos búsquedas (generalmente primero a lo

ancho), una desde el estado inicial con encadenamiento hacia adelante y otra desde el

estado objetivo con encadenamiento hacia atrás, hasta que se encuentren en un

estado común en la frontera de ambas búsquedas. Entonces el camino desde el estado

inicial se concatena con el inverso del camino desde el estado objetivo, para formar el

camino solución completo (Bello et al., 1992).

Para poder realizar una búsqueda bidireccional se requiere conocer un estado objetivo

en lugar de un criterio objetivo y que los operadores del problema sean invertibles.

I.3.2 Tipos de máquinas de inferencia

Existen diversos tipos de máquinas de inferencia, unas más populares que otras,

algunas más versátiles y otras más fáciles de usar. En los dos epígrafes siguientes se

hace un resumen de dos de ellas, la primera es la máquina de inferencia interna del

lenguaje Prolog y la segunda es un producto del Grupo de Informática Educativa.

I.3.2.1 La máquina de inferencia del lenguaje Prolog

Dentro de los lenguajes orientados a la lógica tiene gran importancia el Prolog. La

máquina de inferencia del lenguaje se caracteriza por tener una dirección de búsqueda

dirigida por objetivos y actúa de forma distinta a las máquinas tradicionales ante el fallo


19

de alguna de las premisas de la regla que se esté usando, según Lezcano pueden

lograrse sistemas expertos que usen búsqueda dirigida por datos en Prolog, aunque los

métodos propuestos pueden resultar poco natural y resulta difícil la puesta a punto

cuando se detecten errores de ejecución (Lezcano, 2000).

El método de solución de problemas que utiliza Prolog como máquina de inferencia es

la búsqueda primero en profundidad (depth - first), que procede generando

primeramente un sucesor del nodo raíz y luego un sucesor de este, y continúa

extendiendo el mismo camino hasta que termina o se realiza un corte a alguna

profundidad; si no se ha alcanzado el objetivo se realiza un retroceso al nivel anterior

para generar otro camino.

La ventaja de utilizar este método de solución de problemas está en la eficiencia que se

alcanza en el uso de la memoria. Como sólo se necesita almacenar el camino actual y

la longitud máxima, d, de los nodos, la complejidad del espacio es O(d). En la práctica

la búsqueda por este método se limita por el tiempo, no por el espacio.

La desventaja de este método de búsqueda es que requiere que se defina un corte a

una profundidad arbitraria. Sin la existencia de este corte un camino podría ser infinito o

caer en un lazo infinito.

Las ventajas que brinda Prolog como máquina de inferencia sobre otras herramientas

desarrolladas con ese propósito según Lezcano (Lezcano, 2000) son:

� Prolog ofrece un poderoso mecanismo de inferencia, unido a una gran facilidad

en la creación de interfaces con los usuarios.

� Prolog brinda interfaces cómodas con lenguajes populares tales como Pascal, C

y Ensamblador.

� Las aplicaciones Prolog son compiladas, lo que hace que el código de sus bases

de conocimiento esté oculto a curiosos que le pueden ocasionar daños y mal

funcionamiento al sistema.


20

� En cualquier máquina de inferencia no se tiene mucho control sobre ella y

muchas veces se siente esa necesidad, en Prolog los mecanismos de cortes,

tijeras y repeat... fail hacen fácil controlarla.

� Prolog no posee un mecanismo propio para el cálculo de la certidumbre, pero

esto no es una desventaja si se toman en cuenta diversas facilidades para

cualquier programador y que permiten escoger la forma de cálculo que se desee.

I.3.2.2 Máquina de Inferencia para Sistemas de Enseñanza (MISE)

La Máquina de Inferencia para Sistemas de Enseñanza (MISE), controla la

manipulación de preguntas y respuestas y usa como FRC frames que contienen reglas

de producción.

La primera versión de MISE se diseñó e implementó para el sistema operativo MS-DOS

y se distribuyó junto a un conjunto de programas utilitarios como son: editores de

textos, compilador de bases de conocimiento, bibliotecarios de preguntas y respuestas,

entre otros. Algunos de los sistemas elaborados con MISE son:

� EICOF: Entrenador inteligente para el análisis del comportamiento de una

función relativo a su continuidad,

� GALILEI: Entrenador que aborda una temática de la Física: dinámica de la

partícula.

� INTERFER: Entrenador que le permite a un estudiante profundizar en la rama de

la óptica, en específico la interferencia luminosa.

� Sistema para la enseñanza de la Electrostática.

� Entrenadores para la enseñanza de la Electrónica (Duarte, 1994).

� Entrenadores para la enseñanza de la Matemática Numérica.

Una segunda versión se hizo sobre el SO WINDOWS y la conforman dos módulos:

WINMISE-P es el módulo para que el profesor haga las bases de conocimiento y

WINMISE-E que está destinada a los estudiantes.


21

En el diseño e implementación de esta herramienta se respetó la sintaxis de las bases

de conocimiento de los sistemas ya existentes y solamente se eliminaron comandos y

funciones que la experiencia demostró que no son necesarias.

Desde el punto de vista estructural, cada base de conocimiento es un conjunto de

armaduras, que incluyen un cierto número de ranuras (slots), con ayuda de las cuales

se pueden expresar conceptos, reglas para su evaluación y listas de acciones a realizar

previa o posteriormente a dicha evaluación.

Cuando la máquina de inferencia comienza a trabajar, crea una lista de nodos que se

corresponden con los frames. El proceso de búsqueda de una solución comienza por

fijar un apuntador al frame que contiene la información sobre el objetivo (goal) de la

inferencia, después se van valorizando todos los frames que aparezcan mencionados

en sus reglas o en las de sus descendientes. Para cada concepto se parte de la

primera regla y a medida que estas fallen se irán desactivando hasta encontrar una

regla satisfactoria o hasta agotar todas las reglas (caso crítico). Cada vez que un frame

toma valor se retrocede a aquel que indujo dicha evaluación. El proceso de inferencia

termina una vez que se logra valorizar al frame que representa el objetivo de la base.

I.4 Conclusiones del capítulo

El estudio realizado en el presente capítulo, acerca de los métodos de inferencia,

sienta las bases para poder comparar esos mecanismos con los de la versión anterior

del sistema UCShell, que se discute en el capítulo II.

Las máquinas de inferencia MISE y UCShell versión 2, así como la que posee el

lenguaje Prolog brindan algunos mecanismos que pudieran adoptarse en la nueva

versión de UCShell o que pueden valorarse para futuras ampliaciones del sistema.

Capitulo ll. UCShell por dentro

22

Capítulo II. UCShell por dentro

En este capítulo se describe el código interno del sistema UCShell versión 2.1. Se

detallan los mecanismos heredados de la versión 2.0 y los introducidos en la versión

actual. El capítulo se traza el objetivo de ayudar al mantenimiento del sistema o a la

realización de nuevas versiones.

II.1 Módulos que componen el sistema

UCShell 2.1 es en realidad un sistema constituido por varios subsistemas. Las

funcionalidades de cada una de sus partes están íntimamente relacionadas, pero

pueden usarse de forma independiente. Los componentes que ostentan ese tipo de

relación son los siguientes:

� UCShell Compiler 2.0: Es un compilador de bases de conocimiento que genera

una forma interna que es la entrada de la máquina de inferencia. Para

interactuar con el usuario cuenta con una sencilla interfaz visual.

� UCShell Symbolic Compiler 2.0: Es una versión del compilador capaz de generar

bases de conocimiento objetos que incluyen información simbólica y sirven de

entrada a la máquina de inferencia TeachShell (Morales, 2011). El análisis de

errores que realiza es mucho menos profundo que el de UCShell Compiler 2.0 y

además no reconoce los comentarios.

� UCShell Library 2.0: Es una biblioteca que contiene los mecanismos de

compilación de UCShell 2.0 y de UCShell Symbolic Compiler 2.0, además tiene

incluida una máquina de inferencia. No cuenta con interfaz visual ya que fue

diseñada para que otros productos hiciesen uso de los mecanismos que tiene

incorporada y definieran su propia interfaz visual.

II.2 Actores y casos de uso

El sistema puede usarse de diversas formas y por distintos actores. En este acápite se

describen los distintos tipos de usuario y los casos de uso de cada actor específico.


23

Existen tres actores en el sistema:

� El ingeniero del conocimiento, es el encargado de tomar el conocimiento del

experto en la materia y formalizarlo en forma de reglas de producción sobre una

o varias bases de conocimiento.

� El programador, es el encargado de dar mantenimiento al software,

modificándolo o añadiéndole nuevas funcionalidades.

� El usuario, que interactúa con el sistema experto obtenido.

La figura II.1 muestra el diagrama que relaciona cada actor con los casos de uso del

sistema, los cuales serán explicados más adelante.

Figura II.1 Diagrama de casos de uso de UCShell


24

A continuación se ilustran los diferentes casos de uso que no sufrieron modificaciones

relevantes:

� Compilar base de conocimiento: El ingeniero de conocimiento compila la base de

conocimiento. Si existe algún error de tipo sintáctico o semántico, que se pueda

reconocer en tiempo de compilación, se mostrará en la línea en que ocurre. En

caso contrario se generará la forma interna que podrá entregarse como producto

final cuando se considere que cubre todas las expectativas.

� Compilar base de conocimiento con información simbólica: Es similar a la

anterior pero la forma interna se genera con información simbólica que usarán

sistemas que trabajen con este tipo de información, tales como el TeachShell

(Morales, 2011). En este caso se obtiene una base de conocimiento que puede

servir a algún proceso de enseñanza-aprendizaje.

� Editar base de conocimiento: Se podrán crear nuevos proyectos que agrupen

varias bases de conocimiento o crear una de estas de manera independiente. En

este último caso el sistema provee una plantilla genérica que facilita el trabajo

del ingeniero del conocimiento. Se pueden abrir proyectos o archivos creados

anteriormente. Se podrán editar los archivos con las facilidades propias de un

editor de texto tales como las operaciones de copiado, pegado, guardado,

búsqueda, entre otras. Además el sistema, resalta las palabras reservadas del

lenguaje para facilitar la programación.

� Realizar inferencia: La inferencia se realiza de manera interactiva ya que el

sistema le puede hacer preguntas al usuario que se contestan seleccionando

entre las posibles respuestas, en caso de que estas sean discretas o

introduciendo el valor que se estime preciso de acuerdo a la interrogante del

sistema. Una vez terminada la inferencia el usuario puede consultar, de manera

visual, los resultados y ver de qué forma se alcanzaron.

Los casos de uso Consultar ayuda, Poner a punto la base de conocimiento,

Personalizar la interfaz visual y Añadir nuevas funcionalidades, fueron modificados en

gran medida, tratando así que el sistema quedara de una forma más funcional y mejor


25

a la hora de tratar los errores. A continuación se describirán estos cambios más

detalladamente.

II.2.1 Consultar ayuda

La versión 2.0 de UCShell no cuenta con una ayuda automatizada en línea, lo que

dificulta el trabajo interactivo de usuarios e ingenieros de conocimiento. La versión 2.1

supera esa limitante al brindar una ayuda que puede consultarse en cualquier

momento por todos los actores que usan el sistema.

Para la realización de la ayuda se utilizó la biblioteca JavaHelp , el uso de esta

herramienta viene dado por el objetivo de que la aplicación sea multiplataforma. Esta

biblioteca utiliza código HTML para la configuración de los archivos de ayuda que se

quieran mostrar. Para su utilización hay que crear tres paquetes: help ,

help.JavaHelpSearch y help.html, este último contiene documentos web que

conformarán la ayuda del sistema, por otra parte los paquetes help.JavaHelpSearch y

help contienen los archivos de configuración de la biblioteca. La figura II.2 muestra un

ejemplo de la ayuda brindada por UCShell.

Figura II.2 Ayuda del sistema UCShell


26

II.2.2 Poner a punto la base de conocimiento

El uso de múltiples hilos de ejecución permite a las aplicaciones dividir sus tareas de

modo que trabajen de manera independiente unas de otras, con el fin de hacer el mejor

uso posible del tiempo del procesador.

La versión anterior del software permitía la ejecución de varias bases de conocimiento

al mismo tiempo controladas por distintos hilos de ejecución. Tomando en cuenta que

la eficiencia de un sistema experto no está dada por la velocidad de ejecución se

elimina esa facilidad lo que garantiza, además, que cada método se ejecute totalmente

antes de invocar cualquier otro. Con esta nueva forma de trabajo se garantiza que los

objetos estén siempre en un estado válido.

Una parte muy importante (muchas veces la mayor) del tiempo destinado a la

elaboración de un programa se destina a la detección y corrección de errores. La traza

mostrada por el sistema posee una importancia vital para el proceso de enseñanza –

aprendizaje además de ayudar a la puesta a punto de las bases de conocimiento; a

través de ella se puede apreciar con claridad las acciones más relevantes que realiza la

máquina de inferencia, permitiéndose observar:

� Una representación visual que muestra el recorrido que se realiza para inferir un

atributo.

� El recorrido que realiza la máquina de inferencia por la base de conocimiento

mientras trata de probar un objetivo.

Mientras se está ejecutando la traza se puede interactuar con los atributos que

intervinieron en el proceso de inferencia, ordenándolos de acuerdo a diversos criterios:

alfabéticamente por el nombre o por el valor que tomaron durante el proceso, por el

valor de certidumbre que alcanzan los atributos y por la regla que originó su valor.

En la figura II.3 se puede observar como la traza de ejecución muestra el recorrido de

la máquina de inferencia sobre una base de conocimientos. En el panel inferior


27

izquierdo se pueden observar las reglas y acciones que se están ejecutando, mientras

dentro de la base de conocimiento se resalta el lugar por donde va la inferencia.

Figura II.3 Ejemplo de la traza de ejecución.

Después de ejecutar la traza (figura II.3.1) se pueden observar todos los valores de los

atributos, también se pueden agregar nuevos atributos que toman el valor UNKNOWN,

la certidumbre 1.0 y en el campo regla contienen el valor -1, lo que especifica que no se

ha usado ninguna regla para inferirlo.

Figura II.3.1 Ejemplo de la traza de ejecución.


28

II.2.3 Personalizar la interfaz visual

La interfaz visual de la versión anterior del software tenía varias deficiencias y por ende

complejizaba la interacción del usuario con el software, realmente las deficiencias eran

poco notables, pero hacían que el sistema no estuviera totalmente adecuado.

II.2.3.1 Número de líneas

La versión actual del sistema numera las líneas del código fuente, lo que permite

informar al usuario la localización de los errores de compilación de forma que puedan

corregirse fácilmente.

El editor muestra cada una de las líneas de la base de conocimientos precedida por su

número (no forma parte del código). La figura II.4 muestra un ejemplo del problema que

puede resolver esta nueva modificación en el sistema, en este caso el compilador ha

detectado un lexema no permitido e informa en que línea está el error, de forma que el

ingeniero de conocimiento puede arreglarlo fácilmente.

Figura II.4 Ejemplo de el editor con el número de l ínea.


29

II.2.3.2 Control de errores

El control de los errores tanto en UCShell como en cualquier sistema es de vital

importancia, la figura II.5 muestra el mensaje de error que produce la interfaz visual

cuando se intentan ejecutar dos bases de conocimiento al mismo tiempo, por otra parte

en la figura II.6 se puede apreciar el mensaje de error que se presenta cuando se

intenta ejecutar una base de conocimiento que aún no se ha compilado.

Figura II.5 Error de ejecución

Figura II.6 Error al querer ejecutar sin compilar

II.2.4 Añadir nuevas funcionalidades

El árbol de inferencia o árbol de decisión es una nueva funcionalidad añadida a

UCShell 2.1, aunque también son nuevas funcionalidades la mejora de la interfaz

visual, la traza y la ayuda, las cuales se discutieron desde la perspectiva de otros

actores.


30

Para la realización del árbol de decisión se utilizó la biblioteca Jung , que brinda soporte

para una variada representación de entidades y sus relaciones, además de incluir

implementaciones de algoritmos de teoría de grafos, análisis exploratorio, entre otros.

La figura II.7 muestra un ejemplo derivado de una base de conocimiento para la

clasificación de polímeros, en la cual se quiere saber qué composición alcanza un

determinado polímero a partir de las dependencias de cada una de las variables que

intervienen en su clasificación (Reaccion_a, Reaccion_b, etc.), la parte izquierda de la

figura muestra los valores que han tomado dichos atributos.

Figura II.7 Ejemplo del árbol de decisión para la c lasificación de polímeros.

La figura II.8 muestra una de las facilidades que brinda esta biblioteca para agrupar

cada variable por su conjunto de dependencia. Ofrece, además la opción de ver el

árbol en forma hiperbólica y permite seleccionar uno o varios nodos, aumentando o

disminuyendo el tamaño del gráfico en general, etc.


31

Figura II.8 Facilidades para representar el árbol d e decisión.

La clase DrawTree (figura II.9) es la encargada de pintar el árbol construido en la clase

TfindAction, su constructor recibe como parámetros un bosque (varios árboles). En

futuras implementaciones del sistema se puede añadir la posibilidad de ver el árbol de

inferencia de varios atributos al mismo tiempo.

Figura II.9 Clase DrawTree.


32

II.3 Generalidades internas de UCShell

Seguidamente se describirán las principales clase de UCShell: de su máquina de

inferencia y de su compilador, de forma tal que sean más fáciles las modificaciones a

realizar en el sistema.

II.3.1 Paquete compiler

UCShell dispone de un compilador de bases de conocimientos integrado al paquete

compiler , el cual está constituido los siguientes módulos:

� Los paquetes:

o Operadores

o Acciones

o Funciones

� Parser

� Scaner

II.3.1.1 Los operadores

El subpaquete Operadores contiene todos los operadores que admite UCShell y los

subdivide en dos grupos: operadores booleanos (admiten solo dos valores en el

dominio de respuesta, verdadero o falso) y operadores aritméticos. Cada operador se

define en una clase propia, la cual brinda las funcionalidades específicas de cada de

uno de ellos.

Los operadores booleanos heredan de la clase TbooleanOperator , la cual hereda de

la clase Toperator , mientras los operadores aritméticos heredan directamente de

Toperator , la cual contiene un atributo para el nombre de la operación, otro para el

símbolo que representa la operación y otro con la cantidad de operandos.

La figura II.10, muestra la clase Toperator y sus atributos, con parte de los operadores

correspondientes.


33

Figura II.10 Diagrama de clases de los operadores e n el compilador

II.3.1.2 Las acciones

En la figura II.11 se muestra un fragmento del diagrama de clases correspondiente a

las acciones que se ejecutan en el sistema. La clase Taction_list contiene una lista de

acciones compuesta, al menos, por una acción que es miembro de la clase Taccion .

En el ejemplo la clase Taction_list contiene una sola acción que es TfindAction .


34

Figura II.11 Diagrama de clases de las acciones en el compilador

II.3.1.3 Las funciones

Las funciones del sistema, al igual que los operadores y las acciones están definidas

cada una en una clase y heredan de Tfunction que contiene una variable con el

nombre de la función y otra con el símbolo que representa dicha función.

La clase que representa cada función se encarga de evaluar, mientras que en la clase

Tfunction se hace un chequeo de tipo y se toman los valores que devuelve la función

para concatenarlos en la cadena polaca.

La figura II.12 muestra un breve resumen del diagrama de clases correspondiente a las

funciones.


35

Figura II.12 Diagrama de clases de las funciones en el compilador

II.3.1.4 Gramática y generación de código

Las gramáticas constituyen la mejor vía para la descripción sintáctica de los lenguajes

de programación. Existen diversas razones que justifican tal afirmación:

� Las gramáticas brindan una especificación sintáctica precisa de los lenguajes

de programación.

� Para ciertas clases de gramáticas pueden construirse analizadores sintácticos

eficientes que determinan si el programa fuente está bien escrito. El proceso

de construcción del parser puede además, revelar ambigüedades sintácticas

no detectadas en la fase de diseño del lenguaje.

� Una gramática bien diseñada puede ayudar a la traducción del programa

fuente en código objeto y a la detección de errores.


36

� Es fácil añadir nuevas construcciones al lenguaje cuando está descrito a

través de una gramática.

De las cuatro clases de gramáticas de la jerarquía de Chomsky, las gramáticas libre de

contexto (GLC) son las más importantes desde el punto de vista de la aplicación en los

lenguajes de programación y compiladores. Una GLC puede utilizarse para especificar

la estructura sintáctica de un lenguaje de programación y además constituye la base

para los diferentes esquemas de traducción, por esas razones es el tipo de gramática

que se escogió para el presente proyecto.

El diseño de las clases del paquete compiler en UCShell se modeló a semejanza de la

gramática, definiendo una clase por cada uno de sus símbolos no terminal.

La figura II.13 muestra el esquema de interacción entre los diferentes módulos que

conforman el compilador de UCShell.

Scanner Parser

Tabla de Símbolos

Programa

Fuente

token

obtenerprox. token

Árbol sintáctico

Figura II.13 Representación de la estructura intern a del compilador

II.3.1.4.1 Análisis Lexicológico (Scanner)

El scanner de UCShell, reconoce cada uno de los lexemas o tokens del lenguaje y se

los entrega al parser.

El lenguaje está constituido por un conjunto de símbolos (operadores aritméticos como

la suma y la división, lógicos como el AND y el OR, etc.) y un conjunto de lexemas que

constituyen palabras reservadas del lenguaje (los nombres de las cláusulas, de las

funciones trigonométricas, etc.).


37

La sintaxis del lenguaje reconoce también los comentarios tanto de una línea como de

varias, esa facilidad no estaba presente en las versiones anteriores. Las cadenas de

caracteres se tomarán como literales si están entre comillas simples, los números se

tomarán como enteros o como doubles si tienen parte decimal.

En el scanner se reconocen también atributos (son las variables del sistema). Los

identificadores de los atributos pueden contener caracteres alfanuméricos, pero

necesariamente han de comenzar en una letra. El sistema no es sensible a mayúsculas

y minúsculas, sin embargo, el editor sí lo es y toma en cuenta el tipo de letra para

resaltar las palabras reservadas.

Los errores que reconoce el scanner son los de lexemas mal formados. Cada vez que

el analizador lexicográfico encuentra un lexema bien formado retorna el símbolo

correspondiente. En caso de encontrar errores los informa sin clasificar pero mostrando

el número de la línea en que ocurrió el error.

La tabla de símbolos contiene las entradas para los distintos tipos de identificadores. Al

inicio del análisis lexicográfico se agregan, a la tabla, todos los operadores permitidos

en la gramática. Los atributos se van insertando según van apareciendo. Tanto a los

atributos como a los operadores se les asigna un código para identificarlos

internamente. La tabla de símbolos contiene una estructura con todos los datos

necesarios para trabajar con cada entrada.

La tabla de símbolos fue implementada usando una tabla hash que tiene como entrada

el nombre de la variable o la palabra reservada que lo identifica en el caso de los

operadores.

II.3.1.4.2 Análisis sintáctico (Parser)

Una vez realizado el análisis lexicológico es necesario examinar la secuencia de tokens

para determinar si cumple ciertas convenciones estructurales de la definición sintáctica

del lenguaje. Para hacer esto, el parser toma la secuencia de lexemas generada por el

scanner.


38

Para generar la forma interna fue necesario el diseño de un conjunto de clases que

permitieran a la máquina de inferencia ejecutar las acciones descritas, en la base de

conocimiento, por el ingeniero del conocimiento.

Cada vez que parser infiere por un no terminal, se construye un objeto miembro de la

clase del no terminal. El nombre del no terminal que contiene toda la información

concerniente a la forma interna se denomina punto_partida y se representa con la clase

Tpunto_partida , la estructura de esta se puede apreciar en la figura II.14:

� Tvar_list representa la lista de atributos externos del sistema,

� Trule_list es la lista de reglas,

� Tencabezamiento contiene las acciones globales,

� Tasks_list es la lista de atributos que deberán preguntarse al usuario del sistema

experto.

Figura II.14 Diagrama de clases que contiene la for ma interna del compilador

Para generar el parser se usó la herramienta CUP, la cual permite definir los métodos

que se usarán en las acciones semánticas como código Java. En el caso de UCShell

desde esta sección se invoca el método writeFI, que recibe, por parámetros, una lista

de objetos (usualmente un objeto de la clase Tpunto_partida y la tabla de símbolos) y el

nombre del archivo donde se va a escribir, si el archivo existe se sobrescribirá y en


39

caso contrario se creará. La forma interna se escribe cuando el analizador sintáctico

termina su análisis.

II.3.1.4.3 Ejemplo para agregar cláusulas al lenguaje de UCShell

Con el objetivo de ayudar a dar mantenimiento al sistema se presenta un ejemplo para

agregar una cláusula nueva al sistema. Por simplicidad se ejemplifica con la cláusula

DISPLAY que en realidad ya está definida, pero el método es fácil de generalizar.

La cláusula DISPLAY está definida por una imagen o por uno o varios elementos

visibles, todos separados por una coma (,).

� Paso I: Definición de las reglas léxicas.

Para agregar una nueva cláusula, al lenguaje de UCShell o a cualquier otro, lo primero

que se debe hacer es definir las reglas léxicas que permitan al scanner reconocerlas

como un lexema.

El scanner tiene que ser capaz de reconocer las palabras reservadas, los símbolos y

las expresiones regulares asociadas al lenguaje.

A continuación se muestran ejemplos (figura II.15) de definición de:

� palabras reservadas (ACTIONS y DISPLAY ),

� símbolos (, y >),

� dígitos decimales.

Figura II.15 Ejemplo de la definición de las reglas léxicas


40

� Paso II: Definición de los tokens.

En este segundo paso se comienza a construir el parser, donde primeramente se

definen los lexemas o tokens de la gramática, tanto los terminales como los no

terminales (figura II.16).

Figura II.16 Ejemplo de definición de los tokens

En la gramática de UCShell se definieron un conjunto de 76 terminales y 37 no

terminales. Dentro de los primeros se definen las palabras reservadas del lenguaje, los

operadores y las acciones.

� Paso III: Definición de la precedencia de los operadores.

En el caso de los operadores es necesario definir su precedencia y si son asociativos a

la derecha o a la izquierda. Mediante estas definiciones se instruye al generador del

analizador sintáctico en qué orden realizar las operaciones (figura II.17).

Figura II.17 Ejemplo de definición de la precedenci a de los operadores


41

El orden de precedencia se declara desde abajo hacia arriba, como se muestra en el

ejemplo, el operador de más precedencia es el factorial y el de menos la asignación.

� Paso IV: Definición de las reglas gramaticales.

Para definir las reglas gramaticales se usa un procedimiento general, en este ejemplo y

en aras de simplificar, se explica la regla para la cláusula DISPLAY , que puede

generalizarse fácilmente.

Cada producción de la regla gramatical puede o no tener acciones semánticas

asociadas, para definirlas se usa un código en lenguaje Java delimitado por {: :} .

El no terminal “accion” puede ser cualquier acción del sistema UCShell. En la figura

II.18 se muestra la acción DISPLAY:

DISPLAY part_display:p ,

Su acción semántica se define como:

{:RESULT = new TDisplayAction ("DISPLAY " + p.toStr ing(), p);:}

Lo que provoca que se cree un objeto de tipo TDisplayAction con la palabra reservada

DISPLAY y part_display (la variable p hace referencia a ella). El no terminal

“part_display” puede ser una imagen (“imagen”) u otra parte del display

(“part_display1”), en este segundo caso el no terminal “part_display1” está compuesto

por un elemento visible (“elemento_visible”), que va ser un valor (“value”) o un atributo

(“var”), o varios elementos visibles. Esta última parte se usa principalmente cuando se

desean mostrar los valores que han tomado las variables o su certidumbre.


42

Figura II.18 Ejemplo de definición de las reglas

II.4 Conclusiones del capítulo

En el capítulo se ha ofrecido una visión general de la forma interna del sistema UCShell

con el objetivo de ayudar a los programadores e ingenieros de conocimiento.

El compilador del sistema UCShell se basa en una gramática GLC y para realizar el

parser se usó la herramienta CUP lo que facilita agregar nuevas cláusulas o facilidades

generales al sistema de una forma relativamente fácil.

El capítulo III da una visión más externa del sistema y por eso va dirigido a los usuarios

de los sistemas expertos y a los ingenieros del conocimiento.

Capitulo lll. Entorno de programación UCShell

43

Capítulo III. Entorno de programación UCShell

UCShell es un sistema para el desarrollo de sistemas expertos (SE) que cuenta con

varios módulos, entre los que se destacan: el editor de bases de conocimientos, el

compilador y la máquina de inferencia. Para implementar un sistema experto sobre

UCShell, se usa el editor como ambiente de programación, sobre él se escribe el

código que analizará el compilador para generar una forma interna que posteriormente

podrá ser interpretada por la máquina de inferencia.

En este capítulo se describe el entorno de programación UCShell y los componentes

de una base de conocimientos (atributos, cláusulas, etc.).

Existen dos unidades sintácticas importantes en una BC de UCShell: los atributos que

son los responsables de almacenar los valores y las cláusulas que son las

herramientas de programación. Si se hiciera un símil con un lenguaje de programación,

los atributos serían las variables y las cláusulas las sentencias.

III.1. Base de Conocimientos

Una base de conocimiento describe el saber sobre un campo dado a través de algún

lenguaje que es específico para un determinado entorno. Las bases de conocimiento

de UCShell están constituidas por diversas partes, cada una de ellas tiene determinada

responsabilidad dentro del sistema experto. Las partes o módulos de una base de

conocimientos de UCShell se pueden apreciar en la figura III.1 y son las siguientes:

� el bloque de atributos externos que se declara con la palabra reservada

EXTERNAL ,

� el bloque de atributos preguntables , definido por ASKS ,

� el bloque de reglas definido con la palabra reservada RULES,

� el bloque de acciones definido con la palabra reservada ACTIONS.


44

Figura III.1 Esquema representativo de una base con ocimientos

Los bloques Rules, External y Asks son opcionales y, aunque no tiene mucho sentido

hacer un SE sin reglas, pueden existir pequeñas bases que sirvan de auxiliares a otras

en donde esa concepción tiene sentido, el bloque de preguntables puede ser que no

exista, sobre todo en un SE que trabaje con búsqueda dirigida por datos, por último el

bloque External solo se usa cuando el SE consta de varias bases de conocimientos

que necesitan enlazarse de alguna manera.

El bloque Actions, es el punto de inicio del SE, desde él se ordena la búsqueda de los

objetivos a probar y se controla la inferencia.

El fin de cada bloque se especifica, implícitamente, con el inicio de otro, excepto el

bloque de acciones, que finaliza con la palabra reservada END seguida por un punto (.)

indicando el fin de la base de conocimientos.

III.1.1 Atributos externos

Los atributos externos (figura III.2) se especifican dentro del bloque EXTERNAL , y

como ya se apuntó, son los atributos que se definen en una base de conocimiento A y

se usan en otra B. De esta forma es posible conservar los valores, obtenidos o fijados,

en la base A para después realizar un cambio a la base B manteniéndolos. Los

atributos que se definen dentro de un bloque ASKS , con la cláusula ASK y los que se

infieren como conclusión de una regla son externos implícitamente.

La cláusula CHAIN, está ligada intrínsecamente a los atributos externos debido a que

se usa para hacer un cambio de una base a otra, por ejemplo de la base A hacia la B.


45

En versiones anteriores de UCShell era responsabilidad del programador guardar los

valores que se desearan conservar antes de hacer el cambio de A hacia B y una vez en

B también era necesario programar la carga de esos valores, en la versión actual ese

proceso transcurre de forma oculta a los programadores.

Figura III.2 Sintaxis del bloque External

III.1.2 Atributos preguntables

La palabra reservada ASKS (figura III.3) define el bloque de atributos que se pueden

preguntar al usuario del SE.

Figura III.3 Sintaxis de las variables preguntable s

III.1.2.1 Definición de ASK

Figura III.4 Definición de ASK


46

Cada atributo que se desea preguntar se define por la palabra reservada ASK (figura

III.4). A cada atributo preguntable se asocia:

� la pregunta en sí (ID del atributo),

� el dominio de respuesta (opcional: Conjunto de selección o Dominio de

definición),

� una justificación de por qué se pregunta (opcional: Explicación).

III.1.2.1.1 Conjunto de selección

El Conjunto de selección se define mediante la palabra reservada CHOICE y se usa

para especificar una lista de literales o atributos separados por coma, que son las

respuestas válidas para la pregunta (figura III.5).

Figura III.5 Definición del Conjunto de selección

� Número: Puede ser un entero o un real.

� Cadena: En UCShell una cadena es un texto dentro de comillas simples.

� Atributos.

Los atributos preguntables que forman parte del <Conjunto de selección> tienen que

haber sido previamente definidos en la base de conocimientos, de lo contrario se

genera un error de compilación debido a que dichos atributos se tienen que haber

convertido previamente en hechos.


47

Cuando un usuario responde una pregunta puede asociarle un factor de certidumbre

que se define como un valor del intervalo [0, 1]. Un valor 0 es equivalente a responder

falso y un valor 1 significa que se tiene total certeza de la respuesta.

III.1.2.1.2 Dominio de definición

La palabra reservada DOMAIN define el dominio de respuesta de una variable. En la

figura III.6 se muestra la sintaxis de dominio de definición.

Figura III.6 Dominio de definición.

Los elementos del dominio pueden ser cadenas o números que pueden estar o no

asociados a una imagen. Para el caso que la respuesta tenga un imagen asociada, la

opción a escoger por el usuario es la cadena que está a la derecha del signo igual (=).

El sistema garantiza que los atributos definidos por DOMAIN solo puedan tomar valor

dentro del dominio.

Una imagen mostrada, en el proceso de inferencia, se enmarca dentro del espacio que

la interfaz le asigne, reduciendo su tamaño proporcionalmente, pero puede verse en

toda su dimensión mediante un doble clic sobre ella.

Las respuestas a este tipo de preguntas también pueden estar acompañadas de un

factor de certidumbre, de acuerdo a las mismas reglas establecidas en el acápite

anterior.


48

III.1.2.1.3 Ejemplos de declaraciones de ASKS

La figura III.7 muestra un ejemplo de definición de un atributo preguntable, con un

dominio de definición acompañado por una imagen. El atributo también tiene asociada

una parte que explica el por qué se hace la pregunta (el bloque BECAUSE). La figura

III.8 muestra la interfaz que el sistema le presenta al usuario para hacer esta pregunta.

Figura III.7 Atributo preguntable con imagen y beca use

Figura III.8 Interfaz del atributo preguntable defi nido en la figura III.7


49

La figura III.9, muestra un atributo preguntable que no viene acompañado de posibles

respuestas (ni CHOICE, ni DOMAIN). Este tipo de atributo espera una respuesta que

no puede establecer previamente, por ejemplo un valor numérico. En este caso el

atributo tampoco tiene BECAUSE asociado. La figura III.10 muestra la interfaz visual de

esta pregunta.

Figura III.9 Atributo preguntable con dominio no de finido

Figura III.10 Interfaz del atributo preguntable def inido en la figura III.9

En la figura III.10 se puede observar que la pregunta no muestra las posibles

respuestas y en su lugar muestra un pequeño editor de línea sobre el que el usuario

debe teclear su respuesta. Es responsabilidad del usuario teclear la respuesta correcta,

por ejemplo si se espera un número no debe teclearse una cadena. Como la pregunta

no tiene asociada una explicación el botón Because se presenta desactivado.


50

III.1.3 Definición del conocimiento. Bloque de reglas

La palabra reservada RULES, declara el inicio del bloque de reglas. Este bloque es el

más importante de cualquier BC, ya que en él se definen las reglas de producción que

contienen el conocimiento formalizado por el programador del SE. La figura III.11

muestra la sintaxis del bloque de reglas, se puede apreciar que está constituido por un

conjunto de reglas separadas por el símbolo de punto y coma (;). El bloque de reglas

termina con la declaración del inicio del bloque de acciones (ACTION).

Figura III.11 Sintaxis de RULES

III.1.3.1 Definición de reglas

Cada regla (figura III.12) se identifica por la palabrada reservada RULE y un

<identificador> que es un numero entero. El formalismo empleado en el sistema es el

de <reglas de producción > que toman la forma IF… THEN…, las cuales expresan que

si se cumple el <conjunto de condiciones> se cumple la conclusión o <conjunto de

conclusiones>.

Los elementos sintácticos de cada regla son los siguientes:

� Entero: Identifica la regla, el número debe ser único y en caso contrario el

sistema reporta error.

� Condición: Define un conjunto de condiciones unidas por operadores booleanos.

La evaluación de la condición durante el proceso de inferencia da resultado

booleano (verdadero o falso), en caso de ser verdadero la regla se cumple y en

caso de ser falso la regla falla y provoca un backtracking global, o sea se evalúa,

si existe, la próxima regla.


51

� Conclusión: Define la conclusión o las conclusiones a la cual se arriba cuando se

cumple la regla y se caracteriza por la asignación de un valor al atributo (o

atributos) que se está probando.

� Acción: Define un conjunto de acciones que se ejecutan cuando se cumple la

regla. En este sub bloque se puede usar cualquier cláusula de UCShell.

� La explicación de la regla, permite saber cómo se llegó a una conclusión, su

sintaxis es la misma que la de la explicación en los ask. En el sistema se pueden

definir reglas débiles.

Figura III.12 Definición de RULE

III.1.3.1.1 Definición de la parte <condición>

La parte <condición> de una regla expresa el conjunto de condiciones que se deben

satisfacer para que la parte <conclusión> sea verdadera y se realicen las acciones

asociadas a la regla.

El conjunto de condiciones no es más que una cierta cantidad de proposiciones lógicas

unidas por los operadores booleanos AND u OR y. Las proposiciones tienen la forma:

[not]<expresión 1> operador relacional [not]<expres ión 2>


52

La evaluación de cualquier proposición toma un valor booleano (verdadero o falso) y la

parte <condición> se evalúa como verdadera o falsa de acuerdo a las reglas de

evaluación de los operadores lógicos (AND, OR y NOT).

Los operadores relacionales que están disponibles en UCShell se pueden apreciar en

la tabla III.1 y los operadores lógicos se muestran en la tabla III.2.

.

Tabla III.1 Operadores relacionales

Operador Operación Relación Ejemplo

NOT Negación unario NOT (A=B)

AND And lógico binario A=B AND C=D

OR Or lógico binario A=B OR A=C

Tabla III.2 Operadores condicionales

Para el operador AND, la evaluación de las proposiciones que conforman la

<condición> se define como de circuito corto o evaluación parcial (short-circuit), lo que

Símbolo Operación Tipo de operadores

= Igual Atributos, cadenas y números

<> Diferente Atributos y números

< Menor Atributos y números

> Mayor Atributos y números

<= Menor o igual Atributos y números

>= Mayor o igual Atributos y números


53

significa que si, en algún momento de la evaluación de las condiciones relacionadas

con AND, alguna es falsa la condición también es falsa y la regla que se está

evaluando falla y por tanto se abandona sin evaluar el resto de las condiciones.

Para el operador OR también se hace una evaluación de circuito corto, pero en este

caso si alguna de las condiciones es verdadera, la regla tiene éxito. Como se cumple

su <condición> se da por verdadera su <conclusión> sin necesidad de evaluar el resto

de las condiciones.

Los operadores lógicos no se comportan como operadores sobre bits por lo que las

condiciones de comparación tienen la máxima prioridad.

Los operadores relacionales pueden ser definidos sobre elementos del mismo tipo o

sobre los tipos compatibles.

Los atributos que aún no se han inferido tienen como valor la constante UNKNOWN lo

que se puede tomar en cuenta para saber si aún no se ha probado (contiene el valor

UNKNOWN) o ya se probó y por tanto es un hecho (tiene un valor diferente de

UNKNOWN).

III.1.3.1.2 Definición de la parte <conclusión>

La conclusión de una regla es la parte de la regla donde se le asigna un valor al

atributo (o a los atributos) cuando se pueda probar. El valor asignado puede estar

asociado a un factor de certidumbre (figura III.13).

Figura III.13 Definición de la conclusión de una re gla


54

A los atributos que están a la izquierda de la sentencia de asignación (:=) se les

denominan deducibles.

La certidumbre de la regla se puede expresar (opcionalmente) a través de la palabra

reservada CNF seguida de un número real perteneciente al intervalo [0, 1] y se le

denomina valor real, el cual expresa el grado de certeza con que, según el experto, se

puede afirmar la conclusión siendo las premisas verdaderas.

Para calcular la certidumbre de la regla en un proceso de inferencia dado, se usa el

siguiente criterio:

� El valor de CNF (valor real), se multiplica por el valor de certidumbre con que se

haya evaluado la regla. Puede observarse que, si todas las premisas fueran

absolutamente verdaderas, el valor de la certidumbre de la condición es 1 y el

resultado de la multiplicación es el propio CNF que viene expresado en la regla.

� En caso de que no se especifique CNF el valor de la certidumbre de la

conclusión es 1 y por tanto el valor de la conclusión es igual al valor de la

certidumbre con que se haya evaluado la condición.

La figura III.14 muestra dos ejemplos de reglas.

Figura III.14 Ejemplos de declaraciones de reglas


55

La primera de las reglas tiene asociado un factor de certidumbre en la conclusión. Las

reglas declaradas contienen bloques de acciones asociadas, en ambos caso solamente

con el uso de la cláusula DISPLAY.

III.1.4 Bloque de acciones

Existen dos bloques de acciones, ambos se especifican con la palabra reservada

ACTIONS y se usan para especificar un conjunto de acciones que debe ejecutar la

máquina de inferencia.

.

Figura III.15 Sintaxis de ACTIONS

� El bloque de acciones principal, se define como el último bloque de cualquier

base de conocimientos y al contrario de los restantes bloques (External, Asks y

Rules) es obligatorio.

En este bloque están contenidas las órdenes globales que se le dan a la máquina de

inferencia. La ejecución de cualquier proceso de inferencia en UCShell comienza y

termina por el bloque de acciones principal, es por eso que dentro de ese bloque,

usualmente, se encuentre alguna cláusula find o findforward para dar la orden de

probar un determinado atributo.

� El bloque de acciones de una regla define el conjunto de acciones que se

ejecutarán cuando la condición de la regla se haga verdadera. Este bloque es

opcional.

Las acciones que se pueden realizar sobre los elementos de la base de conocimientos

están definidas por un conjunto de cláusulas que especifican operaciones sobre los

atributos o la base de conocimiento en sentido general.


56

Las cláusulas siguientes pueden escribirse dentro de los bloques de acciones

solamente1:

DISPLAY FIND FINDFORWARD

FINDALL ASSUME REPEAT

RESET CHAIN SAVEFACT

LOADFACT

III.1.4.1 Cláusula DISPLAY

La cláusula DISPLAY permite especificar una lista de imágenes o de elementos visibles

que se mostrarán en pantalla en tiempo de ejecución. La figura III.16 muestra su

sintaxis.

Figura III.16 Sintaxis de DISPLAY

III.1.4.2 Cláusula ASSUME

La clausula ASSUME (figura III.17) es la única forma de asignar un valor a un atributo

por programa. El atributo que se instancia puede ser un atributo preguntable, externo o

deducible.

Figura III.17 Sintaxis de ASSUME 1 Dentro de este grupo hay cláusulas que aunque se reconocen, están obsoletas, tales como SAVEFACT, LOADFACT.


57

En UCShell existen tres vías para que un atributo se convierta en hecho:

� Cuando se deduce. Son atributos deducibles que alcanzan su valor por el

proceso de inferencia que no es controlado por el programador.

� Por respuestas del usuario. Son atributos preguntables y alcanzan su valor a

partir de respuestas obtenidas por los usuarios del SE.

� Por medio de la cláusula ASSUME.

El uso de la cláusula ASSUME es muy importante en un SE con búsqueda dirigida por

datos ya que el SE tiene que partir de algún conjunto de hechos conocidos para poder

realizar la inferencia.

La certidumbre que tiene un hecho obtenido con el uso de una cláusula ASSUME es 1,

o sea el valor máximo permitido.

Si al atributo asociado a ASSUME (a la izquierda de IS) se le asigna otro atributo con

valor desconocido, se produce un proceso de inferencia del segundo atributo y el valor

obtenido se le asigna al primero.

III.1.4.3 Cláusula FIND y FINDFORWARD

La cláusula Find (figura III.18) inicia el proceso de inferencia, del atributo especificado,

con dirección de búsqueda dirigida por objetivos (backward chaining o encadenamiento

hacia atrás).

La cláusula Findforward (figura III.19) inicia el proceso de inferencia, del atributo

especificado, con dirección de búsqueda dirigida por datos (forward chaining o

encadenamiento hacia adelante).

Como los atributos tienen por defecto el valor UNKNOWN, el fallo de la inferencia deja

el atributo con ese valor (aún no es un hecho). Si la inferencia tiene éxito el atributo

especificado toma el valor probado durante ese proceso y pasa a ser un hecho.


58

Figura III.18 Sintaxis de FIND

Figura III.19 Sintaxis de FINDFORWARD

La prueba o búsqueda de un atributo en UCShell sigue el siguiente algoritmo general:

Si el atributo es un hecho se toma su valor y certidumbre.

Retornar

En caso contrario

Si el atributo es un preguntable

se realiza la pregunta asociada al atributo,

se toma la respuesta del usuario del SE como su valor,

el atributo deja de ser un preguntable y se convierte en un hecho, Retornar.

En caso contrario

Si el atributo es un deducible,

se inicia el proceso de inferencia,

Si no tiene éxito,

Retornar

En caso contrario

el atributo deja de ser un deducible y se convierte en un hecho,

Retornar.

III.1.4.4 Cláusula FINDALL

La cláusula FINDALL tiene como objetivo obtener todas las instancias posibles de un

atributo.


59

Un ejemplo para comprender esta utilidad se puede ver en la medicina. Dado un SE

para diagnosticar enfermedades, si se modela el programa usando la cláusula FIND

solamente dará una respuesta y pudiera ser que los síntomas hagan posible que sean

otras. Si se modela con un FINDALL, el médico, usuario del SE, podrá discernir si es

verdad que el paciente tiene todas esas enfermedades o solo alguna de ellas.

La clausula FINDALL actúa con dirección de búsqueda dirigida por objetivos y en ese

sentido es igual a FIND, excepto que es más exhaustiva.

III.1.4.5 Cláusula REPEAT

Es la cláusula que permite programar ciclos dentro de una base de conocimientos, la

sintaxis de esta cláusula (figura III.20) permite incluir, en el ciclo, cualquier otra

cláusula. El ciclo se repite hasta que el atributo controlador se haga conocido, es decir

cuando se transforme de UNKNOWN a un hecho con un determinado valor.

El atributo controlador (el que se sitúa después de la palabra reservada

UNTILKNOWN) no se infiere en el momento de la evaluación solo se verificará si su

valor es conocido o no.

Figura III.20 Sintaxis de REPEAT

III.1.4.6 Cláusula RESET

Los atributos de una base de conocimientos tienen dos estados: son desconocidos

(tiene el valor Unknown), o son hechos y por tanto almacenan un valor que tienen algún

significado dentro de la BC.


60

La cláusula RESET (figura III.21) especifica una lista de atributos separados por coma,

o todos los atributos si se usa la palabra reservada ALL , a los que se les asignará el

valor de desconocido (Unknown).

La cláusula RESET resulta útil para reiniciar un proceso de inferencia sobre un atributo,

ya que al hacerlo desconocido se buscará su valor ante cualquier orden de búsqueda

(find, findall, findforward).

Figura III.21 Sintaxis de RESET

III.1.4.7 Cláusula SAVEFACT

La sentencia SaveFact (figura III.22), que se usaba en versiones anteriores, para poder

realizar el proceso de encadenamiento entre de dos bases, es obsoleta en la versión

actual y solo se conserva por problemas de compatibilidad, aunque no tiene acción

semántica asociada.

Figura III.22 Sintaxis de SAVEFACT

Su uso permitía guardar los valores asociados a los atributos de la base de

conocimiento activa (base origen) con el objetivo de hacer un enlace con otra base de


61

conocimiento (base destino). Los atributos que se guarden con esta sentencia, deberán

ser declarados externos en la base de conocimiento destino.

La acción SAVEFACT utiliza una zona de memoria para almacenar la dirección de los

últimos atributos guardados, cada ejecución de la acción SAVEFACT sobrescribe las

direcciones anteriores.

III.1.4.8 Cláusula CHAIN

La cláusula CHAIN (figura III.23) especifica el camino hacia una base de conocimiento

destino con la que se va a enlazar la base de conocimiento origen.

Figura III.23 Sintaxis de CHAIN

Si la base de conocimientos se compiló previamente, entonces existe el archivo .KBO

(contiene la forma interna) y se trabaja sobre él, en caso contrario el sistema compilará

la base (archivo .KBS) y creará el archivo (.KBO).

La ejecución de la cláusula CHAIN provoca:

1. Un cambio de ejecución desde la base de conocimiento origen hacia una base

de conocimiento destino.

2. Realiza el intercambio de hechos entre las bases. Las variables de la base de

conocimiento anterior, de las cuales se pretenda conservar su valor han de ser

declaradas externas en la nueva base, los hechos que no estén asociados a las

variables se perderán.

La forma de utilización de estas facilidades es la siguiente:

Supóngase que se tiene un sistema experto que utiliza dos bases de conocimiento B1 y

B2, algunos de los atributos inferidos durante la utilización de la base B1 van a

utilizarse en la base B2. Los pasos a seguir son los siguientes:


62

1. En B1 poner la sentencia (CHAIN ‘B2.kbo’ o CHAIN ‘B2.kbs’) en el lugar

apropiado para cambiar la inferencia de B1 a B2 en el momento deseado.

2. La sentencia CHAIN puede utilizar tanto la base de conocimiento previamente

compilada o sin compilar. En el segundo caso el sistema la compilará en el acto

y creará el archivo ‘B2.kbo’ con el cual trabajará posteriormente.

3. En B2 declarar externos los atributos cuyo valor será necesario conservar.

III.1.5 Otras elementos de una base de conocimiento

A continuación se hará una descripción más exhaustiva de la sintaxis de algunos

elementos que acompañan a las cláusulas de UCShell.

III.1.5.1 Definición de imagen

Se utiliza la palabra reservada IMAGE (figura III.24) para especificar el camino de

búsqueda de un archivo (incluye el archivo) que contiene la imagen que se desea

mostrar.

Figura III.24 Definición de IMAGE

Se puede utilizar esta facilidad para mostrar preguntas con imágenes (figura III.25),

elementos de un dominio con imágenes asociadas, o para mostrar una imagen

mediante la sentencia Display.

Figura III.25 Ejemplo utilizando IMAGE


63

III.1.5.2 Definición de explicación

La palabra reservada BECAUSE permite asociar a cada pregunta una explicación que

faculta al sistema experto para justificarlas cuando el usuario lo solicite.

Figura III.26 Sintaxis de Because

La conformación del texto que se muestra al usuario como explicación de la pregunta

se hace a partir de ítems denominados “elementos visibles”.

Un texto definido como BECAUSE de una pregunta se mostrará como parte de la

interfaz cuando se oprima el botón Because.

III.1.5.3 Definición de elemento visible

Los elementos visibles (figura III.27) son aquellos que se pueden mostrar mediante las

cláusulas BECAUSE y DISPLAY. La definición de una lista de elementos visibles

permite incluir:

� Literal: Imprime el valor del literal (número o cadena).

� Atributo: Si el atributo no ha sido instanciado lo infiere y luego imprime el valor.

Los atributos que no están definidos previamente como preguntables ni externos

se consideran deducibles y en tiempo de ejecución se tratan de inferir.

� ASK de atributo: Si el identificador no es un preguntable genera un error de

compilación de lo contrario imprime el texto de la pregunta del identificador.

� CNF del atributo: Si el identificador no ha sido instanciado lo induce y luego

imprime la certidumbre del valor asignado al atributo.


64

Figura III.27 Definición de Elemento visible

En la figura III.28 se muestra un ejemplo de elementos visibles definidos dentro de las

sentencias DISPLAY y BECAUSE.

Figura III.28 Ejemplo de uso de elementos visibles en la a cción Display

III.1.5.4 Definición de literal

El sistema es capaz de manipular literales como:

� Cadena de caracteres: de cualquier tamaño encerrado entre comillas simples

� Enteros: Secuencia de dígitos en el rango de -32768...32767

� Reales: Secuencia de dígitos permitiendo la inclusión de punto flotante en el

rango 2.9 x 10-39...1.7 x 1038

III.1.5.5 Definición de Expresión

La definición de expresión permite conformar las más complejas relaciones entre


65

operandos aritméticos teniendo en cuenta su nivel de prioridad y la asociación de los

operadores de igual prioridad. EL nivel de precedencia de los operadores se aprecia en

la tabla III.3.

Operador Operación Relación Ejemplo

! Factorial unaria 6!

^ Potenciación binaria 6^2

* Multiplicación binaria Peso * Altura

- Menos unario unario -7

/ División binaria Tamaño /2

% Resto de la división entera

binaria 54 % 3

Div División entera binaria 56 Div 7

- Resta binaria 6-7

+ Suma binaria 8+5

Tabla III.3 Operadores reconocidos por el sistema

Existen tres reglas básicas de precedencia:

� Si dos operadores tienen diferente prioridad se ejecutará primero el de mayor

prioridad.

� Si dos operadores tienen igual prioridad se ejecutará primero el de la izquierda.

� Las expresiones entre paréntesis tienen la máxima prioridad y se ejecutarán

primero que cualquier operador simple.

III.1.5.6 Definición de Funciones

El sistema ofrece un conjunto de sentencia para la ejecución de funciones matemáticas

de gran uso que se pueden apreciar en la tabla III.4.


66

Tabla III.4. Funciones reconocidas por el sistema

Función Operación Entrada Salida

COS Coseno Numérica Real (Radianes)

ACOS Arco Coseno Numérica Real (Radianes)

COSH Coseno Hiperbólico

Numérica Real (Radianes)

SIN Seno Numérica Real (Radianes)

ASIN Arco Seno Numérica Real (Radianes)

SINH Seno Hiperbólico


TAN Tangente Numérica Real (Radianes)

ATAN Arco Tangente


TANH Tangente Hiperbólica


LN Logaritmo Neperiano

Numérica Numérica

LOG Logaritmo Natural

Numérica Numérica

SQR Potencia de 2 Numérica Numérica

SQRT Raíz Cuadrada

Numérica Numérica

EXP Exponencial Numérica Numérica

ABS Módulo(Valor Absoluto)

Numérica Numérica

SIN Seno Numérica Real (Radianes)

ASIN Arco Seno Numérica Real (Radianes)


67

III.2 Conclusiones del capítulo

El sistema UCShell es un entorno para el desarrollo de sistemas expertos que consta

de un conjunto de módulos importantes, entre los que se destacan:

� La máquina de inferencia que realiza procesos de deducción con dirección de

búsqueda dirigida por datos y por objetivos.

� Un editor de bases de conocimientos.

� Un compilador que permite transformar la base de conocimiento escrita en un

lenguaje fuente a una base de conocimiento en forma interna, la cual es

interpretada por la máquina de inferencia, de forma que no existan errores de

compilación en tiempo de ejecución y permitiendo proteger el código de daños,

intencionales o no, que provoquen un mal funcionamiento.

Conclusiones.

68

Conclusiones generales

Una vez terminado el trabajo se puede arribar a las siguientes conclusiones:

• Se obtiene una nueva versión (2.1) del sistema para el desarrollo de sistemas

expertos UCShell que soluciona las carencias detectadas en las versiones

anteriores.

• La nueva versión presenta una interfaz mejorada que facilita la comunicación

entre el sistema y sus usuarios.

• Se incorporan mecanismos de depuración y un árbol de decisión que sirven de

ayuda al proceso de puesta a punto de las bases de conocimientos y auxilian al

proceso de enseñanza.

Recomendaciones.

69

Recomendaciones

El tema de los Sistemas Expertos es muy abarcador, por tal motivo resulta difícil

realizar un ambiente para la construcción de estos, que abarque todas las utilidades

que se puedan ofrecer. Por este motivo se presentan las siguientes recomendaciones

que perfeccionarán el estado actual del sistema:

� Incluir en la gramática atributos que permitan la selección múltiple.

� Incorporar en la interfaz visual rutinas para el manejo de materiales

audiovisuales que ya están reconocidos en la gramática.

� Se exhorta a que la utilización del mismo no se limite a la educación, sino que se

extienda a resolver problemas reales presentes en nuestra sociedad.

Bibliografía

70

Bibliografía

BELLO, R. 2000. Introducción a la Inteligencia Artificial. BELLO, R., GARCÍA, Z., GARCÍA, M. & LOBATO, A. 2002. Aplicaciones de la

Inteligencia Artificial, México. BELLO, R. E., GÁLVEZ, D., GARCÍA, M. M. & LEZCANO, M. 1992. Modelos

Computacionales Avanzados, Editora de la UCLV. CÉSARI, M. 1990. Sistemas Expertos. DUARTE, J. C. 1994. Investigación y elaboración de recursos para la enseñanza de la

Electrónica Analógica asistida por computadora. Tesis de doctor en Ciencias Técnicas, UCLV.

FROST 1991. Bases de Datos y Sistemas Expertos, Universidad de la Habana. GÁLVEZ, D. 1998. Sistemas Basados en el Conocimiento. GARCÍA, L. & LEMAGNE, J. 1990. Introducción a la Matemática Discreta, Universidad

de la Habana. HILL, G. 1984. Manual de usuario del Golden Common LISP, Cambridge

Massachusetts. HUANG, C. & DARWICHE, A. 1996. Inference in Belief Networks: A procedural guide.

International Journal of Approximate Reasoning. LEZCANO, M. G. 2000. Prolog y los Sistemas Expertos. MINSKY, M. & ISSUE 1974. A framework for representing knowledge. MORALES, Y. G. 2011. TeachShell Versión 2.0 Herramienta de apoyo a la enseñanza

de Sistemas Expertos. Universidad Central "Marta Abreu" de Las Villas. POST 1943. Production rules. QUILLAN. 1968. Semantic Information Processing. ed, Cambridge. RUSSELL, S. J. & NORVIG, P. 1995. Inteligencia Artificial Un enfoque moderno. SCHANK, R. & ABELSON, R. 1977. Scripts, plans, goals, and understanding: An

inquiry into human knowledge structures. . TURBAN, E. 1995. Expert Systems and Applied Artificial Intelligence. TUTHILL, G. S. 1990. Knowledge Engineering.

Anexos

Ministerio de Educación Superior Universidad Central ...

Documents

Transcript of Ministerio de Educación Superior Universidad Central ...