ESCUELA SUPERIOR DE INFORMÁTICA
109
UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA GRADO EN INGENIERÍA EN INFORMÁTICA TECNOLOGÍA ESPECÍFICA DE TECNOLOGÍAS DE LA INFORMACIÓN TRABAJO FIN DE GRADO REMGRAFEE TOOL: Herramienta para el Estudio de los Sistemas Basados en Reglas Mediante Grafos RETE José Luis Mora Díaz Junio, 2016
Transcript of ESCUELA SUPERIOR DE INFORMÁTICA
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
GRADO EN INGENIERÍA EN INFORMÁTICA
TECNOLOGÍA ESPECÍFICA DE TECNOLOGÍAS DE LA INFORMACIÓN
TRABAJO FIN DE GRADO
REMGRAFEE TOOL: Herramienta para el Estudio de los
Sistemas Basados en Reglas Mediante Grafos RETE
José Luis Mora Díaz
Junio, 2016
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
Tecnologías y Sistemas de Información
TECNOLOGÍA ESPECÍFICA DE TECNOLOGÍAS DE LA INFORMACIÓN
TRABAJO FIN DE GRADO
REMGRAFEE TOOL: Herramienta para el Estudio de los
Sistemas Basados en Reglas Mediante Grafos RETE
Autor: José Luis Mora Díaz
Director: Luis Jiménez Linares
Junio, 2016
v
TRIBUNAL:
Presidente:
Vocal:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE VOCAL SECRETARIO
Fdo.: Fdo.: Fdo.:
vi
vii
I Resumen
Los sistemas basados en reglas son uno de los paradigmas más comunes para la
modelización del comportamiento y el control de sistemas complejos, donde se necesita
una representación de conocimiento simbólica, cualitativa, basada en relaciones, etc..
Cualquier sistema basado en reglas está constituido por un conjunto de reglas que definen
acciones o conclusiones si se cumplen determinadas condiciones, así como un mecanismo
de control de inferencia que determina la manera y orden de ejecución de las reglas. Estos
modelos son probablemente la herramienta más general y más popular de la Inteligencia
Artificial.
El proceso de aprendizaje del funcionamiento de estos modelos, así como la
familiarización de sus conceptos característicos, suele ser difícil. Principalmente, debido a
que en este modo de trabajo los datos son gestionados desde un punto de vista muy
diferente en comparación con otros sistemas.
En el presente TFG se propone el desarrollo de una aplicación web que asista al
usuario en la labor de aprendizaje en lo relacionado a estos sistemas, pero más
concretamente con las redes RETE. Esta herramienta permitirá al usuario gestionar una
base de conocimiento, construir una red RETE a partir de ésta y realizar actualizaciones
sobre ella para analizar los cambios procesados.
viii
ix
II Abstract
Rule-based systems are one of the most common paradigms for modeling the
behavior and control of complex systems, which need a symbolic, qualitative and based on
relationships representation of knowledge. Any rule-based system consists of a set of rules
that define actions or conclusions if specific conditions are met, as well as a control
inference engine that determines the way and order of execution of the rules. These models
are probably the most usually and most popular tool of Artificial Intelligence.
The learning process about the working of these models and the adaptation of their
characteristic concepts, is often difficult. Mainly, because in this operating mode, data are
managed from a very different point of view compared to other systems.
In the current TFG it makes the proposal of development a web application to assist
the user in learning task in relation to these systems, but more specifically with RETE
networks. This tool will allow to the user to manage a knowledge base, to build a RETE
network from this and make updates on it to analyze the processed changes.
x
xi
III Agradecimientos
En primer lugar quiero dar las gracias a mis padres porque sin ellos nada hubiera sido
posible, gracias por el apoyo tanto en los malos como en los buenos momentos, gracias por
compartir mis alegrías y decepciones.
También quiero dar las gracias a mis amigos, por soportarme en momentos difíciles
de agobio, desilusión, frustración en los que era complicado incluso mantener una simple
conversación conmigo. Pero no sólo en los malos momentos, también agradezco esos
buenos momentos de desconexión que hacían olvidar un mal examen, un programa que no
salía o un trabajo que parecía interminable.
No me quiero olvidar de todos los compañeros con los que he compartido esta etapa
de mi vida y que me han ayudado a mejorar tanto en el ámbito personal como en el
educativo.
Y por último, dar las gracias a mi director de proyecto por el apoyo mostrado y por
los conocimientos adquiridos. Así como, a todos los profesores que han compartido sus
conocimientos conmigo durante toda la carrera.
xii
xiii
IV ÍNDICE GENERAL
I Resumen ............................................................................................................................ vii
II Abstract ............................................................................................................................. ix
III Agradecimientos .............................................................................................................. xi
IV ÍNDICE GENERAL ...................................................................................................... xiii
V ÍNDICE DE FIGURAS.................................................................................................. xvii
VI ÍNDICE DE TABLAS ................................................................................................... xxi
VII LISTADO DE ACRÓNIMOS ................................................................................... xxiii
1. INTRODUCCIÓN ................................................................................................... 25
1.1 SISTEMAS BASADOS EN REGLAS ............................................................ 25
1.1.1. Ventajas ...................................................................................................... 27
1.2 ESTRUCTURA DE LA MEMORIA .............................................................. 27
2. OBJETIVOS ............................................................................................................ 29
2.1 DESCRIPCIÓN DEL PROBLEMA ................................................................ 29
2.2 OBJETIVOS .................................................................................................... 29
2.2.1 Otros objetivos ........................................................................................... 29
3. ANTECEDENTES, ESTADO DE LA CUESTIÓN ............................................... 31
3.1 ALGORITMO RETE ...................................................................................... 31
3.1.1 Partes de la red ........................................................................................... 32
3.2 LENGUAJES DE PROGRAMACIÓN VISUAL (VPL) ................................ 32
4. MÉTODO DE TRABAJO ....................................................................................... 39
4.1 METODOLOGÍA ÁGIL DE DESARROLLO SOFTWARE ......................... 39
4.1.1 El manifiesto ágil ............................................................................................ 40
4.1.2 Etapas de una metodología ágil ...................................................................... 41
4.1.2.1 Análisis de requisitos ............................................................................... 41
xiv
4.1.2.2 Diseño ...................................................................................................... 41
4.1.2.3 Codificación ............................................................................................. 41
4.1.2.4 Pruebas ..................................................................................................... 42
4.1.2.5 Mantenimiento ......................................................................................... 42
4.2 OTROS ASPECTOS DE LA METODOLOGÍA .................................................. 42
4.2.1 Scrum (modelo en espriral) ............................................................................. 43
4.3 HERRAMIENTAS TECNOLÓGICAS ................................................................ 44
4.3.1. Herramientas de desarrollo software ............................................................. 44
4.3.2. Herramientas de modelado ............................................................................ 47
5. RESULTADOS ....................................................................................................... 51
5.1 SPRINT 1 ......................................................................................................... 51
5.1.1 Arquitectura Seleccionada. ........................................................................ 52
5.1.1.1 Arquitectura Cliente-Servidor ............................................................... 52
5.1.1.1.1 Cliente ............................................................................................ 53
5.1.1.1.2 Servidor .......................................................................................... 55
5.1.1.1.3 Comunicación cliente-servidor ...................................................... 56
5.1.1.2 Plataforma como Servicio (PaaS) ......................................................... 58
5.1.1.2.1 Google App Engine. ....................................................................... 59
5.1.2. Definición de requisitos del sistema .............................................................. 60
5.1.2.1 Requisitos funcionales ............................................................................. 60
5.1.2.2 Requisitos no funcionales ........................................................................ 66
5.2 SPRINT 2 ............................................................................................................... 66
5.2.1 Funcionamiento del algoritmo RETE ............................................................. 67
5.2.1.1 Operación join .......................................................................................... 68
5.2.1.2 Procedimiento de construcción de la red ................................................. 69
5.3 SPRINT 3 ......................................................................................................... 74
xv
5.3.1 Desarrollo inicial de la interfaz .................................................................. 74
5.3.2 Creación bloques Blockly ........................................................................... 77
5.3.3 Implementación mediante base de datos relacionales ................................ 78
5.4 SPRINT 4 ......................................................................................................... 83
5.5 SPRINT 5 ......................................................................................................... 84
5.5.1 Implementación completa del algoritmo RETE ......................................... 84
5.5.1.1 Construcción de la red ........................................................................... 85
5.5.1.2 Actualización de la red .......................................................................... 86
5.5.2 Desarrollo final de la interfaz ......................................................................... 88
5.5.2.1 Resultado de la interfaz ............................................................................ 88
5.5.3 Análisis de las herramientas relacionadas con el módulo gráfico .................. 90
5.5.4 Implantación del módulo gráfico .................................................................... 93
5.5.5 Funcionamiento .............................................................................................. 94
5.5.6 Pruebas ............................................................................................................ 97
6. CONCLUSIONES Y PROPUESTAS ..................................................................... 99
6.1 OBJETIVOS LOGRADOS ............................................................................. 99
6.2 MEJORAS Y PROPUESTAS ............................................................................. 100
7. BIBLIGRAFÍA ...................................................................................................... 101
ANEXO A. MANUAL DE USO DE REMGRAFEE TOOL ........................................... 103
xvi
xvii
V ÍNDICE DE FIGURAS
1.1 – Representación de un sistema basado en reglas .......................................................... 25
3.1 – Interfaz de Scratch ...................................................................................................... 34
3.2 – Interfaz de Flowgorithm ............................................................................................. 34
3.3 – Interfaz del editor gráfico de la lógica e acción de Blender. ...................................... 35
3.4 – Interfaz del mecanismo de control de animación en Unity3D .................................... 36
3.5 – Interfaz de craft ai ....................................................................................................... 37
3.6 – Interfaz de Kodu .......................................................................................................... 37
4.1 - Gráfico que muestra las diferentes etapas dentro de un ciclo de vida ........................ 39
4.2 – Ilustración ciclo de desarrollo en espiral .................................................................... 43
4.3 – Interfaz de Eclipse ...................................................................................................... 45
4.4 – Interfaz de Blockly ...................................................................................................... 47
4.5 – Interfaz de Dia ............................................................................................................ 48
4.6 – Interfaz de Visual Paradigm ....................................................................................... 49
4.7 – Interfaz de Balsamiq moqups ..................................................................................... 50
4.8 – Interfaz de Xmind ....................................................................................................... 50
5.1 – Mapa conceptual de metas .......................................................................................... 51
5.2 – Representación modelo cliente-servidor ..................................................................... 53
5.3 – Métodos de la interfaz HttpServlet ............................................................................. 56
5.4 – Especificación de objeto en formato JSON ................................................................ 57
5.5 – Especificación de colección de valores en formato JSON ......................................... 58
5.6 – Caso de uso de selección de hecho/regla .................................................................... 61
5.7 – Caso de uso de eliminar/editar elemento seleccionado .............................................. 61
5.8 – Caso de uso de eliminar/editar elemento .................................................................... 62
5.9 – Caso de uso de crear nuevo hecho o regla .................................................................. 62
xviii
5.10 – Caso de uso de crear elemento .................................................................................. 63
5.11 – Caso de uso de compilar red RETE .......................................................................... 63
5.12 – Caso de uso de actualizar compilación de red RETE ............................................... 64
5.13 – Caso de uso de actualizar red RETE ......................................................................... 64
5.14 – Caso de uso de actualizar RETE ............................................................................... 64
5.15 – Caso de uso de seleccionar versión de la red RETE ................................................. 65
5.16 – Caso de uso de obtener grafo .................................................................................... 65
5.17 – Nodos alfa del ejemplo propuesto ............................................................................ 70
5.18 – Generación del primer nodo beta .............................................................................. 71
5.19 – Generación del segundo nodo beta ........................................................................... 72
5.20 – Red resultante de la regla propuesta ......................................................................... 73
5.21 – Boceto de la interfaz en pestaña de gestión .............................................................. 75
5.22 – Boceto de la interfaz en pestaña de edición .............................................................. 76
5.23 – Boceto de la interfaz en pestaña de visualización ..................................................... 77
5.24 – Interfaz de Block Factory ......................................................................................... 78
5.25 – Fisionomía del grafo representativo de la red ........................................................... 79
5.26 – Descripción de la tabla “Alfas” ................................................................................ 79
5.27 – Descripción de la tabla “Betas” ................................................................................ 80
5.28 – Descripción de la tabla “Reglas” .............................................................................. 81
5.29 – Descripción de la tabla “Predicados” ........................................................................ 81
5.30 – Descripción de la tabla “Hechos” ............................................................................. 82
5.31 – Clase “Rete” .............................................................................................................. 85
5.32 – Parte de la interfaz correspondiente a la pestaña de gestión. .................................... 89
5.33 – Parte de la interfaz correspondiente a la pestaña de edición. .................................... 89
5.34 – Parte de la interfaz correspondiente a la pestaña de visualización. .......................... 90
5.35 – Fisionomía del grafo resultante. ................................................................................ 94
xix
5.36 – Diagrama de secuencia de “Mostrar datos correspondientes a la base de reglas y la
base de hechos al cargar la página”. .................................................................................... 95
5.37 – Diagrama de secuencia de “Seleccionar un elemento de cualquiera de las listas y
modificarlo”. ........................................................................................................................ 96
5.38 – Diagrama de secuencia de “Seleccionar versión de la red que desea mostrar”. ....... 97
A.1 – Botón desplegable .................................................................................................... 103
A.2 – Mostrar bloques disponibles .................................................................................... 105
A.3 – Cohesión de bloques ................................................................................................ 105
A.4 – Construcción de una regla ........................................................................................ 106
A.5 – Eliminar un bloque ................................................................................................... 106
A.6 – Seleccionar la versión de la red que se desea mostrar ............................................. 107
xx
xxi
VI ÍNDICE DE TABLAS
5.1 – Ejemplo de join tabla 1………………………………………………………………69
5.2 – Ejemplo de join tabla 2………………………………………………………………69
5.3 – Ejemplo de join tabla resultado……………………………………………………...69
5.4 – Ejemplo RETE “es el autor de”……………………………………………………...71
5.5 – Ejemplo RETE “es un libro”……………………………………………………...…71
5.6 – Ejemplo RETE “es escritor de ciencia ficción”……………………………………..72
5.7 – Ejemplo RETE “es el autor de & es escritor de ciencia ficción”……………………73
5.8 – Ejemplo RETE “es el autor”………………………………………………………...74
xxii
xxiii
VII LISTADO DE ACRÓNIMOS
RHS Right Hand Side
LHS Left Hand Side
BC Base de Conocimiento
TFG Trabajo de Fin de Grado
PaaS Platform as a Service
HTML HyperText Markup Language
VPL Visual Programming Language
FSM Finite-State Machine
JDT Java Development Tools
IDE Integrated Development Environment
SGML Standard Generalized Markup Language
CSS Cascading Style Sheets
W3C World Wide Web Consortium
SQL Structured Query Language
UML Unified Modeling Language
CASE Computer Aided Software Engineering
GUI Graphical User Interface
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
URL Uniform Resource Locator
TCP Transmission Control Protocol
xxiv
API Application Programming Interface
XML Extensible Markup Language
JSON JavaScript Object Notation
SGBD Sistema Gestor de Base de Datos
25
1. INTRODUCCIÓN
1.1 SISTEMAS BASADOS EN REGLAS
Los sistemas basados en reglas están basados, principalmente, en tres partes
importantes: un conjunto de reglas que definen su base de reglas (parte básica de la base de
conocimiento), la base de hechos y el mecanismo por el cuál son interpretadas las reglas,
llamado comúnmente motor de inferencia [CST].
Figura 1.1 – Representación de un sistema basado en reglas
Las reglas definen las distintas variantes del comportamiento, y por otro lado el
mecanismo de control de inferencia se encarga de la correcta selección y ejecución de las
mismas.
El formato más popular en el cual aparecen las reglas se define de la siguiente manera:
si -antecedente- entonces –consecuente-
El -antecedente- puede ser nombrado, según el ámbito, de varias formas: parte
condicional, condiciones, condiciones previas, etc., pero en el contexto en el que se va a
hablar en este documento será nombrado LHS (parte izquierda). Por otra parte, el -
consecuente- también posee varios términos para su nombramiento, como pueden ser,
conclusión, hipótesis, acción, etc., pero al igual que el -antecedente-, en el nombrado
documento vamos a utilizar el término RHS (parte derecha). El significado básico de las
reglas de este tipo es que si las condiciones que se han definido en el -antecedente- se
26
satisfacen, las conclusiones o acciones definidas en el -consecuente- se pueden ejecutar
[WST].
Hasta este punto solamente se ha hablado de la parte más básica de la base de
conocimiento, que son las reglas, por lo que ahora es el turno de hablar de los denominados
hechos. Éstos representan conocimientos sobre el problema, como pueden ser datos,
hechos establecidos, fines, etc. También pueden concebirse como una relación entre
entidades. En la definición de los hechos estas entidades se representan mediante símbolos
o términos que sean representativos. Se suelen representar en formato de lista. Como puede
ser la siguiente forma:
(x vuela), (x tiene plumas)
El conjunto de todos los hechos definidos para uno o varios problemas conforman una
base de hechos. Ésta representa el problema en curso de solución, y va cambiando a
medida que el proceso de inferencia se va ejecutando. Se pueden distinguir dos partes en la
BC: parte permanente, en la cual se especifican características que siempre se dan en el
problema; y parte temporal, que por el contrario se describen las características que van a
cambiar durante el proceso de solución del problema.
Y por último, queda por hablar de la parte que da sentido y utilidad a las dos anteriores,
el motor de inferencia. Éste usa ambas partes descritas anteriormente para inferir
resultados en forma de nuevas conclusiones o hechos.
En el tema que nos concierne se puede hablar de dos estrategias para inferir resultados
partiendo de una base de hechos: encadenamiento hacia atrás y encadenamiento hacia
delante.
En el encadenamiento hacia atrás, también conocido como dirigido por objetivos, se
intenta probar una hipótesis a través de sus premisas. Del modo que en primer lugar se
consideran sus premisas y se trata de comprobar si éstas son correctas, de este modo se
desemboca en la comprobación de otras reglas que podrían confirmar estas premisas, y así
sucesivamente hasta llegar a un marco en el cual todas las premisas anteriores son
correctas, o por el contrario hasta que se determine que el encadenamiento no es el
correcto. Con lo cual esta estrategia puede llegar a ser muy ineficiente debido a que se
puede demorar demasiado en la búsqueda de la satisfacibilidad de la regla.
27
En cambio, en el encadenamiento hacia adelante, también denominado dirigido por
datos, se parte de un conjunto de hechos conocidos con los que se intentarán satisfacer las
premisas de las reglas de la base de reglas, para así dispararlas y obtener nuevos hechos.
Esta estrategia se lleva a cabo en tres pasos: detección de reglas aplicables, selección de
una regla aplicable y disparo de la regla seleccionada en el paso anterior [MRN] [MRK].
En el ámbito que se va a desarrollar este proyecto se va a utilizar la segunda estrategia
descrita, ya que se va a utilizar un algoritmo llamado RETE (término cuyo significado es
red en latín), el cual se basa en dicho modo de trabajo.
1.1.1. Ventajas
En este apartado se va a hacer una evaluación de las posibles ventajas que se pueden
obtener al usar este tipo de sistemas.
o Una de las principales ventajas de estos sistemas es que al describir los problemas
en formato de reglas permite definir el problema de una manera sencilla y por
consecuencia obtener las soluciones verificadas (las reglas son mucho más fáciles
de leer que le código).
o La rapidez y escalabilidad respecto a otros sistemas es otro de los puntos fuertes a
tener en cuenta. Distintos algoritmos que utilizan este sistema de conocimiento
como puede ser RETE o Leaps son un ejemplo de patrones que pueden proveer esta
eficiencia a el problema a resolver.
o Existen numerosas herramientas que permiten una integración con el entorno de
desarrollo orientado a estos sistemas, los cuales proporcionan una manera cómoda
de editar y gestionar reglas.
1.2 ESTRUCTURA DE LA MEMORIA
Este documento ha sido estructurado según el formato que se recomienda en la
normativa de trabajos de fin de grado de la Escuela Superior de Informática de la
Universidad de Castilla-La Mancha, el cual está integrado por los siguientes capítulos:
o El capítulo 1, en el que nos encontramos presentes, consta de una introducción de
los temas que se van a hablar durante todo el documento para que el lector entre en
materia. Como en este caso pueden ser los sistemas basados en reglas y la red
RETE.
28
o En el capítulo 2 se exponen los distintos objetivos que se pretenden alcanzar con la
realización de este proyecto, así como las principales limitaciones a tener en cuenta
y el material que se ha necesitado para su desarrollo.
o En el capítulo 3 se analizan y se exponen los antecedentes que existen en el ámbito
en el que se ha trabajado.
o En el capítulo 4 se describen tanto las metodologías de trabajo que se han seguido
para la elaboración del proyecto, como las herramientas y entornos utilizados.
o En el capítulo 5 se exponen los resultados obtenidos al aplicar las diferentes
técnicas descritas en el apartado anterior.
o En capítulo 6 se dilucidarán las conclusiones obtenidas en el desarrollo del trabajo
y se propondrá posibles mejoras de cara al futuro.
o Más allá del capítulo 6, se incluye un listado con las referencias bibliográficas
utilizadas tanto en el estudio previo del arte, como en el desarrollo del trabajo.
o Y en último lugar se encuentra el anexo, dónde se puede encontrar una guía de
usuario detallada con los principales aspectos que se tienen que tomar en cuenta
para la utilización de la herramienta.
29
2. OBJETIVOS
2.1 DESCRIPCIÓN DEL PROBLEMA
El problema que se aborda en la realización de este TFG es mostrar el funcionamiento
de una red RETE para una mejor comprensión de este algoritmo.
2.2 OBJETIVOS
Se propone abordar el problema descrito mediante el desarrollo una aplicación web que
permita la visualización gráfica del proceso de actualización de una red RETE.
El usuario podrá modificar la base de hechos editando, eliminando o añadiendo nuevos
hechos, así como modificar la base de reglas con las mismas acciones que se permiten en
el caso de los hechos. Terminada la fase de modificación, el usuario podrá visualizar
gráficamente los cambios que se han ejecutado en la red RETE.
2.2.1 Otros objetivos
A parte del objetivo principal que se propone en este documento, existen otros objetivos
adyacentes que merecen ser mencionados.
Objetivos teóricos:
o Análisis de antecedentes de herramientas que ya existen con estas
características o similares.
o Estudio detallado del funcionamiento del algoritmo RETE.
o Estudio de los procedimientos para representar la red mediante grafos.
o Análisis del lenguaje gráfico propuesto para la edición de conocimientos, el
cual va a ser Blockly, desarrollado por Google.
Objetivos prácticos; la aplicación que se va a desarrollar permitirá al usuario:
o Administrar correctamente tanto una base de hechos, como una base de reglas.
o Realizar correctamente la inserción de reglas y hechos. Teniendo constancia de
qué relaciones entre antecedentes se pueden incluir dentro de una misma regla y
qué hechos se deben incluir en la base de hechos.
o Comprender la representación de este tipo de red mediante un grafo.
30
o Familiarizarse con el entorno gráfico propuesto para la edición de reglas y
hechos, en este caso, que como se ha nombrado antes, es Blockly.
Objetivos académicos; la realización de este TFG supondrá la superación de los
siguientes objetivos académicos:
o Estudiar y aplicar los múltiples elementos de programación necesarios para el
desarrollo del trabajo.
o Practicar el modo de trabajo que conlleva una metodología de desarrollo
software.
2.3 ENTORNO DE TRABJO Y LIMITACIONES.
Para realización del proyecto se ha usado un ordenador personal portátil haciendo uso
del sistema operativo Windows 10.
Como entorno de trabajo para el desarrollo de la aplicación se ha utilizado el IDE de
Eclipse1 (Eclipse Luna SR1 ). Se tomó esta determinación por la simple razón de que es la
herramienta más confortable y que posee mayor compatibilidad de elementos en este
ámbito. Además, existe un plugin que permitirá coordinar perfectamente nuestro proyecto
con el modelo PaaS seleccionado para el desarrollo del trabajo. Como Paas se van a
utilizar los servicios de Google App Engine2, cuyas características se explicarán más
adelante.
En lo que atañe a los lenguajes de programación se han utilizado; Java, para la
programación en el lado del servidor; Java Script, en el lado del cliente; y HTML en el
ámbito de la interfaz gráfica.
1 http://www.eclipse.org/ 2 https://cloud.google.com/appengine/
31
3. ANTECEDENTES, ESTADO DE LA CUESTIÓN
En este capítulo se va a exponer qué antecedentes existen y qué información, obtenida
durante el proceso de análisis, es importante destacar. En primera instancia se va
profundizar en lo que se refiere al algoritmo RETE, se va a describir con detenimiento su
funcionamiento y a exponer sus principales características. A continuación, se hablará de
los VPL (lenguajes de programación visual) y sus posibles aplicaciones.
3.1 ALGORITMO RETE
Para implementar un algoritmo que permita inferir resultados, a priori, podría
proponerse una solución en la cual se comprobara cada antecedente de una regla con cada
uno de los hechos de la base de conocimiento, disparando así a regla si fuera necesario.
Este método puede servir para sistemas que están formados por un número pequeño de
reglas, pero para sistemas reales que implican un número elevado de reglas y una regla
puede tener a su vez cientos de hechos a comprobar es muy ineficiente.
Como posible solución a este problema de ineficiencia surge RETE, el que es definido
como mecanismo de encaminamiento hacia delante. RETE se basa en una red de
reconocimiento de patrones que fue presentada por el profesor Dr. Charles Forgy en su
tesis doctoral en la cual describe como reducir el tiempo necesario para decidir qué reglas
deben de ser activadas en cada ciclo de inferencia. El funcionamiento de este algoritmo se
basa en dos premisas:
1. La memoria es muy grade y no sufre variaciones notables entre dos ciclos, por
lo que gran parte de la información es muy útil para futuros ciclos.
2. Al haber similitud entre las condiciones de las reglas y que a su vez sean
estáticas, hace que se puedan procesar la reglas antes de ser utilizadas
localizando sub-condiciones habituales entre reglas de manera que no sean
redundantes.
RETE construye una red de nodos en la cual el estado del proceso de emparejamiento de
los nodos es almacenado, de este manera que sólo es necesario re-calcular cambios en caso
de que los hechos se vean modificados. La lista de hechos puede cambiar en cada ciclo de
inferencia, por lo que dado este caso, en cada finalización de ciclo existirán reglas cuyos
patrones sí puedan ser satisfechos y antes no [SVN].
32
3.1.1 Partes de la red
La red de RETE es un grafo acíclico dirigido que está compuesto por nodos que
representan un determinado patrón en las condiciones de las reglas. Estos nodos permiten
hacer una criba de los datos de entrada, es decir, la combinación de hechos que coinciden
con una parte de las condiciones que posee una regla. Propagando al resto de nodos sólo
los datos que hayan pasado la criba.
Existen tres tipos de nodos: alfa, beta y gamma. Los nodos alfa se encargan de realizar
pruebas sobre hechos individuales, en cambio los llamados beta, cotejan la relación
existente entre las variables de los antecedente de las reglas. Asimismo, cada nodo posee
una memoria asociada que se denomina memoria alfa y memoria beta respectivamente, las
cuales almacenarán los hechos que han sido emparejados en ciclos previos. Dicha razón es
la culpable del hecho de decir que con RETE se sacrifica memoria para ganar velocidad de
procesamiento. Así como, si varias reglas poseen el mismo antecedente, compartirían el
mismo nodo alfa dentro de la red, evitando así una posible redundancia en la base de
reglas.
Estableciendo una analogía con el modelo de bases de datos relacionales, podemos
equiparar la operación SELECT al proceso de selección de un hecho de la lista de hechos
disponibles para someterlo a la criba de nodos alfa, de tal modo que si el hecho coincide
con la condición que se define en un nodo alfa cualquiera, éste será almacenado en la
memoria alfa correspondiente. Continuando con la analogía propuesta, a la operación JOIN
la podemos asemejar al proceso de verificar la consistencia entre la cohesión de distintas
de distintas variables que constituyen el antecedente de una regla [CBN]. En el capítulo de
resultados se ahondará más en este tema, y se propondrá un modelo de base de datos que
satisfaga los requisitos de este algoritmo.
3.2 LENGUAJES DE PROGRAMACIÓN VISUAL (VPL)
La programación es considerada generalmente como una labor complicada a la cual se
dedica mucho tiempo, incluso cuando se refiere a profesionales. Este hecho proviene en
gran parte de la discrepancia que existe entre los entornos de programación. Una de las
posibles soluciones a este problema reside en la utilización de recursos visuales en la
programación.
33
Se llama lenguaje de programación visual a todo lenguaje de programación que permite
la creación de programas mediante la manipulación de los elementos característicos de la
programación de una forma gráfica, en lugar de especificarlos textualmente. De este modo,
posibilita la programación con expresiones visuales, disposiciones de texto en algunos de
los elementos y símbolos gráficos, utilizados indistintamente como elementos de sintaxis o
de notación secundaria. La programación se lleva a cabo simplemente con la disposición
de los iconos o figuras en la pantalla. Además, el sistema muestra los resultados parciales
de ejecución a medida que se avanza en el desarrollo del programa, de manera que el
usuario puede seguir el proceso de manera interactiva. Este último dato es una de las
grandes bazas con las que cuenta este nuevo estilo de programación, ya que permite la
depuración en línea y la generación automática de programas y de documentación [BRN].
Se distinguen varias categorías dentro de este modo de trabajo en función de la forma
en que se relacionan los distintos artefactos. A continuación se exponen algunas de estas
categorías y las características que las definen [HS] [DH]:
Educativo: en este tipo la gramática es esencialmente la misma que en el caso de
un lenguaje de programación imperativo clásico, con la diferencia que los
elementos gráficos ayudan a tratar de una forma más evidente las combinaciones
de los elementos básicos como pueden ser variables, condiciones o controles de
flujo. La mayor baza de este formato es el estilo colorido y amigable de sus
elementos, en lugar de un puñado de líneas de código. Este aspecto favorece el
interés de aprendizaje del usuario. Como ejemplo de esta categoría se pueden
proponer: Scratch. Blockly, Etoys, Snap!, etc.
34
Figura 3.1 – Interfaz de Scratch
Inspirados en diagramas de flujo: este modo parte de la idea del uso de “cajas y
flechas” para la descripción de los programas. Estos VPLs utilizan una
representación visual muy cercana a la que representa los diagramas de flujo para
describir el flujo de control principal. Se representa la secuencia de ejecución
mediante formas geométricas, en cambio el flujo de ejecución se representa
generalmente mediante flechas. Se usa el resultado o salida de una de estas figuras
para elegir cuál de ellas se ejecutará a continuación. Bajo este enfoque, la gramática
visual es fácil de entender, pero las construcciones lógicas que se pueden crear a
través del lenguaje gráfico son muy limitadas. Algunas de las herramientas que
siguen este patrón son: Raptor, Flowhub, Flowgorithm, etc.
Figura 3.2 – Interfaz de Flowgorithm
35
Flujo de datos: este formato es uno de los más utilizados para herramientas
profesionales, dirigidas a desarrolladores en lugar de usuarios novatos en
programación. En este modo cada bloque representa una función y el flujo está
representado por uniones entre estos bloques. Se crea una relación entre el
elemento de salida del bloque con el elemento de entrada de otro, definiendo así el
flujo de ejecución. Por lo tanto la gramática visual es muy simple, se limita a elegir
qué bloques (funciones) utilizar y cómo en lazarlas. Por lo cual gran parte de la
codificación del programa se encuentra dentro de los bloques. Drakon, Simulink,
Blender (editor gráfico de la lógica de acción) son algunas de las herramientas que
se basan en este tipo de formato.
Figura 3.3 – Interfaz del editor gráfico de la lógica e acción de Blender.
Máquinas de estado finito (FSM): en este tipo se definen estados, y las transiciones
entre ellos son accionadas por condiciones. Cuando un estado cambia, las
instrucciones se activan. Esta descripción se representa gráficamente mediante
bloques en caso de los estados y uniones en el caso de las transiciones. El usuario
diseña el flujo de ejecución de la misma forma que en los diagramas de flujo. Se
pueden proponer como ejemplo de este tipo de herramientas: Unity3D (mecanismo
de control de animación), xaitControl, EKI One, etc.
36
Figura 3.4 – Interfaz del mecanismo de control de animación en Unity3D
Modelo de árbol: en éste se sigue la inspiración el tipo de máquinas de estado
finito. La gramática visual se rige por bloques y enlaces entre éstos, los cuáles
definen el flujo de ejecución. Pero a diferencia de los modelos similares, los
bloques son evaluados y devuelven un estado al bloque anterior, siguiendo la
estructura de árbol (padres e hijos). De esta manera un bloque adquiere un
comportamiento que dependerá de sus hijos, y controlará el flujo de ejecución en
consecuencia del resultado. El diseño del programa es más directo y legible de una
manera más cómoda debido a que hay menos lógica en los campos de texto.
Algunas de las herramientas que usan este modelo son: Angry Ant Behave y craft
ai.
37
Figura 3.5 – Interfaz de craft ai
Eventos basados en reglas: este es el tipo más simple dentro de los VPLs.
Consiste en la utilización de la estructura “si-entonces”, es decir, la regla se
activa si se cumplen una serie de condiciones, y una vez activada se
ejecutan unas instrucciones específicas. Los elementos visuales suelen ser
muy simples, principalmente bloques que pueden ser utilizados en el lado
de las condiciones o en el de los consecuentes. Como ejemplos se pueden
proponer: Zapier, Netvibes Dashboard Of Things, Kodu.
Figura 3.6 – Interfaz de Kodu
38
39
4. MÉTODO DE TRABAJO
En este apartado se va a describir la metodología que se ha usado para el desarrollo de
la aplicación y las herramientas tecnológicas que se han requerido para su implementación.
4.1 METODOLOGÍA ÁGIL DE DESARROLLO SOFTWARE
En el proceso de desarrollo de un proyecto software pueden surgir serios problemas a
la hora de introducir cambios sustanciales. Cabe la opción de que el cliente introduzca
nuevos requisitos o simplemente prescinde algunos de ellos. En este marco es dónde nace
la metodología ágil enfocada al desarrollo de software. Las principales premisas de esta
metodología se basan en un desarrollo del trabajo de forma iterativa e incremental, en la
cual los requisitos y objetivos evolucionan con el tiempo dependiendo de las necesidades
en ese momento. El trabajo es realizado mediante la cooperación de quipos auto-
organizados y multidisciplinarios que comparten la toma de decisiones, la cuales se toman
a corto plazo.
Figura 4.1 - Gráfico que muestra las diferentes etapas dentro de un ciclo de vida
Esta definición modernizada de metodología ágil es el resultado de una evolución
iniciada a mediados de los años 1990 como reacción en contra de las metodologías usadas
en esa etapa. Éstas se caracterizaban por seguir un modelo de desarrollo en cascada, que
era visto como un modelo de trabajo lento e inconsistente con los modelos que realmente
llevaban a cabo un trabajo eficiente. Más adelante, ya en el año 2001, se reunieron en Utah
40
los principales exponentes de esta comunidad y adoptaron el nombre de métodos ágiles. Al
poco tiempo, parte de este mismo grupo de personas formaron, lo que se denominó en su
momento la The Agile Allianze3 (alianza ágil). Consiste en una organización sin ánimo de
lucro que se encarga de promover los conceptos relacionados con el desarrollo ágil de
software y prestar ayuda a las organizaciones para que adopten estos conceptos. Crearon
un documento, llamado Manifiesto Ágil, en el cual se resume la filosofía ágil [PZ] [ISSI].
4.1.1 El manifiesto ágil
Según el manifiesto prevalecen los siguientes valores[ISSI]:
o Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. La gente es el principal factor de éxito de un proyecto software. Es
más importante construir un buen equipo que construir el entorno. Muchas veces se
comete el error de construir primero el entorno y esperar que el equipo se adapte
automáticamente. Es mejor crear el equipo y que éste configure su propio entorno
de desarrollo en base a sus necesidades.
o Desarrollar software que funciona, más que conseguir una buena
documentación. La regla a seguir es “no producir documentos a menos que sean
necesarios de forma inmediata para tomar un decisión importante”. Estos
documentos deben ser cortos y centrarse en lo fundamental.
o La colaboración con el cliente, más que la negociación de un contrato. Se
propone que exista una interacción constante entre el cliente y el equipo de
desarrollo. Esta colaboración entre ambos será la que marque la marcha del
proyecto y asegure su éxito.
o Responder a los cambios más que seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a los largo del proyecto (cambios en los
requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso
del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
3 www.agilealliance.org
41
4.1.2 Etapas de una metodología ágil
Como se ha descrito anteriormente este modelo se trabaja mediante iteraciones o
etapas. Cada iteración del ciclo de vida se divide a su vez en cinco etapas.
4.1.2.1 Análisis de requisitos
En esta etapa se extraen los requisitos de un producto software. Debe existir un
consenso entre el desarrollador software y el cliente. El cliente por norma general expondrá
sus requisitos sin conocimientos de diseño, por lo que existirán contradicciones,
ambigüedades, a su vez que definiciones incompletas. Como resultado de esta fase se
obtiene el documento de especificación de requisitos. Esta fase es crucial, ya que de ésta
depende en gran medida el cumplimiento de los objetivos finales.
4.1.2.2 Diseño
En esta etapa del ciclo de vida se determina la manera en la que el software funcionará
de forma general, sin entrar en detalles. Se incorporarán los detalles de la implementación
tecnológica que son necesarios tener presente, como pueden ser el hardware, la red, etc.
Son definidos los casos de uso que serán necesarios para satisfacer las funciones que
realizará el sistema.
4.1.2.3 Codificación
En la presente etapa se plasma en código todo lo descrito en la fase de diseño. A priori
puede parecer la fase más ardua en cuanto a trabajo y dificultad dentro del ciclo de vida,
pero no necesariamente tiene que ser así. El nivel de dificultad y de trabajo dependerá
directamente de la calidad del diseño y de los lenguajes de programación que es necesario
usar.
42
4.1.2.4 Pruebas
Se realizan las pruebas pertinentes para comprobar que el producto software obtenido
cumple con los requisitos indicados en la especificación del problema. Las pruebas
ofrecerán mejores resultados si la persona que ejecuta las pruebas no es la misma que ha
desarrollado esa parte del software.
4.1.2.5 Mantenimiento
Una vez desplegado el producto pueden aparecer errores o pueden surgir nuevos
requisitos. Por lo tanto comienza una nueva etapa, la de mantenimiento, en la cual se
corrigen errores, se perfeccionan funciones o se añaden nuevas funcionalidades.
Dependiendo de estos factores, el mantenimiento adquiere diferentes nombres. Correctivo,
perfectivo, evolutivo o adaptativo.
4.2 OTROS ASPECTOS DE LA METODOLOGÍA
Esta es la metodología que a grandes rasgos se ha seguido en la elaboración del
proyecto. Pero siempre existen pequeñas modificaciones que surgen respecto a un modelo
base. Esto se refiere a que dentro de esta metodología se ha seguido un modelo de trabajo
más orientado a la consecución de metas. En casa fase del desarrollo se han ido marcando
metas, en las cuales existían unos logros de objetivos. Se tomó esta decisión para poder
permitir una mayor adaptabilidad de ideas entre el cliente (el director del proyecto en este
caso) y el desarrollador (el autor del proyecto), debido a la previsión de cambios en
algunos de los requisitos establecidos previamente.
Este modelo descrito se puede asemejar a un tipo de metodología ágil llamado Scrum,
siguiendo un modelo en espiral. La elección del modelo en espiral reside en el hecho de
poder echar un paso hacia atrás y realizar una revisión del trabajo realizado hasta ese
momento, permitiendo detectar pequeños fallos en fases anteriores los cuales podrían
derivar en errores más graves en un futuro.
43
Figura 4.2 – Ilustración ciclo de desarrollo en espiral
4.2.1 Scrum (modelo en espriral)
Como ya se ha expuesto en apartados anteriores, Scrum es una metodología ágil para la
gestión de desarrollo de software. En este modelo se llevan a cabo entregas parciales y de
una manera regular del producto final, dando prioridad al beneficio que aportan al cliente.
Por tanto este modelo está orientado, principalmente, a proyectos donde existe la necesidad
de obtener resultados rápidamente, donde los requisitos son cambiantes y donde la
productividad y la flexibilidad son fundamentales [ISSI].
Esta metodología de trabajo fomenta la innovación, compromiso y motivación del
grupo de trabajo que forma parte del proyecto, por lo que aumenta la eficiencia a la hora de
llevar a cabo el trabajo.
Sprint Planning (Planificación de la iteración)
La planificación de los objetivos a cumplir en cada iteración se divide en dos partes:
o Primera parte; el cliente presenta al equipo de desarrollo las lista de objetivos que
se deben alcanzar y cuáles de ellos son los prioritarios. El equipo realiza una
revisión de la lista y pregunta posibles dudas surgidas, a su vez que se compromete
con el cliente al cumplimiento de una selección de objetivos que son más
determinantes en la presente iteración.
o Segunda parte; el equipo de desarrollo llevaba a cabo una planificación de la
iteración. Elaboran el procedimiento por el cual conseguirán mejores resultados con
el mínimo esfuerzo posible. Se definen las tareas necesarias para poder completar
44
cada objetivo, y con éstas se crea un documento llamado Sprint Backlog (lista de
tareas de la iteración).
Ejecución del Sprint
Se denomina Sprint a cada una de las iteraciones. Es el período en el cual se lleva a
cabo el trabajo en sí. Se recomienda que la duración del mismo sea constante y definida
por el equipo en relación a la experiencia que poseen. Al final de cada sprint deberá
mostrar los avances logrados, habiendo obtenido un producto que, potencialmente, se
puede entregar al cliente, a esta práctica se la denomina Sprint Retrospective (retrospectiva
del sprint).
Sprint Review (revisión del sprint)
Una vez terminado el sprint es necesario revisar que parte del trabajo fue completado y
cual no. El trabajo que sí ha sido completado se muestra al cliente para que éste pueda dar
el visto bueno y poder realizar observaciones o adaptaciones.
Roles
o Product owner; representa al cliente. Es el encargado de que el equipo realiza su
trabajo adecuadamente desde la perspectiva del negocio, así como de definir
objetivos del proyecto, dirigir sus resultados y de decidir qué requisitos son
prioritarios para el cliente.
o ScrumMaster; su principal fin es eliminar los obstáculos que impiden que el equipo
alcance los objetivos del sprint. No figura como líder del equipo, únicamente se
asegura que el proceso Scrum se cumpla adecuadamente.
o Equipo; es el conjunto de personas que adquiere la responsabilidad del desarrollo
del producto. Cada uno de ellos posee las habilidades necesarias para la realización
del trabajo.
4.3 HERRAMIENTAS TECNOLÓGICAS
4.3.1. Herramientas de desarrollo software
Eclipse; es una plataforma de software que está compuesto por un conjunto de
herramientas de programación de código abierto multiplataforma para el desarrollo
de lo que se denomina “Aplicaciones de Cliente Enriquecido”, opuesto a las
45
aplicaciones de “Cliente-liviano” basadas en navegadores. Esta plataforma ha sido
usada normalmente para desarrollar entornos de desarrollo integrados (que
proviene del término anglosajón IDE), como puede ser el IDE de Java (JDT).
Su integración con el PaaS escogido mediante un plugin y el perfecto soporte de
los lenguajes de programación que se han usado, han sido factores clave para la
elección de esta herramienta como entorno de trabajo.
En la figura 4.3 se muestra la interfaz principal del entorno Eclipse.
Figura 4.3 – Interfaz de Eclipse
HTML; es un lenguaje de marcas de hipertexto (HyperText Markup Language) que
está basado en el metalenguaje SGML, y que es utilizado para la elaboración de
páginas web. Se caracteriza por poseer una estructura básica y hacer uso de un
código, determinado para la definición de contenido dentro de una página web,
como pueden ser, imágenes, textos, videos, etc. Este código tiene dos partes
notablemente diferenciadas; el conjunto de etiquetas del propio lenguaje HTML y el
contenido en sí de la información.
CSS; su nombre viene definido por la siglas de su denominación en inglés
(cascading style sheets), y que en castellano significan hoja de estilo en cascada.
46
Como su propio nombre indica es una hoja de estilo que es usada para definir y
crear la presentación de un documento escrito en HTML. La idea principal al
desarrollar esta idea es separar la especificación de la estructura del documento de
su presentación. El World Wide Web Consortium (W3C) es el encargado de
formular la especificación de las hojas de estilo que posteriormente sirven de
estándar para los navegadores.
JavaScript; es un lenguaje de programación interpretado, dialecto del estándar
ECMAScript. En su definición consta como orientado a objetos, basado en
prototipos, imperativo, dinámico y débilmente tipado. Se utiliza principalmente en
la parte del cliente, implementado como parte de un navegador web permitiendo
mejoras en la interfaz de usuario y páginas web dinámicas.
Blockly4; es un lenguaje de programación totalmente visual que permite construir
código, simplemente, juntando pequeños elementos gráficos. Cada uno de estos
elementos gráficos es también un elemento de código, de manera que conforme se
van juntando estas piezas se van formando funciones de código. Este proyecto está
desarrollado por Google, y se puede catalogar como una reminiscencia de la
herramienta Scratch. Blockly está implementada en JavaScript, pero a su vez puede
compilar en JavaScript, Dart o Python.
Esta herramienta es la elegida para definir nuevos hechos y nuevas reglas en el
sistema propuesto.
En la figura 4.4 se muestra la interfaz de esta herramienta.
4 https://developers.google.com/blockly/
47
Figura 4.4 – Interfaz de Blockly
Dot; es un lenguaje descriptivo en texto plano. Provee una forma sencilla de
describir gráficos que sean entendibles por humanos y computadores [BLT];.
SQL; es un lenguaje de tipo declarativo orientado a accesos a base de datos
relacionales, el cual permite especificar diversos tipos de operaciones entre ellas.
Una de sus principales características es el uso del cálculo relacional y el álgebra
que permiten realizar consultas con el propósito de recuperar información de bases
de datos y ejecutar cambios sobre las mismas
4.3.2. Herramientas de modelado
Dia5; es una programa que permite la creación de diagramas. Está desarrollado en
módulos, dándole la oportunidad al usuario de elegir entre varios paquetes según
las necesidades. La versión en la que en este momento se encuentra, permite la
creación de diagramas UML (Unified Modeling Language), diagramas entidad-
relación, diagramas de flujo, diagramas de redes, etc.
En la figura 4.5 se muestra la interfaz de esta herramienta.
5 http://dia-installer.de/
48
Figura 4.5 – Interfaz de Dia
Visual paradigm6: es una herramienta de tipo CASE (Computer Aided Software
Engineering) para el modelado UML. Constituye un conjunto de ayudas para el
desarrollo de software en cada una de sus etapas, desde la planificación,
continuando con el análisis y el diseño, incluso con la generación de código y
documentación. El principal propósito para el que se creó esta herramienta fue el
soporte completo del ciclo de vida del desarrollo de software, a través de la
creación de gran variedad de diagramas.
Esta herramienta ha sido usada en el presente trabajo para crear los diferentes
diagramas UML que se incluyen.
En la figura 4.6 se muestra un ejemplo de la interfaz de esta herramienta.
6 http://www.visual-paradigm.com/
49
Figura 4.6 – Interfaz de Visual Paradigm
Balsamiq moqups7; es una herramienta que se utiliza para la realización de bocetos
y diseños de borradores de interfaces de usuario. Permite representar gran mayoría
de los elementos presentes en una interfaz, además de una manera fácil y rápida.
En la figura 4.7 se muestra la interfaz de esta herramienta.
7 https://balsamiq.com/
50
Figura 4.7 – Interfaz de Balsamiq moqups
Xmind8; es un programa de software libre que permite al usuario la creación de
mapas conceptuales. Ayuda a anotar ideas, organizar gráficos, y compartirlos para
trabajar de una manera colaborativa.
En la figura 4.8 se muestra la interfaz de esta aplicación.
Figura 4.8 – Interfaz de Xmind
8 http://www.xmind.net/
51
5. RESULTADOS
En este capítulo el foco de atención se centrará en describir los resultados obtenidos
una vez aplicado el modelo de trabajo descrito en el capítulo anterior, una metodología ágil
basada en Scrum siguiendo un modelo en espiral.
La elaboración del proyecto se ha dividido en cinco grandes etapas o Sprints, en las que
cada una tendrá una lista de objetivos asociados, y que han sido acordados previamente
con el cliente. Al inicio de cada etapa se realizó una reunión para acordar estos objetivos, y
cuáles de ellos poseían mayor prioridad dentro del mismo Sprint.
Una vez terminado el Sprint, y antes de pasar a la definición de objetivos del siguiente,
se realizaba una retrospectiva para analizar qué objetivos se habían alcanzado
correctamente y cuáles no. También se realizaban demostraciones al cliente de los
objetivos alcanzados, dándole la oportunidad de dar observaciones y proponer
adaptaciones al resultado obtenido.
Figura 5.1 – Mapa conceptual de metas
5.1 SPRINT 1
Esta primera etapa se dedicó al análisis de la situación del arte y qué elementos existían
en este ámbito. Se establecieron una serie de reuniones con el cliente dónde se discutieron
y se propusieron las diferentes opciones que se barajaban en cuanto a las funcionalidades
que iba a poseer el presente proyecto. Llegados a este punto se definieron formalmente los
requisitos funcionales que la herramienta debería cumplir. Para este fin se llevó acabo un
modelo orientado a casos de uso. Cada caso de uso es una acción que un actor (por ejemplo
el usuario o el servidor) podrá llevar a cabo en el sistema implementado.
52
Una vez obtenidos los resultados del análisis se procedió a determinar “el cómo” de la
herramienta a desarrollar. Se llevó a cabo una investigación para determinar qué elementos
o arquitecturas se adaptaban a las necesidades que se habían acordado en el punto anterior,
para así poder desarrollar satisfactoriamente el proyecto.
5.1.1 Arquitectura Seleccionada.
Para llevar a cabo este proyecto se decidió utilizar un modelo de aplicación web.
Ésta era la opción más versátil y más cómoda para el usuario. Se valoraron otras opciones,
como por ejemplo una aplicación de escritorio, pero sopesados los problemas que podría
ocasionar crear una herramienta instalable en una determinada plataforma o entorno,
restándole así usabilidad, se decidió rechazar esta opción. Por otra parte, de cara al usuario,
es más cómodo el uso de una aplicación web, que incluso podría utilizarla con un
dispositivo móvil o una tableta.
En cuanto a lo que se refiere a la implementación, se propuso una estructura cliente-
servidor apoyada por PaaS (Platform as a Service), o Plataforma como Servicio. Hoy en
día ésta es la forma más eficiente y cómoda de llevar a cabo modelos de este tipo. En los
siguientes apartados se explicará más a fondo las características y el funcionamiento de
estas arquitecturas.
5.1.1.1 Arquitectura Cliente-Servidor
A grandes rasgos esta arquitectura consiste en que un cliente realiza peticiones a un
servidor y éste le contesta con la información solicitada si se la puede proporcionar.
Ésta forma pensamiento se puede aplicar en multitud de usos en el ámbito de la
computación, pero dónde más se usa es en plataformas web. Este modelo se usó por
primera vez en 1980, pero no empezó a ser extendido su uso hasta finales de esa misma
década. El principal motivo de la evolución de esta idea de trabajo es la necesidad que
existe en las organizaciones, ya sean empresas o instituciones públicas, de llevar a cabo
sus funciones de una manera más agil y eficiente. Debido a la creciente competencia a
la que éstas están sometidas, necesitan que su personal sea más productivo, así como, la
reducción de gastos de operación y de costos. Por lo tanto, es nesario adquirir una
infrasestructura de precesamiento de información, que posea estos elementos
53
requeridos para proveer un mejor servicio a los clientes. El modelo cliente-servidor
posee las características necesarias para suministrar estos servicios.
Figura 5.2 – Representación modelo cliente-servidor
Bajo un punto de visto más técnico, también se pueden dar variedad de razones por la
cuales este modelo es el óptimo para el ámbito que se requiere en este trabajo. Como
pueden ser:
o Cliente y servidor pueden actuar como una sola entidad, o pueden actuar como
entidades separadas, pudiendo realizar tareas diferentes.
o Las funciones de cliente y servidor pueden estar en la misma plataforma o en
plataformas separadas. Por lo tanto, cada una de ellas es escalable
independientemente. Los cambios realizados se realizan de una manera trnsparente
para el usuario final.
o El servidor proporciona servicio a varios clientes de forma concurrente.
5.1.1.1.1 Cliente
El cliente es el encargado de proporcionar al usuario la funcionalidad de formular las
peticiones y enviarselos al servidor, también llamado front-end.
Generalmente, el cliente es el encargado de manipular las funciones relacionadas con el
despliegue y precesamiento de datos. Por esta razón, es necesario que estén desarrollados
en plataformas que permitan contruir interfaces gráficas de usuario (GUI), y que además
puedan acceder a los servicios distribuidos necesarios.
54
Las principales funciones que lleva a cabo el proceso cliente son:
o Administración de la interfaz de usuario.
o Interacción con el usuario.
o Generar consultas de bases de datos.
o Recibir y dar formato a los resultados del servidor.
Como ya se ha explicado anteriormente en el cliente reside reside todos los elementos
que están relacionados con la interacción con el usuario. En el caso del modelo propuesto
en este trabajo, se ha utilizado html y CSS para dar formato a la interfaz de usuario y java
script para la lógica de esta parte de la infraestructura. Por otra parte para la comunicación
con el servidor se ha utlizado el elemento XMLHttpRequest.
Interfaz XMLHttpRequest
Esta interfaz se emplea para realizar peticiones mediante protocoles HTTP y HTTPS a
servidores web. HTTP (Hypertext Transfer Protocol), como su propio nombre indica, es un
protocolo de transferencia de hipertexto, que se encuentra en el nivel de aplicación, y que
permite intercambios de información entre cliente-servidor. Al cliente que realiza la
petición (generalmente un navegador) se le denomina user agent y a la información
transmitidida se la conoce como recurso y que a su vez se la identifica por medio de un
localizar uniforme de recursos (URL). Estos recursos puede ser el resultado de una
consulta de base de datos, el resultado e la ejecución de un programa, un archivo, etc. Es
un protocolo que no guarda información de conexiones previas, es de decir, no tiene
estado. Debido a que, habitualmente, las aplicaciones web que se desarrollan en este
ámbito necesitan guardar el estado, se utilizan otros elementos como pueden ser las cookies
y las sesiones. La principal diferencia que existe entre estas dos propuestas es la
localización de su almacenamiento; las cookies se almacenan localmente, y por el contrario
las sesiones se almacenan en el servidor.
Un escenario típico de este tipo de conexión podría ser el siguiente:
1. El cliente incicia una conexión TCP con el servidor por el puerto 80. Este
número es el definido por defecto.
55
2. El servidor, el cual se encuentra escuchando en el puerto 80, acepta la conexión
y se lo notifica al cliente.
3. El cliente manda un mensaje de petición POST dentro de la conexión abierta.
4. El servidor recibe esta petición, la procesa y crea el mensaje de respuesta. En
este mensaje de respuesta inlcuye la datos o el documento que se le ha
solicitado previamente.
5. El servidor cierra la conexión.
6. En el lado del cliente se recibe el mensaje y se realiza la acción para la que
estaba destinada la información o los elementos requeridos.
5.1.1.1.2 Servidor
El servidor es el encargado de atender a los múltiples clientes que le hacen peticiones de
recursos que éste administra. A este proceso también se llama back-end. El servidor
normalmente es el encargado de las operaciones lógicas, aunque puede ser habitual ver
parte de esta lógica en la parte del cliente.
A continuación se muestran las funciones que puede desarrollar el servidor:
o Dar formato a los datos para transmitirlos a los clientes.
o Aceptar requerimientos de bases de datos que realizan los clientes.
o Procesar consultas de base de datos.
o Procesar la lógica de la aplicación y realizar validaciones en cuanto a bases de
datos se refiere.
Tecnologías usadas en el servidor
En el lado del servidor también es necesario implementar una interfaz que nos permita
la conexión con el cliente. En este caso la interfaz que se va a usar es HttpServlet, la cual
pertenece a una API de Java llamada servlet. Estos elementos, llamados comúnmente
servlets, reciben las peticiones que se envían por parte del cliente, y a su vez permiten
contestar con los resultados correspondientes.
La interfaz nombrada anteriormente contiene, entre otros métodos a implementar, los
métodos doGet y doPost. Éstos son los más destacables, ya que van a ser los encargados de
56
recibir los datos implicados en la conexión. La diferencia a la hora de usar uno u otro es la
forma en la que los parámetros son recibidos o enviados; en el caso de doGet los
parámetros estarán contenidos dentro de la URL de la web concatenados entre sí y
utilizando como separador el símbolo “&”, por lo tanto los datos son visibles por el
usuario y tienen una capacidad de contenido muy limitada; en cambio el método doPost no
va a distorsionar la URL amigable de la web, y lo que es más determinante, va a permitir el
envío de grandes cadenas de texto[PL]. Este último factor descrito es el que tiene más
relevancia en el caso que nos atañe, debido a la necesidad de enviar las largas cadenas de
texto necesarias para procesar la información de la especificación XML de los bloques
Blockly usados en la interfaz.
Figura 5.3 – Métodos de la interfaz HttpServlet
5.1.1.1.3 Comunicación cliente-servidor
Hasta ahora, en los diferentes apartados anteriores, se ha descrito el modelo utlizado
para la comunicación entre las dos grandes partes en la que se dividide nuestro sistema. En
cambio en esta parte, es el turno de hablar del lenguaje que se ha utilizado para moldear los
57
datos en función de la forma que son requeridos en cada parte para que el entendimiento en
la comunicación sea satisfactorio. Es decir, si en el lado del servidor se utiliza el lenguaje
Java, los datos son formateados para que puedan ser enviados al cliente, y éste pueda
darles el formato que se requiere, en este caso la información tendrá que ser legible en
lenguaje Java Script.
Para este fin, hemos utilizado el formato JSON. Es el mecanismo de intercambio de
objetos complejos más utilizado en este ámbito. Su gran aceptación se debe, entre otras
cosas, a que permite representar objetos complejos como mapas de cadenas, que es mucho
menos pesado que otros mecanismos de intercambio, como puede ser XML, y que además
es fácilmente legible por las personas[PL]. Dada una descripción general de este formato
se va a profundizar un poco más en cómo se trabaja con él.
Puesto que en cada lado de la comunicación, comúnmente, va a existir discrepancia
de lenguajes, se utilizan estructuras universales. Estructuras que todos los lenguajes de
programación soportan de una forma u otra.
La primera estructura que se presenta es una colección de pares nombre/valor. Esta
práctica puede ser conocida en otros lenguajes como objeto, estructura, diccionario, tabla
hash, lista de claves, etc. Y La segunda es una lista ordenada de valores, o también
llamadas en otros lenguajes, vectores, listas o secuencias.
Estas estructuras se presentan en JSON de la siguiente manera:
1. El objeto es una colección desordenada de pares nombre/valor. Empieza con el
carácter “{” y termina con “}”. A cada nombre le sigue “:” y los pares
nombre/valor aparecen separados por “,”.
Figura 5.4 – Especificación de objeto en formato JSON
Ejemplo: {predicado : padre. parámetro: Luis}
58
2. Una colección de valores. Comienza con “[” y termina con “]” y lo valores se
encuentran separados por “,”.
Figura 5.5 – Especificación de colección de valores en formato JSON
Ejemplo: [luis, pedro, juan]
La colección de valores puede ser incluida como valor dentro del par nombre/valor
del objeto.
Ejemplo: {predicado : padre. parámetro: [luis, pedro, juan]}
5.1.1.2 Plataforma como Servicio (PaaS)
El modelo PaaS es una categoría de servicios proporcionados en la nube, también
conocida como cloud, que proveen un entorno y una plataforma que hace posible a los
usuarios crear herramientas y servicios que trabajen a través de la red.
Este servicio permite a los desarrolladores crear aplicaciones software utilizando
herramientas proporcionadas por el proveedor. Éste pone a disposición del usuario una
serie de servicios a los cuales podrán acceder por medio de suscripciones o alquileres. Por
norma general, no es necesario contratar todo el conjunto de herramientas de las que se
disponen, permitiendo al usuario elegir únicamente las necesarias para cubrir sus
requisitos. También ofrecen servicio técnico. Los servicios son actualizados
constantemente, tanto para añadir funcionalidades nuevas, como para mejorar las
existentes. Incluso, algunas de las organizaciones que proporcionan estos servicios ofrecen
la colaboración con los desarrolladores, desde la concepción del proyecto hasta el
desarrollo de la aplicación, o incluso llegando a la fase de pruebas.
A continuación se listan algunos de los servicios que pueden incluirse dentro de un
modelo PaaS:
o Sistema de gestión de base de datos.
o Hosting.
59
o Herramientas de diseño y desarrollo.
o Sofware de servidor.
o Sistema operativo.
o Almacenamiento.
o Acceso a la red.
o Soporte técnico.
Esta forma de trabajo no sólo aporta beneficios de cara a los desarrolladores y
programadores, también, aporta ventajas a los posibles clientes, a los cuáles, éstos están
prestando servicio.
Algunas de las ventajas más destacadas son propuestas a continuación:
o Flexibilidad; los usuarios pueden crear una plataforma adaptada perfectamente a
sus requisitos.
o Adaptabilidad; en caso de que las necesidades cambien, el desarrollador puede
modificar las funcionalidades.
o Seguridad; proveen varias políticas de seguridad, incluyendo protección de datos y
la realización y recuperación de copias de seguridad.
o No necesidad de inversión en una infraestructura física; el cliente se ahorra gastos
de hardware y tiempo en la configuración del mismo.
o Da la oportunidad de desarrollar aplicaciones a usuarios con pocA experiencia en
este ámbito; algunas de las propuestas PaaS ofrecen un servicio por pasos a través
de una sencilla interfaz.
Existen multitud de empresas que proveen estos servicios. Algunas de las más exitosas
son: Heroku, Windows Azure, Amazon AWS, Google App Engine, etc. Cada una se amolda
a un tipo de modelo y de forma de trabajo. Por lo tanto, sopesando las características de
cada una y analizando las necesidades del proyecto a desarrollar se decidió usar Google
App Engine.
5.1.1.2.1 Google App Engine.
Esta propuesta de servicio PaaS es idónea para los intereses que nos atañen. Las
principales características que aporta y que coinciden con los requisitos que necesita
nuestro modelo son las siguientes:
60
o Soporte de varios lenguajes de programación. Entre ellos, Java, que es el que se va
a utilizar en el proyecto.
o Servicio de almacenamiento de datos; en este ámbito Google ofrece a los usuarios
dos posibles opciones. Una de ellas consiste en un servicio de Datastore y la
segunda opción que propone es un servicio de base de datos relacional basada en
MySQL. La segunda opción es la más apropiada para las necesidades del proyecto a
realizar.
o Gestor de aplicaciones; mediante la administración de una cuenta de Google, se
permite al usuario administrar los permisos y el control de acceso de la aplicación.
Pudiendo añadir colaboradores o supervisores al proyecto.
5.1.2. Definición de requisitos del sistema
En este apartado se expondrán y describirán los requisitos, tanto funcionales como no
funcionales, del sistema. Esta lista de funcionalidades corresponde a la idea inicial de la
aplicación, ya que posteriormente, a medida que se iba analizando el estado del arte y
cogiendo nuevas ideas, se iban introduciendo pequeñas modificaciones que favorecieran la
calidad final del proyecto.
5.1.2.1 Requisitos funcionales
Un requisito funcional define una función que el sistema debe realizar. A continuación
se realizará una breve descripción de cada requisito funcional, acompañado de su
correspondiente escenificación en forma de caso de uso.
Selección de regla o hecho; en la visión inicial de la interfaz se proporciona al
usuario una lista completa tanto de hechos como de reglas disponibles en la base
de conocimiento. Cada uno es seleccionable por el usuario, para que
posteriormente ejecute una acción sobre este elemento. En la siguiente figura se
muestra el caso de uso correspondiente a este requisito.
61
Figura 5.6 – Caso de uso de selección de hecho/regla
Eliminar/editar un hecho o una regla; una vez seleccionado uno de estos
elementos se le da la oportunidad al usuario de realizar una de estas acciones. En
la siguiente figura se muestra el caso de uso correspondiente a este requisito.
Figura 5.7 – Caso de uso de eliminar/editar elemento seleccionado
Puesto que la información correspondiente a los hechos y las reglas se
encuentra almacenada en la base de datos, en este escenario es necesaria la
escenificación de otro caso de uso, el cual representa la actualización de la base
de datos en consecuencia de la acción ejecutada por el usuario.
62
Figura 5.8 – Caso de uso de eliminar/editar elemento
Creación de nuevos hechos y reglas mediante lenguaje Blockly; la herramienta
tiene que proporcionar la funcionalidad de construir nuevas reglas o hechos
mediante la unión de bloques de tipo Blockly. Finalizada la edición se salvará la
información en la base de datos. A continuación se presenta una figura
representativa de este caso de uso.
Figura 5.9 – Caso de uso de crear nuevo hecho o regla
Al igual que el caso anterior se realizarán modificaciones en la base de datos,
por lo que es necesario la inclusión de un caso de uso adicional, y que se
presenta en la siguiente figura.
63
Figura 5.10 – Caso de uso de crear elemento
Compilar red RETE; el usuario tendrá la opción de compilar de nuevo la red. Al
insertar nuevas reglas esta acción es necesaria. En la siguiente figura se puede
observar el caso de uso correspondiente a esta acción.
Figura 5.11 – Caso de uso de compilar red RETE
En este escenario de uso también es necesario el acceso a la base de datos para
salvar la información correspondiente a la nueva versión de la red RETE. Como
se puede apreciar en la siguiente figura mediante un caso de uso.
64
Figura 5.12 – Caso de uso de actualizar compilación de red RETE
Actualizar red RETE; una vez que se ha terminado la edición de la base de
conocimiento, el usuario podrá actualizar la información correspondiente en la
red. En la siguiente figura se muestra el caso de uso correspondiente.
Figura 5.13 – Caso de uso de actualizar red RETE
Una vez más, es necesario salvar la información procesada y por lo tanto
actualizar los datos en la base de datos. Por lo que es necesario proponer el caso
de uso mostrado en la siguiente figura.
Figura 5.14 – Caso de uso de actualizar RETE
65
Seleccionar una versión de la red RETE; en la parte de la interfaz correspondiente
al visionado del grafo de la red, se propone una lista de las versiones
seleccionables. Cada una de la versiones corresponderán a un estado de la red
RETE, ya sean anteriores o el actual. En la siguiente figura se representa el caso
de uso de esta acción.
Figura 5.15 – Caso de uso de seleccionar versión de la red RETE
Una vez seleccionada la versión de la red que se desea visualizar, el sistema
cliente solicitará la información necesaria para mostrar el grafo correspondiente.
El sistema servidor actuará de intermediario entre el sistema gestor de base de
datos (el encargado de almacenar la información) y el sistema cliente. A
continuación se muestra, en la figura, el caso de uso correspondiente a la situación
descrita.
Figura 5.16 – Caso de uso de obtener grafo
66
5.1.2.2 Requisitos no funcionales
Un requisito no funcional especifica un criterio que puede ser usado para juzgar la
operación de un sistema, es decir, no definen un comportamiento del sistema. En las
siguientes líneas se realizará una descripción de los requisitos no funcionales que debe
cumplir la aplicación.
Interfaz gráfica usable; la interfaz gráfica debe ser intuitiva y perfectamente
manejable sin la necesidad de invertir un esfuerzo abultado en la comprensión de
su funcionamiento.
El sistema seguirá el modelo cliente-servidor, utilizando los lenguajes de
programación adecuados en cada lado de la arquitectura. Java en caso del
servidor y JavaScript y HTML en el caso del cliente.
El sistema dispondrá de una base de datos para almacenar, tanto la información
correspondiente a la red RETE, como los datos que están relacionados con otros
aspectos del sistema.
5.2 SPRINT 2
En esta fase del desarrollo, en primer lugar, se realizó un análisis de las herramientas
que se podían utilizar para satisfacer los requisitos propuestos. Como resultado se obtuvo
la lista de elementos que se propuso anteriormente en el apartado “herramientas
tecnológicas”, con excepción de alguno de ellos, que se añadió posteriormente.
Una de las tecnologías seleccionadas en este punto se erige como la base de la interfaz
gráfica de la herramienta. Estamos hablando del lenguaje de programación visual Blockly.
Damos tal importancia a este elemento porque gracias a él, editar o cumplimentar los
distintos parámetros que son característicos de la definición de una regla o un hecho, se
convierte en una tarea amena e intuitiva. Los beneficios de estos factores que se nombran
fueron probados personalmente por el desarrollador del proyecto. Era necesario ponerse en
la piel del usuario para poder entender en qué medida esta herramienta podía ser intuitiva,
para más tarde, proponer un uso adecuado y explotando al máximo sus características
innovadoras. Para ello el desarrollador completó varios tutoriales en los cuales se realizaba
un aprendizaje a fondo del uso de esta herramienta y se mostraban todos los elementos de
los que ésta dispone.
67
A parte de lo comentado anteriormente, también se tuvo que realizar un estudio a fondo
del algoritmo RETE. Se consultaron varios textos recomendados por el cliente (en este
caso el director del proyecto) y otros textos de interés encontrados por el desarrollador.
Esta información fue complementada por varios ejemplos propuestos por el director y otros
realizados por el autor del proyecto.
5.2.1 Funcionamiento del algoritmo RETE
En anteriores capítulos se han detallado las principales características y componentes
por los que se caracteriza este algoritmo, pero no se ha expuesto la forma de trabajo que se
utiliza.
En primer lugar hay que recordar que existe una base de reglas, la cual contiene cada
una de las reglas definidas en el sistema, así como una base de hechos, que contiene todos
los hechos disponibles. Al compuesto de estos dos conjuntos se llama base de
conocimiento. Una vez que se posee toda la información que debe albergar la red se
procede a construir la red RETE.
Como ya se ha dicho en capítulos anteriores la red está representada con un grafo
acíclico dirigido y que en ella constan de tres tipos de nodos: alfas, betas y gammas. Cada
uno de ellos se distingue por tener unas características y unas funciones distintas.
Alfas; este tipo de nodo representa a cada uno de los antecedentes y consecuentes
de una regla. Cada nodo tiene asociada una memoria con los datos de los hechos
individuales que le corresponden. En el caso de este proyecto cada uno de ellos
está representado por una tabla en una base de datos y los hechos como entrada de
dicha tabla.
Betas; en este caso, este tipo representa el resultado de la comparación de dos
nodos alfa, un alfa y un beta o dos betas. Coteja información obtenida en nodos
anteriores y almacena los resultados. En una base de datos relacional esta acción
se asocia con la operación join. En caso de que se necesite realizar la misma
comparación más de una vez se utilizan los resultados ya obtenidos en la primera
ocasión, es decir, no se vuelve a realizar la operación.
Gammas; este nodo representa el resultado final de una regla.
68
5.2.1.1 Operación join
En el apartado anterior se ha mencionado un tipo de operación relacionada con bases
de datos relacionales y no se ha explicado en ningún momento como procede en su
funcionamiento. Esta operación se denomina en dicho ámbito, join, y permite combinar
registros de dos o más tablas de la base de datos propuesta. En lenguaje SQL existen
diferentes tipos de join, como pueden ser, interno, externo, cruzado, entre otros.
En el tema que nos concierne se va a utilizar el de tipo interno, porque es el que mejor
se adapta a las necesidades requeridas. Este tipo combina los registros de dos o más tablas
siempre que haya concordancia de valores en un campo en común.
Para realizar una explicación más detallada se propone un breve ejemplo de esta
operación. Para ello se presentan las dos tablas siguientes:
Tabla 5.1 – Ejemplo de join tabla 1 Tabla 5.2 – Ejemplo de join tabla 2
Si se realiza una operación join sobre estas tablas cogiendo “ID” como campo en
común, la tabla resultante es la siguiente:
Tabla 5.3 – Ejemplo de join tabla resultado
ID nombre
1 Juan
2 Marta
3 Isabel
4 Alejandro
ID
2
4
8
9
ID nombre
2 Marta
4 Alejandro
69
Como se observa, se ha realizado una comparación de todos los registros del campo
“ID” que poseen las dos tablas, mostrando como resultado únicamente los datos que
coinciden.
5.2.1.2 Procedimiento de construcción de la red
Una vez explicadas las principales características y elementos de esta metodología, se
va a proceder a exponer la forma con la que se procede a construir la red. Para ello se va a
proponer un ejemplo, que sirva como ayuda para la comprensión de la explicación.
En primer lugar definimos una regla ejemplo para observar la forma de su
construcción.
Si Y es el autor de X
Y es escritor de ciencia ficción
X es un libro
Entonces X es un libro de ciencia ficción
Y en segundo lugar proponemos una serie de hechos.
Stephenson es el autor de La era del diamante
Gibson es el autor de Neuromante
Stephenson es escritor de ciencia ficción
Neuromante es un libro
La edad del diamante es un libro
Dick es el autor de Laberinto de muerte
Gibson es escritor de ciencia ficción
Dick es escritor de ciencia ficción
El jugador es un libro
Ubik es un libro
70
Laberinto de muerte es un libro
Banks es el autor de El jugador
Como se puede observar en el ejemplo de regla propuesto, dicha regla posee tres
antecedentes y un consecuente, por lo tanto cada uno de ellos va a estar representado por
un nodo alfa. Y a su vez cada alfa va a tener asociados, en su memoria alfa, sus hechos
correspondientes. En la siguiente figura están representados los nodos alfa y en las
posteriores tablas los hechos que se le atribuyen a cada uno.
Figura 5.17 – Nodos alfa del ejemplo propuesto
es el autor de
X Y
La edad del
diamante
Stephenson
Neuromante Gibson
Laberinto
de muerte
Dick
El jugador Banks
Tabla 5.4 – Ejemplo RETE “es el autor de” Tabla 5.5 – Ejemplo RETE “es un libro”
es un libro
X
Neuromante
La edad del diamante
El jugador
Ubik
Laberito de muerte
71
Tabla 5.6 – Ejemplo RETE “es escritor de ciencia ficción”
Una vez creados los nodos alfa se procede a la creación de los nodos beta y sus
relaciones con los nodos alfa. Se empieza relacionando el primer antecedente con el
segundo, y se obtiene un nodo beta, el cual va a contener el resultado obtenido de
comparar los hechos de los dos nodos alfas.
Figura 5.18 – Generación del primer nodo beta
En la siguiente tabla se muestran los resultados correspondientes a la operación join de los
dos nodos alfa.
es escritor de ciencia
ficción
Y
Stephenson
Gibson
Dick
72
Tabla 5.7 – Ejemplo RETE “es el autor de & es escritor de ciencia ficción”
Una vez realizadas estas acciones se procede a realizar exactamente la misma
operación, esta vez, involucrando al nodo beta obtenido y el nodo alfa correspondiente al
antecedente de la regla que queda sin relacionar. Gráficamente resultará de la siguiente
manera.
Figura 5.19 – Generación del segundo nodo beta
es el autor de
&
es escritor de ciencia
ficción
X Y
La edad del
diamante
Stephenson
Neuromante Gibson
Laberinto
de muerte
Dick
73
Como consecuencia de la acción llevada a cabo, se obtiene un nuevo nodo beta con
los resultados que se muestran en la siguiente tabla.
Tabla 5.8 – Ejemplo RETE “es el autor”
Una vez hecho esto, se recuerda que la regla propuesta como ejemplo tenía tres
antecedentes, por lo tanto esa regla está satisfecha y puede ser disparada. Esto significa que
el último nodo beta obtenido es el antecedente de un nodo terminal, que representará los
resultados finales obtenidos. A su vez, el nodo alfa que en principio correspondía al
consecuente ahora pasará a ser un nodo gamma. Esta terna de acciones se pueden observar
visualmente en la siguiente figura.
Figura 5.20 – Red resultante de la regla propuesta
es el autor de & es escritor de ciencia ficción & es un libro
X Y
La edad del diamante Stephenson
Neuromante Gibson
Laberinto de muerte Dick
74
El nodo gamma resultante va a poseer los datos, del nodo beta predecesor, que sean
relevantes en su definición. Es decir, en el nodo terminal existirán solamente las columnas
necesarias por su composición. En el ejemplo propuesto se observa que el consecuente sólo
posee una variable, y el nodo beta del que procede está definido por dos variables, por
tanto únicamente se usará el campo que coincide.
Dado el caso que existieran más reglas, la operatoria sería exactamente la misma,
pero teniendo en cuenta que en caso de que existan comparaciones de nodos ya realizadas
anteriormente, los resultados de estas comparaciones se compartirán, excluyendo así
redundancia de datos.
5.3 SPRINT 3
En esta etapa del desarrollo se inició la implementación de algunos de los elementos
principales del sistema, como son la interfaz, la arquitectura cliente-servidor y bloques
Blockly. A parte de estos elementos de implementación, también de diseño el modelo de
base de datos que posteriormente se utilizaría para albergar, tanto toda la red RETE, como
otros datos relevantes del sistema.
En los siguientes apartados se procede a dar una descripción más a fondo de los
desarrollos llevados a cabo en esta fase. En caso de la arquitectura cliente-servidor no es
necesario, ya que en la explicación del Sprint 1 ya se entró en detalle en este tema.
5.3.1 Desarrollo inicial de la interfaz
Como se proponía en apartados anteriores, la interfaz debe estar compuesta por
elementos fácilmente reconocibles por el usuario, de uso intuitivo. Los artefactos
principales que se proporcionan para la navegación dentro de la web y sus diferentes
opciones, son elementos que aparecen frecuentemente en la mayoría de portales webs
existentes en la actualidad, como son pestañas, botones desplegables, listas seleccionables,
botones, etc. Se pretendía esta sencillez en la navegación debido a que la interfaz Blockly
es un elemento que no se usa habitualmente y que, a pesar de ser altamente intuitivo, el
usuario puede experimentar pequeñas dudas en su funcionamiento, por lo tanto no se
quería arriesgar en la introducción de elementos confusos en otros ámbitos.
75
Se creó un primer boceto de la interfaz para permitir al cliente dar sus primeras
impresiones, y así poder ofrecer otro punto de vista y poder incluir algunas mejoras y/o
adaptaciones. Aun así, no fue necesario hacer grandes cambios, ya que tanto el
desarrollador, como el cliente estuvieron de acuerdo. Por lo que los bocetos iniciales distan
muy poco de la versión final.
En primer lugar se va a mostrar el boceto del diseño original en la figura que continúa
este texto y posteriormente explicarán brevemente los elementos que contiene.
Figura 5.21 – Boceto de la interfaz en pestaña de gestión
Como se observa la interfaz es muy sencilla. Se basa en un contenedor con tres
pestañas, cada una de las cuales ejerce una función dentro de las tres principales premisas
del proyecto, gestión, edición y visualización. En esta primera imagen se muestran los
elementos pertenecientes a la primera pestaña, la de gestión de la base de conocimiento.
Ésta contiene dos lista de elementos seleccionables, una de hechos y otra de reglas. Cada
uno de estos componentes es seleccionable por el usuario, y una vez indicada la selección
se da la opción de eliminar o editar el elemento, gracias al botón desplegable existente en
la esquina superior derecha de cada contenedor. En caso de seleccionar la edición,
automáticamente se redirigirá al usuario a la pestaña de edición.
En la siguiente imagen se muestra el boceto de la segunda pestaña, la de edición.
76
Figura 5.22 – Boceto de la interfaz en pestaña de edición
En el caso de la segunda pestaña, está basada principalmente en la interfaz de Blockly.
En el centro se encuentra el contenedor que albergará íntegramente la edición de bloques, y
a la izquierda se localiza un panel navegable que contiene las categorías de bloques que se
proponen, y dentro de cada categoría los distintos tipos de bloques asociados a cada una
ellas. A la derecha se sitúan dos botones, guardar y actualizar; los cuales sirven,
respectivamente, para salvar los cambios, tanto de hechos como de reglas, y para
actualizar la red rete e caso de que se hayan introducido nuevos datos.
La pestaña restante pertenece a la función de visualización de la red en forma de
grafo. En la siguiente figura se puede contemplar el boceto de esta parte de la interfaz.
77
Figura 5.23 – Boceto de la interfaz en pestaña de visualización
Se puede ver que el elemento principal de esta pestaña va a ser un contenedor, que
será el encargado de mostrar el grafo resultante de la red RETE. Para facilitar al usuario la
comparación de la situación actual del grafo con otras versiones, se propuso dotar de una
lista de estados anteriores de la red. Cada una de estas versiones se muestran en la parte
izquierda en forma de lista con elementos seleccionables.
Una vez terminado el diseño de la interfaz se procedió a implementar los principales
elementos para poder avanzar en otros aspectos del desarrollo. En primera instancia se
desarrolló la primera pestaña con sus correspondientes contenedores y botones, dejando
preparadas las otras dos pestañas restantes para añadir posteriormente sus elementos.
5.3.2 Creación bloques Blockly
La API de este lenguaje gráfico incluye numerosos bloques predeterminados que se
incluyen en la implementación de esta herramienta, como pueden ser bloques de
operaciones lógicas, operaciones matemáticas, bucles, funciones, etc. Pero para las
funcionalidades que esta herramienta se iba a usar en el presente trabajo, no existían los
bloques necesarios. Por tanto fue necesario nuevos bloques que se adecuaran a las
necesidades que se requerían.
78
Google provee una herramienta web, llamada Block Factory, que permite crear
nuevos bloques dinámicamente. En ella también se usa el lenguaje Blockly para definir
todas las características y elementos que formarán el nuevo bloque. El diseño de los
bloques es dinámico gracias a que, a medida que se va realizando la definición, la web va
proporcionando a su vez el código javascript que define el bloque.
Figura 5.24 – Interfaz de Block Factory
El código resultante en la generación es incluido en el archivo javascript
correspondiente dentro de la API proporcionada para que, al inyectar Blockly en la interfaz,
estos nuevos bloques sean accesibles.
5.3.3 Implementación mediante base de datos relacionales
Para la implementación de la red RETE se va a utilizar un modelo de trabajo basado
en bases de datos relacionales. De este modo, cada uno de los elementos que hemos
descrito anteriormente existentes en la red va a estar relacionado con un elemento
característico de la las bases de datos, como pueden ser: tablas, columnas, filas, etc.
79
Figura 5.25 – Fisionomía del grafo representativo de la red
Cada nodo alfa va a ser representado con una tabla con tantas columnas como variables
contenga el antecedente que ésta va a representar, y cada fila de dichas tablas
corresponderá a un hecho. Al mismo tiempo, va a existir una tabla llamada “alfas”, y que
constará de tres columnas:
o idAlfa: este campo contendrá un identificador del nodo.
o alfaSelect: columna en la cual se proporcionará la sentencia select
correspondiente al nodo alfa correspodiente.
o idTabla: contendrá el identificador correspondiente a la tabla propia del
nodo alfa.
o cambiado: el propósito de esta columna es proporcionar la información
necesaria para saber si este nodo ha sido modificado en el último ciclo de
inferencia, o bien es un nodo nuevo.
Figura 5.26 – Descripción de la tabla “Alfas”
80
Cada uno de los nodos beta también estará representado en este modelo por una tabla.
Esta tabla será la resultante de aplicar una sentencia join entre dos tablas antecesoras, ya
sea dos de tipo alfa, una de tipo alfa y otra de beta o las dos de tipo beta. Al igual que en el
caso de los nodos alfa, también va a existir una tabla llamada “betas”, la cual estará
compuesta por seis columnas:
o idBeta: campo que representará el identificador del nodo.
o nivel: este campo indica el nivel al que pertenece el nodo. Más adelante se
explicará la finalidad de este dato.
o padre_1: este campo contendrá el identificador correspondiente a uno de sus
dos nodos antecesores.
o padre_2: al igual que el anterior contendrá un identificador, pero en este
caso corresponderá al otro beta que falta para completar la dupla de
antecesores.
o sqlJoin: esta columna está destinada a almacenar la sentencia join
correspondiente, cuyo resultado da lugar a este nodo.
o idtabla: al igual que en el caso de la tabla “alfas”, este campo contendrá un
identificador que corresponderá a la tabla correspondiente a este nodo.
Figura 5.27 – Descripción de la tabla “Betas”
Asímismo, las reglas también tendrán su correspondiente tabla representativa en este
modelo propuesto. En este caso con sólo una tabla será suficiente para almacenar los datos
necesarios. Dicha tabla estará compuesta por cuatro columnas:
o id_reglas: esta columna tiene el propósito de almacenar la nomenclatura con
la cual se va a identificar cada regla de cara al usuario.
81
o LHS: en este campo se va a almacenar la parte izquierda de la regla, es
decir, la parte en la que se encuentran los antecedentes.
o RHS: éste tendrá un fin similar al anterior, pero en este caso se almacenará
la parte derecha de la regla, también llamado consecuente.
o xml: este campo no tiene relación con el modelo de datos ya que
únicamente contiene el código XML que representa a la regla, y que es
utilizado posteriormente por el cliente para mostrarlo en forma de bloques
Blockly. Ésto se explicará posteriormente con más determinación en el
presente documento.
Figura 5.28 – Descripción de la tabla “Reglas”
A su vez, tanto los predicados como los hechos también tendrán una tabla
representativa. Ambos contarán con dos columnas. En el caso de los predicados son las
siguientes:
o idpredicado: este campo es un identificador numérico y único para cada
predicado. Es incremental, no se sigue ningún patrón ni restricción para la
asignación del mismo.
o nombre: esta columna contiene el nombre que el mismo usuario ha dado a
este predicado.
Figura 5.29 – Descripción de la tabla “Predicados”
82
Por otra parte, la tabla de hechos también estará compuesta por dos columnas:
o id_hechos: en dicha columna se almacenará el identificador alfanumérico
por el cual el usuario reconocerá cada hecho en la interfaz de usuario.
o xml: almacena el código correspondiente a la representación gráfica del
hecho en bloques Blockly. Al igual que sucedía en la tabla de las reglas, este
campo únicamente tiene relación con el modelo que se ha elegido para la
edición de los datos del sistema.
Figura 5.30 – Descripción de la tabla “Hechos”
Bajo un pensamiento orientado a base de datos relacionales cabe pensar que entre estas
dos tablas puede haber una relación, y de hecho la hay, pero no se ha creído necesario
incluirla debido a que, como se ha explicado anteiormente, cada predicado va a estar
representado por una tabla exclusiva para el mismo. Cada hecho va a estar incluido en la
tabla de su correspondiente predicado, por lo tanto la relación que anteriormente se
nombraba ya se encuentra explícita en este hecho y no es necesrio incluirla como tal.
Como ya se ha mencionado varias veces, cada nodo alfa va a estar representado por
una tabla. La nomenclatura que van a seguir cada una de éstas es la siguiente; en cuanto al
nombre de la tabla, va a ser el nombre del predicado al cual se asocia el nodo alfa, y que a
su vez es el que el usuario le ha proporcionado en su creación. En el caso de que dicho
nombre proporcionado contenga espacios, se suprimirán por evitar posibles errores en la
creación de las tablas. En lo que concierne a las columnas, poseerán tantas como variables
se le haya proporcionado al predicado a la hora de su creación. Cada fila de esta tabla
representará un hecho.
Al igual que en el caso de los alfas, cada nodo beta también está representado en forma
de tabla, como ya se habló anteriormente. En este caso, la nomenclatura que se sigue a la
hora de dar un nombre a las tablas es distinta, ya que dicha tabla será el resultado de
realizar una operación join entre dos nodos, ya sean alfa o beta. Dicho esto, el nombre será
la concatenación de los nombres de las tablas predecesoras, utilizando como separador
entre cadenas el carácter “$”. Se ha utlizado este símbolo porque otros, que a priori podrían
83
ser más representativos de su fin que éste, eran caracteres reservados del lenguaje utilizado
para la creación de las tablas, SQL en este caso. En lo que se refiere a las columnas, como
es lógico, en la tabla va a haber un número de columnas igual al de la tabla incluida dentro
del join con mayor número de columnas.
5.4 SPRINT 4
Con la base de la interfaz ya creada, se procedió a analizar el procedimiento que se
debía seguir para inyectar Blockly en la herramienta. El propio desarrollador de dicha
herramienta facilita en gran medida esta tarea, dado que ofrece varios mecanismos de
inyección con HTML. Para seleccionar uno de los nombrados mecanismos se realizaron
una serie de pruebas de funcionamiento para decidir qué funcionalidades y características
de cada uno de ellos se asemejaba a los requisitos que el proyecto necesitaba. Además, en
esta fase también se llevó a cabo el correcto acoplamiento de los bloques creados en la
etapa anterior.
Una vez ensamblado Blockly a la interfaz, era necesario encontrar la forma de salvar
bloques en la base de datos, así como recuperarlos de la misma. Este problema se resolvió
gracias a una función, que proporciona la API de la herramienta, la cual permite exportar
toda la construcción de los bloques a código XML. Este hecho facilita mucho las cosas
debido a la universalidad por la que se caracteriza este lenguaje. El código XML resultante
se almacena en la base de datos junto con otros datos de cada hecho y cada regla. Por lo
tanto a la hora de recuperar los bloques guardados anteriormente, únicamente hay que
recuperar el código de la base de datos y volver a inyectar el código en la interfaz Blockly.
Otra de las acciones más relevantes llevadas a cabo en esta fase del desarrollo fue
realizar la implementación de una fase inicial del algoritmo RETE. Este primer ciclo de
implementación del algoritmo se utilizó, además, como ejercicio de aprendizaje para el
desarrollador, ya que se captan desde otros puntos de vista algunos de los procedimientos
de construcción de la red. En este ciclo, únicamente se dieron los primeros pasos de
construcción de la red, como son la creación de los nodos alfa o la construcción de los
primeros nodos beta.
Se llevaron a cabo numerosos análisis sobre cómo realizar las diferentes operaciones
que se deben realizar en el funcionamiento del algoritmo. Con esto se refiere al hecho que,
84
cada acción que se desea realizar (creación de nodos, comparación de nodos, etc.), cada
dato que se desea obtener (información en general de la red) hay que plasmarlo u obtenerlo
de la base de datos, por lo tanto es necesario hacer especial hincapié en que estas acciones
se lleven a cabo de un modo eficiente.
5.5 SPRINT 5
Esta etapa es la última del desarrollo, en ella se finalizaron aquellos módulos del
proyecto que permanecían inacabados, especialmente la interfaz y la implementación del
algoritmo RETE. Una vez terminadas estas tareas, se precedió a analizar las diferentes
herramientas que se podían utilizar para el módulo gráfico del proyecto, para
posteriormente elegir la que mejor se ajustara a las necesidades y en último término
ensamblarla con el trabajo que ya estaba realizado.
5.5.1 Implementación completa del algoritmo RETE
En el sprint anterior se comentaba que se había realizado un primer desarrollo de este
módulo y que se había analizado el modus operandi de ciertas operaciones importantes que
se tenían que llevar a cabo en este ámbito. Por lo tanto en esta última etapa del desarrollo
había que finiquitar la implementación del algoritmo. Esta implementación se divide en
dos grandes partes, cada una de las cuales llevará a cabo una función final determinada,
construcción de la red (compilación) y actualización.
En la siguiente figura se muestra la representación gráfica en UML de la clase “Rete”,
que es la encargada de realizar estas acciones.
85
Figura 5.31 – Clase “Rete”
5.5.1.1 Construcción de la red
En esta parte de la implementación se plasmó en código toda la información y el
funcionamiento expuesto en el apartado “Procedimiento de construcción de la red”. Ya
involucrados en el desarrollo se apreciaron algunos detalles que sobre el plano teórico no
surgieron y que hubo que tomar algunas decisiones destacables. Una de estas
determinaciones fue dotar a los nodos de un orden parcial que se basaba en un
identificador único. Esta medida se tomó por la razón de que a la hora de actualizar la red
es necesario priorizar unos nodos frente a otros, es decir, los nodos que se encuentran más
arriba en la jerarquía dentro de la red es necesario que se actualicen antes que los de menos
rango. Por lo tanto el id de los nodos y el respectivo nivel al que pertenecen se obtendrán
siguiendo las siguientes premisas:
86
ID (nodo ∈ nivel(k)) < ID’ (nodo ∈ nivel(k’)) si nivel(k) < nivel(k’) ∧
ID (nodo ∈ nivel(k)) > ID’ (nodo ∈ nivel(k’)) si nivel(k) > nivel(k’)
De manera que el nivel de los nodos quedará establecido de le siguiente manera:
o Nivel 0: constituido por nodos alfa.
o Nivel 1: nodos beta con padres alfa.
o Nivel 2: a este nivel pertenecerán nodos beta con un padre de nivel 1 y otro
con nivel menor o igual a 1.
o Nivel n: pertenecerán al nivel n los nodos beta con un padre de nivel (n-1) y
otro de nivel menor o igual que (n-1).
A continuación se muestra un listado de código, que permite el cálculo del nivel de
cada nodo.
if(nivel1==0 && nivel2==0) result=1;
else {
if(nivel1>=nivel2){
mayor=nivel1;
menor=nivel2;
}
else {
mayor=nivel2;
menor=nivel1;
}
while(seguir){
if((mayor == cont-1) && menor <=cont-1){
result=cont;
seguir=false;
}else cont++;
}
}
Una vez resuelto este hecho se procedió a continuar la implementación de la
construcción de la red, como se describía en las primeras líneas de este apartado, siguiendo
las pautas ya descritas en apartados anteriores. Este procedimiento fue temporalmente
costoso debido a la ardua tarea de plasmar toda la información en la base de datos, así
como obtener la mayoría de datos de la misma.
5.5.1.2 Actualización de la red
Se llama actualización de la red al proceso por el cual la información añadida o
eliminada se propaga a todos los nodos de una manera que respete los principios del
87
algoritmo RETE. Una de las premisas que se debe cumplir al realizar esta operación es la
actualización únicamente de los nodos que hayan sido cambiados en un ciclo de inferencia
o directamente por una edición de la base de conocimiento.
En esta parte es dónde adquiere sentido lo explicado en el apartado anterior, referido
al orden parcial que se ha dotado a los nodos y a los niveles que pertenece cada uno. Como
se ha mencionado en la explicación anterior, es necesario que los nodos que poseen un
nivel de jerarquía mayor sean actualizados antes que los que se encuentran a más bajo
nivel. Por lo tanto, dado que se ha dotado a los nodos de un identificador que sigue un
orden parcial dentro de estos niveles, se puede utilizar una estructura llamada cola de
prioridad, que es idónea para este fin. Consiste en una estructura de elementos ordenada,
en la cual el orden se determina por el valor de sus elementos. Previsiblemente, en el caso
que nos ocupa dicho valor será el identificador del nodo.
Una vez dados los detalles previos a la explicación se va a proceder a la exposición de
la misma. Para favorecer la comprensión del algoritmo se facilita un pseudocódigo de la
mecánica que se sigue:
lista_acualizar: lista de los nodos que se han de actualizar
lista_actualizar sucesores nodos alfa cambiados
cambiado de nodo alfa falso
MIENTRAS lista_actualizar no vacía
nodo sacar nodo de lista_actualizar
actualizar(nodo)
FIN-MIENTRAS
La primera acción que se realiza es obtener una lista de los nodos alfa que han sido
modificados, para inmediatamente después obtener los sucesores de cada uno de ellos.
Pero no únicamente los sucesores directos, se obtienen todos los sucesores en la red. Esta
acción se lleva a cabo de esta manera porque es necesario que la cola de prioridad contenga
desde este momento todos los nodos que se deben actualizar. Si no fuera así los nodos se
actualizarían en varias ocasiones, saltándose una de las principales premisas del algoritmo
RETE. A continuación, es necesario actualizar la propiedad “cambiado” cada no alfa, se
88
cambia a “falso”. En el siguiente paso se entra en un bucle “while”, que perdurará hasta
que la lista de actualización esté vacía. Mientras tanto, en cada iteración del bucle se sacará
el primer elemento de la lista (el de ID más bajo) y se procederá a su actualización. Con a
finalización de este bucle termina el proceso de actualización de la red.
5.5.2 Desarrollo final de la interfaz
Hasta este momento sólo se había desarrollado una parte de la interfaz, que incluían
gran parte de los elementos de las dos primeras pestañas. En esta fase se completó el
desarrollo, no sólo añadiendo los elementos que faltaban, también depurando otros
aspectos de funcionamiento que ocasionaban fallos y mejorando diversos aspectos de
funcionalidad. Una de las cosas que se mejoró fue la actualización simultánea de datos. En
la primera versión del desarrollo era necesario recargar la página para que los cambios
realizados en la base de conocimiento fueran visibles en la interfaz, por lo que se creyó de
gran ayuda para el usuario realizar la mejora mencionada.
Respecto al diseño inicial, se añadió un botón en la pestaña de gestión de la base de
conocimiento, que permitía al usuario indicar al sistema la compilación de la red RETE
después de una actualización de la base de conocimiento. El significado del término
“compilar” en este ámbito indica que dada la actualización de información en la red,
especialmente si se ha modificado la base de reglas, es necesario realizar una
“reconstrucción” de la red.
En esta fase también se implementó la parte correspondiente al módulo gráfico, pero
hubo un pequeño paréntesis dedicado al análisis de las herramientas necesarias para este
fin. En los próximos apartados se explicará más a fondo las decisiones tomadas sobre este
tema.
5.5.2.1 Resultado de la interfaz
En este apartado únicamente se va exponer el resultado final de la interfaz. Las
cualidades y elementos principales de la interfaz se describieron en apartados anteriores,
por lo tato en el presente no se detalla nada de estos aspectos.
89
En la siguiente figura se muestra el aspecto final de la pestaña dedicada a la gestión de
la base de conocimiento.
Figura 5.32 – Parte de la interfaz correspondiente a la pestaña de gestión.
El resultado final de la pestaña de edición es mostrado en la siguiente figura.
Figura 5.33 – Parte de la interfaz correspondiente a la pestaña de edición.
La pestaña que resta, que corresponde a la función de visualización, se muestra a
continuación.
90
Figura 5.34 – Parte de la interfaz correspondiente a la pestaña de visualización.
5.5.3 Análisis de las herramientas relacionadas con el módulo gráfico
Una vez desarrollado y conocido el funcionamiento del sistema, se llevó acabo un
barrido de información para conocer qué herramientas existían relacionadas con la
representación de grafos en HTML y cuál de ellas proporcionaba las características que se
adecuaban a las necesidades del sistema. A continuación se describen las herramientas
analizadas en esta fase:
o Librería “vis.js”9; consiste en una librería en Javascript que permite la
visualización de gráficos, orientada a navegadores web y que ha sido diseñada
para facilitar al máximo su utilización. Es capaz de gestionar grandes
cantidades de datos dinámicamente, y además ofrece al usuario la posibilidad
de interactuar con dichos datos.
o Graphviz10; es un software de código abierto orientado a la visualización de
grafos. Por el simple de hecho de ser una herramienta software en sí, y no una
librería como en el caso anterior, indica que no está totalmente dirigido a
navegadores web. Este dato es relevante en lo que se refiere a los intereses
para las necesidades que se requieren, ya que se necesita un elemento que se
amolde lo mejor posible al trabajo ya realizado. Aun así, gracias a la gran
9 http://visjs.org/ 10 http://www.graphviz.org/
91
relevancia que posee esta herramienta en este ámbito, existen numerosas
formas de aprovechar sus funcionalidades. Existen gran variedad de
herramientas derivadas de este software que aprovechan la gran polivalencia
de este software.
o Google Charts11; es una aplicación de google de licencia gratuita, que se
utiliza para realizar gran variedad de gráficos, desde diagramas de dispersión
sencillos a árboles jerárquicos. Permite una amplia gama de customizaciones
en cuanto a diseño, y es perfectamente compatible con arquitecturas web.
Además, ofrece un modo de ejecución basado en Graphviz, característica que
hace de ésta una herramienta muy completa.
o Dot; permite describir gráficos en texto plano de una manera sencilla y
legibles por personas y computadoras a la vez. Este lenguaje es, usualmente,
el método de entrada, en el que se utilizan los datos a la hora de trabajar con
la herramienta Graphviz, la cual se ha citado anteriormente [BLT] [GNR].
Una vez expuestas las principales herramientas que se barajaron en su momento, se
va a proceder a exponer las decisiones tomadas y los motivos por los que éstas se llevaron
a cabo.
En cuanto a la primera herramienta expuesta, la librería “vis.js”, hay que destacar que
posee buena compatibilidad con las necesidades que se abordaban, pero en este caso el
grafo habría que haberlo construido en la parte el cliente dado que la construcción del
mismo se realiza con lenguaje Javascript. Esta restricción era significativa para nuestros
intereses por la razón de que toda la información de la red era accesible desde la parte del
servidor. Este hecho derivaría en un envío de gran cantidad de datos entre las dos partes de
la arquitectura, restando así eficiencia al sistema. Por lo tanto era importante que la
herramienta elegida permitiera la construcción en la parte del servidor.
En cuanto a las otras dos herramientas, se puede decir que ambas poseen
características y funcionalidades que son adecuadas a nuestros intereses, pero también hay
11 https://developers.google.com/chart/
92
otros aspectos que no concuerdan con los ideales marcados. Esto podría llegar a ser un
problema porque en condiciones normales estaríamos obligados a elegir entre una
herramienta u otra, pero en este caso tenemos la suerte de contar con una funcionalidad de
Google Charts que permite utilizar a su vez Graphviz.
La forma más común de utilizar Google Charts es con código JavaScript, pero como
ya se ha explicado anteriormente, este modo de trabajo no concuerda con las necesidades
del proyecto. Pero esta herramienta cuenta con una gran versatilidad, y da la oportunidad
de trabajar utilizando otros modelos. Dentro de la API de Google Charts existe una
función que permite usar este artefacto a través de URL, es decir, dada una URL con los
parámetros adecuados se obtiene como resultado un grafo con el formato y características
que se especifican en dichos parámetros. En las siguientes líneas se dará una explicación
detallada de la construcción del grafo.
La URL final que proporcionará el grafo es el resultado de la concatenación de una
URL base y de una serie de parámetros que darán el formato requerido. Existe un abanico
muy variado de parámetros que se pueden incluir. A continuación se exponen los que se
han utilizado:
o URL base: http://chart.apis.google.com/chart
o Parámetro “cht”; se refiere al tipo de gráfico que va a albergar. En el caso
presente será “cht=gv”. Las siglas “gv” pertenecen al tipo Graphviz.
o Parámetro “chs”; gracias a este parámetro se va a dar dimensiones a la imagen
resultante. El formato en el que se dan las medidas es “WxH”, siendo “W” el
ancho de la imagen y “H” el alto de la misma.
o Parámetro “chl”; en este parámetro es dónde va a ir incluido el texto que
describe el grafo RETE. Aparecerá escrito en lenguaje Dot.
Sintaxis Dot
En este lenguaje existen también numerosas posibilidades de especificación de
características, pero nos centraremos en las usadas en el proyecto [GNR] [BLT]:
o Comienzo de un bloque: dentro de este bloque se especificará el grafo.
digraph Rete{ }
93
o Indicar tamaño de la fuente de los nodos.
node [fontsize=10];
o Defininir un enlace entre nodos.
nodo1 -> nodo2
Asignar un mismo nivel a los nodos del mismo tipo para mantenerlos
alineados.
{rank=same; nodo1; nodo2}
Modificar características de los nodos: color y forma.
nodoAlfa [color=lightblue, shape=Mrecord]
nodoBeta [color=red, shape=Mrecord]
nodoGamma[color=yellow, shape=Mrecord]
Asignar información a los nodos: mediante esta característica se determinan
los datos que contendrá el nodo; el identificador, nombres de columnas y
entradasde las mismas.
nodo[label= “ ”]
5.5.4 Implantación del módulo gráfico
Una vez determinados los elementos que se iban a utilizar en esta parte del desarrollo
se procedió a desarrollar definitivamente la parte correspondiente a la visualización
gráfica.
La primera meta que se propuso dentro de esta fase fue generar el grafo resultante
después de construir la red RETE. Para este fin, se desarrolló un algoritmo que recorriera
todos los nodos alfa, y a su vez, obtuviese los sucesores de tipo beta de cada uno de ellos,
para a continuación realizar la misma operación con cada uno de estos sucesores. Se
94
realizan estas acciones sucesivamente hasta hallar un nodo terminal o gamma. En el
momento que se va desenrollando cada uno de los nodos, se añade a la especificación del
grafo, (en lenguaje Dot ) tanto las características dependiendo del tipo de nodo que sea,
como las relaciones correspondientes entre cada nodo.
Para favorecer la distinción visual de cada tipo nodo, se decidió asignar un color
distinto a cada uno de ellos. Como se puede apreciar en la siguiente figura los nodos alfa
aparecerán de color azul, los beta de color rojo y los gamma de amarillo.
Figura 5.35 – Fisionomía del grafo resultante.
En un principio se analizó la idea de distinguirlos además por una forma distintiva,
pero dado la cantidad que texto que se necesitaba mostrar, el tamaño de cada nodo
resultaba demasiado grande.
5.5.5 Funcionamiento
Una vez terminado por completo el desarrollo, se va a profundizar en el
funcionamiento interno del sistema. Se van a proponer una serie de escenarios de uso y se
comentará en cada uno de ellos el funcionamiento que siguen los diferentes elementos que
pertenecen al sistema. Para facilitar la comprensión se facilitará un diagrama de secuencia
en cada caso.
95
Mostrar datos correspondientes a la base de reglas y la base de hechos al
cargar la página. A la hora de cargar la página principal de la aplicación se
muestran dos listas correspondientes a los datos de la base de hechos y de la base
de reglas. Los datos que aparecen en dichas listas son solicitados al servidor por
medio de una request, a su vez, el servidor consulta los datos requeridos al SGBD
(Sistema Gestor de Base de Datos). Una vez que el servidor obtiene los datos, los
codifica en formato JSON para así poderlos enviar a la parte del sistema cliente.
Los datos son recibidos por el cliente mediante un mensaje response. En el
momento de la recepción los datos se encuentran codificados, por lo tanto, se
realiza una decodificación. Finalmente, los datos se muestran en el navegador web.
En la siguiente figura se muestra el diagrama de secuencia correspondiente a este
escenario.
Figura 5.36 – Diagrama de secuencia de “Mostrar datos correspondientes a la base de reglas y la base de hechos al cargar
la página”.
Seleccionar un elemento de cualquiera de las listas y modificarlo. En este caso,
entra en acción el usuario, el cual será el encargado de seleccionar una regla o
hecho de una de las listas para después editarlo. Una vez escogido el elemento, el
cliente se encarga de codificar los datos para enviarlos al sistema servidor. Éste
recibirá los datos, los decodificará y enviará la información al SGBD, para que éste
actualice la información correspondiente. Una vez actualizados los datos devolverá
96
un mensaje de confirmación en caso de éxito, o una de error en caso de que haya
habido algún problema. A su vez, el servidor notificará al cliente con el mismo
procedimiento y el cliente mostrará un mensaje de retroalimentación al usuario. A
continuación se muestra la figura perteneciente al diagrama de flujo del escenario
descrito.
Figura 5.37 – Diagrama de secuencia de “Seleccionar un elemento de cualquiera de las listas y modificarlo”.
Seleccionar versión de la red que desea mostrar. El cometido del usuario en esta
ocasión será seleccionar, de la lista correspondiente, la versión de la red que se
desea mostrar. Al igual que en el caso anterior, una vez hecha la selección, se
codifican los datos que es necesario enviar al sistema servidor. Ya recibida la
información en el servidor, se decodifican los datos y se solicita al SGBD la
información del grafo requerida. Esta información se envía de nuevo al cliente, el
cual se encarga de generar la imagen que se mostrará posteriormente.
97
Figura 5.38 – Diagrama de secuencia de “Seleccionar versión de la red que desea mostrar”.
5.5.6 Pruebas
A medida que se avanzaba en el desarrollo de cada uno de los módulos
implementados en esta última fase se iban realizando pruebas unitarias de caja negra para
cerciorarse de que el funcionamiento de cada función era el adecuado. A su vez, dichas
pruebas derivan en pruebas de regresión, puesto que la funcionalidad del sistema
evolucionaba constantemente, hay que asegurarse que las partes implementadas
anteriormente siguen funcionando adecuadamente.
98
99
6. CONCLUSIONES Y PROPUESTAS
Este capítulo se divide en varios apartados en los cuales se van a exponer las
conclusiones obtenidas una vez terminado el desarrollo del proyecto, así como las
propuestas de mejora y la firma del autor.
6.1 OBJETIVOS LOGRADOS
Ya finalizado el desarrollo del proyecto se puede hacer una valoración del trabajo
realizado y de los objetivos que se han alcanzado. Echando la mirada atrás y analizando los
objetivos que se proponían en un principio, se puede concluir que se han alcanzado la
mayoría de objetivos.
Se ha desarrollado una aplicación web basada en un modelo cliente-servidor que
permite la gestión de la base de conocimiento de un sistema basado en reglas. La gestión se
consigue gracias a un editor gráfico basado en la interfaz Blockly que posibilita la edición
tanto de reglas como de hechos. Permitiendo la creación de nuevos hechos o reglas,
eliminación de los mismos y la edición de los datos ya existentes en la base de
conocimiento.
También se ha desarrollado un sistema capaz de compilar una red RETE partiendo de
una base de conocimiento, respetando estrictamente las principales premisas por las que se
caracteriza el algoritmo RETE. Así como, un mecanismo de actualización de la red que
cumple las especificaciones que se exigen al realizar esta acción.
Otro de los objetivos prioritarios alcanzados consiste en la implementación del módulo
gráfico del sistema. Se ha implementado un sistema capaz de crear un grafo representativo
de una red RETE, que a su vez es mostrado por pantalla para facilitar al usuario la
comprensión de los cambios realizados en la edición de la misma. Aportando la posibilidad
de seleccionar entre una de la versiones anteriores de la red o la versión actual.
100
6.2 MEJORAS Y PROPUESTAS
Aun habiendo cumplido los objetivos prioritarios propuestos en el inicio del Trabajo
de Fin de Grado, se pueden mejorar algunas cosas así como añadir nuevas funcionalidades.
Las posibles mejoras y otras habilidades que se pueden adquirir se listan a continuación:
o Mejorar la representación de los datos correspondientes a reglas y hechos en las
listas de selección.
o Ofrecer un sistema de reconocimiento de errores simultáneo a la edición de
conocimientos.
o Mejorar la visualización gráfica de la red. Utilizando otro modelo de visualización
en el que el usuario pueda interactuar con él.
o Añadir la posibilidad de exportar e importar redes RETE externas.
101
7. BIBLIGRAFÍA
[CST] Castillo, E., Gutiérrez, J.M. y Hadi, H. 1997. Expert Systems and Probabilistic
Network Models (Versión Española editada por la Academia Española de Ingeniería).
Springer, New York.
[MRN] Moreno, V. 2005. I. A. Clásica Sistemas Expertos. Url: http://avellano.fis.usal.es/
~lalonso/Cursos/SistemasInteligentes/LectureNotes/ssee.pdf
[CBN] Carbonell, J., Jin, C. y Hayes, P. 2005. ARGUS: Rete + DBMS = Efficient
Persistent Profile Matching on Large-Volume Data Streams. Url:
http://repository.cmu.edu/cgi/viewcontent.cgi?article=1420&context=isr
[SVN] Selvamony, R. 2010. Introduction To The Rete Algorithm. Url: http://sapassets.
edgesuite.net/sapcom/docs/2015/09/703d5a24-577c-0010-82c7-eda71af511fa.pdf
[MRK] Miranker, D. 1987. TREAT: A Better Match Algorithm for AI Production Systems.
Technical Report AI TR87-58
[BRN] Burnet, M., M., Hossli, R., Pulliam, T. VanVoorst, B. y Yang, X. 1994. Toward
Visual Programming Languages for Steering Scientific Computations. IEEE
Computational Science & Engineering.
[DH] Dehouck, R. 2015. The maturity of visual programming. Url:
http://www.craft.ai/blog/the-maturity-of-visual-programming
[HS] Hosick, E. 2014. Visual Programming Languages – Snapshots. Url: http://blog.
interfacevision.com/design/design-visual-progarmming-languages-snapshots
[PZ] Paez, N., Fontdevila, D., Súarez, P., Fontela, C., Degiovannini, M. y Molinari, A.
2014. Construcción de software: una mirada ágil. Eduntref.
[ISSI] Grupo ISSI (Ingeniería del Software y Sistemas de Información). 2003.
Metodologías Ágiles en el Desarrollo de Software. Taller Metodologías Ágiles en el
desarrollo de Software. Url: http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf
[GNR] Gansner, E., Koutsofios, E. y North, S. 2015. Drawing graphs with dot. Url:
http://www.graphviz.org/pdf/dotguide.pdf
[PL] Polo, M.. Apuntes de Tecnologías y Sistemas Web Curso 2014-2015. UCLM
102
[BLT] Ballantyne, T. Drawing Graphs using Dot and Graphviz.
www.tonyballantyne.com/graphs.html
[WNT] Winston, P. H. 1994. Inteligencia Artificial. Addison-Wesley Iberoamérica
103
ANEXO A. MANUAL DE USO DE REMGRAFEE TOOL
En este anexo se va a detallar el manual de uso de la herramienta desarrollada. Se van
a explicar los principales aspectos que se tendrán que tener en cuenta para un correcto uso
de la aplicación.
En primer lugar se ejecuta la aplicación en un navegador web mediante la URL
proporcionada para su uso. Una vez cargada la web, aparecerá la interfaz principal de la
herramienta Remgrafee, formada por tres pestañas. Cada una pertenece a una función
determinada.
Pestaña “Base Conocimiento”
En esta pestaña es donde se va a realizar la gestión de la base de conocimiento.
Consta de dos listas, una destinada a la representación de los hechos de la base de hechos y
la segunda a la representación de cada una de las reglas de la base de reglas.
Para proceder a editar la información, únicamente hay que elegir un elemento de una
de estas listas y situar el puntero del ratón sobre el botón desplegable correspondiente a la
lista. Las opciones que se incluyen en el desplegable son: editar o eliminar.
Figura A.1 – Botón desplegable
104
En el caso de que se desee ejecute la opción de editar el elemento, se redireccionará a
la pestaña de edición; y en el caso de ejecutar la opción de eliminar, el sistema eliminará el
elemento y notificará al usuario mediante un cuadro de diálogo del navegador.
Aparte de los elementos mencionados anteriormente, hay un botón “Compilar red
RETE” que realiza la acción que su propio nombre indica. Cabe destacar que la
compilación de la red únicamente es necesaria realizarla cuando ha habido cambios en la
base de reglas, por lo tanto, cuando se realicen cambios en la base de hechos no es
necesario volver a realizar esta operación. En caso de que las reglas no estén correctamente
definidas o haya habido algún problema interno durante la construcción de la red, se
notificará al usuario mediante un cuadro de diálogo.
Pestaña “Editar conocimientos”
Esta pestaña es la destinada a realizar los cambios oportunos en la base de
conocimiento, mediante la utilización de Blockly. El cajón que contiene toda la lógica del
editor Blockly se divide en dos partes. En la parte izquierda aparecen las diferentes
categorías de bloques disponibles que se pueden seleccionar para la edición y en la parte
derecha se encuentra el área de edición. Si pinchamos en una de las categorías, se
desplegará hacia la derecha un segundo cajón que contendrá los bloques seleccionables.
Llegados a este punto para seleccionar un bloque hay que hacer click en uno de ellos y,
manteniendo pulsado el botón del ratón, se arrastrará hasta soltarlo en el área de edición.
105
Figura A.2 – Mostrar bloques disponibles
Hay observar que cada uno de ellos posee una pequeña mueca y un pequeño
sobresaliente. Destacado esto, para lograr la cohesión entre los bloques, hay que arrastrar
uno de ellos sobre otro logrando coincidir la mueca con el sobresaliente de cada uno de
ellos.
Figura A.3 – Cohesión de bloques
Es importante tener en cuenta que para añadir un hecho determinado, su predicado
correspondiente debe existir anteriormente, sino la adición de este hecho será errónea.
Como en casos anteriores, se mostrará un cuadro de diálogo comunicando el éxito o el
fracaso de la operación.
En el caso de la construcción de reglas se procede de una manera similar. Los bloques
se cohesionarán de la misma forma, pero en este caso es necesario la utilización de otro
tipo de bloque, el bloque contenido en la categoría de “Reglas”. Este bloque posee dos
espacios para insertar otros bloques, uno para los antecedentes y otro para el consecuente.
106
Figura A.4 – Construcción de una regla
Al igual que sucede con los hechos para guardar los datos únicamente hay que pulsar
el botón “Guardar”. El sistema reconoce por sí mismo si los bloques que se encuentra en el
área de edición pertenecen a hechos o a reglas.
En el área de edición existe un icono con forma de papelera. La función de este
elemento es eliminar hechos que se encuentran en este espacio. Para ello basta con
arrastrar un bloque hasta situarlo sobre la papelera y soltarlo.
Figura A.5 – Eliminar un bloque
A parte del botón “Guardar”, de cuyo funcionamiento ya se ha hablado en varias
ocasiones, existe un segundo botón, “Actualizar”. Éste tiene la función de indicar al
sistema que es necesaria una actualización de la red RETE. Es necesaria llevar a cabo esta
acción cuando se ha modificado la base de hechos.
107
Pestaña “Visualización”
En la pestaña de visualización es dónde se lleva a cabo la representación gráfica de la
red. Para ello, se selecciona una de las versiones del grafo presentes en la lista de selección
que se muestra a la izquierda. Después se ha de pulsar el botón “Mostrar Grafo” para que
el grafo se muestre en el contenedor de la derecha.
Las versiones de la red están representadas por la fecha y hora en la que se creó dicha
versión. Cada una de estas versiones corresponde a un estado de la red justo después de
cada acción de compilación o de actualización de la red.
Figura A.6 – Seleccionar la versión de la red que se desea mostrar
108
109
