Post on 15-Oct-2021
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.
Capitulo l. Procesos de inferencia
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.
Capitulo l. Procesos de inferencia
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.
Capitulo l. Procesos 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.).
Capitulo l. Procesos de inferencia
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
Capitulo l. Procesos de inferencia
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
Capitulo l. Procesos de inferencia
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:
Capitulo l. Procesos de inferencia
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.
Capitulo l. Procesos de inferencia
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.
Capitulo l. Procesos de inferencia
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.
Capitulo l. Procesos de inferencia
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.
Capitulo l. Procesos de inferencia
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
Capitulo l. Procesos de inferencia
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
Capitulo l. Procesos de inferencia
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.
Capitulo l. Procesos de inferencia
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
Capitulo l. Procesos de inferencia
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
Capitulo l. Procesos de inferencia
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.
Capitulo l. Procesos de inferencia
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.
Capitulo l. Procesos de inferencia
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.
Capitulo ll. UCShell por dentro
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
Capitulo ll. UCShell por dentro
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
Capitulo ll. UCShell por dentro
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
Capitulo ll. UCShell por dentro
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
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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 .
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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.).
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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
Capitulo ll. UCShell por dentro
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
Capitulo ll. UCShell por dentro
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
Capitulo ll. UCShell por dentro
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.
Capitulo ll. UCShell por dentro
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.
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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>
Capitulo lll. Entorno de programación UCShell
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
Capitulo lll. Entorno de programación UCShell
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
Capitulo lll. Entorno de programación UCShell
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
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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
Capitulo lll. Entorno de programación UCShell
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:
Capitulo lll. Entorno de programación UCShell
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
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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
Capitulo lll. Entorno de programación UCShell
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.
Capitulo lll. Entorno de programación UCShell
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
Numérica Real (Radianes)
TAN Tangente Numérica Real (Radianes)
ATAN Arco Tangente
Numérica Real (Radianes)
TANH Tangente Hiperbólica
Numérica Real (Radianes)
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)
Capitulo lll. Entorno de programación UCShell
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