facultad de matemática, física y computación
TRANSCRIPT
Universidad Central “Marta Abreu” de Las Villas
Facultad de Matemática, Física y Computación
Licenciatura en Ciencia de la Computación
TRABAJO DE DIPLOMA
ESTUDIO PRÁCTICO DEL SISTEMA UCSHELL.
MEJORAS NECESARIAS.
Autora: Daylem Rojas Sosa.
Tutor: Dr. Mateo G. Lezcano Brito.
Lic. Lissett Fundora Fdez.
2013
La que suscribe: Daylem Rojas Sosa, hace constar que el trabajo titulado “Estudio práctico
del sistema UCShell. Mejoras necesarias”, fue realizado en 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
Dr. Mateo G. Lezcano Brito. Dr. Mateo G. Lezcano Brito.
Fecha
PENSAMIENTO
El hombre sin propósito es como un barco sin timón, un soplo, nada, nadie.
Thomas Carlyle
DEDICATORIA
A mis padres, por su gran amor y por ayudarme a llegar a la meta.
AGRADECIMIENTOS
A mi Padre amado, porque su gracia no ha sido en vano para conmigo.
A mis padres por su amor y apoyo que me alentaron durante todo el camino.
A mi Abu querida por su amor y entrega durante todos mis estudios.
A mis hermanos, por su cariño.
A Pedro, mi Kuku, por su apoyo incondicional.
A mi tía Maritza por su preocupación, apoyo y cariño.
A toda mi familia por su contribución.
A Yadira, por su incondicionalidad como amiga y apoyo invaluable.
A Sandra H. por sus consejos y por estar siempre para mí.
A mis amigas Maye, Marbe y Lini por su cariño y preocupación.
A Dámaris, Dayana, Maricel y Sandra E. por la amistad, cariño y años
compartidos durante esta carrera.
A Adrián, Darian, Pachi y Alejandro, mis grandes amigos y compañeros.
A mis queridos tutores Mateo y Lissett por su ayuda y contribución, pero sobre
todo, por su Paciencia.
A todos los que de una forma u otra contribuyeron a la realización de este
trabajo y a la culminación de esta etapa de mi vida.
RESUMEN
RESUMEN
UCShell, es un producto informático para el desarrollo de sistemas expertos. La versión 1.0
del sistema se desarrolló en el lenguaje Borland Pascal y se implementó específicamente
para el sistema operativo MS-DOS. Para programar la segunda versión se usó el lenguaje
Object Pascal y a su nombre original se le agregó, al inicio, la letra W para significar el
hecho de que estaba específicamente diseñado para el sistema operativo Windows. La
versión 2.0 de UCShell (Shell de la Universidad Central) retomó su nombre original y
ahora puede ejecutarse sobre cualquier sistema operativo ya que está soportado sobre la
máquina virtual de Java.
El sistema ha probado su efectividad pero su uso continuado y las facilidades incorporadas
en la versión 2.1 hacen que sea necesario realizarle una verificación total. La prueba
consiste en la puesta a punto de un sistema experto para la clasificación de animales que
tiene la complejidad necesaria para explotar todas las facilidades del sistema con el
propósito de descubrir las posibles fallas y enmendarlas, siendo ese el principal objetivo de
este trabajo.
ABSTRACT
ABSTRACT
UCShell is a software product for developing expert systems. Version 1.0 of the system
was developed in Borland Pascal language and implemented specifically for MS-DOS
operating system. To program the second version was used the Object Pascal language and
to its original name was added, at the beginning, the letter W to denote the fact that it was
specifically designed for the Windows operating system. The version 2.0 of UCShell (Shell
Central University) that sums up its original name and it means that you can run it on any
operating system because it is programmed in the Java language.
The system has proved to be effective, the continued use and the new facilities added en the
version 2.1 make necessary a total verification. The test consists in the creation of an expert
system for animal classification with the necessary complexity to explode all the facilities
of the system with the purpose of finding all possible failures and fixing it, being that the
main target of this thesis.
TABLA DE CONTENIDO
INTRODUCCIÓN ......................................................................................................................... 1
I. UCSHELL, LOS SISTEMAS EXPERTOS Y LAS PRUEBAS DE PROGRAMAS ................ 4
I.1. Introducción ......................................................................................................................... 4
I.2. Los Sistemas expertos .......................................................................................................... 4
I.2.1. Arquitectura de los Sistemas Expertos ......................................................................... 5
I.3. Estructura de las bases de conocimiento de UCShell .......................................................... 7
I.3.1. Bloque de atributos externos ......................................................................................... 8
I.3.2. Bloque de preguntas ...................................................................................................... 8
I.3.3. Bloque de reglas............................................................................................................ 9
I.3.4. Bloque de acciones ..................................................................................................... 10
I.4. Compilación ....................................................................................................................... 10
I.4.1. Compilación en UCShell ............................................................................................ 11
I.5. Proceso de inferencia ......................................................................................................... 12
I.5.1. Direcciones de búsqueda ............................................................................................ 15
I.6. Interfaz Visual ................................................................................................................... 17
I.6.1. Interfaz con el usuario ................................................................................................. 19
I.7. Árbol de Inferencia ............................................................................................................ 20
I.8. Pruebas de Software .......................................................................................................... 21
I.8.1. Tipos de pruebas ......................................................................................................... 21
I.9. Conclusiones del capítulo .................................................................................................. 29
II. INGENIERÍA DE CONOCIMIENTO. REINO ANIMAL ................................................. 30
II.1. Introducción ...................................................................................................................... 30
II.2. Ingeniería del Conocimiento ............................................................................................ 30
II.2.1. Extracción del conocimiento ..................................................................................... 31
II.3. Conjunto de prueba: El Reino Animal ............................................................................. 33
II.3.1. Filogenia .................................................................................................................... 33
II.4. Adquisición de conocimiento ........................................................................................... 34
II.5. Sistema experto de clasificación taxonómica ................................................................... 34
II.5.1. Base de conocimientos para UCShell 2.1 .................................................................. 35
II.6. Conclusiones del capítulo ................................................................................................. 47
III. VISIÓN FUNCIONAL .......................................................................................................... 48
III.1. Introducción .................................................................................................................... 48
III.2. Compilación .................................................................................................................... 48
III.2.1. Detección de errores ................................................................................................. 48
III.2.2. Generación de la Forma Interna ............................................................................... 54
III.3. Inferencia ........................................................................................................................ 55
III.3.1.Ventanas .................................................................................................................... 59
III.3.2. Árbol de inferencia ................................................................................................... 60
III.4. Depuración ...................................................................................................................... 61
III.5. Interacción con el software ............................................................................................. 62
III.6. Conclusiones del capítulo ............................................................................................... 65
CONCLUSIONES ....................................................................................................................... 66
RECOMENDACIONES .............................................................................................................. 67
BIBLIOGRAFÍA ......................................................................................................................... 68
INTRODUCCIÓN
1
INTRODUCCIÓN La Ingeniería del Conocimiento es la rama de la Inteligencia Artificial (IA) dedicada al
diseño y desarrollo de los Sistemas Expertos (SE), los cuales son sistemas basados en un
cierto dominio del conocimiento.
El conocimiento que usan los SE puede provenir de la experiencia de uno o varios
expertos en ese dominio o de alguna fuente de información pública.
Los sistemas basados en conocimiento emplean métodos matemáticos, informáticos y
lingüísticos para crear nuevos saberes a partir del conocimiento explícito presente en los
documentos de las bases de datos bibliográficas o el acervo cultural de los expertos. En
este entorno el acto de descubrir debe diferenciarse de encontrar algo que ya existe y se
concibe como un acto genuino de creación de un conocimiento anteriormente no
existente. Los sistemas de conocimiento tienen su origen en los productos de software
ciencimétricos desarrollados para facilitar el análisis de grandes conjuntos documentales
(artículos científicos, patentes, tesis doctorales, etc.).
El instrumento adecuado para determinar la calidad de un producto de software no es
más que un conjunto de procesos de pruebas de sus componentes. En este proceso se
ejecutan pruebas dirigidas a componentes del software o al sistema de software en su
totalidad con el objetivo de medir el grado con que se cumplen los requerimientos. Es
imprescindible que todo sistema de programas se pruebe exhaustivamente, para detectar
sus defectos, antes de entregarse al cliente.
El sistema UCShell data de varios años y se ha utilizado por mucho tiempo en diferentes
lugares, su principal usuario ha sido el departamento de Ciencia de la Computación de la
Universidad Central “Marta Abreu” de Las Villas (UCLV) que le ha dado diferentes
usos: docente, investigativo y de aplicación, sin embargo nunca se ha hecho una prueba
real del producto y la existencia de varias versiones, que se han reprogramado en
diferentes lenguajes, no garantiza que la versión actual (2.1) esté probada en todas las
formas de explotación posibles.
UCShell 1.0, se implementó en el lenguaje Borland Pascal para el sistema operativo MS-
DOS. Usa una búsqueda dirigida por objetivos con el método primero en profundidad y
el parser del compilador se generó con la herramienta YACC. Con esta versión se hizo
INTRODUCCIÓN
2
el sistema experto Plástico para la fábrica INPUD, que está conformado por nueve bases
de conocimientos que permitieron explotar todas las facilidades de UCShell 1.0, pero la
puesta a punto del sistema Plástico no fue una prueba real de validación ya que no
cumplía con todos los requisitos que exige este tipo de prueba.
La segunda versión, denominada WUCShell, se implementó en el lenguaje Object
Pascal para el sistema operativo Windows y las diferencias fundamentales con la
primera eran dos: una nueva interfaz basada en las ventanas típicas del sistema operativo
y el hecho de que el compilador se hizo manualmente, esto último en lugar de ser una
ventaja ha sido una desventaja por lo difícil que resulta agregar nuevas sentencias al
lenguaje. Para WUCShell se usó el sistema Plástico y se han hecho muchos otros
sistemas por los estudiantes los cuales en realidad no explotan todas las funcionalidades
del sistema.
UCShell 2.0 se programó en el lenguaje Java y no está concebida para un sistema
operativo particular debido a que se ejecuta sobre la máquina virtual de Java. La nueva
versión retoma el nombre original e incorpora la búsqueda dirigida por datos.
Finalmente se obtuvo la versión 2.1 que tomó en cuenta todas las experiencias anteriores
con el propósito de resolver sus posibles problemas y continuar cualquier desarrollo
ulterior sobre esta plataforma.
UCShell 2.1, dio un salto en calidad, sin embargo sus usuarios han reportado algunos
errores que necesitan corregirse y por eso se realiza el presente trabajo que está
específicamente encaminado a la prueba, verificación y futura corrección de sus errores.
Problema de investigación
¿Qué tipo de prueba debe hacerse para poder detectar todas las posibles fallas del
sistema UCShell?
Objetivo general
Realizar un estudio acerca de todas las facilidades con que cuenta UCShell con el
propósito de detectar posibles errores de funcionamiento para sugerir soluciones y
mejoras.
INTRODUCCIÓN
3
Objetivos Específicos
1. Crear un SE para clasificar animales que servirá como patrón de prueba del sistema
USChell 2.1.
2. Determinar las carencias de UCShell para poder resolverlas.
Preguntas de investigación
1. ¿Presentará la versión 2.1 del sistema UCShell vicios que deban corregirse?
2. ¿El desarrollo de un SE complejo sobre UCShell hará visible las carencias
funcionales y lógicas del sistema?
3. Tomando en cuenta los problemas detectados, ¿se podrá obtener una versión
mejorada de la máquina de inferencia de UCShell que permita dar por “terminada” la
herramienta?
Justificación de la investigación
Aunque la última versión de UCShell está totalmente funcional se deben explorar todas
sus funcionalidades para buscar posibles fallas no detectadas y funcionalidades no
incluidas que estén avaladas por la práctica.
Hipótesis
Las pruebas que se le efectúan al sistema UCShell permiten explotar todas sus
funcionalidades de forma tal que es posible detectar sus carencias para corregirlas y
poder entregar, en un futuro, una versión libre de fallas.
El trabajo que se presenta está estructurado en tres capítulos. En el capítulo I, “UCShell,
los sistemas expertos y las pruebas de programas”, se ofrece una panorámica general
acerca del sistema UCShell y su imbricación en el tema de los sistemas expertos para
después detallar las técnicas de pruebas de programas. El segundo capítulo “Ingeniería
de conocimiento. Reino animal”, discute aspectos generales de la ingeniería del
conocimiento que particulariza en la creación del sistema experto que se usa para probar
el sistema UCShell, detallando especificidades de este último que inciden en el nuevo
sistema experto. En el tercer capítulo “Visión funcional” se discuten aspectos propios
del funcionamiento del sistema UCShell y se enfatiza en los errores detectados en el
sistema, lo que constituye el eje central de este trabajo.
CAPÍTULO I
4
I. UCSHELL, LOS SISTEMAS EXPERTOS Y LAS
PRUEBAS DE PROGRAMAS
I.1. Introducción
UCShell 2.1 es una herramienta para desarrollar sistemas expertos que se programó en el
lenguaje Java, cuenta con un Ambiente de Desarrollo Integrado (IDE por sus siglas en
inglés) que hace uso de la biblioteca UCShell Library 2.0, esta última contiene los
mecanismos de inferencia y de compilación. El sistema incluye un editor de bases de
conocimiento que posee facilidades comunes a estas aplicaciones, tales como: resaltado
y completamiento de las palabras reservadas, búsqueda de expresiones, copiado, pegado
etcétera.
En el presente capítulo se ofrece una panorámica general de los sistemas expertos,
destacándose las particularidades de UCShell 2.1, y se analizan los distintos tipos de
pruebas que se le pueden aplicar a los programas con el propósito de determinar las que
se usarán en la verificación de funcionalidad a la que será sometido el sistema UCShell.
I.2. Los Sistemas expertos
La inteligencia artificial es el área de las ciencias que desarrolla o usa técnicas para
permitir a las computadoras actuar de la misma manera que lo hace un organismo
inteligente. Los objetivos varían desde los extremos más débiles, donde un programa
parece “un poco más inteligente” de lo que cabría esperar, hasta el extremo más fuerte,
donde el intento es desarrollar una entidad, basada en computadora, completamente
consciente e inteligente. El extremo inferior está continuamente desapareciendo en el
marco general de la informática (Raynor, 1999).
Los sistemas expertos constituyen un campo particular de investigación dentro de la IA
y se pueden definir como una aplicación informática que es capaz de aconsejar,
categorizar, analizar, comunicar, consultar, diseñar, diagnosticar, explicar, explorar,
formar conceptos, interpretar, justificar y planificar.
Los verbos resaltados en caracteres itálicos del párrafo anterior le atribuyen capacidades
a los SE que necesitan una intervención humana especializada, de ahí que un SE debe
CAPÍTULO I
5
actuar como un especialista humano (un experto) en un dominio particular o área de
conocimiento.
I.2.1. Arquitectura de los Sistemas Expertos
Aunque existen distintas arquitecturas que describen, de forma funcional y organizativa,
a las aplicaciones informáticas conocidas como sistemas expertos, todas ellas tienen los
componentes que se describen en los epígrafes siguientes.
I.2.1.1. Base de Conocimiento
Para que el SE tenga el conocimiento que atesoran los expertos humanos y las fuentes
bibliográficas, es necesario codificarlo e incorporarlo a la aplicación.
El componente que contiene el conocimiento de un SE se denomina Base de
Conocimiento (BC). En ella se almacena una formulación simbólica del conocimiento
que debe manejar el sistema.
La construcción de la BC es un punto crucial en el desarrollo del sistema experto,
cualquier error de diseño o de formulación del conocimiento en sí hará que el SE no
funcione en forma correcta.
I.2.1.2. Memoria de Trabajo
El saber contenido en la BC se almacena durante la etapa de diseño del SE y queda ahí
durante toda la vida del SE.
Por otra parte cuando se inicia el proceso de inferencia se comienzan a obtener nuevos
conocimientos que no estaban presentes en la BC. Ese conocimiento es necesario
almacenarlo temporalmente para usarlo en otras inferencias y en el reporte que se le dará
al usuario del SE. La memoria de trabajo (MT) es el lugar donde el motor de inferencia
deja la información deducida a partir de la BC y de la memoria de trabajo en sí.
I.2.1.3. Motor de Inferencia
El motor o máquina de inferencia es el responsable de realizar el proceso de
“razonamiento” o inferencia, para hacerlo debe explorar la BC y la MT y la forma en
que lo haga dependerá de la dirección de búsqueda y método de solución de problemas
que disponga entre sus herramientas.
CAPÍTULO I
6
También se encarga de proporcionar al trazador de explicaciones, las reglas que
motivaron una determinada consulta al usuario.
El Motor de Inferencia puede trabajar bajo dos principios:
Universo cerrado. Establece que toda información necesaria está contenida en el
sistema y en consecuencia lo que no puede demostrar como verdadero lo supone
falso.
Universo abierto. Establece que la información necesaria que no está contenida
en el sistema, está fuera de él y en consecuencia se comunica con el usuario.
I.2.1.4. Trazador de Consultas
Organiza y presenta en una forma semántica y sintácticamente aceptable para el usuario,
los requerimientos de información del sistema, las respuestas suministradas por el
usuario serán asentadas en la MT.
I.2.1.5. Trazador de Explicaciones
Es la parte del sistema responsable de explicar a los usuarios del porqué de sus
preguntas.
I.2.1.6. Manejador de Comunicaciones
Este módulo tiene dos responsabilidades:
Derivar la información inicial que suministra el usuario hacia la MT
Interpretar los mensajes del usuario: respuesta a una pregunta formulada por el
sistema o solicitud de una explicación.
Un resumen gráfico de las interrelaciones entre cada uno de los componentes
mencionados se puede apreciar en la figura I.1.
CAPÍTULO I
7
Figura I.1. Interrelaciones entre cada uno de los componentes de un Sistema Experto
I.3. Estructura de las bases de conocimiento de UCShell
La máquina de inferencia de cualquier SE actúa sobre sus bases de conocimientos y la
memoria de trabajo, de ahí que para hacer pruebas que validen el funcionamiento de
UCShell es importante conocer la estructura de este componente de su arquitectura y la
forma en que se representa el conocimiento contenido en ella.
La figura I.2 muestra la sintaxis de una base de conocimiento para UCShell. Cada base
está constituida por cuatro bloques que se identifican por una palabra reservada a su
inicio. El único bloque obligatorio es el de acciones y las bases terminan con la palabra
reservada End seguida por un punto. Los bloques son:
De atributos externos (comienza con External).
De preguntas (se inicia con Asks).
De reglas (Rules marca su comienzo).
De acciones (Actions denota su inicio).
CAPÍTULO I
8
Figura I.2. Sintaxis de la Base de Conocimiento
I.3.1. Bloque de atributos externos
Comienza con la palabra reservada EXTERNAL y si existe tiene que ser el primero. El
propósito del bloque es definir los atributos que conservan sus valores cuando se
produce un cambio, durante el proceso de inferencia, de una base de conocimiento a
otra. El cambio lo hace la máquina de inferencia cuando se encuentra la sentencia Chain
obase, en ese instante se produce un cambio de contexto desde la base actual hacia la
nueva base (simbolizada por obase en este caso) y el sistema elimina la forma interna de
la base anterior para cargar la base nueva, pero conserva los atributos de la base vieja
que se hayan incluidos en el bloque de atributos externos de la base nueva. Los atributos
aparecen en el bloque separados por comas.
I.3.2. Bloque de preguntas
Este bloque está precedido por la palabra reservada ASKS y cuando existe el bloque de
atributos externos se sitúa después de él (en caso contrario es el primer bloque). El
bloque contiene todos los atributos que deben preguntarse al usuario (se dice que son
atributos tipo preguntas).
Cada atributo tipo pregunta se declara con la palabra reservada ASK, como se aprecia en
el ejemplo de la figura I.3.
CAPÍTULO I
9
Figura I.3. Ejemplo de Ask declarado dentro de una base de conocimiento
La sintaxis para declarar un atributo tipo pregunta es la siguiente:
ASK <Atributo>: 'Texto 1' + 'Texto 2', +…
[[CHOICES 'R1','R2' …] | [DOMAIN [Image ('a1'):=] 'R1', [Image ('a2'):=] 'R2', …
]]
[BECAUSE 'Texto 1', 'Texto 2',…]
Donde <Atributo> es el nombre del atributo tipo pregunta y CHOICES o DOMAIN
(uno de ellos, no pueden usarse los dos) contienen las posibles respuestas que, para el
caso de DOMAIN, pueden ir acompañadas de una imagen que estará contenida en un
archivo (a1, a2 en este caso). Si el atributo no tiene CHOICES ni DOMAIN significa
que no se conocen las posibles respuestas.
La parte BECAUSE se usa para escribir la explicación que se le dará al usuario si este
indaga sobre el porqué de la pregunta formulada.
I.3.3. Bloque de reglas
Es el bloque que contiene el conocimiento expresado en forma de reglas de producción o
sea en la forma IF… THEN…, lo que significa: SI se cumplen las condiciones de la
regla ENTONCES se arriba a la conclusión que se especifica. Este bloque está precedido
por la palabra reservada RULES y termina con la declaración del bloque de acciones
(que no es opcional). La declaración de una regla comienza por la palabra reservada
RULE y termina con END;. Una regla, internamente, está compuesta por el número de
la regla; la condición de la regla; una lista de conclusiones; la certidumbre de la regla; la
explicación de la regla y una lista de acciones, la figura I.4 muestra un ejemplo de regla.
CAPÍTULO I
10
Figura I.4. Ejemplo de declaración de una regla dentro de una base de conocimiento
I.3.4. Bloque de acciones
Es el único bloque que no es no opcional y define las acciones que ejecutará la máquina
de inferencia. Todo el proceso de inferencia se inicia y finaliza en este bloque. Dentro de
las acciones que pueden provocar el inicio de la inferencia están: FIND, FINDALL y
FINDFORWARD. Este bloque está precedido por la palabra reservada ACTIONS.
El fin de la base de conocimiento se reconoce con la expresión “END.”. Una base de
conocimientos para UCShell admite comentarios en cualquier parte, los cuales son
ignorados por el compilador pero ayudan a darle claridad a los sistemas elaborados.
I.4. Compilación
Para que una máquina de inferencia realice el proceso de deducción es necesario que
pueda interpretar el conocimiento que está contenido en sus bases de conocimiento. En
general existen dos formas de hacerlo:
La primera es interpretar línea a línea el contenido de la base de conocimiento tal
y como lo hacen muchos lenguajes interpretados.
La segunda es someter la base a un proceso de traducción para que la deje en
alguna forma interna que sea reconocida por la máquina de inferencia, de forma
que la pueda interpretar, ese proceso se conoce por compilación.
Un compilador es un programa informático que traduce un programa escrito en un
lenguaje de programación a otro que deberá ser interpretado por alguna instancia.
CAPÍTULO I
11
Usualmente el segundo lenguaje es el lenguaje de máquina, pero también puede ser
simplemente un texto. La construcción de un compilador involucra la división del
proceso en una serie de fases que variará con su complejidad. Generalmente estas fases
se agrupan en dos tareas: el análisis del programa fuente y la síntesis del programa
objeto (Laborda et al., 1985).
Las gramáticas constituyen la mejor vía para la descripción sintáctica 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. Algo muy importante cuando se usan
gramáticas para generadores automáticos de parser es que resulta fácil añadir nuevas
construcciones al lenguaje (Salazar Acosta, 2012).
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.
I.4.1. Compilación en UCShell
Las bases de conocimientos para el sistema UCShell se basan en la forma de
representación del conocimiento conocida como reglas de producción y se pueden
escribir en el editor de texto que está incorporado a su IDE. Una vez que se ha escrito
una base de conocimiento se debe guardar en un archivo con extensión kbs. El
compilador del sistema toma como entrada la base de conocimiento (archivo .kbs) y la
compila para producir una forma interna, si no existen errores, que almacena en un
archivo con extensión kbo.
La estructura sintáctica del lenguaje reconocido por el compilador de UCShell se basa en
una gramática libre de contexto y sus bases de conocimientos están formadas por cuatro
bloques que permiten organizar el saber expresado en ellas en una forma clara y
armónica.
CAPÍTULO I
12
I.4.1.1. Errores
Los errores forman parte de la vida y su ocurrencia en el desarrollo de un producto de
software es habitual, por eso el compilador y la máquina de inferencia deben estar
preparados para enfrentarse a ellos.
I.4.1.1.1. Errores Sintácticos
El análisis sintáctico (parser) se hace a nivel de sentencias. Su función es tomar el
programa fuente en forma de lexemas (tokens), que recibe del analizador léxico y
determinar la estructura de las sentencias del programa. Este proceso es análogo a
determinar la estructura de una frase en cualquier idioma, identificando quién es el
sujeto, el predicado, el verbo y los complementos. Un error de sintaxis típico puede
presentarse cuando el analizador sintáctico encuentra un símbolo que no corresponde al
esperado.
Para la detección de estos errores UCShell implementa el modo pánico y detiene la
compilación en el momento que encuentra el error. La principal ventaja de este modo es
la detección de errores lo más rápidamente posible, aunque eso conlleva a la
recompilación cada vez que se corrija uno.
I.4.1.1.2. Errores Semánticos
Los errores semánticos corresponden a la interpretación de lo que se dice y se reconoce
durante el proceso de inferencia, por ejemplo cuando se intenta realizar una operación y
los tipos de los operadores no son permitidos. Estas situaciones no se pueden reconocer
durante el proceso de compilación porque no se sabe aún cuáles valores van a tomar los
atributos.
Cada operador tiene una clase asociada en la cual está implementada la rutina de
manipulación de los errores a los que es susceptible. Una vez que UCShell comprueba
que el sistema no contiene errores, genera la forma interna a partir de la cual se podrá
realizar el proceso de inferencia.
I.5. Proceso de inferencia
La palabra inferencia en este contexto significa derivar nuevos hechos a partir de las
reglas almacenadas en la base de conocimiento y los hechos preestablecidos o inferidos
CAPÍTULO I
13
anteriormente. El motor de inferencia utiliza la base de conocimientos y los hechos para
adquirir nuevos conocimientos acerca del problema que está resolviendo.
Existen distintos tipos de inferencias, entre las que se pueden citar las siguientes:
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 (CÉSARI, 1990).
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 (Turban, 1995).
Inferencia analógica: Este tipo de inferencia resulta natural para los humanos pero
es difícil lograrla mecánicamente, en ella se asume que la respuesta a una pregunta 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.
La inferencia difusa: Es un método que interpreta los valores en el vector de
entrada y, basado en algún conjunto de reglas, asigna valores al vector de salida. Los
sistemas de inferencia más comunes son el sistema Mamdani y el Takagi-Sugeno
(Llano et al., 2007).
La inferencia probabilística: Una inducción permite establecer una verdad con
mayor índice de probabilidad que las demás.
El mecanismo de inferencia de UCShell (2.0 y 2.1) usa la clase “Inference” (contenida
en el paquete “inference”). Esta clase implementa los métodos para inferir y también es
la responsable de cargar la forma interna de la base de conocimiento, a continuación se
detallan los atributos y métodos de este paquete.
Los atributos que toman los valores de la forma interna son:
LinkedList<Tvar> externalVars: Variables externas al sistema.
LinkedList<Trules> rules: Reglas de la Base de Conocimiento.
LinkedList<Tasks> asks: Atributos tipo preguntas.
LinkedList<Taccion> actions: Acciones.
SymTab table: Tabla de símbolos.
LinkedList<Tfact> facts: Los hechos que toman valores durante la inferencia.
CAPÍTULO I
14
String currprojectName: Nombre del proyecto actual.
QuestionMaker qm: Objeto que implementa la interfaz QuestionMaker. Define el
comportamiento de las ventanas con las que interactúa el usuario cuando responde las
preguntas. El método a implementar en esta interfaz es:
Fact makeQuestion (Ask ask): En este método se define la forma en que se
interrogará al usuario y recibe, por parámetros, un objeto de tipo Ask que contiene toda
la información relativa a la pregunta. Una vez contestada la interrogante se devuelve un
objeto de tipo Fact que contiene los detalles de la respuesta dada por el usuario.
Displayer displayer: Objeto que implementa la interfaz Displayer. Define cómo se
mostrarán los datos al usuario: textos, imágenes o videos. Los métodos a implementar
son:
void display (String cadena): Se define cómo el sistema mostrará una cadena.
void displayWithImage (String imageDir): Se define cómo el sistema mostrará una
imagen, la dirección de la misma es imageDir.
void displayWithVideo (String video): Se define cómo el sistema mostrará un
video. La ubicación del video está contenida en la cadena video.
Métodos
void initInference (Displayer displayer, QuestionMaker qm): Es necesario llamar a
este método antes de realizar la inferencia. En él se le asigna a la clase Inference los
objetos que implementan la interfaz: Displayer y QuestionMaker.
boolean infer (String filename, String errorsFileName, String
standardOutInferenceFileName, String currProjectName): Este método es el que carga la
forma interna y realiza la inferencia, devolviendo true o false si tiene éxito o no. Los
parámetros que se le pasan al método son:
String fileName: El nombre del archivo que contiene la forma interna de la base de
conocimiento.
String errorsFileName: el nombre del archivo donde se guardarán los errores
detectados durante la inferencia.
String standardOutInferenceFileName: El nombre del archivo donde se guardarán los
mensajes enviados por el sistema, en caso de que se envíe alguno.
CAPÍTULO I
15
String currProjectName: La dirección del proyecto actual.
De manera general, cuando se quiere inferir debe crearse un objeto de la clase Inference,
luego llamar al método initInference pasándole por parámetros los objetos displayer y
questionMaker. Finalmente se llama al método infer con los parámetros requeridos. Una
vez terminada la inferencia los hechos probados se encontrarán en el atributo facts de la
clase Inference.
La implementación de la máquina de inferencia 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). Las dos direcciones de búsqueda se detallan seguidamente.
I.5.1. Direcciones de búsqueda
La máquina de inferencia es el módulo de un Sistema Experto encargado de encontrar la
solución a un problema dado, para hacerlo usa la información almacenada en la base de
conocimientos y los datos iniciales del problema. La implementación de la máquina de
inferencia 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.5.1.1. Dirección de búsqueda backward
La búsqueda con encadenamiento hacia atrás (backward chaining) o proceso de
inferencia dirigida por objetivos 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 proceso de búsqueda de un objetivo cualquiera se construye un árbol de búsqueda
que tiene en su raíz el objetivo buscado. El siguiente nivel del árbol se genera
encontrando todas las reglas cuyas conclusiones concuerden con el nodo raíz y usando
CAPÍTULO I
16
las condiciones para crear los nuevos estados. Este proceso continúa hasta generar un
estado que concuerde con el estado inicial (Bello, 2000).
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. Esta búsqueda se desencadena en UCShell mediante las
sentencias FIND y FINDALL.
La ejecución de la sentencia FINDALL es similar a la de la sentencia FIND, la
diferencia radica en que la búsqueda de una solución provocada por FIND se detiene
cuando encuentra la primera solución, mientras FINDALL busca todas las soluciones
posibles y las inserta en la lista de hechos de la clase Inference, de forma que cuando
termina de ejecutarse esta acción la lista puede contener varios valores, los cuales se
pueden ver mediante la interfaz visual.
I.5.1.2. Dirección de búsqueda forward
La búsqueda con encadenamiento hacia delante (forward chaining) o proceso de
inferencia dirigida por datos 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 comienza a construirse el árbol situando como raíz el
estado inicial. El siguiente nivel del árbol se genera encontrando todas las reglas cuyas
partes condiciones concuerden con el nodo raíz y usando sus partes conclusiones para
CAPÍTULO I
17
crear los nuevos estados. De esta manera el proceso continúa hasta generar un estado
que satisfaga o no las condiciones.
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 solución de problemas de planificación,
monitorización e interpretación.
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. UCShell usa la sentencia findforward para
desencadenar este tipo de búsqueda.
I.5.1.3. Bidireccional
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). UCShell no usa esta dirección de búsqueda.
I.6. Interfaz Visual
La interfaz gráfica de UCShell 2.1 permite hacer tres acciones básicas sobre las bases de
conocimientos: compilar, ejecutar inferencias y editar. El entorno gráfico se sirve de
menús y cuadros de diálogos que facilitan la interacción con el conocimiento, ocultando
los procesos que pueden ser de difícil comprensión para el usuario final, el cual
usualmente no tiene conocimientos avanzados de computación.
La ventana principal del sistema se puede ver en la figura I.5. Puede apreciarse, a la
izquierda, el árbol de proyectos y a la derecha el panel donde se carga la base de
conocimiento seleccionada para su edición y debajo el panel donde se muestran los
mensajes del sistema.
CAPÍTULO I
18
Figura I.5. Ventana principal de UCShell 2.1
Se puede observar además la barra de herramientas, la cual ofrece un acceso rápido a
algunas de las funcionalidades del software. Mediante la barra de Menú se puede
acceder a la totalidad de las funciones del sistema.
La versión actual de UCShell numera las líneas del código fuente con el objetivo de que
el usuario pueda localizar, fácilmente, los errores detectados durante el proceso de
compilación (los números no forman parte del código). La figura I.6 muestra un
ejemplo, en este caso el compilador ha detectado un lexema no permitido (la coma
después del AND en la línea 531) e informa en qué línea está el error, de forma que el
ingeniero de conocimiento puede localizarlo y arreglarlo sin mayores dificultades.
CAPÍTULO I
19
Figura I.6. Ejemplo del editor con el número de línea.
I.6.1. Interfaz con el usuario
El diálogo entre el sistema experto y el usuario se realiza a través de las preguntas
lanzadas por el sistema y las respuestas brindadas por el usuario. Las preguntas pueden
tener asociadas imágenes y posibles respuestas para que se escoja una de ellas o pueden
ser respondidas editando la respuesta, la figura I.7 muestra un ejemplo en que se hace
una pregunta y el usuario tiene dos alternativas de respuesta (sí o no), también se aprecia
que la respuesta sí tiene una imagen asociada y que se puede responder con un valor de
certidumbre. En este caso el botón Because está desactivado pero si estuviera activo el
usuario puede pedir una explicación acerca de por qué el sistema le pregunta eso.
De acuerdo a la forma en que se haya codificado la base de conocimiento, el sistema
puede informar los resultados en cualquier momento de la inferencia o brindar cualquier
otra información, para lo cual se debe usar la sentencia DISPLAY. La figura I.8 muestra
una ventana donde se informan algunos de los resultados obtenidos por el sistema. Esta
sentencia se puede usar en cualquiera de los bloques de acciones (de las reglas o del
bloque de acciones principal).
CAPÍTULO I
20
Figura I.7. Ejemplo de pregunta hecha por el sistema
Figura I.8. Ventana solución
I.7. Árbol de Inferencia
El árbol de inferencia o árbol de decisión (figura I.9) es una nueva funcionalidad añadida
a UCShell 2.1. Para su implementación se utilizó la biblioteca Jung, que brinda soporte
para una variada representación de entidades y sus relaciones, e incluye, además,
implementaciones de algoritmos de teoría de grafos y análisis exploratorio, entre otros.
Esta y otras funcionalidades del sistema UCShell son muy útiles y deben probarse en la
práctica para certificar que están funcionales totalmente, en el epígrafe siguiente se hace
una descripción de las pruebas que se le pueden realizar al software.
CAPÍTULO I
21
Figura I.9. Árbol de Inferencia
I.8. Pruebas de Software
El desarrollo de cualquier sistema de software implica la realización de una serie de
actividades predispuestas a incorporar fallos, es totalmente normal que esos fallos de
funcionamiento ocurran debido a la habilidad innata de los humanos de provocar errores.
En sentido estricto, deben realizarse pruebas de todos los artefactos generados durante la
construcción de un producto, lo que incluye especificaciones de requisitos, casos de uso,
diagramas de diversos tipos y, por supuesto, el código fuente y el resto de los productos
que forman parte de la aplicación.
I.8.1. Tipos de pruebas
Los tipos de pruebas pueden clasificarse en dos grandes grupos en dependencia de si
necesitan la ejecución del código de la aplicación o no, las primeras se denominan
dinámicas y las segundas estáticas. También se pueden agrupar de acuerdo a otros
criterios tales como: el enfoque, el nivel, la funcionalidad que se desea probar o de
acuerdo a la ejecución.
De acuerdo al nivel se clasifican en tres grupos. Las pruebas unitarias, que buscan
asegurar que el código funcione de acuerdo con las especificaciones y que el módulo
lógico sea válido, las pruebas de integración para identificar errores introducidos por la
combinación de programas probados unitariamente y las pruebas de sistema con el
CAPÍTULO I
22
objetivo de asegurar una navegación apropiada dentro del sistema, ingreso de datos,
procesamiento y recuperación (Rodríguez Tello, 2011).
Por otra parte las pruebas funcionales tienen el objetivo de detectar los errores en
versiones iniciales de manera fácil. Probar el sistema constantemente garantiza poco
esfuerzo en su integración y asegura los resultados de las pruebas unitarias, reduciendo
los riesgos y la baja calidad. Se pueden realizar: pruebas de regresión para determinar si
los cambios recientes en una parte de la aplicación tienen efecto adverso en otras partes;
pruebas de aceptación para detectar errores en el sistema bajo un ambiente controlado y
beta testigo para realizar la validación del sistema por parte del usuario.
Las pruebas no funcionales son el mayor grupo, estas pruebas son: de seguridad, de
usabilidad, de rendimiento, de internacionalización y localización, de escalabilidad, de
posibilidad de mantenimiento, de facilidad de instalación y de portabilidad (Rodríguez
Tello, 2011).
Por su ejecución, las pruebas se separan en tres grupos: manuales, automáticas y lógicas
y por su enfoque se separan en dos tipos: de caja blanca (o estructurales) que tienen
como objetivo probar que todos los caminos del código están correctos y de caja negra
(o funcionales) que tienen como objetivo probar que tan bien cumple el programa con
los requerimientos.
El objetivo de este trabajo de investigación y desarrollo es comprobar qué tan bien se
cumplen los objetivos para los que fue creado UCShell, en ese sentido pueden ser
valiosas las pruebas de caja blanca y de caja negra que se describen a continuación.
I.8.1.1. Pruebas de Caja Blanca
El objetivo en este tipo de prueba es encontrar casos de prueba “viendo” el código
interno. El conocimiento del diseño interno del software se usa para desarrollar los casos
de pruebas y asegurar que la operación interna y las especificaciones del programa se
ajustan a lo que se pretendió hacer (se prueban todos los componentes) (Carolina
Martinez, 2012). Algunas de las pruebas de estructura de control son de camino básico,
para ellas se diseña un caso de prueba por cada camino independiente, pueden ser: de
condiciones, todas las condiciones del programa se evalúen como cierto/falso, de bucles
se intenta ejecutar un bucle 0,1,…, n-1, n y n+1 veces (siendo n el número máximo).
CAPÍTULO I
23
En la figura I.10 se muestra una imagen de esta prueba.
Figura I.10. Caja Blanca
Cuando se pasan casos de prueba al programa que se está probando, es conveniente
conocer qué porcentaje del programa se ha ejecutado, de manera que se casi se pueda
asegurar que todo es correcto (evidentemente, es imposible alcanzar una certeza del
100%). Existen varias formas de medir la cobertura lograda en el programa por los casos
de prueba, algunas de las cuales se presentan a continuación.
I.8.1.1.1. Criterios de cobertura
De acuerdo con Cornett (Cornett, 2002), el análisis de cobertura del código es el proceso
de encontrar fragmentos del programa que no se ejecutan con los casos de prueba para
después crear casos de prueba adicionales que incrementen la cobertura y determinar un
valor cuantitativo de esta (que es, de manera indirecta, una medida de la calidad del
programa). Adicionalmente, su análisis también permite la identificación de casos de
prueba redundantes, que no incrementan la cobertura. Los casos pueden ser de varios
tipos (Polo Usaola, 2010):
Cobertura de sentencias: Comprueba la cantidad de sentencias ejecutables que se han
activado.
Cobertura de decisiones: Comprueba la cantidad de decisiones ejecutadas,
considerando que lo ha hecho cuando se han recorrido todas sus posibles ramas (la que
la hace verdadera y la que la hace falsa, pero también todas las posibles ramas de un
condicional de múltiples selecciones o switch).
Cobertura de condiciones: Comprueba el número de condiciones activadas,
entendiendo que se ha ejecutado una condición cuando lo han hecho todas sus posibles
ramas.
CAPÍTULO I
24
Cobertura de condiciones múltiples: Comprueba el número de condiciones múltiples
ejecutadas, considerando que se ha activado una condición múltiple cuando todas sus
correspondientes ramas con todas las posibles variantes de la instrucción condicional lo
han hecho.
Cobertura de condiciones/decisiones: Comprueba el número de condiciones y
decisiones activadas hasta el momento.
Cobertura de caminos: Comprueba el número de caminos linealmente independientes
que se han ejecutado en el grafo de flujo de la unidad que se está probando. El número
de caminos linealmente independientes coincide con la complejidad ciclomática de
McCabe (McCabe, 1976).
Cobertura de funciones: Comprueba el número de funciones y procedimientos que se
han llamado.
Cobertura de llamadas: Comprueba el número de llamadas a funciones y
procedimientos que se han ejecutado. No debe confundirse con la cobertura de
funciones: en la cobertura de funciones se cuenta la cantidad de funciones del programa
que se llamaron mientras que la cobertura de llamadas cuenta cuántas de las llamadas a
funciones que hay en el programa se han ejecutado.
Cubrimiento de bucles: Comprueba la cantidad de bucles que han sido ejecutados cero
veces (excepto para bucles do while), una vez y más de una vez.
Cubrimiento de carrera: Comprueba el número de tareas o hilos que han ejecutado
simultáneamente el mismo bloque de código.
Cobertura de operadores relacionales: Comprueba si se han ejecutado los valores
límites en los operadores relacionales (>, <, >=, <=), ya que se asume la hipótesis de que
estas situaciones son propensas a errores.
Cobertura de tablas: Comprueba si se ha hecho referencia a todos los elementos de los
arreglos.
I.8.1.1.2. Mutación
Un mutante es una copia del programa que se está probando (programa “original”) al
que se le ha introducido un único y pequeño cambio (normalmente sintáctico, como la
sustitución de un signo + por un *), lo que supone tener una versión defectuosa del
CAPÍTULO I
25
programa original. Supóngase que se ejecuta un mismo caso de prueba en el programa
original y en el mutante, y suponiendo, además, que la salida del programa original es
correcta, y la salida del mutante difiere en algo de la salida del original. Entonces, se
puede asegurar que, para ese caso de prueba, la instrucción mutada es correcta en el
programa original (Polo Usaola, 2010).
Si a ambos programas se le pasa una batería de casos de prueba y siempre se obtuvieran
resultados correctos en el original e incorrectos en el mutante, se podría afirmar, con
poco temor a equivocarse, que la instrucción mutada del programa es correcta. Un
mutante que produce la misma salida que el programa original se dice que está vivo, y
muerto si su salida es diferente. Cuantos más mutantes se logre matar, se estará logrando
mayor cobertura del programa original, lo que de manera indirecta es una medida de la
calidad del programa. Tradicionalmente, se considera que para matar a un mutante
deben producirse tres condiciones:
Alcance: la sentencia mutada debe ser ejecutada por el caso de prueba.
Necesidad: entre la entrada y la salida del programa debe crearse un estado intermedio
erróneo.
Suficiencia: el estado incorrecto debe propagarse hasta la salida del programa.
La condición de suficiencia puede ser difícil de conseguir en muchas ocasiones, lo que
puede dificultar la obtención de casos de prueba a un coste razonable. La mutación débil
se queda en la condición de necesidad para determinar que un caso de prueba ha matado
a un mutante: compara el estado intermedio del mutante y el del programa original
inmediatamente después de haber ejecutado la instrucción mutada, marcando el mutante
como muerto si los estados son diferentes. Se ha comprobado experimentalmente que
esta técnica puede ahorrar hasta el 50% del coste de las pruebas sin degradar
excesivamente su calidad (Polo Usaola, 2010).
I.8.1.2. Pruebas de Caja Negra
Este tipo de prueba verifica que el ítem que se está probando produce los resultados
esperados cuando se dan las entradas apropiadas. Los datos de prueba se escogen
atendiendo a las especificaciones del problema, sin importar los detalles internos del
programa (figura I.11), a fin de verificar que el programa corra bien. Con este tipo de
CAPÍTULO I
26
prueba se verifica el correcto manejo de funciones externas provistas o soportadas por el
software, se verifica que el comportamiento observado se apegue a las especificaciones
del producto y a las expectativas del usuario. Es necesario decir además que los casos de
prueba se construyen a partir de las especificaciones del sistema (Rodríguez Tello,
2011). Se pueden considerar como el complemento de las pruebas de caja blanca
(Carolina Martinez, 2012). Con este tipo de pruebas se pueden encontrar:
• Funciones incorrectas o ausentes.
• Errores de interfaz.
• Errores en estructuras de datos o en accesos a las bases de datos externas.
• Errores de rendimiento.
• Errores de inicialización y terminación.
Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce la
cantidad de casos de pruebas y dicen algo sobre la presencia o ausencia de errores. Los
casos de prueba que se eligen deben cumplir una serie importante de requerimientos,
tales como: que el caso ejecute el máximo número de posibilidades de entrada diferentes
para así reducir el total de casos, que cubra un conjunto extenso de otros casos posibles.
Cada caso debe cubrir el máximo número de entradas y debe tratarse el dominio de
valores de entrada dividido en un número finito de clases de equivalencia que cumplan
la siguiente propiedad: la prueba de un valor representativo de una clase permite suponer
«razonablemente» que el resultado obtenido (existan defectos o no) será el mismo que el
obtenido probando cualquier otro valor de la clase (Polo Usaola, 2010).
La prueba de caja negra ha hecho que cada organización dedicada al desarrollo de
software contemple dentro de ella un departamento especial dedicado a las pruebas.
El principal objetivo es determinar la funcionalidad del software y parte de tratar al
programa como si fuera una función matemática, estudiando si las respuestas o salidas
son codominio de los datos entrantes (dominio). La prueba de caja negra pretende
también determinar la eficiencia del programa desde el desempeño en el equipo, el
tiempo de retardo de las salidas hasta el nivel de recuperación del sistema luego de fallas
o caídas, sean estas producidas por manejo incorrecto de datos, equipos, o producidas
externamente como cortes de energía.
CAPÍTULO I
27
La prueba de caja negra debe cubrir el espectro entero de sucesos factibles, pero nunca
se sabe si se han cubierto todos los casos o gran parte de ellos y no termina una vez que
salió del laboratorio.
Figura I.11. Prueba de caja negra.
I.8.1.2.1. Partición equivalente
Una partición equivalente es un método de prueba de caja negra que divide el dominio
de entrada de un programa en clases de datos de los que se pueden derivar casos de
prueba. El diseño de casos de prueba para la partición equivalente se basa en la
evaluación de las clases de equivalencia (Carolina Martinez, 2012).
Un caso de prueba ideal descubre de forma inmediata una clase de errores que, de otro
modo, requerirían la ejecución de muchos casos antes de detectar el error genérico. La
partición equivalente se dirige a la definición de casos de prueba que descubran clases
de errores, reduciendo así el número total de casos de prueba que hay que desarrollar.
I.8.1.2.2. Análisis de valores límite
Este tipo de análisis lleva a elegir las pruebas que ejecutan los valores límite, con esta
técnica se complementa la partición equivalente. Los errores tienden a darse más en los
límites del campo de entrada que en el centro. Por ello, si la entrada se encuentra en el
rango a..b entonces hay que probar con los valores a -1, a, a+ 1, b - 1, b y b + 1, en otro
caso si la entrada es un conjunto de valores entonces hay que probar con los valores
max-1, max, max+1, min-1, min y min+1 (Carolina Martinez, 2012).
CAPÍTULO I
28
I.8.1.2.3. Prueba de comparación
Esta técnica consiste en la comparación de salidas de diferentes versiones de un mismo
software e implica una variada selección de los datos de prueba así como una buena
interpretación de los resultados para determinar el nivel de optimización de la
funcionalidad del sistema (Kaner 1993).
I.8.1.2.4. Métodos de prueba basados en grafos
Parte de determinar los objetos que se modelan en el software y las relaciones que los
conectan (objetos de datos, objetos de programa tales como módulos o colecciones de
sentencias del lenguaje de programación), para después definir una serie de pruebas que
verifiquen que todos los objetos tienen entre ellos las relaciones esperadas.
En este método se crea un grafo de objetos importantes y sus relaciones y se diseña una
serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus
relaciones para descubrir errores. Según Beizer (Beizer 2003) existe un número de
modelados para pruebas de comportamiento que pueden hacer uso de los grafos, que se
muestran a continuación.
Modelado del flujo de transacción
Los nodos representan los pasos de alguna transacción (por ejemplo, los pasos
necesarios para una reserva en una línea aérea usando un servicio en línea), y los enlaces
representan las conexiones lógicas entre los pasos (por ejemplo, vuelo, información,
entrada es seguida de validación /disponibilidad, procesamiento).
Modelado de estado finito
Los nodos representan diferentes estados del software observables por el usuario (por
ejemplo, cada una de las pantallas que aparecen cuando un telefonista coge una petición
por teléfono), y los enlaces representan las transiciones que ocurren para moverse de
estado a estado (por ejemplo, petición-información se verifica durante inventario-
disponibilidad-búsqueda y es seguido por cliente-factura-información-entrada).
Modelado de flujo de datos
Los nodos, objetos de datos y los enlaces son las transformaciones que ocurren para
convertir un objeto de datos en otro.
CAPÍTULO I
29
Modelado de planificación
Los nodos son objetos de programa y los enlaces son las conexiones secuenciales entre
esos objetos. Los pesos de enlace se usan para especificar los tiempos de ejecución
requeridos al ejecutarse el programa.
I.9. Conclusiones del capítulo
En muchas ocasiones un producto de software se da por terminado cuando el equipo de
diseño y programación lo entrega a los usuarios, muchas veces sin haber realizado antes
una validación total de todas sus funcionalidades.
El ambiente para el desarrollo de sistemas expertos UCShell posee diversas facilidades
(edición y compilación de bases de conocimientos, inferencia con traza o no, diversas
interfaces, etc.), lo que unido a que es una herramienta que permite crear otras (los
sistemas expertos) complejiza la tarea de certificar que esté totalmente validado.
Las pruebas de software son el medio más eficaz de comprobar la eficacia y eficiencia
de un software y consisten en la verificación dinámica de su comportamiento con una
cantidad finita de casos de prueba. Entre esas pruebas se pueden destacar las de caja
negra para detectar los errores funcionales y las de caja blanca con el objetivo de
detectar errores estructurales.
En este capítulo se han expuestos las diversas funcionalidades del sistema UCShell,
tomando en cuenta su funcionamiento e interfaz y se han analizado los distintas tipos de
pruebas, haciendo énfasis en las de caja negra y blanca, con el propósito de desarrollar
un sistema experto para clasificar animales que permita probar el sistema UCShell en
toda su funcionalidad.
CAPÍTULO II
30
II. INGENIERÍA DE CONOCIMIENTO. REINO
ANIMAL
II.1. Introducción
En el diseño y puesta a punto de un sistema experto intervienen dos actores, el o los
expertos y el ingeniero del conocimiento.
El experto es una persona que tiene un amplio y reconocido dominio en un área del
saber y el ingeniero del conocimiento es el encargado de extraer la experiencia del
experto para expresarlo, en alguna forma, en las bases del sistema.
En este capítulo se presenta la ingeniería del conocimiento realizada para la confección
del sistema experto Reino Animal, el cual se usa como modelo de prueba de la máquina
de inferencia empotrada en el ambiente de desarrollo para sistemas expertos UCShell.
II.2. Ingeniería del Conocimiento
La ingeniería del conocimiento es un área de la inteligencia artificial que se encarga del
diseño y desarrollo de los sistemas expertos. Para hacer su trabajo usa diferentes
metodologías que le permiten expresar, en alguna forma de representación del
conocimiento, el saber extraído de los expertos (conocimiento privado) y de la
bibliografía (conocimiento público).
De acuerdo a Feigenbaum (Edward Feigenbaum, 1983 ), la Ingeniería de Conocimiento
es la disciplina que comprende la integración del conocimiento a los sistemas de
computación con el objetivo de resolver problemas que normalmente necesitarían de un
elevado nivel de experiencia humana. Por ser una ingeniería, debe usar técnicas y
metodologías de carácter cuantitativo e instrumental (Polanco, 1998).
La tarea del ingeniero del conocimiento resulta difícil debido a que él no es un experto
en el campo que intenta modelar y el experto no tiene experiencia representando su
conocimiento, de ahí que existan diversas técnicas para extraer el saber, las cuales se
mencionan en el epígrafe siguiente.
CAPÍTULO II
31
II.2.1. Extracción del conocimiento
El proceso de extracción del conocimiento que poseen los expertos lleva implícitas
varias tareas, las cuales se pueden clasificar como: familiares, entrevistas, de
información limitada, de simulación del escenario hacia delante y de descomposición de
objetivos (García Martínez, 2012).
II.2.1.1. Tareas familiares
La idea central de este método es observar al experto cuando realiza su labor diaria. Se
debe documentar la información obtenida en estas observaciones para utilizarla en la
profundización de áreas específicas del conocimiento del experto en posteriores
sesiones.
En esta observación el ingeniero de conocimiento debe esclarecer:
Las similitudes y diferencias, establecidas por el experto, entre el problema en curso
de solución y otros resueltos previamente.
Las diferencias de términos y categorías establecidas por el experto.
La habilidad puesta en juego por el experto para inferir nueva información y
plantear nuevas hipótesis.
II.2.1.2. Entrevistas
En este tipo de tarea y a partir del discurso del experto, el ingeniero de conocimiento
identifica cuáles son los módulos de conocimiento. Debe priorizarse el acceso al experto
y minimizarse las interrupciones. Existen dos tipos de entrevistas:
Entrevista no estructurada
Consiste en hacer preguntas espontáneas al experto. Una técnica muy utilizada es poner
al ingeniero de conocimiento en el lugar de un novato para hacerle preguntas sobre
procedimientos, ideas sobreentendidas por el experto, tratando en todo momento de que
el experto piense en voz alta.
Entrevista estructurada
Combina la técnica de tareas familiares con entrevistas no estructuradas para formular
un protocolo de preguntas sobre áreas mal definidas o vacantes en los procesos de
deducción de conocimiento previamente realizados.
CAPÍTULO II
32
II.2.1.3. Tareas de información limitada
La idea de este método consiste en explorar alternativas que, en una primera
recopilación de información, no fueron suministradas por el experto; tomando cada tarea
y profundizando sobre aspectos que al experto puedan parecerle más relevantes. Puede
comenzarse con el método de tareas familiares para recopilar información y profundizar
utilizando las técnicas de procesamiento restringido.
II.2.1.4. Simulación del escenario hacia delante
En este caso el experto elige un escenario muy elemental y verbalmente “camina dentro
de él” usando los razonamientos necesarios para llegar al objetivo. Esta técnica toma
lugar en condiciones de laboratorio, no en el ambiente de trabajo del experto.
II.2.1.5. Descomposición de objetivos
La descomposición de objetivos es el acercamiento al problema por la técnica de
reducción tradicional y es útil para enumerar estados objetivos y describir sus categorías
generales. La técnica puede empezar con “Suponga que hay una X pero colapsa en…”
“¿Qué está impidiendo a X lograr su misión?”.
En la tabla II.1 se ofrece un resumen de las técnicas de extracción del conocimiento
analizadas en estos últimos epígrafes con relación a sus ventajas y desventajas
principales.
Tabla II.1. Comparación de métodos de deducción
Método Ventaja Desventaja
Tareas Familiares El experto está cómodo Puede consumir mucho
tiempo
Entrevistas Genera mucha información
para el primer prototipo
Puede consumir mucho
tiempo
Tareas de información
limitada
Se puede extraer información
sobre subdominios
seleccionados
El experto no está cómodo
Simulación de escenarios
hacia adelante
Se puede extraer información,
estrategias de inferencia del
experto
Consume tiempo y el experto
se siente incomodo
Descomposición de objetivos
Se puede extraer información
sobre subdominios
seleccionados
Consume tiempo y el experto
se siente incomodo
CAPÍTULO II
33
II.3. Conjunto de prueba: El Reino Animal
Como ya fue mencionado en el capítulo I, para probar una aplicación de software es
necesario escoger un conjunto de prueba que permita explorar todas sus variantes. En el
caso de un sistema experto para UCShell es conveniente que el caso de prueba posea
algunas características esenciales, entre las que cabe señalar: ser lo suficientemente
grande para comprobar que no rebase la pila de objetivos, ser descomponible para poder
estructurar el conocimiento en diferentes bases que necesiten de una cierta
comunicación, usar distintas facilidades del sistema (preguntas de distintos tipos con o
sin apoyo de imágenes, explicaciones, etc.). El conocimiento acerca del reino animal
permite explotar todas esas facilidades.
En la clasificación científica de los seres vivos, el reino Animalia (animales) y en
particular los metazoos, constituye un amplio grupo de organismos eucariotas,
heterótrofos, pluricelulares y tisulares. Se caracterizan por su capacidad para la
locomoción, por la ausencia de clorofila y de pared en sus células, y por su desarrollo
embrionario, que atraviesa una fase de blástula y determina un plan corporal fijo
(aunque muchas especies pueden sufrir posteriormente metamorfosis) (Soltis, 2003). Los
animales forman un grupo natural estrechamente emparentado con los hongos y las
plantas. Animalia, es uno de los cinco reinos de la naturaleza y a él pertenece el ser
humano.
II.3.1. Filogenia
El reino animal se subdivide en una serie de grandes grupos denominados filos
(phylum); cada uno responde a un tipo de organización bien definido, aunque hay
algunos de afiliación controvertida.
Para la creación del sistema experto que se usa para probar UCShell se tomaron las
relaciones filogenéticas entre los diversos animales partiendo de la definición dada por
Brusca (Brusca and Brusca, 2005); se trata de una hipótesis filogenética "clásica" en la
que se reconocen los grandes clados1 admitidos tradicionalmente (pseudocelomados,
1 Clado. Cada una de las ramas del árbol filogenético propuesto para agrupar a los seres vivos.
CAPÍTULO II
34
articulados, etc.) y asume la teoría colonial como la explicación sobre el origen de los
metazoos.
II.4. Adquisición de conocimiento
Como ya se ha apuntado, el conocimiento que se codifica en una base de un sistema
experto puede provenir de los expertos o de diversas fuentes de información. En el caso
del conjunto de prueba elegido se decidió usar el conocimiento público debido a la no
disponibilidad de expertos (dispuestos a cooperar) en el área escogida y a la existencia
de una abundante información que cumple con los requisitos del modelo de prueba que
se desea usar.
La información acumulada fue tomada de trabajos realizados anteriormente por
especialistas en esta materia y que son de dominio público. Algunos de estos son:
Invertebrados (Brusca and Brusca, 2005), Numbers of Living Species in Australia and
the World (Chapman, 2009), The position of arthropods in the animal kingdom: A
search for a reliable out group for internal arthropod phylogeny (Giribert, 1998),
Catálogo de moluscos marinos de las costas nororientales de Venezuela: Clase Bivalva
(LODEIROS S, 1999), Principios integrales de zoología (HICKMAN, 2006).
II.5. Sistema experto de clasificación taxonómica
El fin último de la taxonomía es presentar un sistema de clasificación que agrupe a toda
la diversidad de organismos en unidades discretas dentro de un sistema estable. Cada
filo responde a un tipo de organización bien definido, aunque hay algunos de afiliación
controvertida. El sistema de clasificación cataloga a los animales en: Filos, SubFilos,
SuperClases, Clases y SubClases, correspondiendo una base de conocimiento a cada uno
tal y como se aprecia en la figura II.1.
La tabla II.2 muestra las conclusiones contenidas en las reglas que corresponden a las
bases de conocimientos: Filos, SubFilos, SuperClases, Clases y SubClases.
CAPÍTULO II
35
Figura II.1. Organización jerárquica y de archivos del SE
Tabla II.2. Conclusiones asociadas a las bases de conocimientos
Atributo Valor
Filo
Acanthocephala, Acoelomorpha, Annelida, Arthropoda, Brachiopoda, Bryozoa,
Chaetognatha, Chordata, Cnidaria, Ctenophora, Cycliophora, Echinodermata, Entoprocta,
Gastrotrichia, Gnathostomulida, Hemichordata o Faringotremata, Kinorhyncha, Loricifera,
Micrognathozoa, Mollusca, Monoblastozoa, Myxozoa, Nematoda, Nematomorpha,
Nemertea, Onychophora, Orthonectida, Phoronida, Placozoa, Platyhelminthes, Pogonophora
o Siboglinidae, Porifera, Priapulida, Rhombozoa, Rotifera, Sipuncula, Tardigrada,
Xenoturbellida.
Subfilo
Chelicerata, Crustacea, Unirramia, Urochordata, Cephalochordata, Vertebrata, Pelmatozoa,
Eleutherozoa.
Superclase Hexápoda, Myriapoda, Agnatha, Gnathostomata, Tetrapoda.
Clase
Turbellaria, Trematoda, Monogenea, Enopla, Adenophorea, Secernentea, Caudofoveata,
Solenogastres, Polyplacophora, Monoplacophora, Bivalvia, Scaphopoda, Gastropoda,
Cephalopoda, Enteropneusta, Asteroidea, Concentricycloidea, Echinoidea, Holothuroidea,
Ophiuroidea, Hydrozoa, Anthozoa, Cubozoa, Scyphozoa, Polypodiozoa, Tentaculata, Nuda,
Enteropneusta, Crinoidea, Archiacanthocephala, Palaeacanthocephala, Eoacanthocephala,
Polychaeta, Clitellata, Myzostomida, Echiura, Arachnida, Merostomata, Pycnogonida,
Branchiopoda, Remipedia, Cephalocarida, Maxillopoda.
Subclase
Oligochaeta, Hirudinea, Thecostraca, Tantulocarida, Branchiura, Pentastomida,
Mystacocarida, Copepoda, Myodocopa, Podocopa, Eumalacostraca, Hoplocarida,
Phyllocarida, Elasmobranchii, Holocephali, Chondrostei, Neopterygii, Coelacanthimorpha,
Dipnoi, Tetrapodomorpha, Synapsida, Anapsida, Diapsida, Neornithes, Prototheria, Theria,
Octocorallia, Hexacorallia, Ceriantipatharia, Prosobranchia, Opisthobranchia, Pulmonata,
Enoplia, Chromadoria, Aspidogastrea, Digenea.
II.5.1. Base de conocimientos para UCShell 2.1
Como ya fue establecido en el epígrafe I.3, las bases de conocimiento para UCShell se
componen de cuatro partes, de las cuales sólo una es obligatoria (el bloque de acciones).
CAPÍTULO II
36
Figura II.2. Base de conocimiento con todas sus partes
La figura II.2 muestra una pequeña base de conocimiento que posee las cuatro partes:
La primera parte, el “Bloque de atributos externos”, declara que los atributos:
Filo, SubFilo, Superclase y Clase, son externos a esta base.
La segunda parte, el “Bloque de atributos tipo pregunta”, define los atributos que
deben obtener sus valores a través de preguntas al usuario.
La tercera parte el “Bloque de reglas”, está constituido por un conjunto de reglas
de producción que deberá usar la máquina de inferencia en su proceso de prueba
de los objetivos.
La cuarta y última parte el “Bloque de acciones”, contiene las órdenes que deberá
ejecutar la máquina de inferencia.
II.5.1.1. El bloque de atributos externos
El boque de atributos externos, si existe, tiene que ser el primer bloque de cualquier base
de conocimientos, se inicia con la palabra reservada EXTERNAL (figura II.3) y termina
con el inicio de otro de los bloques admitidos.
Figura II.3. Sintaxis del bloque de atributos externo
Este bloque especifica una lista de atributos que se usan en una base dada y no están
declarados en ella, lo que permite cambiar de una base a otra durante el proceso de
inferencia (usando la sentencia CHAIN en la base origen). En la figura II.4 se puede
CAPÍTULO II
37
apreciar que la base actual es SubClases.kbs, en ella los atributos: Filo, SubFilo,
SuperClase y Clase se han declarado externos, lo que significa que cuando se ejecute en
cualquier otra base la sentencia CHAIN SubClases.kbs (o .kbo) y se cargue está base de
conocimiento se deberán conservar los valores de los atributos: Filo, SubFilo,
SuperClase y Clase que fueron adquiridos en las bases Filos.kbs, SubFilos.kbs,
SuperClases.kbs y Clases.kbs respectivamente.
Figura II.4. Ejemplo de uso del bloque EXTERNAL
II.5.1.2. El bloque de preguntas
La figura II.5, muestra la sintaxis del bloque de preguntas, el cual tiene que iniciarse con
la palabra reservada ASKS y finaliza al definir otro bloque.
Figura II.5 Bloque de preguntas
El bloque contiene un conjunto de atributos tipo pregunta (ASK) que se definen de
acuerdo a la sintaxis que se aprecia en la figura II.6.
Figura II.6. Definición de atributo tipo pregunta
En la definición de la figura II.6, los campos tienen los siguientes significados:
ASKS DEFINICION DE ASKS
ASK Nombre Atributo
: Pregunta
Conjunto de Selección
Dominio de Definición
Explicación
CAPÍTULO II
38
Nombre Atributo, especifica el nombre del atributo tipo pregunta. (Marino y
Reproducción en la figura II.7).
Pregunta, es una cadena que contiene la pregunta en sí (si contiene varias
cadenas se concatenan con el signo +).
Figura II.7. Ejemplos de atributo tipo pregunta
Conjunto de selección (figura II.8). Se define mediante la palabra reservada
CHOICE (figura II.7 inferior) y especifica una lista de números (reales o
enteros), cadenas o atributos separados por coma, que son las posibles respuestas
a las preguntas.
Figura II.8. Sintaxis del conjunto de selección
Dominio de definición (figura II.9). Se define mediante la palabra reservada
DOMAIN. Los valores del campo Literal pueden ser una cadena o un número y
son las respuestas esperadas. Existen dos formas de poner los literales, tal y
como se aprecia en la sintaxis de la figura II.9:
o Sin imagen asociada, respuesta No de la figura II.10.
o Con imagen asociada, respuesta Sí de la figura II.10. En este caso se usa la
palabra IMAGE para preceder el camino hacia el archivo que contiene la
imagen seguido por el operador de asignación (:=) y el valor del literal, de no
existir ese valor, el atributo recibe toma el camino de la imagen.
CHOICE
Atributo
Cadena
Número
,
CAPÍTULO II
39
Figura II.9. Sintaxis del dominio de definición
Figura II.10. Ejemplos de atributo tipo pregunta con DOMAIN
Explicación (figura II.11). Se usa en dos partes de las bases de conocimiento de
UCShell, con fines similares pero en diferentes contextos. En el caso del
BECAUSE (opcional), que puede acompañar a los atributos definidos por ASK,
se usa para explicarle, a los usuarios del sistema experto, por qué se les hace esa
pregunta. El texto de la explicación es un conjunto de cadenas encerradas entre
apóstrofes y separadas por comas (figura II.12).
,
(
DOMAIN
IMAGE
Camino de
Búsqueda )
Literal
Literal
:=
CAPÍTULO II
40
Figura II.11. Sintaxis de BECAUSE
Figura II.12. Ejemplo de un BECAUSE asociado a un ASK
II.5.1.3. El bloque de reglas
El bloque de reglas, como su nombre lo indica, contiene la definición de todas las reglas
de las bases de conocimientos para UCShell. La definición del bloque comienza con la
palabra reserva RULES y termina con la definición del bloque de acciones.
La definición de una regla comienza por la palabra reservada RULE y termina con la
palabra reservada END seguida de un punto y coma (End;).
La sintaxis para el bloque de reglas (son reglas de producción) se aprecia en la figura
II.13:
Figura II.13. Sintaxis del bloque de reglas
RULE ENTERO
CONDICIÓN
IF
THEN
CONCLUSIÓN
ACTIONS Sentencia
aa
BECAUSE
END
Preguntable o
Preguntable ASK
BECAUSE Cadena de
caracteres ' '
´
,
CAPÍTULO II
41
El campo ENTERO, se usa para identificar la regla y es un número entero que
debe ser único. El sistema reporta error si se usa el mismo número más de una
vez.
El campo CONDICIÓN, contiene las condiciones que deben satisfacerse para
que la regla se cumpla y está compuesto por un conjunto de operaciones de
comparación (tabla II.1) unidas por OR o AND que pueden estar negados o no
(tabla II.2). El resultado de evaluar esta parte de la regla es booleano (verdadero
o falso).
Tabla 0.2. Operadores relacionales
Símbolo Operación Tipo de operandos Ejemplo
= Igual Atributos, cadenas y números Reacción = 'Exotérmica'
<> Diferente Atributos y números Cantidad <> 5
< Menor Atributos y números Peso < 7
> Mayor Atributos y números Peso * Altura > 40
<= Menor o igual Atributos y números Tamaño -30 <= Peso *5
>= Mayor o igual Atributos y números Resolución >= 9
Tabla 0.3 Operadores booleanos
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
La palabra reservada UNKNOWN permite realizar comparaciones para
determinar si un atributo dado ha sido inferido (si ya tiene un valor se dice que es
un hecho).
El campo CONCLUSIÓN (figura II.14), está compuesto por las conclusiones de
la regla (pueden ser varias). Si la regla se cumple los atributos a la izquierda del
operador de asignación (:=) toman los valores a la derecha del operador.
CAPÍTULO II
42
Figura II.14. Sintaxis de la parte conclusión de una regla
Cada conclusión puede tener asignado un valor de certidumbre (CNF, opcional)
mayor que cero (0) o menor o igual a uno (1). El valor por defecto es 1 y
significa que se tiene total certeza del resultado. Los atributos que aparecen a la
izquierda del símbolo de asignación (:=) de una conclusión son atributos
deducibles.
El valor de la certidumbre con que se arriba a una conclusión se calcula de la
forma siguiente:
El valor expresado después de CNF se multiplica por el valor de certidumbre
que la condición de la regla alcance durante la inferencia.
En caso de que no se especifique el bloque CNF el valor de la certidumbre de
la conclusión es la máxima definida por el sistema (1).
El campo ACTIONS (es opcional, figura II.15), contiene un conjunto de
sentencias del lenguaje que se ejecutan cuando la regla se cumple. Usualmente
en las acciones de una regla es donde se muestran los resultados que se
alcanzaron durante la inferencia, para lo cual se usa la sentencia DISPLAY.
Figura II.15. Sintaxis del bloque de acciones de una regla
Las acciones o sentencias del lenguaje son: DISPLAY, FIND, FINDFORWARD,
FINDALL, ASSUME, REPEAT, RESET y CHAIN. Estas sentencias sólo se pueden
escribir en el bloque de acciones principal y en el bloque de acciones de las reglas.
El campo BECAUSE permite explicar cómo se llegó a una conclusión. Su
sintaxis es la misma que la de la explicación en los ASK.
Atributo Valor :=
CNF Certidumbr
e
Actions Definición de acción
CAPÍTULO II
43
Figura II.16. Ejemplo de regla
La figura II.16, muestra un ejemplo de regla, en este caso el identificador de la regla es
el número 5, la parte CONDICIÓN, está compuesta por tres sentencias lógicas de
comparación unidas por AND, existe una sola conclusión que expresa “si se cumplen las
condiciones, el animal pertenece a la SuperClase Tetrapoda” y el bloque de acciones
tiene dos sentencias DISPLAY, la primera muestra un texto y la segunda una imagen.
II.5.1.4. El bloque de acciones
El bloque de acciones es el último de los cuatro bloques en que se divide una base de
conocimientos para el sistema UCShell y es el único que es obligatorio.
Es similar al bloque de acciones de la regla, la única diferencia es su posición y su
carácter de obligatoriedad.
El bloque de acciones se inicia con la palabra reservada ACTIONS y finaliza con la
palabra reservada END seguida por un punto (End.) lo que constituye, además, el fin de
la base de conocimientos.
CAPÍTULO II
44
II.5.1.5. Sentencias del lenguaje UCShell
El lenguaje UCShell provee un conjunto de sentencias que permiten programar las
acciones durante el proceso de inferencia.
Sentencia DISPLAY
La sentencia DISPLAY (figuras II.17 y II.18) permite imprimir textos y elementos
visibles que se muestran al usuario del sistema experto en tiempo de ejecución.
Figura II.17. Sintaxis de la sentencia DISPLAY
Figura II.18. Ejemplo de uso de la sentencia DISPLAY
Sentencia ASSUME
La sentencia ASSUME (figura II.19), se usa para asignarle valor a un atributo que se
desea declarar como un hecho y es muy útil en la búsqueda forward debido a que la
estrategia seguida parte de hechos conocidos. La certidumbre del valor asignado por
medio de ASSUME tendrá el valor máximo del sistema. Cuando al atributo de la
izquierda se le asigna un atributo con valor desconocido, el de la derecha se infiere.
Figura II.19. Sintaxis de la sentencia ASSUME
DISPLAY IMAGEN
ELEMENTO VISIBLE
,
CAPÍTULO II
45
Sentencia REPEAT
Mediante esta sentencia se puede definir un conjunto de acciones cíclicas (figura II.20).
El fin del ciclo se especifica con la palabra reservada UntilKnown. La condición de
terminación del ciclo se alcanza cuando el atributo que está a continuación de
UntilKnown recibe un valor diferente de desconocido (unknown). El atributo que se
encuentra como condición de parada no se infiere en el momento de la evaluación solo
se verificará si su valor es conocido o no.
Figura II.20. Sintaxis de la sentencia REPEAT
Sentencia FIND
La sentencia FIND (figuras II.21), es la orden que inicia un proceso de inferencia
dirigido por objetivos o backward chaining (encadenamiento hacia atrás).
Figura II.21. Sintaxis y ejemplo de uso de la sentencia FIND
Si el proceso es exitoso, el atributo se instancia con el valor inferido y si no tiene éxito
continua con el valor UNKNOWN (es el valor por defecto). La búsqueda se realiza
siguiendo el siguiente orden:
Se comprueba si el atributo es un hecho, en ese caso no hay nada que probar y se
toma el valor asociado a ese atributo y su certidumbre.
Si no es hecho se comprueba si es atributo tipo pregunta, si lo es, se realiza la
pregunta asociada al atributo. Una vez respondida la pregunta, el atributo pasa a
ser un hecho.
Si el atributo no era un hecho ni de tipo pregunta tiene que ser deducible y en ese
caso comienza su prueba dirigida por objetivos.
REPEAT Sentencia UNTILKNOWN Atributo
FIND Atributo
CAPÍTULO II
46
Sentencia FINDALL
Esta sentencia es similar a la sentencia FIND, pero la inferencia no se detiene cuando se
prueba el atributo (por alguna regla) sino que se sigue buscando otras reglas con igual
atributo en la parte izquierda de la conclusión para obtener todas las instancias posibles.
Sentencia RESET
La sentencia RESET (figura II.22) actúa sobre una lista de atributos o sobre todos (ALL)
a los cuales la asigna el valor de desconocido (Unknown). Es útil cuando finaliza un
proceso de inferencia y se desea volver a hacer una consulta partiendo desde cero ya que
los atributos que tienen valores distintos de Unknown son hechos y por tanto no son
deducibles.
Figura II.22. Sintaxis de la sentencia RESET
Sentencia CHAIN
La sentencia CHAIN (figuras II.23 y II.24) especifica un camino (debe terminar en el
nombre de un archivo) que contiene una base de conocimiento destino con la que se va a
enlazar la base de conocimiento actual u origen.
Si existe el archivo .kbo relacionado con la base de conocimiento seleccionada, UCShell
carga esa forma interna, de no ser así, primero se compila el archivo .kbs, se crea el
archivo .kbo con la forma interna y se carga para realizar la inferencia. La ejecución de
CHAIN provoca un cambio de ejecución desde la base de conocimiento origen hacia la
base de conocimiento destino si se desean conservar los valores de algunos de los
atributos de la base origen, deberán declararse como externos (en el bloque
EXTERNAL) de la base destino.
RESET
Variable
ALL
,
CAPÍTULO II
47
Figura II.23. Sintaxis de la sentencia CHAIN
Figura II.24. Ejemplo del uso de la sentencia CHAIN
II.6. Conclusiones del capítulo
El capítulo ha presentado algunas reflexiones acerca de la ingeniería del conocimiento y
del saber asociado al Reino Animal que se ha usado para hacer el sistema experto que ha
servido de modelo de prueba del sistema UCShell.
La pruebas realizadas han resultados medulares para determinar los fallos del sistema
que se analizan en el capítulo III.
CAPÍTULO III
48
III. VISIÓN FUNCIONAL
III.1. Introducción
Una vez realizada la ingeniería del conocimiento en el campo del Reino Animal, el
sistema experto obtenido ha permitido poner a prueba la máquina de inferencia de
UCShell, validar sus bondades y encontrar sus problemas. En este capítulo se ofrece una
visión funcional del sistema y se detallan los problemas detectados, los cuales deberán
corregirse en versiones posteriores.
III.2. Compilación
Las bases de conocimiento que utiliza UCShell están contenidas en archivos fuentes
(tienen extensión kbs). Para que la máquina de inferencia pueda hacer su trabajo es
necesario realizar un proceso de compilación que analiza los errores y genera una forma
interna que puede interpretar la máquina de inferencia. El código que genera el
compilador, si no hay errores, queda almacenado en un archivo, con extensión kbo, y
sobre él actúa la máquina de inferencia.
III.2.1. Detección de errores
Como ya se mencionó en el capítulo II, en este trabajo se creó un sistema experto de
clasificación taxonómica que se toma como base de prueba para el sistema UCShell 2.1.
El proceso de puesta a punto de este sistema ha permitido detectar diferentes fallos y
deficiencias, en el funcionamiento del software, que se analizan a continuación.
No es posible ejecutar el sistema experto partiendo de cargar un archivo .kbo
obligando a los usuarios a compilar de nuevo la base conocimiento para poder
realizar el proceso. La figura III.1 muestra el mensaje de error generado al
intentar ejecutar la base Clases.kbo, reportando que no existe ese archivo que sin
embargo está listado en el proyecto (se ha enmarcado en un cuadrilátero).
CAPÍTULO III
49
Figura III.1 Reporte de error al tratar de ejecutar un .kbo
Figura III.2. Las acciones asociadas al menú desplegable no se ejecutan
El menú desplegable asociado a los archivos .kbs y .kbo u otras carpetas del árbol
de proyectos (a la izquierda de la figura), no permite realizar las acciones
desplegadas (figura III.2).
No se chequea si los atributos definidos en la base se usan o no. Aunque eso no
es un error grave no debería permitirse en este entorno (en muchos lenguajes
CAPÍTULO III
50
modernos se hace ese tipo de verificación que resulta muy útil). La figura III.3
muestra el proceso de compilación de una base en la que se ha definido el
atributo tipo pregunta AtributoSinUso, que no se utiliza en la base (se destacan
en cuadriláteros los aspectos señalados).
Figura III.3. Proceso de compilación, sin errores de una base
La sentencia DISPLAY no permite mostrar imágenes y texto juntos, lo que
obliga a definir tantas cláusulas DISPLAY como texto, imágenes o videos se
quieran mostrar. Sería muy práctico que se pudieran mostrar textos con imágenes
o videos asociados mediante DISPLAY ya que esta es la vía que se utiliza para
presentar información a los usuarios que pueden ser guías para responder
preguntas o conclusiones que se deseen mostrar (parciales o finales). La figura
III.4 muestra la forma de “solución” actual.
La funcionalidad de mostrar videos no está implementada en el IDE, a pesar de
que sí es reconocida por la gramática y por la biblioteca UCShell Library 2.0.
Los videos constituyen una magnífica vía para lograr una mejor interacción entre
los usuarios y el sistema (figura III.5).
CAPÍTULO III
51
Figura III.4. Método actual para mostrar textos e imágenes a través de DISPLAY
Figura III.5. DISPLAY VIDEO no tiene acción semántica asociada
CAPÍTULO III
52
No se permite el menos unario como parte de un operando que se usa en los
operadores relacionales.
Se permite definir atributos con el mismo nombre en la base de conocimiento, lo
cual es una fuente segura de errores de concepción difíciles de detectar (figura
III.6).
Figura III.6. Definición de un atributo doble
Si se está realizando una inferencia paso a paso y se detiene el proceso, al tratar
de reiniciar el proceso casi todas las facilidades del sistema están bloqueadas: en
el área inferior izquierda sale la alerta Inference has been stoped sin haber
comenzado el proceso (figura III.7).
CAPÍTULO III
53
Figura III.7. Efecto adverso de detener y reanudar la inferencia paso a paso
En la ventana de hechos probados (figura III.8) el botón Rule Because permanece
activo aún para aquellos atributos que son de tipo de preguntas y también para
los que siendo inferibles no tienen parte Because en la regla. Además los
atributos no inferibles que aparecen en la reglas que tienen parte Because tienen
asociados la explicación (lo cual no es correcto).
Figura III.8. Ventana de hechos probados con el botón Rule Because activo
CAPÍTULO III
54
Cuando un proyecto tiene más de un archivo sólo se puede compilar el último
que se cargue debido a que cualquier compilación ulterior se realiza sobre el
mismo archivo, aun cuando se cierren todos los demás. En la figura III.9 se ha
realizado el siguiente proceso: primero se abrió el archivo Filos.kbs, después se
abrió el archivo SubClases.kbs se trabajó con él y se cerró, finalmente se intentó
compilar el archivo que permaneció abierto (Filos.kbs) sin embargo el sistema
compiló el archivo SubClases.kbs que es el que consideró activo (puede
observarse este error resaltado dentro de cuadriláteros.
Figura III.9. Proceso de compilación no deseado
III.2.2. Generación de la Forma Interna
El sistema muestra los resultados del proceso de compilación en el árbol de proyectos
(izquierda del IDE de UCShell). La figura III.10 permite apreciar ese árbol antes de
compilar (carpeta Knowledge Bases) y la figura III.11 después de compilar (carpeta
Compiled Files). Como ya se ha señalado, antes de hacer un proceso de inferencia es
Clase activa
Clase que resulta
de la compilación
CAPÍTULO III
55
necesario compilar la base de conocimiento para que el sistema genere la forma interna
(debe compilarse al menos la que contiene el inicio del proceso).
Figura III.10. Proyecto ReinoAnimal antes de compilar
Figura III.11. Proyecto ReinoAnimal después de compilado
III.3. Inferencia
UCShell ofrece dos vías para realizar el proceso de inferencia: la primera es a través de
la barra de herramientas, para lo cual se usa el botón que provoca que se infiera sobre
la base de conocimiento actual o la última compilada después de haber cargado; la
CAPÍTULO III
56
segunda necesita dos pasos: primero se selecciona el archivo compilado (.kbo) sobre el
que se desea inferir y después se usa el botón (figura III.12). Seguidamente se
detallan los errores que subyacen en el sistema y se pueden presentar durante el proceso
de inferencia.
Figura III.12. Inicio del proceso de inferencia
Si una regla dada usa en sus condicionales un atributo no definido, el sistema
falla totalmente. La figura III.13 muestra un ejemplo en el que se cometió la
equivocación de poner Guasano en lugar de Gusano (el compilador no
comprueba que los atributos usados en esa parte estén definidos) y el proceso de
inferencia da por terminado su trabajo pero no llega a ninguna conclusión. Este
es, posiblemente, el error peor de todos los detectados.
Actualmente el botón Because que se asocia a las preguntas, no debe utilizarse ya
que si el usuario lo oprime durante el proceso de inferencia (para indagar porqué
se le pregunta algo), el sistema presenta la explicación en forma correcta pero
después pasa directamente a mostrar los resultados sin haber terminado el
proceso de inferencia. La figura III.14 muestra esta desacertada situación.
1-Seleccionar
con doble clic
2-Clic para
comenzar inferencia
3-Resultado
CAPÍTULO III
57
Figura III.13. Uso de un atributo no definido
Figura III.14. Error crítico en la inferencia
CAPÍTULO III
58
Un problema importante que se ha detectado está relacionado con la sentencia
CHAIN y las bases de conocimientos grandes. En esos casos el encadenamiento
no se hace apropiadamente (figuras III.15 y III.16), al parecer por problemas de
memoria (esa afirmación no está probada del todo).
Figura III.15. Problemas con la sentencia CHAIN en la ejecución normal
Figura III.16. Problemas con la sentencia CHAIN en la ejecución paso a paso
CAPÍTULO III
59
III.3.1.Ventanas
Los atributos tipo preguntas pueden tener o no sugerencias de respuestas e imágenes
asociados a ellos, la figura III.17 muestra la interfaz de una pregunta definida con
DOMAIN e imagen asociada, mientras la figura III.18 usa la misma interfaz, a través de
DOMAIN, y sin imagen asociada.
Figura III.17. Ventana generada por ASK, DOMAIN con imagen
Figura III.18. Ventana generada por ASK, DOMAIN sin imagen
La figura III.19 muestra la interfaz de una pregunta que no tiene asociada posibles
respuestas (ni DOMAIN, ni CHOICE). Como la pregunta se definió con una parte
Because, el botón correspondiente aparece activo.
CAPÍTULO III
60
Figura III.19. Pregunta sin DOMAIN ni CHOICE y efecto de oprimir el botón Because
III.3.2. Árbol de inferencia
El sistema ofrece la facilidad de mostrar el árbol de inferencia una vez que ha concluido
ese proceso, la figura III.20 y la figura III.21 permiten apreciar algunas de sus vistas.
Figura III.20. Árbol de inferencia derivado de la conclusión (Filo)
CAPÍTULO III
61
Figura III.21. Vistas del árbol de inferencia
También es posible ver una explicación, acerca del proceso de inferencia dada por el
sistema a través del botón How, (figura III.22).
Figura III.22. Hechos probados
III.4. Depuración
La opción de inferir paso a paso permite observar todas las acciones de la máquina de
inferencia, así como las implicaciones que tienen las respuestas de los usuarios sobre el
proceso de inferencia.
En la figura III.23 se ha señalado, con el número 1, el botón que permite activar la
inferencia paso a paso, subsecuente acciones de oprimir ese botón permiten que se
ejecuten los pasos siguientes. En el área marcada con el numero 2 aparecen todas las
acciones llevadas a cabo, hasta ese momento, por la máquina de inferencia, mientras el
CAPÍTULO III
62
área marcada con el numero 3 corresponde a la interfaz que se ejecuta en ese momento:
se ha activado la pregunta asociada al atributo Metameros, si el usuario selecciona Sí, el
SE concluirá que el Filo del animal analizado es Arthropoda.
Figura III.23. Compilar paso a paso
III.5. Interacción con el software
El entorno gráfico utiliza diferentes menús y cuadros de diálogo que facilitan la
interacción de los usuarios con el software.
Para crear un proyecto nuevo, por ejemplo, existen dos alternativas (figura III.24): la
primera es a través del menú File y posteriormente seleccionar la opción New Project,
la segunda es usando la barra de herramientas (se indica con una flecha).
Figura III.24. Proyecto nuevo
1
2 4
3
CAPÍTULO III
63
La selección de esta opción, en ambos casos, hace que se presente un cuadro de diálogo
(figura III.25) solicitando la información del nuevo proyecto a crear (ReinoAnimal en
este caso).
Figura III.25. Ventana para insertar los datos del nuevo proyecto
Si el proyecto existe y lo que se desea es acceder a él (figura III.26), es posible hacerlo a
través del menú File y su opción Open Project o a través del tercer ícono de la barra de
herramientas (se señala con una flecha).
Figura III.26. Abrir proyecto
Cuando un proyecto está activo todos los archivos que le pertenecen aparecen en el árbol
de proyectos (a la izquierda del IDE y debajo de la etiqueta Projects). Los archivos del
proyecto se subdividen en dos carpetas: Knowledge Bases que agrupa las bases de
conocimientos fuentes (.kbs) y Compiled Files que refiere los archivos compilados
(.kbo). Si se desea modificar algún archivo fuente, se debe activar la ventana de edición
haciendo doble clic sobre su nombre.
Entre las facilidades de edición se incluye un conjunto de opciones asociadas al menú
desplegable que emerge al dar clic con el botón derecho del mouse en la ventana de
edición que permite insertar: una línea de sentencias, operadores, acciones, o
declaraciones nuevas. La figura III.27 muestra todas esas facilidades.
CAPÍTULO III
64
Figura III.27. Opciones de Insert Statement
El sistema permite realizar búsquedas, a través de la combinación Ctrl+F, de sentencias,
palabras, etc. La figura III.28 muestra el botón de la barra de herramientas asociado a
esa opción y la figura III.29 el cuadro de diálogo asociado a la búsqueda ordenada.
Figura III.28. Icono de buscar o reemplazar en la barra de herramientas
Figura III.29. Buscar o reemplazar líneas
CAPÍTULO III
65
III.6. Conclusiones del capítulo
En el capítulo se ha ofrecido una visión funcional del sistema UCShell 2.1, destacando
los procesos más importantes y las bondades del sistema. Se ha hecho énfasis en resaltar
los errores detectados ya que son la base para una versión futura en la cual no deberán
existir, algunos de los errores se ha podido corregir pero otros quedan para ese trabajo
posterior.
CONCLUSIONES
66
CONCLUSIONES El trabajo presentado consiste en un estudio de las facilidades del sistema UCShell con
el propósito de detectar posibles errores de funcionamiento para sugerir soluciones y
mejoras.
Con el propósito de llevar a cabo esa tarea se estudiaron diferentes técnicas de pruebas
de programas y se determinó que la mejor prueba para UCShell era la realización de un
sistemas experto complejo que pusiera a punto todas sus funcionalidades. El sistema
realizado permite hacer una clasificación taxonómica de los metazoos.
La complejidad y extensión del sistema desarrollado ha permitido detectar las carencias,
errores y debilidades del sistema UCShell.
RECOMENDACIONES
67
RECOMENDACIONES Al ser el objetivo fundamental de este trabajo la detección de errores del sistema
UCShell existe una primera recomendación que es muy clara: Corregir todos los
errores detectados en este experimento.
El hecho de haber realizado una prueba en la cual algunas opciones no pudieron
probarse del todo precisamente por no funcionar determinadas facilidades, es
imprescindible hacer una nueva prueba exhaustiva, con el mismo SE, antes de
afirmar que el sistema es funcional en ese aspecto.
Uno de los problemas detectados es con la sentencia CHAIN cuando se hacen
diferentes encadenamientos con bases, como la hecha en este trabajo, que son
grandes. Al parecer existen problemas con la memoria o con la pila de objetivos
que deberán analizarse.
Sería recomendable mejorar las opciones de: búsqueda, búsqueda y
reemplazamiento y la ayuda entre otras cosas.
BIBLIOGRAFÍA
68
BIBLIOGRAFÍA BEIZER , B. 2003. Software Testing Techniques
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.
BRUSCA, R. C. & BRUSCA, G. J. 2005. Invertebrados, Madrid, McGraw-Hill-Interamericana.
CAROLINA MARTINEZ, I. 2012. Pruebas de Software. Pruebas de Software. Universidad
Simon Bolivar.
CÉSARI, M. 1990. Sistemas Expertos.
CORNETT, S. 2002. Code Coverage Analysis.
CHAPMAN, A. D. 2009. Numbers of Living Species in Australia and the World, Australian
Biodiversity Information Services ISBN.
EDWARD FEIGENBAUM, P. M. 1983 The fifth generation, Addison Wesley.
GARCÍA MARTÍNEZ, D. R. 2012. Construcción de sistemas expertos. Técnicas de educción
del conocimiento.
GIRIBERT, G. R., C. 1998. The position of arthropods in the animal kingdom: A search for a
reliable outgroup for internal arthropod phylogeny.
HICKMAN, C. P., OBER, W. C. & GARRISON, C. W. 2006. Principios integrales de zoología,
McGraw-Hill-Interamericana, Madrid (etc.).
KANER , C. 1993. Testing Computer Software.
LABORDA, J., GALIMANY, J., PENA, R. M. & GUAL, A. 1985. Biblioteca práctica de la
computación, Barcelona.
LODEIROS S, J. M., MARIN E, B. Y PRIETO A, A. 1999. Catálogo de moluscos marinos de
las costas nororientales de Venezuela: Clase Bivalvia.
LLANO, L., ZAPATA, G. & OVALLE, D. 2007. Sistema de Inferencia Difuso para Identificar
Eventos de Falla en Tiempo Real del STE usando Registros SOE
MCCABE, T. J. 1976. "A Complexity Measure", IEEE Transactions on Software Engineering.
POLANCO, X., FRANÇOIS, C., & KEIM, J. P. 1998. Artificial neural network technology for
the classification and cartography of scientific and technical information.
Scientometrics.
POLO USAOLA, D. M. 2010. Mantenimiento Avanzado de Sistemas de Información, Pruebas
de Software.
RAYNOR, W. J. 1999. The International Dictionary of Artificial Intelligence. New York:
Glenlake Publishing Company.
RODRÍGUEZ TELLO, D. E. A. 2011. Importancia de las pruebas de software. Tamaulipas.
RUSSELL, S. J. & NORVIG, P. 1995. Inteligencia Artificial Un enfoque moderno.
SALAZAR ACOSTA, I. N. 2012. UCShell versión 2.1, un ambiente para la construcción de
Sistemas Expertos. Universidad de Las Villas.
SOLTIS, D. E. S., P. S. 2003. The Role of Phylogenetics in Comparative Genetics.
TURBAN, E. 1995. Expert Systems and Applied Artificial Intelligence.
TUTHILL, G. S. 1990. Knowledge Engineering.