una herramienta didáctica para el aprendizaje de semántica

UNIVERSIDAD NACIONAL DEL CENTRO DE LAPROVINCIA DE BUENOS AIRES

TRABAJO FINAL DE CARRERA

Una Herramienta Didáctica para elAprendizaje de Semántica en Lógica de

Predicados de Primer Orden

Autor:Cristian Luis TORRES

Directores:Mg. María Virginia MAUCO

Dr. Enzo FERRANTE

Trabajo Final de carrera para obtener el Título deIngeniero de Sistemas

de

Facultad de Ciencias ExactasUniversidad Nacional del Centro de la Provincia de Buenos Aires

18 de agosto de 2016

«En verdad, sólo quien piensa acertadamente puede enseñar a pensar acertadamente aun cuan-do, a veces, piense de manera errada. Y una de las condiciones para pensar acertadamente es queno estemos demasiado seguros de nuestras certezas.»

Paulo Freire[Pedagogía de la autonomía]

III

Agradecimientos

A mi mamá, a mi papá, a mis amigos, y a sus familias quienes me acompañaron yapoyaron durante todos estos años de estudios.

A Nacho por los consejos, a Nacha por las charlas técnicas, a Mante por pasar siemprepor casa y a Lucho por estar siempre ahí. Gracias por los momentos compartidos.

A mis profesores, a mi directores y al jurado por leer este trabajo.A todos ellos, muchísimas gracias.

V

Índice general

Agradecimientos V

1. Introducción 11.1. Descripción de la Problemática . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Organización del Informe . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Lógica de Predicados de Primer Orden 52.1. Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Sistemas Lógicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2. Lógica Computacional . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Lógica de Predicados de Primer Orden . . . . . . . . . . . . . . . . . . . . 82.2.1. Lenguaje de Primer Orden . . . . . . . . . . . . . . . . . . . . . . 82.2.2. Validez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3. Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3. Enseñanza de la LPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4. Herramientas Existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. LogicWorld: La Herramienta Desarrollada 233.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1. Tecnología Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.2. Especificación General del Diseño . . . . . . . . . . . . . . . . . . 243.1.3. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Arquitectura Interna del Cliente . . . . . . . . . . . . . . . . . . . 26Arquitectura Interna del Servidor . . . . . . . . . . . . . . . . . . 27

3.1.4. Pautas de Usabilidad para el Desarrollo de una Aplicación Web . 293.1.5. Interacción entre los Usuarios y la Solución . . . . . . . . . . . . . 30

3.2. Aplicación Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.2. Implementación e Integración . . . . . . . . . . . . . . . . . . . . . 313.2.3. Componente Home-page . . . . . . . . . . . . . . . . . . . . . . . . 343.2.4. Componente Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Componente LogicWorld . . . . . . . . . . . . . . . . . . . . . . . 35Componente Sentencias . . . . . . . . . . . . . . . . . . . . . . . . 36Componente Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 37Componente Elementos . . . . . . . . . . . . . . . . . . . . . . . . 38Archivos de Configuración . . . . . . . . . . . . . . . . . . . . . . 39

3.2.5. Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.2. Capa Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.3. Capa Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

VII

Paquete Fórmula . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Paquete LexicoySintactico . . . . . . . . . . . . . . . . . . . . . . . 45Paquete Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Paquete Generadores . . . . . . . . . . . . . . . . . . . . . . . . . . 47Paquete Modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4. Instanciación del Framework 494.1. Estrategia Basada en Archivos de Configuración . . . . . . . . . . . . . . 49

4.1.1. Configuración de un Nuevo Frame . . . . . . . . . . . . . . . . . . 494.1.2. Configuración Visual de la Aplicación . . . . . . . . . . . . . . . . 50

Configuración de la Pizarra de Trabajo . . . . . . . . . . . . . . . 50Configuración del Panel de Trabajo . . . . . . . . . . . . . . . . . 51

4.1.3. Configuración de la Semántica . . . . . . . . . . . . . . . . . . . . 52Configuración de Predicados . . . . . . . . . . . . . . . . . . . . . 54

4.2. Frame Granja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.1. Especificación de la Pizarra de trabajo . . . . . . . . . . . . . . . . 564.2.2. Especificación del Panel de trabajo . . . . . . . . . . . . . . . . . . 574.2.3. Especificación de la Semántica [Granja] . . . . . . . . . . . . . . . 584.2.4. Frame Instanciado . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3. Frame Figuras Geométricas . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3.1. Especificación de la Pizarra de Trabajo . . . . . . . . . . . . . . . . 604.3.2. Especificación del Panel de Trabajo . . . . . . . . . . . . . . . . . . 604.3.3. Especificación de la Semántica [Figuras] . . . . . . . . . . . . . . . 614.3.4. Frame Instanciado . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5. Conclusiones 635.1. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

A. JFlex - Analizador Léxico 67A.1. Reglas lexicográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.2. Reglas léxicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

B. CUP - Analizador Sintáctico 69B.1. Símbolos terminales y no terminales . . . . . . . . . . . . . . . . . . . . . 69B.2. Gramática del analizador sintáctico . . . . . . . . . . . . . . . . . . . . . . 70

C. Archivos de configuración - Frame Granja 71C.1. Panel.config.json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71C.2. Board.config.json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72C.3. Semantica.config.json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

D. Archivos de configuración - Frame Figuras Geométricas 75D.1. Panel.config.json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75D.2. Board.config.json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76D.3. Semantica.config.json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Bibliografía 81

VIII

Índice de figuras

2.1. Estructura de los sistemas lógicos. . . . . . . . . . . . . . . . . . . . . . . 72.2. Evolución histórica de la interfaz de usuario de la herramienta «Tarski’s

World» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3. Captura de pantalla de la aplicación «Jape» . . . . . . . . . . . . . . . . . 142.4. Ejemplos de primeras herramientas Webs . . . . . . . . . . . . . . . . . . 162.5. Captura de pantalla de la aplicación AProS(CPT) . . . . . . . . . . . . . . 172.6. Ejemplo de actividades «Logic Couch» . . . . . . . . . . . . . . . . . . . . 172.7. Ejemplos de herramientas para evaluar semánticamente en LPO. . . . . 19

3.1. Arquitectura cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . 243.2. Estructura de navegación web y Componentes del Servidor . . . . . . . 253.3. Arquitectura MVC dentro del Cliente . . . . . . . . . . . . . . . . . . . . 273.4. Diagrama UML de Componentes del Cliente . . . . . . . . . . . . . . . . 283.5. Diagrama de Capas del Servidor . . . . . . . . . . . . . . . . . . . . . . . 283.6. Tecnologías del Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7. Pantalla principal del sitio web . . . . . . . . . . . . . . . . . . . . . . . . 343.8. Diagrama UML de Componentes dentro del Editor . . . . . . . . . . . . 363.9. Regiones de la interfaz visual del Cliente . . . . . . . . . . . . . . . . . . 373.10. Diagrama UML - Paquetes dentro del Cliente . . . . . . . . . . . . . . . . 383.11. Pantalla del Editor - Sin seleccionar un frame . . . . . . . . . . . . . . . . 393.12. Diagrama de Capas y de Componentes del Servidor . . . . . . . . . . . . 423.13. Pre proyecto - Generación de AL y AS . . . . . . . . . . . . . . . . . . . . 433.14. Diagrama UML de Paquetes - Motor de inferencia . . . . . . . . . . . . . 443.15. Diagrama UML de Clases - Paquete Formula . . . . . . . . . . . . . . . . 453.16. Ejemplo de una formula y su estructura de árbol asociado . . . . . . . . 453.17. Diagrama UML de Clases - Paquetes Relaciones . . . . . . . . . . . . . . 473.18. Diagrama UML de Clases - Clase Estructura . . . . . . . . . . . . . . . . 48

4.1. FOLST : Frame Granja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.2. Granja: Imágenes del Board.config . . . . . . . . . . . . . . . . . . . . 574.3. Imágenes de los elementos del frame Granja . . . . . . . . . . . . . . . . . 574.4. Captura de pantalla del frame Granja Implementado . . . . . . . . . . . . 594.5. Figuras Geometricas: Imágenes del Board.config . . . . . . . . . . . . 604.6. Imágenes de los elementos del frame Figuras Geométricas . . . . . . . . . 614.7. Captura de pantalla del frame Figuras Geométricas implementado . . . . 62

IX

Índice de tablas

2.1. Tabla comparativa de herramientas existentes . . . . . . . . . . . . . . . . 202.2. Continuación de la tabla comparativa de herramientas existentes . . . . 21

A.1. Reglas léxicas - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

B.1. Declaración de símbolos terminales y no terminales . . . . . . . . . . . . 70

XI

Capítulo 1

Introducción

La lógica ha sido considerada, históricamente, como uno de los principales compo-nentes de la filosofía. Con el paso del tiempo y la evolución de las ciencias, se ha idoincorporando naturalmente a otras disciplinas como la matemática y las ciencias de lacomputación. En la actualidad, la mayoría de las carreras de informática incluyen eldictado de cursos básicos de Lógica, dado que muchos de sus conceptos son aplicablesen una gran variedad de contextos específicos tales como la programación, la inteligen-cia artificial, la ingeniería de software, el uso y diseño de sistemas de bases de datos,entre otros.

En dichos cursos, los alumnos deben resolver gran cantidad de ejercicios para ad-quirir práctica en el manejo de formalismos ya que la mejor forma de aprender nuevosconceptos es justamente poniéndolos en práctica (Mauco, Ferrante y Felice, 2014). Uti-lizar software educativo que acompañe el proceso de enseñanza/aprendizaje puedeinfluir positivamente siempre que éstos posean un ambiente amigable y no requie-ran demasiado tiempo de aprendizaje para su utilización (Kenny y Pahl, 2009). Eneste contexto, una gran cantidad de aplicaciones didácticas han sido desarrolladasno sólo para el ámbito universitario, sino en todos los niveles del sistema educativo(Barker-Plummer, Barwise y Etchemendy, 2007; Hausman, Kahane y Tidman, 2012;Allen y Hand, 2001; Mauco y col., 2012a). En la actualidad, diversas estrategias edu-cativas han adoptado modelos de aprendizaje en los cuales este tipo de tecnologías sonutilizadas para reforzar, apoyar y acompañar el proceso de aprendizaje de los alumnos.

Si bien este tipo de aplicaciones surgieron fundamentalmente como apoyo a la edu-cación a distancia, las mismas han evolucionado con el paso de los años adaptándosea las nuevas tecnologías y haciendo uso de sus nuevas potencialidades. Herramientasque en una primera instancia consistían en una serie de trabajos mecánicos y repeti-tivos que tenían que ser instaladas en la computadora, se han transformado hoy enaplicaciones que sirven como complemento a la educación presencial, desarrolladasutilizando tecnologías Web o incluso para dispositivos móviles.

Este tipo de aplicaciones son utilizadas con el objetivo de facilitarle a los alumnosla comprensión de los diferentes conceptos abarcados en los cursos, a partir de ejerci-taciones y ejemplos concretos y visuales. Esto resulta de especial utilidad en materiasque poseen un alto nivel de abstracción, como en el caso de los cursos de lógica.

1.1. Descripción de la Problemática

La Lógica de Predicados de Primer Orden (LPO) es una extensión de la lógica pro-posicional, la cual hace uso de los mismos operadores (implicación, disyunción, con-junción y negación) pero aumenta el poder expresivo de la misma al incluir la nociónde predicados, funciones y cuantificadores. El valor de verdad de una fórmula dependede la definición del modelo en el cual se la evalúa. Un modelo está definido por un dominio

1

2 Capítulo 1. Introducción

del discurso (dominio) y un lenguaje (conjunto de: constantes, funciones y predicados).Mediante la definición de dichos elementos es que se le otorga una interpretación se-mántica (un significado) a los componentes que conforman la fórmula, y a ésta mismaen su totalidad. Por lo tanto, para poder analizar cuándo una formula es válida o no enun determinado modelo, previamente es necesario definir dicho modelo.

Si bien existen algunas herramientas educativas para la evaluación semántica defórmulas en LPO (en las cuales los usuarios tienen la posibilidad de definir distin-tos modelos), todas trabajan sobre un dominio preestablecido, con relaciones y funcio-nes también preestablecidas, limitando entonces los tipos de modelo que pueden serdefinidos. Éstas proporcionan al usuario un marco de trabajo que le permite definirdiferentes instancias de un dominio y evaluar la validez de un conjunto de fórmu-las (Barker-Plummer, Barwise y Etchemendy, 2007; Mauco y col., 2012a; Mauco y col.,2012b). Generalmente, proveen además material de estudio específico que lo acom-paña. Sin embargo, no existe una herramienta que permita al usuario definir nuevassemánticas de acuerdo a sus preferencias y de forma sencilla.

La capacidad expresiva de la LPO reside justamente en la posibilidad de trabajarcon dominios arbitrarios, definidos según las necesidades del usuario, quien tambiéndebería poder especificar las relaciones y funciones necesarias teniendo en cuenta lasituación que desea formalizar. Se considera entonces de interés contar con una herra-mienta interactiva y visual, que permita especificar distintos dominios, con relacionesy funciones asociadas, para luego definir los modelos o interpretaciones concretas.

Permitir la creación de diferentes “tipos de modelos” (“marcos de trabajos” o “frames”,como serán denominados en este trabajo) constituye un aporte sustancial para quienesdeseen desarrollar sus propias actividades y material de consulta para el dictado decursos de lógica que abarquen los temas en cuestión. Es importante considerar tam-bién que la definición de múltiples frames proporciona diversidad dentro del dictadode dichos cursos. Incluso, puede ser ventajoso para los estudiantes que los mismos seencuentren centralizadas en una única herramienta.

1.1.1. Objetivo

El objetivo de este trabajo es implementar una herramienta didáctica, interactivay visual que brinde un soporte adecuado en el proceso de enseñanza/aprendizaje desemántica en Lógica de Predicados de Primer Orden. La aplicación, además, debe po-seer una interfaz amigable e intuitiva, conservando las características positivas de lasherramientas existentes, y mejorando algunas de las falencias que otras herramientaspresentan.

Por otro lado, mediante el desarrollo de un framework, se pretende facilitar a losdocentes la tarea de generar nuevos frames, incorporando dominios, relaciones y fun-ciones definidos por el usuario con el fin de poder personalizar las aplicaciones a utili-zar dentro de una cátedra de lógica.

Buscando cumplir con el objetivo planteado, se propone el desarrollo de una apli-cación que encapsule toda la funcionalidad requerida y que además provea el soportenecesario para definir nuevos frames (definir nuevos contextos personalizados con losque trabajar). Debe tratarse de una herramienta de libre acceso y que no necesite cono-cimientos de la tecnología en la que fue implementada ni habilidades de programación,para realizar dicha personalización. Además, los frames resultantes deberán ser aplica-ciones interactivas que permitan a los usuarios estudiantes experimentar con diferen-tes modelos, evaluar nuevas fórmulas en ellos y obtener feedback que colabore con

Capítulo 1. Introducción 3

su aprendizaje. Considerando lo investigado hasta el momento de definir el presenteproyecto, no existe aún una aplicación con estas características.

1.2. Organización del Informe

Tal como fue expuesto en la sección anterior, el presente trabajo introduce una he-rramienta para la enseñanza/aprendizaje de LPO mediante la cual es posible modelary resolver problemas semánticos y provee el soporte para poder definir nuevos frames.Además, se incluye a modo de ejemplo de uso, la especificación e implementación dedos frames diferentes, mediante los cuales se pretende caracterizar distintas situacionesy mostrar el potencial del framework desarrollado.

En el Capítulo 2 se incluye una introducción general a la lógica, con foco en la LPO,donde el objetivo es poner en contexto al lector sobre el tema. Se mencionan además losmotivos por los cuales es necesaria la enseñanza de la LPO y se realiza un relevamientode las diferentes herramientas para la enseñanza de lógica que existen en la actualidad,presentando cuestiones como la evolución histórica y los cambios en las tecnologías delas mismas.

En el Capitulo 3 se especifica la solución ante la problemática planteada: una apli-cación web que consta de una interfaz visual para el usuario y un servidor encargadode realizar el procesamiento. El primer componente consta de una página principal yun editor, este último es el que se instancia con los diferentes frames especificados. Porotro lado, el servidor contiene un motor de inferencia y una API, necesaria para co-nectar los pedidos del cliente y las respuestas del procesamiento. Estos componentesenumerados se especifican por separado, detallando los requerimientos funcionales yno funcionales, así como también sus principales características tecnológicas y arqui-tecturales.

En el Capítulo 4 se documenta la estrategia implementada para la especificaciónde nuevos frames basada en archivos de configuración. Además se presentan los dosframes implementados mediante la utilización del framework. El primero basado en elframe “Granja” de la herramienta FOLST (Mauco y col., 2012a) y el segundo toman-do como referencia el frame “Figuras Geométricas” implementado en la herramientaTarski’s World (Barker-Plummer, Barwise y Etchemendy, 2007).

En el Capítulo 5 se presentan las conclusiones de este informe, y se discuten poten-ciales extensiones futuras que pueden desprenderse a raiz de las contribuciones reali-zadas por este trabajo.

Capítulo 2

Lógica de Predicados de PrimerOrden

Este capítulo pretende poner al lector en el contexto de la Lógica de Predicadosde Primer Orden, también denominada Lógica de Primer Orden (LPO). La Sección 2.1presenta una introducción al tema y describe el contexto del mismo dentro de la lógicaen general. En la Sección 2.2 se hace especial énfasis en la Lógica de Predicados dePrimer Orden, introduciendo los distintos conceptos que la conforman y mostrandocómo utilizarlos para analizar argumentos. Posteriormente, en la Sección 2.3, se analizasu vinculación con la educación, señalando la importancia y utilidad de la misma y lasprincipales dificultades encontradas tanto en el aprendizaje de la lógica como en suenseñanza. El capítulo concluye con una recopilación de las herramientas de asistenciaa la enseñanza/aprendizaje de la lógica (Sección 2.4).

2.1. Marco Teórico

La lógica es la ciencia que se encarga del estudio del razonamiento (Gutiérrez, 2000).Por razonar se entiende obtener afirmaciones (usualmente conocidas como conclusiones)a partir de otras afirmaciones (a las que se las denomina premisas) con los criteriosadecuados que aseguren que, si las premisas son verdaderas, entonces las conclusionesobtenidas también son verdaderas (Gutiérrez, 2000). El proceso por el cual se derivanlas conclusiones a partir de las premisas es denominado inferencia o proceso deductivo(Audi, 1999).

El objetivo de la lógica es formalizar el razonamiento y dar criterios precisos que per-mitan distinguir un razonamiento válido de una falacia (Ben-Ari, 2001). Formalizar unrazonamiento es expresarlo de forma tal que sea posible estudiar su validez atendien-do únicamente a la forma de las declaraciones involucradas. Cuando un razonamientoes válida, lo es por la estructura lógica de sus componentes, independientemente delsignificado de los argumentos, o si los mismos son verdaderas o falsos, o del lengua-je utilizado para representarlos (Bergmann, Moor y Nelson, 1990). Así, el proceso deinferencia sólo dependerá del sistema lógico en el cual se trabaje.

Los primeros intentos de formalizar los razonamientos se remontan al trabajo deAristóteles. Aunque sólo estudió una clase muy acotada de razonamientos (los llama-dos silogismos), utilizaba letras para representar los términos involucrados. De estaforma se comienza a distinguir los razonamientos de las falacias mediante criteriospuramente formales (Logic and Metalogic). Siglos mas tarde, esta idea recibe un nue-vo impulso por parte de Leibniz, seguido por Boole, De Morgan, Frege y varios otros.Estos matemáticos trataron de crear un procedimiento para generar y verificar los ra-zonamientos de forma ”mecánica” desde diferentes enfoques (Castillo, 2010).

5

6 Capítulo 2. Lógica de Predicados de Primer Orden

2.1.1. Sistemas Lógicos

Con el paso del tiempo, la lógica ha ido evolucionando desde una lógica informalhasta desarrollar métodos más formales y teóricos. Esto se debe principalmente a lanecesidad de desarrollar una lógica simbólica cada vez más compleja, que permita for-malizar los distintos elementos del lenguaje natural.

Uno de las posibles formas de clasificar las distintas lógicas que existen es agru-pándolas en 2 grandes categorías: lógica informal y lógica formal. La LPO se encuentradentro de este segundo grupo.

La lógica formal puede caracterizarse como un sistema lógico base (conformadopor un conjunto de símbolos, reglas, axiomas, etc) sobre el cual se monta otro que poseemás recursos expresivos y nuevos símbolos. A su vez, a este último sistema se puedenincorporar otras nuevas capas de forma tal que se amplien sus recursos expresivos yaumente la complejidad de la formalización (Gutiérrez, 2000). Teniendo esto presente,es posible estructurar la lógica formal de la siguiente manera:

Lógica Proposicional: Las fórmulas dentro de esta lógica se denominan propo-siciones, las cuales consisten en oraciones o enunciados de los cuales no se ana-liza su composición interna. Este sistema lógico se enfoca en analizar la inferen-cia de proposiciones a partir de otras proposiciones, utilizando conectores lógi-cos(Blackburn, 2005).

Lógica de Predicados de Primer Orden: A diferencia de lo que sucede en la ló-gica proposicional, en este sistema lógico las proposiciones (denominadas sen-tencias) ya no se analizan como un todo, si no que se incorporan mecanismospara estudiar su estructura. Así, las sentencias se asumen como combinacionesde predicados, los cuales tienen su propio valor de verdad. El valor de verdad dela sentencia dependerá del valor de verdad de los predicados que la componen(Gutiérrez, 2000). Cada predicado está definido sobre un conjunto de variables,las cuales pueden tomar valores que están asociados a la semántica de las sen-tencias, y no a su valor de verdad. Por otro lado, el lenguaje formal incorpora laposibilidad de cuantificar los atributos de los elementos con los que se puedeninstanciar las variables. Por todo lo anterior, se dice que la LPO es una lógica declases, dado que en ella las relaciones que se analizan son del tipo pertenencia aun conjunto o posesión de una determinada propiedad o atributo.

Lógicas de orden superior: Estas lógicas surgen para poder expandir el poderexpresivo del lenguaje sin tener que agregar un conjunto nuevo de símbolos ló-gicos. Por ejemplo, si se utiliza como base la lógica de primer orden y ademásse permite cuantificar las propiedades de los elementos del dominio, entonces elsistema lógico resultante constituye una lógica de 2do Orden. Así, según se ad-mitan realizar cuantificaciones sobre propiedades o predicados, o predicados depredicados, se incrementa el orden de la lógica.

Esta clasificación nos permite definir la lógica formal como una estructura de cálcu-los anidados como la que se observa en la Figura 2.1. Es importante agregar que todaslas características que son válidas en un nivel inferior se verifican en los niveles supe-riores que lo contienen, pero no al revés.

Un segundo criterio de clasificación puede ser definido si se toma en cuenta el nú-mero de valores de verdad con los que se trabaja. La Lógica clásica es aquella en la quesus fórmulas puede ser verdaderas o falsas y no puede ocurrir que lo sean en simul-taneo. La LPO, por ejemplo, es una lógica clásica. En cambio una lógica no-clásica, es

Capítulo 2. Lógica de Predicados de Primer Orden 7

FIGURA 2.1: Estructura de los sistemas lógicos.

aquella en la que se contemplan más valores de verdad o se utilizan otro tipo de re-cursos expresivos. Ejemplos de esto son: la lógica trivalente (contempla tres valores deverdad, verdadero, falso y desconocido); la lógica polivalente (una lógica probabilísti-ca en la que los valores de verdad se corresponden con números reales en el intervalo[0,1]); la lógica modal (que incorpora dos nuevos recursos expresivos/símbolos dellenguaje, los operadores modales: “es necesario“ y “es posible“), entre otros.

2.1.2. Lógica Computacional

La lógica computacional es la lógica matemática aplicada en las ciencias de la compu-tación. Su utilización es indispensable y transversal a varias áreas, a saber:

En los sistemas digitales, el uso de la lógica booleana es fundamental para la defi-nición de los circuitos electrónicos. Cada circuito eléctrico puede ser interpretadocomo una fórmula del cálculo proposicional (Shannon, 1938). La comprensión deuna fórmula booleana está íntimamente relacionada con el número de elementosnecesarios en los circuitos correspondientes.

En los lenguajes de programación, el tipo booleano siempre forma parte de lostipos básicos con los que se cuenta, permitiéndole al programador trabajar condos tipos de valores (“verdadero“ y “falso“) y utilizando los operadores “y“, “o“y “no“. Las expresiones booleanas son utilizadas, entre otras cosas, en las senten-cias de flujo de control de los programas.

En la programación lógica, los problemas son descriptos en términos puramentelógicos. Se utiliza un motor lógico que lleva a cabo todas las deducciones posi-bles a partir de la descripción del problema planteado realizando una búsquedaen profundidad sobre el universo definido( a partir de reglas y hechos lógicos),con el fin de obtener la solución esperada. Los principales sistemas de progra-mación lógica son derivados del lenguaje de programación PROLOG. PROLOGrepresenta un ejemplo importante y palpable de la asociación entre la lógica y lacomputación (Seese, 1984; Kowalski, 1988).

En el análisis y optimización de recursos temporales y espaciales de distintosalgoritmos. La verificación y síntesis automática de programas es una técnica quese basa en la lógica de predicados (Davis, 1995).


2.2. Lógica de Predicados de Primer Orden

Existen muchas oraciones del lenguaje natural que no pueden ser expresadas conla Lógica proposicional, debido a que la misma no es lo suficientemente expresiva pa-ra captar ciertas relaciones. Cuando se analizan los argumentos, no se trabaja con laestructura interna de las variables proposicionales sino únicamente con la estructurade las fórmulas, teniendo en cuenta las sentencias que la componen. Esto genera in-convenientes cuando la validez del razonamiento depende de la estructura interna delas proposiciones. La Lógica de Predicados permite realizar un análisis más fino de loscomponentes que intervienen en una expresión. En la presente sección se introducencada uno de los conceptos básicos del lenguaje formal de la LPO, se indaga con mayorprofundidad sobre el concepto de validez de una fórmula, y finalmente se define lo quees un Modelo dentro de la LPO.

2.2.1. Lenguaje de Primer Orden

Un lenguaje de primer orden está formado por una serie de elementos que permitenexpresar cualquier afirmación del lenguaje natural. A continuación se define cada unode ellos:

1. Símbolos Lógicos.

Variables: Son elementos numerables, cuya referencia no está determinadadebido a que la misma depende del contexto de la expresión que la utiliza.Las variables generalmente se representan con letras minúsculas que se en-cuentran cerca del final del abecedario, o una misma letra pero numeradacon un índice (ej: x, y, z, ..., x1, x2, x3, ...). Es posible ver a las variables comouna representación formal de las expresiones del lenguaje natural del estilo“él”, “ella”, “eso”, etc. De esta manera es posible formalizar expresiones delestilo “eso es un gato” como “x es un gato”. Es posible ver, entonces, que elvalor de verdad de la expresión depende del valor que toma la variable x.

Cuantificadores: Un cuantificador es una expresión que afirma que una con-dición se cumple para todos los elementos que abarca (cuantificador univer-sal ∀), o que se cumple para al menos uno de ellos (cuantificador existencial∃). Con la incorporación de los cuantificadores es posible formalizar expre-siones que contengan además cuantificaciones del estilo: “para todo x” o“existe algún x”, como por ejemplo: “para todo x, x es gato” o “todo x esgato”. Vale aclarar que el valor de verdad de estas expresiones depende deldominio de análisis: si el mismo es un grupo de personas, entonces la afir-mación “todo x es gato” es falsa; sin embargo, si el dominio es el de los gatossiameses, entonces la afirmación anterior es verdadera.

Conectivos Lógicos: La LPO incorpora los conectivos de la lógica Proposi-cional. Los mismos son utilizados para unir dos predicados, y de esta formacombinar sus distintos valores de verdad. Los conectivos son utilizados pa-ra representar, en el lenguaje formal, el significado que se les asocia comun-mente en el lenguaje natural. De tal forma es posible representar la negación(“eso no es un gato”), la conjunción (“eso es un gato y es un mamífero”), ladisyunción (“eso es un gato o es un felino”), la implicación (“si eso es ungato entonces eso es un felino”) y el bicondicional (“eso es un felino si y


solo si maúlla”). Los símbolos asociados a cada uno de estos conectivos son,respectivamente, ¬,∧,∨,→,↔.

2. Símbolos Auxiliares.

Así como ocurre en las operaciones matemáticas, los operadores lógicos poseenun único y bien definido orden de preferencia al momento de operar. Al incorpo-rar los paréntesis (paréntesis que abren “(” y paréntesis que cierran “)”) es posibleanular la precedencia de los operadores externos y forzar el análisis prioritario delo que está encerrado. También se los utiliza para definir los argumentos de unpredicados o de una función. Otro uso es para modificar el alcance de los cuanti-ficadores dentro de una fórmula, debido a que los cuantificadores sólo afectan alas variables libres inmediatamente siguientes.

3. Constantes.

Una constante es un ’nombre’ que hace referencia a un elemento en particular deldominio con el que se está trabajando. Las contantes generalmente se representancon letras minúsculas del principio del abecedario (a, b, c, ...). Sin embargo, tam-bién puede ocurrir que en algunos conjuntos en particular las constantes esténdefinidas por la interpretación común del ámbito de trabajo; por ejemplo el nom-bre propio de los elementos sobre el que se trabaja (sin son planetas: Mercurio,Venus, etc; si son personas: Nacho, Luis, María Ignacia, etc) o un valor numérico(Números naturales: 1, 2, 3, ...).

4. Predicados.

En el lenguaje natural los predicados son conectivos entre una o varias expresio-nes. En LPO los predicados expresan propiedades y relaciones entre los elemen-tos a analizar, son funciones que retornan un valor verdadero o falso dependien-do de los argumentos con los que se los define. Cuando se intenta formalizar laexpresión “eso es un gato”, “es un gato” pasa a ser el contenido de un predicadodenominado, por ejemplo, con la letra mayúscula “G”. La formalización de dichaexpresión termina siento G(x), lo que da lugar a dos nuevos conceptos a teneren cuenta. Por un lado, todo predicado posee asociado un número natural quedefine la aridad del mismo, siendo aridad la cantidad de argumentos necesarios,siempre distinta de 0. Por otro lado, los predicados trabajan sobre un determinadodominio, por lo que su valor de verdad depende directamente de los argumentosutilizados, y dicho resultado no varía a menos que cambien los argumentos. Lospredicados suelen ser representados con letras mayúsculas que se encuentran apartir de la letra P (P , Q, R, ...), pero puede ocurrir que en algunos casos, parafacilitar la interpretación de los mismos, se utilicen otras letras o incluso palabrascompletas.

5. Funciones.

Las funciones se utilizan para representar individuos, de la misma manera quelas constantes y las variables, con la diferencia de que el individuo que represen-tan depende del/los argumento/s que reciban. Por ejemplo, la función padre(x),definida en un dominio de personas, devolvería el padre del individuo x. Lasfunciones pueden ser utilizadas para definir relaciones y propiedades entre ele-mentos. De igual forma que en los predicados, la cantidad de argumentos queposee una función determina la aridad de la misma. La diferencia fundamentalentre un predicado y una función es que esta última retorna un elemento del


dominio y no un valor de verdad. Los símbolos para representar las distintasfunciones suelen ser las letras f , g, h, etc, siempre en minúsculas.

Los símbolos lógicos y los símbolos auxiliares son comunes a cualquier Lenguajede Primer Orden. Esto implica que un Lenguaje de Primer orden queda caracterizadopor la definición de sus predicados, constantes y funciones. Sin embargo, como dijimosanteriormente, la validez de las distintas fórmulas, en la mayoría de los casos, dependedirectamente del conjunto de elementos sobre el cual se trabaja. Al momento de anali-zar la validez de una o mas fórmulas, es indispensable determinar o definir el dominiocon el que se está trabajando (lo que se conoce como semántica). La definición de unlenguaje de lógica de predicado sumado a la definición de un dominio es lo que sedenomina interpretación o Modelo).

2.2.2. Validez

Existen algunos casos de fórmulas que son sintácticamente Verdaderas (denomina-das Tautologías) o Falsas (denominadas Contradicciones). Una tautología es una fór-mula cuya validez puede ser analizada sin tener en cuenta el dominio de discurso sobreel que se está trabajando (sin definir una semántica sobre las fórmulas). Cuando unafórmula es una Tautología, se puede asegurar que la misma es verdadera para todoslos posibles infinitos modelos que se pueden definir. De igual manera, la contradicciónserá falsa para cualquier modelo que se defina.

2.2.3. Modelos

A continuación se muestra como ejemplo la definición de un lenguaje formal L1

instanciando los tres conjuntos que lo caracterizan < C,R, F >, donde C es el conjuntode las constantes con un solo elemento, R es el conjunto de las relaciones y está confor-mado por una relación unaria P y una binaria I , y F es el conjunto de las funciones enel cual se define la función m.

L1 =< C,R, F > (2.1)

donde C = a, R = {P, I} (con P un predicado con aridad 1 e I con aridad 2) y F = {m}Una vez definido el lenguaje (Ecuación 2.1) entonces es posible listar algunas fór-

mulas que pueden definirse a partir del mismo, por ejemplo: P (x) , P (a) , ∃xP (x), y∀x∀yI(x, y). Dichas fórmulas, sin embargo, carecen de semántica debido a que no tie-nen un dominio asociado, con lo cual no es posible definir si son válidas o no. Paraincorporar la semántica ausente es que se define un modelo. A continuación se defineun modelo M1 en el lenguaje formal de la Ecuación 2.1, donde se establece el Domi-nio (D) al que pertenecen los elementos a analizar, y donde luego se instanciarán lasconstantes, relaciones y funciones. Una definición posible para el modelo M1 es:

M1 =< D,C,R, F > (2.2)

donde D = {0, 1, 2}, CD = {a} con a = 2; RD = {PD, ID} y F = {mD} instanciandoPD = {2}, ID = {(0, 0), (1, 1), (2, 2)} y m(x) = {x ∈ D/x mod 2}

Con el modelo definido entonces podemos decir por ejemplo que:∃xP (x) y P (a) son verdaderas en el modelo definido en la Ecuación 2.2∀x∀yI(x, y) es falsa en el modelo definido en la Ecuación 2.2


2.3. Enseñanza de la LPO

Las materias de lógica dictadas en carreras informáticas presentan características ydificultades similares a las de otras materias relacionadas con la matemática: un ren-dimiento académico bajo de los alumnos, y una alta tasa de abandono (Posso, Gómezy Uzuriaga, 2007; Bartó y Weber, 2013). Al ser la lógica una disciplina instrumental, esfundamental poseer un proceso de enseñanza/aprendizaje interactivo y un feedbackinmediato de los contenidos aprendidos que colabore con la reducción de estas proble-máticas.

Un curso de lógica introductorio típico, dentro de una carrera informática, contienelógica proposicional y lógica de predicados, poniendo especial énfasis en la semánticaformal. En estos cursos, los alumnos deben resolver gran cantidad de ejercicios paraadquirir práctica en el manejo de formalismos Mauco, Ferrante y Felice, 2014. Esta ejer-citación práctica se realiza en papel y lápiz, siendo difícil y en muchos casos tediosopara los alumnos detectar y corregir errores. En consecuencia, los alumnos considerana estos cursos menos atractivos, y en algunos casos más difíciles, que otros en los que,por ejemplo, interactúan con la computadora (Mauco, Ferrante y Felice, 2014). En es-te contexto, los recursos digitales constituyen un buen complemento a los materialestradicionales de estudio, debido a que diferentes tipos de recursos digitales puedenser utilizados para ayudar a motivar y mejorar el proceso de enseñanza/aprendizaje,ya que las actividades interactivas son menos lineales que las ofrecidas en los libros omanuales.

En este escenario, teniendo como objetivo alcanzar una mejora en el rendimientoacadémico, las Tecnologías de la Información y Comunicación (TIC) son una herra-mienta central en el marco de las estrategias educativas (Fernández-Pampillón Ceste-ros, 2009; García y col., 2007). Es en este marco donde cobra relevancia el concepto deE-learning, entendido como las aplicaciones y servicios que, tomando como base es-tas tecnologías, son utilizadas con el fin de facilitar el proceso de enseñanza (Álvarez,2009). E-learning se basa en recursos y actividades accesibles a través de una compu-tadora u otro medio electrónico. En este modelo, los contenidos digitales ofrecidos tie-nen que poseer un considerable nivel de interactividad, permitiendo una formaciónflexible de los alumnos para proporcionar una mayor adaptación a las características ynecesidades de los distintos estudiantes (Fernández-Pampillón Cesteros, 2009).

Entre las principales ventajas de estas herramientas y contenidos digitales, una delas más notorias es que poseen un alto nivel de accesibilidad y pueden ser distribui-dos de forma masiva por medio de Internet. Además, el material puede ser utilizadocualquier día a cualquier hora, pudiendo de esta forma optimizar al máximo el tiempodedicado a la formación de cada alumno. Sin embargo, la creación de estas herramien-tas y recursos interactivos para el apoyo en la enseñanza/educación tienen un altocosto de tiempo y recursos (Murray, Blessing y Ainsworth, 2003).

Los Sistemas Tutores Inteligentes (Intelligent Tutoring Systems – ITS) son herra-mientas o aplicaciones utilizadas para mejorar el proceso de enseñanza/aprendizaje,proporcionando asistencia personalizada, permitiendo la realización de actividades deforma interactiva (Kenny y Pahl, 2009) y ofreciendo una retroalimentación inmediata alos estudiantes (Melis y Ullrich, 2003).

En la actualidad es posible encontrar un considerable número de herramientas quepueden ser utilizadas para la enseñanza/aprendizaje de lógica. Las mismas no sólose adaptan a los constantes cambios de tecnologías, sino que también varían en el ti-po de servicio que brindan. En sus inicios estas herramientas facilitaban la labor de


verificación, permitiendo al usuario generar las soluciones de forma automática. Pos-teriormente, estas herramientas evolucionaron para brindar soporte, no sólo para lageneración de soluciones, sino además para el análisis y la verificación, permitiendochequear si una solución propuesta por el usuario, generada a partir de unos ciertospasos, es la correcta. Igualmente, las distintas herramientas se han adaptado a las ne-cesidades específicas de los usuarios y los temas que abarcan.

Estas herramientas, se pueden clasificar en función del rol que desempeña el estu-diante al momento de utilizarla:

Resolvedores o provers (Endriss, 2000; Moreno y Budesca, 2000; Layman, 2004):Las herramientas que están dentro de esta categoría se caracterizan por su altonivel de automatismo. El usuario es completamente pasivo durante el desarrollode la solución del ejercicio, la cual se calcula y muestra de una manera automática.

Chequeadores o checkers (Layman, 2004; Allen y Hand, 2001): Este tipo de herra-mienta se caracteriza por la poca interacción que realiza el usuario. La actividadprincipal consiste únicamente en verificar una deducción o una formalización. Elfeedback que obtiene el estudiante es acotado. La herramienta se limita a encon-trar errores cuando el usuario solicita explícitamente la verificación del ejerciciollevado a cabo.

Asistentes o constructors (Endriss, 2000; Moreno y Budesca, 2000; Barwise y Et-chemendy, 1994; Barker-Plummer, Barwise y Etchemendy, 2007; Broda y col.,2007): Este tipo de herramientas se caracteriza por poseer un mayor grado deinteractividad con el usuario, mediante la utilización de botones, menús y men-sajes de diálogos. Proporciona a los estudiantes la sensación de que están siendoayudados y asistidos mientras están resolviendo un ejercicio. Además ofrecenmensajes de errores más detallados, que guían al estudiante en la búsqueda de lasolución correcta.

En la Sección 2.4 se presenta una breve revisión histórica de este tipo de herramien-tas, considerando las que se creen relevantes dentro de la evolución histórica y hacien-do especial énfasis en aquellas que pertenecen al grupo de Asistentes. Las herramientasque pertenecen a este grupo presentan un cierto grado de interactividad, proporcio-nan un feedback inmediato y permiten la autoevaluación del estudiante. Este participaen la búsqueda de la solución y la construye de forma progresiva valiéndose de lasrespuestas y/o ayudas que brindan las herramientas.

2.4. Herramientas Existentes

En la actualidad se pueden encontrar un gran número de herramientas utilizadaspara la enseñanza de lógica. Las mismas han ido evolucionando con el paso del tiempoen conjunto con el desarrollo de la informática, adaptándose a las nuevas tecnologías ymejorando con el fin de apoyar la enseñanza de la lógica y el razonamiento deductivo.La presente revisión no es exhaustiva, sino que resume algunas de las herramientasanalizadas de manera previa al abordaje del presente trabajo final.

Ditmarsc, 2009 presenta una lista de 46 herramientas de software lógico educativo,aunque la misma no abarca las contribuciones más recientes. En dicha lista es posibleencontrar por cada herramienta, el link correspondiente a sus páginas web y una bre-ve descripción (sus funciones, la plataforma sobre la que trabajan, sus desarrolladores,


etc.). Más recientemente, Huertas, 2011 presentó un análisis sobre 26 herramientas, con-siderando sólo aquellas en las que el usuario interviene de forma activa, y no aquellasque resuelven las actividades de forma automática. La autora propone una caracteriza-ción de las distintas herramientas presentadas y las clasifica según distintos criterios.

Existen trabajos muy interesantes y destacados en la historia de las herramientas ló-gicas. Es evidente, además, que se cuenta con una amplia variedad, ya sea por el conte-nido lógico que se enseña, el tipo de herramienta del que se trata, la interactividad queposeen, o incluso la plataforma sobre la que se ejecuta. A continuación analizaremosla evolución de las herramientas en el tiempo, teniendo en cuenta las característicasanteriormente mencionadas.

Dentro de este universo tan amplio de aplicaciones algunas no han seguido siendodesarrolladas, pero otras han logrado mejorar y perduran en el tiempo, adaptándosea los cambios en versiones posteriores. Uno de los casos mas destacados es «Tarski’sWorld» (Etchemendy y Barwise, 1992; Barwise y Etchemendy, 1993). Esta herramientaes útil para el aprendizaje de la sintaxis y la semántica de la lógica de primer orden, yademás posee una interfaz de usuario muy intuitiva. La herramienta surge en los añosnoventa, y aún hoy siguen desarrollándose nuevas versiones de la misma (Barker-Plummer, Barwise y Etchemendy, 2007). En la Figura 2.2 se muestra una secuencia deimágenes en la que es posible ver algunas de las antiguas versiones de la herramienta.En la misma se observa la evolución visual en la interfaz de usuario con el paso delos años, conservando la funcionalidad definida en las primeras versiones. La Figura2.2(d) refleja la ultima versión vigente (Tarski’s World V7.2.3).

(a) (b)

(c) (d)

FIGURA 2.2: Evolución histórica de la interfaz de usuario de la herra-mienta «Tarski’s World»


FIGURA 2.3: Captura de pantalla de la aplicación «Jape»

Otra herramienta importante que data de los mismos años fue «Jape» (Bornat y Su-frin, 1999). La misma permitía a los estudiantes construir, revisar y verificar derivacio-nes lógicas formales. Jape podía ser personalizada mediante la definición de un con-junto de reglas de inferencia y la definición de la sintaxis de las sentencias. Además,permitía realizar paso a paso la resolución, por lo que principiantes en el tema podíanaprender de la experimentación mediante el uso de una lógica precodificada (Figura2.3).

En simultáneo con las herramientas anteriores comienzan a surgir las primeras ver-siones de «Pandora» (Proof Assistant for Natural Deduction using Organised Rectan-gular Áreas), una herramienta para apoyar el aprendizaje de la deducción natural deprimer orden que cubre un nicho similar a aquel en el que se enfoca «Jape». En su ul-tima actualización, realizada en el año 2007 (Broda y col., 2007), el proyecto tenia unaversión web de la herramienta que registraba el uso de la misma para la posterior eva-luación de los alumnos. En la actualidad, si se accede a la página del proyecto, sólo esposible encontrar la versión standalone de la herramienta (descargando el ejecutable dela aplicación que fue desarrollado en Java).

Aproximadamente por el año 2000 comienzan a surgir los primeros proyectos deherramientas web. Páginas webs sencillas, con escasa interactividad, las cuales permi-tían al alumno desarrollar actividades definidas y además consultar el material de lostemas que trataba el curso.

Uno de los primero ejemplos dentro de está categoría es «The Logic Café» (Halpin,1995/2006), un curso que abarca los temas de la lógica clásica a través de sus distintoscapítulos. Cada capítulo posee un conjunto de tutoriales que explican el tema a trabajary una sección con actividades a realizar. Las mismas son cuestionarios con múltiplesopciones de respuestas. Cuando se completa una actividad, el alumno obtiene un feed-back instantáneo detallando en cada punto si la respuesta es correcta o no. El cursoes gratuito y el sitio web aun está en funcionamiento, pese a que fue actualizado porultima vez en el año 2006.

Otro tipo de herramientas web que surgieron en simultáneo son las aplicacionesweb demostrantes o resolvedoras, caracterizadas principalmente por ser sistemas quecalculan y muestran la solución de un ejercicio de una manera automática. «InteractiveLogic» (Burris, 1997) y «Gateway to Logic» (Zenker y col., 2011) son 2 ejemplos de este


tipo de herramientas.«Interactive Logic» es una web utilizada en la enseñanza de la lógica proposicional.

La página principal posee una lista con las diferentes secciones que representan cadauno de los temas que aborda la herramienta (Figura 2.4(a)), brindando soporte parala construcción de tablas de verdad con hasta 5 fórmulas distintas, unificación entre2 términos y la aplicación del algoritmo de Davis Putnam(Davis y Putnam, 1960) enun conjunto de fórmulas. Una de las principales falencias de esta herramienta es lafalta de libertad que posee el usuario al momento de definir los elementos con los quequiere trabajar (Figura 2.4(a)). Por ejemplo, para realizar el algoritmo de Davis Putnames necesario seleccionar las cláusulas que se encuentran definidas dentro del conjuntode combinaciones entre P , Q, R, y S (Figura 2.4(c)).

Otra web para el aprendizaje de la lógica proposicional es el proyecto «Gateway ToLogic»(figura 2.4(d)). Una de sus herramientas permite generar las formas normales ylos arboles de refutación, además de consultar por las tablas de verdad. Gateway toLogic provee soporte para escribir las fórmulas utilizando el teclado, solventando laslimitaciones que tenia el ejemplo anterior. El sitio web fue actualizado por última vezen 2014 pero algunas de las secciones de la página no funcionan.

En el año 2003 surge AProS (Automated Proof Search). El proyecto consiste en unconjunto de cinco herramientas que, integradas, se utilizan para el dictado de un cursoweb de lógica. Destacando de entre ellas «Proof Tutor» (CPT - Component Proof Tu-tor) que permite a los estudiantes solicitar consejos durante los distintos pasos de lasdemostraciones. La interfaz visual de este componente presenta en la zona central losdistintos pasos ejecutados utilizando diagramas de Fitch, un panel con las reglas bási-ca a aplicar del lado izquierdo y otro con los mensajes de ayuda sobre el lado derecho(figura 2.5).

También en 2003, aparece las primeras versiones de «Logic Couch» (Hurley, 2011;Hausman, Kahane y Tidman, 2012), el proyecto surge como una herramienta standalo-ne, que cubre gran parte de los temas de los cursos de lógica dictados en la Universis-dad Estatal de Cleveland (Cleveland State University). La herramienta consiste en unaserie de módulos donde cada uno se enfoca en algún tema en particular de la lógicano formal, clásica o simbólica. Dentro de cada módulo es posible acceder a diferentesactividades que pueden ser auto evaluadas por el alumno de forma inmediata (Figura2.6). Desde la página web de la herramienta, actualizada por ultima vez a principios delaño 2015, es posible descargar varias versiones de la misma. La diferencia fundamentalentre ellas es el libro de texto que se utiliza como material de apoyo para el dictado delcurso.

De igual manera que lo que sucedió con las herramientas standalone, las herra-mientas web evolucionaron y pasaron de ser simples resolvedores a ser chequeadoresy asistentes.

En 2006 aparece «Logic Daemon» (Allen y Hand, 2001), una web conformada porun conjunto de aplicaciones interactivas para la enseñanza de la lógica formal, don-de cada sección se enfoca en un tema en particular y cada una posee una herramientaespecifica desarrollada. Para verificar demostraciones formales y proporcionar pistasdurante la construcción de una deducción natural en lógica de predicados y LPO seutiliza «Daemon Proof Checker». Otro ejemplo es utilizar «Quizmaster», una herra-mienta que proporciona ejercicios de diferentes temas para auto evaluarse, verificandosi las respuestas planteadas son correctas o no. La pagina principal de Logic Daemonfue actualizada por ultima vez en el año 2013 y todas las herramientas aun funcio-nan. Otro proyecto similar a Logic Daemon, es «Tools for Logic» el mismo enmarca


(a) InteractiveLogic - Menú principal (b) InteractiveLogic - Tablas de Verdad

(c) InteractiveLogic - Algoritmo de Davis Putnam (d) GatewayToLogic

FIGURA 2.4: Ejemplos de primeras herramientas Webs


FIGURA 2.5: Captura de pantalla de la aplicación AProS(CPT)

FIGURA 2.6: Ejemplo de actividades «Logic Couch»


un conjunto de herramientas webs desarrolladas por un grupo de investigación mul-tidisciplinar que opera dentro del Departamento de Ciencias de la Computación de laUniversidad de Stanford para la enseñanza de la lógica, contemplando temas que vandesde la lógica de Boole, cláusulas de Horn, Unificación, modelos de Herbrand, entreotros.

En el año 2011 se comienza a desarrollar «APLI2» (APLIcaciones de Ayuda ParaLógica Informática), una herramienta utilizada en la enseñanza de las asignaturas deLógica informática y Razonamiento automático en la Universidad de Sevilla. Esta apli-cación web es un conjunto de 51 enunciados en español para que el alumno puedaformalizarlos. El nombre anterior de APLI2 es KRRT(Knowledge Representation andReasoning Tutor system)(Alonso, Aranda y Martn-Mateos, 2007).

Evaluar semánticamente una fórmula resulta complejo debido a la posibilidad dedefinir infinitos modelos arbitrarios y a que la definición del modelo afecta de formadirecta la validez de las fórmulas sobre las que se trabaja. Si bien existen herramientasque permiten experimentar el significado de la LPO en situaciones reales, las mismaslimitan la definición de modelos de acuerdo al dominio, relaciones y funciones im-plementados en cada herramienta, como en el caso de «Tarski’s World» o «Moros ycristianos». Podemos encontrar algunos otros proyectos desarrollados a lo largo de lahistoria que buscan, basándose en estas herramientas, ofrecer alternativas libres y gra-tuitas. Un ejemplo es el surgimiento en 2002 de «Tarski’s World (Java Applet)» 2.7(a).La misma es una aplicación Java que se asemeja bastante al «Tarski’s World» original.No tiene toda la funcionalidad de la herramienta original, pero posee las característicasbásicas de la misma, conservando el dominio de trabajo y reduciendo los predicadosdefinidos sobre el mismo. Otros ejemplos pueden ser FOLST (Mauco y col., 2012a) y Lo-gicChess (Mauco y col., 2012b), dos herramientas didácticas, visuales e interactivas quepermiten la evaluación sintáctica y semántica de fórmulas en modelos construidos porel usuario en el dominio provisto por cada herramienta. En el primero es posible defi-nir modelos sobre dos dominios: Mundo (el cual posee continentes y ciudades, Figura2.7(c)) y Granja (con animales y los lugares en los que se encuentran, Figura 2.7(b)), y lasegunda herramienta trabaja sobre un dominio definido por un tablero de ajedrez consus respectivas fichas (Figura 2.7(d)). Ambos proyectos incluyen la evaluación de fun-ciones definidas dentro de los respectivos dominios, además de contar con una ampliavariedad de predicados con los que trabajar. Estas herramientas fueron desarrolladaspor alumnos de tercer año de la carrera Ingeniería de Sistemas dentro de la UNICEN.

Todas las herramientas presentadas tienen como objetivo contribuir y facilitar laenseñanza de la lógica. En la mayoría de los casos son utilizadas para el apoyo del dic-tado de cursos universitarios. La interactividad con el usuario es la característica fun-damental de este tipo de herramientas, dado que se relaciona con la forma en que losestudiantes las utilizan para resolver las actividades planteadas y el tipo de respuestaque las mismas le brindan al usuario. En las herramientas analizadas en la presente sec-ción es posible observar diferentes ejemplos de ello, desde actividades bien definidas yestructuradas (por ejemplo, ejercicios con opciones de respuestas posibles como ocurreen «Logic Couch III») hasta herramientas que permiten experimentar libremente conellas, definiendo la actividad y permitiendo al usuario verificar las posibles respuestasque el mismo plantea («IDEAS»). Existen otros casos en los que las herramientas sólomuestran si la resolución planteada es correcta o no («Jape» ó «Tarski’s World»). Otrasademás brindan mensajes de error que orientan al estudiante en la búsqueda de la so-lución correcta, como es el caso de «Apros (CPT)», o incluso existen herramientas queagregan la posibilidad de guiar durante el desarrollo de la actividad y especificar másaun la respuesta, explicando de forma detallada por que se cometió determinado error


(a) Tarski’s World (Java Applet) (b) FOLST - Dominio Granja

(c) FOLST - Dominio Mundo (d) LogicChess

FIGURA 2.7: Ejemplos de herramientas para evaluar semánticamente enLPO.

(«Logic Daemon»).Se observa además que muchas de las herramientas existentes están diseñadas para

cubrir los contenidos de un curso («Apros») o un libro en particular («Tarski’s World»,«Interactive Logic»). Con respecto a los temas lógicos sobre los que se trabaja, las herra-mientas generalmente abarcan la Lógica Proposicional («Logic Daemon») o la Lógicade Predicados, en particular la deducción natural («Natural Deduction», «Pandora»),las tablas de verdad («Interactive Logic»), las formas normales («IDEAS», «LogEx»),los arboles de refutación («Tree Proof Generator») y la formalización de sentencias(«APLI2»). Es notoria la poca variedad de herramientas que trabajen sobre la semánticaen la Lógica de Predicados de Primer orden y la evaluación de modelos definidos so-bre la misma. A continuación, se presenta un resumen comparativo entre algunas de lasherramientas existentes relevadas. En la tabla 2.1 se indica: el nombre de las herramien-tas; el año en el que surgen y el año de su ultima actualización; el tipo de herramientaque son: resolvedores, chequeadores o asistentes (utilizando la clasificación definida enla Seccion 2.3); las temáticas que abarcan; y el tipo de plataforma: S.A. (Standalone oaplicación de escritorio) o WEB. En la tabla 2.2 se continua la tabla comparativa ante-rior indicando: las funcionalidades implementadas por cada herramienta y el tipo defeedback ofrecido por cada una.


TABLA 2.1: Tabla comparativa de herramientas existentes. Se indica el nombre de laherramienta, el año de publicación, el tipo de herramienta ([R] Resolvedor, [C] Che-

queador, [A] Asistente), las temáticas que abarca y el tipo de plataforma.

Tipo PlataformaHerramientas Año R C A Contenido S.A. WEBTarski’sWorld 1997/2015 x x

Lógica de predicados(Semántica) x

JAPE 1999/2012 x xLógica proposicional y depredicados (DeducciónNatural)

x

Pandora 1996/2007 x xLógica proposicional y depredicados (DeducciónNatural)

x -

ADN 2000/2003 x xLógica proposicional y depredicados (DeducciónNatural)

-

The LogicCafé 1995/2006 1

Lógica en general(predicado yproposicional, otros)

x

InteractiveLogic 1997/2003 x

Lógica proposicional(Tablas de verdad,Unificación,Davis-Putnam)

x

Gatewayto Logic 1996/2010 x

Lógica proposicional (FN,Tablas de verdad,Arboles de refutación)

x

Tarski’sWorld(JavaApplet)

2002 xLógica de predicados(Semántica - Similaral Tarski’s World)

x

Apros(CPT) 2003/2010 x x

Lógica proposicional y depredicados (demostraciónde axiomas)

x -

LogicCouch III 2003/2015 x

Logicade Predicados (Fromalizacion ,Silogismos, Tablas de verdad)

x

LICS webtutor 2004 2 Lógica en general (predicado

y proposicional, otros) x

Tree ProofGenerator 2004/2015 x

Lógica proposicional y depredicados (Validezutilizando demostraciónpor arboles)

x

LogicDaemon 2006/2013 x x

Lógica proposicional y depredicados (DeducciónNatural, Modelosde Contra Ejemplo)

x

IDEAS 2007 x x FND xLogica(Tools forLogic)

2009/2015 xLógica (Boole, Formaclausular, Unificación,Herbrand, otros)

x

NaturalDeduction 2010/2015 x x

Lógica Proposicional(Deducción Natural) x

APLI” 2011 x Formalizacion xFolst yChest 2012 x x

Lógica de predicados(Semántica) x

Truth tables 2013 xLogicaProposiciona (Tablas de verdad)

3

1 Libro online interactivo para la enseñanza de la Lógica. Capítulos, tutoriales y actividadesauto evaluadas.

2 Actividades con preguntas de multiple-choice auto evaluadas. Actividades agrupadas porcapítulos.

3 “Truth tables” es una aplicación para celulares con Android, descargable desde Google Play


TABLA 2.2: Continuación de la tabla comparativa de herramientas exis-tentes presentada en la Tabla 2.1. Se indica la funcionalidad implemen-

tada y el tipo de feedback ofrecido por la herramienta.

Feedback

Herramientas FuncionalidadVerifica

ResultadosMensajede Error

AsistenciaAdicional

Tarski’sWorld

Evaluar sentencias deLPO (no funciones) x x

JAPEGuia paso a paso en lacontruccion de demostracionesformales

x x

PandoraGuia en la construccion dela deduccion natural,aplicando reglas

x x

ADNConstruccion dedemostraciones formales x x

The LogicCafé

Ejercicios y multiple-choicesauto evaluables x

InteractiveLogic

Seleccionar opciones yverificar si son correctas. x

Gatewayto Logic

Escribir formulas y verel resultado solicitado x

Tarski’sWorld(JavaApplet)

Evaluar sentencias deLPO (no funciones) x

Apros(CPT)

Construcción de demostra-ciones utilizando diagramasde Fitch

x x x

LogicCouch III

Resolver actividadesy verificarlas x x

LICS webtutor

Cuestionarios multiple-choiceauto evaluables x x

Tree ProofGenerator

Verifica validez deuna formula x

LogicDaemon

Guia en la construccion,ofrece ayuda en todas lasetapas

x x x

IDEASGuia en la construccionde la forma normal x x x

Logica(Tools for Logic)

Conjunto de herramientasresolvedoras x x

NaturalDeduction

Genera la solucion overifica la propuesta. x x

APLI”Actividades. Formalizarfrases y razonamientos x

Folst yChest Evaluar sentencias de LPO x xTruth tables Genera las tablas de verdad x

Capítulo 3

LogicWorld: La HerramientaDesarrollada

En este capítulo se detalla la solución propuesta a la problemática descripta en laSección 1.1. En la Sección 3.1 se introduce al lector sobre temas generales, los cualesabarcan desde conceptos tecnológicos hasta algunas de las pautas de usabilidad em-pleadas. El proyecto consiste en dos aplicaciones principales: Una aplicación del tipoasistente para la enseñanza/aprendizaje de la LPO que se ubica del lado del cliente(Sección 3.2) y un servidor encargado de realizar el procesamiento de la información,analizando la validez de un conjunto de sentencias de forma automática (Sección 3.3)Para cada uno de los componentes que intervienen, se describe el diseño de interac-ción, así como las características más importantes de su arquitectura y las tecnologíasempleadas en su implementación.

3.1. Introducción

La herramienta desarrollada en este trabajo, posee las siguientes características:

1. Permite modelar problemas de semántica de Lógica de Predicados de Primer Or-den, proporcionándole al usuario un marco que encapsula los diferentes elemen-tos necesarios para realizar dicha tarea (denominado frame de aquí en adelante);

2. además, la interfaz de usuario es intuitiva y posee un alto grado de interactividad.El usuario utiliza los diferentes botones y componentes para definir una instanciaespecífica del dominio de trabajo (definiendo un modelo) y escribir un conjuntode sentencias sobre las cuales quiera evaluar su validez;

3. la interacción con el usuario al momento de utilizar la herramienta, se dará através de alguno de las modelos lógicos (frames) previamente definidos. Cadauno de los frames está asociado a una interfaz visual independiente con respectoa los otros modelos;

4. por último, la herramienta posee un motor de inferencia que determina la validezde una sentencia definida en un determinado modelo, y proporciona mensajes deerror detallados que guían al usuario en la búsqueda de la solución correcta.

3.1.1. Tecnología Utilizada

La herramienta se desarrolló como una aplicación web. Esta decisión se tomó alconsiderar los diferentes aspectos mencionados cuando se realizó el relevamiento delas herramientas existentes (Sección 2.4) y debido a las ventajas asociadas a este tipo

23

24 Capítulo 3. LogicWorld: La Herramienta Desarrollada

FIGURA 3.1: Arquitectura cliente-servidor utilizada en el diseño de lasolución propuesta. El usuario interactúa con el cliente, mientras que el

procesamiento de los datos es llevado a cabo en el servidor.

de aplicación. Una de las más importantes, es la portabilidad (dado que funciona encualquier plataforma que cuente con un navegador de Internet). Una aplicación deeste tipo puede ser ejecutada en cualquier dispositivo (computadora, tablet, teléfonocelular, etc.) independientemente del sistema operativo que posea, y generalmente norequieren instalaciones ni descargas de componentes para su uso. Otra ventaja es queeste tipo de aplicaciones poseen un alcance global y pueden ser distribuidas de formasencilla, dado que basta con acceder a una URL en Internet para utilizarlas. Dado quesu funcionamiento depende de recursos web, una de las mayores limitaciones asocia-das a este tipo de aplicaciones es su dependencia de Internet.

3.1.2. Especificación General del Diseño

Si bien la aplicación desarrollada toma como base el análisis de las diferentes he-rramientas existentes (presentado en la Sección 2.4), en esta primera etapa, se pretendecaracterizar también los diferentes tipos de modelos, para que éstos puedan ser defini-dos en forma dinámica. Se plantearon diversos ejemplos donde las semánticas difierenunas con otras, buscando atributos y comportamientos en común con el objetivo deabstraerlos. La idea es identificar los diferentes componentes que conforman un mo-delo. Además, es necesario contemplar la evaluación y verificación de sentencias enlos diferentes modelos futuros a definir. Al no tener a priori definidos dichos modelos,la verificación es realizada mediante un motor de inferencia que permite parametrizardichas definiciones.

En la siguiente etapa, se considerarán los diferentes aspectos y características pro-pios del desarrollo de la herramienta: arquitectura Web implementada, frameworksy/o tecnologías utilizadas, estructura de componentes, interfaz visual, modos de pre-sentación de la información, entre otros. Cada uno de estos puntos es desarrollado enmayor detalle en las secciones correspondientes más adelante.

En términos generales, la aplicación cuenta con las siguientes características:

está conformada por un sitio de Internet a través del cual es posible acceder a laaplicación web (con su respectiva interfaz visual), y un servidor que se encargade verificar la validez de las diferentes sentencias (Figura 3.1).

la web posee una estructura de navegación jerárquica. El usuario accede a la apli-cación a través de una página principal o home page que enlaza los diferentes

Capítulo 3. LogicWorld: La Herramienta Desarrollada 25

(a) Estructura de navegación web - Jerarquia (b) Componentes del Servidor

FIGURA 3.2: En el cliente se define cómo se desenvuelve el usuario den-tro del sitio Web: accede a un frame a través del home y vuelve al homepara cambiar de frame. En el servidor se identifican dos componentesindependientes que interactúan entre si, la lógica de negocio y los pro-

tocolos de comunicación

contenidos permitiéndole navegar de forma clara y simple entre los diferentesframes (Figura 3.2(a));

la página principal es el acceso por defecto a la herramienta, siendo el puntode partida desde el cual el usuario estructura su recorrido. El home page poseeinformación del sitio (un texto que introduce al usuario) y los vínculos hacia lasdiferentes versiones de la aplicación web (los diferentes frames cargados);

la aplicación siempre es la misma, su funcionalidad y las zonas donde se ubicanlos diversos elementos son independientes del frame seleccionado para trabajar.Se puede considerar que cada frame genera una ’instancia’ de la aplicación, en laque cambian los elementos a visualizar dentro de la página web;

dentro del servidor se encuentra un componente encargado de determinar la vali-dez de una sentencia (motor de inferencia). Dicho componente puede ser conside-rado como una pequeña aplicación independiente, que nuclea esta funcionalidadespecifica (Figura 3.2(b));

dentro del servidor web, también se encuentran definidos un conjunto de módu-los (denominados servidor de aplicación) que se encargan de realizar la adminis-tración del servidor en si mismo, y además de intermediario entre el motor deinferencia y el front-end (la aplicación web).

3.1.3. Arquitectura

Al definir el proyecto como una aplicación web, el mismo responde a una arquitec-tura cliente-servidor (Berson, 1996). Este modelo de aplicación distribuida, involucradiferentes procesos que se comunican entre sí a través de un sistema en red. Dichosprocesos son clasificados según sus acciones: clientes (consumidores de información)o servidores (productores de información). La red cliente-servidor es una red de co-municaciones en la cual varios clientes (computadoras) están conectados a un servidor


(host), en el que se centralizan los diversos recursos y aplicaciones con que se cuenta;la separación entre cliente y servidor es una separación virtual, donde el servidor noejecuta necesariamente un solo programa. Conceptualmente, el servidor brinda servi-cios de manera transparente a los clientes, mientras que el cliente es quien pide y recibedichos servicios a través de aplicaciones de usuarios.

En una aplicación web es posible considerar al navegador de Internet como el clien-te, dado que al acceder a un sitio web se le está solicitando al servidor el código delmismo para descargarlo y ejecutarlo. El servidor procesa los datos de la lógica de laaplicación y el cliente se encarga de la visualización de la información generada. Alser una aplicación, la comunicación es ida y vuelta, el usuario utiliza la interfaz visualpara generar nueva información y retro alimentar al servidor con el fin de procesarla yobtener una nueva respuesta.

Las arquitecturas de este tipo de aplicaciones han evolucionado mucho con el pasode los años. La diferencia principal es si el cliente y/o el servidor son dinámicos oestáticos:

Cliente estático/Servidor estático - El navegador visualiza la página con estilosCSS e imágenes (no se utiliza JavaScript). Cuando se utiliza un link se carganlas páginas por completo. Bajo esta arquitectura se encuentran las primeras paái-nas web diseñadas, aquellas en las que el servidor siempre devuelve los mismosrecursos.

Cliente estático/Servidor dinámico - Un ejemplo de esta arquitectura es cuandose utiliza una arquitectura de 3 capas para definir tanto al cliente como al servi-dor: el navegador de Internet es la capa de presentación, el servidor es la capa delógica de negocios y además se tiene una base de datos como la capa de datos. Elservidor genera de forma dinámica la página web a mostrar dependiendo de laejecución de un código o de los resultados de una consulta a la base de datos.

Cliente dinámico/Servidor estático - En estos casos el cliente es dinámico debi-do a que incorpora código JavaScript que se ejecuta en el navegador. Este códigosuele ser utilizado para realizar efectos gráficos (menús desplegables, mostrar uocultar información de forma dinámica, páginas adaptables a distintas resolucio-nes, etc).

Cliente dinámico/Servidor dinámico - En está arquitectura, el código JavaScripten el cliente se utiliza para realizar efectos gráficos y para realizar peticiones alservidor en segundo plano a través de funciones AJAX. Cuando se obtiene unresultado de una petición AJAX, es posible actualizar sólo aquellas partes de lapágina necesarias, evitando tener que recargarla por completo. Un caso particularde esta arquitectura son las Single Page Application, en donde existe una únicapágina cuyo contenido va cambiando según el usuario interactúa con la interfazvisual que se le proporciona.

La aplicación web desarrollada responde a una arquitectura de Cliente dinámico yServidor dinámico.

Arquitectura Interna del Cliente

El cliente es una Single Page Application con API REST. El diseño del mismo respon-de a una arquitectura MVC (Model View Controller) y está basado en los paradigmas de


FIGURA 3.3: Arquitectura MVC dentro del Cliente, conformada por unconjunto de controladores, modelos y vistas. El usuario interactúa con laaplicación a través de las vistas que se le muestran en el DOM (DocumentObjet Model, estructura de objetos jerárquica que se genera dentro del

navegador cuando se carga un documento .html)

la programación guiada por eventos (Chandy, 2006) para la interacción entre los dife-rentes componentes del sistema y la comunicación entre la interfaz con los diferentescontroladores (Figura 3.3).

La Figura 3.4 muestra un diagrama de componentes UML de la aplicación, donde esposible observar las distintas partes que la conforman. El componente HomePage se en-carga de las funcionalidades y presenta la vista de la página de inicio de la aplicaciónweb. El componente Editor (descripto en mayor profundidad en la Subsección 3.2.4)encapsula los modelos, vistas y controladores utilizados para generar los frames y pre-sentarle al usuario las vistas mediante las cuales define y evalúa problemas de LPO.Por último, el componente Router es utilizado para administrar la navegación dentrode las diferentes vistas de la aplicación. Dentro de este componente se definen las di-ferentes rutas para navegar en la parte del cliente (administra dos vistas principales: ladel HomePage y la del Editor). La vista que se muestra dentro del editor varía en funciónde los parámetros que conforman la ruta.

Arquitectura Interna del Servidor

El diseño del servidor responde a una arquitectura de capas. En este tipo de diseño,el objetivo que se prioriza es la separación de funcionalidades, donde cada nivel estátotalmente abstraído de cómo trabaja internamente el resto de los niveles y para lacomunicación entre los mismos basta con conocer la interfaz (API) que existe entredos niveles aledaños(Eckerson, 1995). El más utilizado actualmente es el diseño en trescapas, donde las mismas corresponden a: capa de presentación, capa de negocio y capade datos.

La Figura 3.5 muestra un diagrama de componentes UML del servidor, en el cuales posible observar las capas definidas y los componentes que las conforman. Es im-portante remarcar que, en la arquitectura de nuestra aplicación, no se utilizó la capa


FIGURA 3.4: Diagrama UML de Componentes del Cliente. La aplicaciónconsta de dos vistas principales, el home y el editor(herramienta para mo-delar los problemas de LPO). El Router administra qué vista mostrar en

función del sitio web que selecciona el usuario

FIGURA 3.5: Diagrama de Capas del Servidor. La capa de presentaciónse encarga de administrar la comunicación entre cliente y servidor, mien-tras que la capa de negocios se encarga de la lógica (validar una sentencia

en un modelo)


de datos dado que el mismo no implementa persistencia (es decir, que no almacenaningún tipo de información).

La capa de presentación es la encargada de capturar y enviar la información a los di-ferentes clientes. En las aplicaciones REST, el cliente no recibe el código HTML desde elservidor. En su lugar, recibe un conjunto de datos en algún formato estándar (ej: JSONo XML), y es el cliente quien se encarga de darle formato y visualizar esa información.En una aplicación de este estilo, se necesita que el servidor permita el intercambio deinformación hacia y desde el cliente de forma sencilla. Considerando la complejidaddel conjunto de información con los que trabaja la herramienta es necesario especificarestructuras u objetos que puedan ser serializados a través de HTTP en formato JSON oXML. La capa de negocio está conformada únicamente por el subsistema denominadomotor de inferencia, el cual es el encargado de realizar la validación de una sentencia.Tal y como fue mencionado en el párrafo anterior, el servidor no cuenta con una capade datos, debido a que el mismo no almacena ningún tipo de información.

El componente FrontController administra las peticiones de los diferentes clientes,mientras que el componente Controller se encarga de: mapear los diferentes endpointsdefinidos dentro de la aplicación y ejecutar el código correspondiente, decodificandoel mensaje de entrada, ejecutar las acciones definidas y enviar la respuesta al cliente.Por último, el componente Model define la estructura que posee un mensaje desde elcliente para que el Controller pueda parsear los mensajes.

3.1.4. Pautas de Usabilidad para el Desarrollo de una Aplicación Web

Al momento de realizar el diseño de una página o una aplicación Web, la usabili-dad es uno de los requerimientos fundamentales a tener en cuenta. La usabilidad estárelacionada a la facilidad de uso, y a cuan práctica y simple resulta la interacción conla aplicación.

El hecho de que una aplicación cumpla con el cometido para el que fue diseñada,no implica que la misma sea fácil de entender por parte de los usuarios. Aunque esposible diseñar entornos visualmente atractivos, esto no implica necesariamente que laforma en la que se presenta la información sea útil, clara o incluso accesible para losusuarios.

Existen múltiples guías de usabilidad y documentación que plantean algunos prin-cipios básicos que deben tenerse en cuenta para el correcto desarrollo de un proyectocon un alto grado de usabilidad (Nielsen, 1994; Nielsen, 2000; Nielsen y Loranger, 2006;Maniega-Legarda, 2006). Algunos de los más importantes son:

La Facilidad del Aprendizaje, representando cómo los nuevos usuarios interac-túan con la Web, siendo capaces de familiarizarse y utilizarla de forma rápida.

La Facilidad de Uso, representando la facilidad con la que se utiliza la Web, bus-cando que sea de la manera más natural posible.

La Flexibilidad, determinado por la variedad de formas en las que un usuariopuede interactuar con la Web, contemplando diferentes alternativas para realizarlas mismas funciones y la similitud que puede existir con otros desarrollos queposean funcionalidades similares.

La Robustez, garantizando la disponibilidad de la Web.

Existen otros factores que influyen de manera significativa en la usabilidad de unsitio web: la organización de la información; la velocidad de carga y procesamiento;


los colores utilizados; el minimalismo, considerando el uso de imágenes y la cantidadjusta de animaciones; la adaptabilidad a diferentes resoluciones y a los distintos tiposde navegadores de Internet; el tipo y tamaño de letra a utilizar; entre otros.

3.1.5. Interacción entre los Usuarios y la Solución

A continuación se describe la interacción deseada de los diferentes usuarios de laherramienta con la solución propuesta: el proceso comienza cuando un usuario docen-te define la semántica; para ello especifica el dominio, los atributos de sus elementos,los predicados y las funciones que definen al modelo lógico. Una vez generados losarchivos de configuración, se debe agregar el nuevo frame definido al sitio web que alo-ja los distintos frames. Una vez realizada la carga de los archivos de configuración, seprocede a incorporar el link correspondiente a la página principal. Luego, los usuariosestudiantes pueden acceder a la página principal (home page) de la web y seleccionarcon cuál de los frames desean trabajar. Cuando un usuario estudiante selecciona un de-terminado frame (entre las opciones cargadas previamente) se le presenta una interfazvisual que le proporciona todas las herramientas necesarias para modelar y validarproblemas de semántica de LPO correspondientes al frame seleccionado.

3.2. Aplicación Web

En esta sección se describen los requerimientos funcionales y no funcionales de laaplicación. Se introduce al lector en la tecnología utilizada, para luego presentar endetalle el diseño y la implementación de los componente principales y los subcompo-nentes que conforman la aplicación web.

3.2.1. Requerimientos

A nivel funcional, la aplicación web debe:

1. permitir al usuario estudiante ingresar al editor seleccionando alguno de los fra-mes de LPO previamente cargados.

2. permitir al usuario especificar un nuevo modelo (instancia particular del dominiodefinido dentro de un frame) de forma visual;

3. permitir al usuario agregar nuevos elementos al modelo, sobre los cuales es posibledefinir el tipo y qué valores de los atributos posee;

4. permitir eliminar elementos existentes;

5. permitir editar los elementos existentes, modificando nombre y los atributos de-finidos;

6. visualizar el nombre de los diferentes elementos existentes;

7. permitir mover o reubicar los diferentes elementos;

8. permitir al usuario escribir sentencias en LPO, utilizando el teclado;

9. permitir al usuario validar una cantidad variable de sentencias;


10. visualizar el resultado de la verificación de las sentencias, permitiendo identificarcuando las mismas son válidas, falsas o poseen algún error;

11. visualizar el mensaje de error, en caso de que lo hubiese, en cada una de las sen-tencias;

12. por último, también permitir la incorporación de nuevas definiciones de frames(definir nuevas semánticas para otro tipos de modelos).

A nivel no funcional:

1. su uso debe ser intuitivo, el usuario debe poder comprender de forma inmediatadónde se encuentran los diferentes modelos que puede utilizar y cómo funcionael editor (usabilidad);

2. ser accesible, el usuario puede acceder a cualquiera de los modelos definidos através de la web principal;

3. ser agradable para los usuarios (usabilidad);

4. ser visualizado y funcionar correctamente en distintos navegadores (portabili-dad).

5. el tiempo de respuesta debe ser aceptable para el usuario. Es decir, el usuario nodebe percibir el tiempo que pasa entre que se solicita la verificación y se visualizala respuesta (performance, usabilidad);

6. no se tiene que modificar el código de la aplicación cuando se incorpora la defi-nición de un nuevo modelo (adaptabilidad);

7. su código debe ser libre.

3.2.2. Implementación e Integración

Teniendo en cuenta que se optó por realizar una aplicación web, a continuaciónse procede a detallar las diferentes tecnologías utilizadas. En la Figura 3.6 se puedeobservar un cuadro que resume y clasifica las mismas.

En primer lugar, definimos la tecnología y lenguaje de implementación utilizadospor el cliente. De las alternativas que se pueden seleccionar existen un conjunto deestándares web, definidos por el W3C (World wide Web Consortium 1), que todo navega-dor debe implementar, y también existe un conjunto de tecnologías no estándar parala construcción de aplicaciones. El desarrollo de la aplicación se realiza en HTML5 porser un lenguaje nativo y estándar para la generación de páginas web. HTML5 es el úl-timo estándar del lenguaje de hipertexto HTML, el cual en realidad es una familia detecnologías:

HTML: es el lenguaje de modelado semántico que permite estructurar la infor-mación en secciones, párrafos, título, imágenes y otras etiquetas.

JavaScript: es el lenguaje de programación que permite agregar interactividad.

CSS: es el lenguaje que le da estilos al diseño gráfico de HTML, el cual permiteagregarle estética y capacidad visual (colores, tipos de letras, fondos, efectos, etc).

1Sitio web de W3C: https://www.w3.org/


FIGURA 3.6: Tecnologías del Cliente - Se resume las tecnologías utiliza-das agrupadas en categorías dependiendo de su funcionalidad.

En comparación, las otras alternativas descartadas fueron:

Adobe Flash (no estándar) - Es una tecnología utilizada principalmente para ge-nerar contenido multimedia interactivo en las páginas web. Es una tecnología ce-rrada, propietaria (gratis para los usuarios, pero algunas características de desa-rrollo son pagas) y además es considerada ineficiente. Para la ejecución de losdesarrollos en está tecnología es necesario tener descargado Flash Player (comple-mento de flash para el navegador).

Applets de Java (no estándar) - Los applets de Java fueron los precursores de Flash.Su performance suele ser más baja. Hace varios años que esta tecnología se en-cuentra en desuso.

Microsoft Silverlight (no estándar) - Esta tecnología surgió como la alternativacompetitiva de Microsoft a Adobe Flash. Posee un soporte muy limitado en plata-formas diferentes a Windows.

Por otra parte, fue necesario definir la estructura de la aplicación. Para ello, existenmúltiples frameworks de alto nivel que estructuran una aplicación web de forma com-pleta. Los tres más populares al momento de comenzar el desarrollo son: Angular.js2,Backbone.js3 y Ember.js4. Estos son de código abierto, están basados en JavaScript y seutilizan para el desarrollo de aplicaciones web ’single page’ utilizando el patrón de di-seño MV* (Modelo-vista-*). Todos poseen componentes que representan vista, eventos,modelos de datos y enrutamiento. A continuación se presentan algunas de las princi-pales diferencias que poseen:

2Sitio web de Angular.js: https://angularjs.org/3Sitio web de Backbone.js: http://backbonejs.org/4Sitio web de Ember.js: http://emberjs.com/


Backbone.js es ligero y no ocupa mucho espacio, tiene una excelente documen-tación, su código es simple y además posee una única dependencia (para su fun-cionamiento sólo es necesario incorporar la librería de utilidades Underscore.js).Posee una curva de aprendizaje muy chica (si se posee algo de experiencia conjQuery y Unhderscore.js), debido a que no existe mucha diferencia entre desarro-llar en JavaScript con y sin la utilización del framework.

Angular.js posee una enorme popularidad, es el framework de JavaScript quegana si se compara el tamaño de la comunidad de usuarios que lo utilizan, y con-forme mayor sea el tamaño de ésta es más fácil encontrar ejemplos y ayuda paradesarrollar con él. Por otro lado, posee una curva de aprendizaje algo abruptay muchos de sus conceptos claves (como directivas o servicios) no poseen unaexplicación clara y sencilla de entender para usuarios con poca experiencia. Ladocumentación oficial es poco clara y además está orientada a usuarios experi-mentados en la herramienta.

Ember.js funciona bajo el principio de Convention over Configuration (convencio-nes de nombres en lugar de configuraciones), lo que permite al framework asu-mir de forma automática muchas tareas que en otros tienen que ser desarrolladaspor el programador. Como consecuencia directa de esto, el framework posee unaestructura muy rígida. Es necesario aprender cómo funciona internamente el fra-mework (o al menos una parte del mismo) antes de poder empezar a trabajarcon el. Además, en sus últimas versiones se realizaron muchos cambios sobre elproyecto, por lo que mucha de la información que se encuentra en Internet estádesactualizada.

Se escogió utilizar Backbone.js ya que al comenzar el proyecto no se poseía expe-riencia previa y la webapp es de un tamaño pequeño/mediano. Sin embargo, debidoa la simplicidad de dicho framework, se decidió incorporar una librería que permi-ta facilitar el desarrollo. De las diferentes alternativas existentes se optó por utilizarMarionette.js5. Marionette es una librería para aplicaciones web, complementaria aBackbone que simplifica y mejora la construcción de aplicaciones JavaScript, incorpo-rando funciones y utilidades. Entre todas las mejoras que ofrece esta librería podemosdestacar: modificaciones a los tipos de vistas que se definen en el proyecto, la posibi-lidad de definir regiones para poder organizar mejor la visualización de las vistas y laincorporación de controladores al patrón de diseño que utiliza Backbone (Completandoel patrón de diseño MVC). Backbone en conjunto con Marionette proporcionan un mar-co sobre el cual organizar el código. El modelo conserva el estado de la aplicación yproduce eventos al ser modificado, de forma que la vista se pueda actualizar indepen-dientemente para ambos. La vista proporciona la interfaz del controlador a través delque se modifica el modelo de forma adecuada. De esta manera, todos los elementosestán relacionados pero cada uno posee una funcionalidad bien definida.

Además, se utilizaron otras tecnologías durante el desarrollo de la aplicación web.Se utiliza jQuery6, una librería que ofrece facilidad de uso, potencia y compatibilidadentre navegadores para funcionalidades basadas en JavaScript. Es utilizada general-mente para gestionar la interfaz y para realizar peticiones AJAX en conjunto con jQuer-yUI7, una librería de componentes para JQuery que le añaden un conjunto de interac-ciones, comportamientos, widgets y efectos visuales para la creación de aplicaciones

5Sitio web de Marionette.js: http://marionettejs.com6Sitio web de jQuery: https://jquery.com/7Sitio web de jQueryUI: https://jqueryui.com/


FIGURA 3.7: Pantalla principal del sitio web

web. En cuanto a manejo de CSS, se utiliza Bootstrap8, una librería desarrollada porTwitter que simplifica el proceso de creación de diseños Webs (maquetado).

La comunicación entre el cliente y el servidor se realiza a través de llamados AJAXen el formato JSON (JavaScript Object Notation9), el cual es fácil de leer y escribir paralas personas y de generar y parsear para las computadoras.

El entorno de desarrollo utilizado fue el editor de texto Atom, una herramientaOpen Source desarrollada por Github. Para realizar el control de versiones se utilizóGIT10, un sistema de control de versiones distribuido de código abierto, en conjunto conGithub el cual es un servicio para alojamiento de repositorios de software gestionadospor el sistema de control de versiones Git.

Por último, para organizar todas estas herramientas se utiliza Bower11 y Grunt12 enconjunto con npm13. Bower es un gestor de paquetes para desarrollo web en el ladodel cliente el cual funciona con Git y utiliza además repositorios de GitHub. Por otrolado, Grunt permite configurar tareas automáticas y gestionar dependencias entre otrasfuncionalidades. Así, es posible ahorrar tiempo durante el desarrollo y despliegue deaplicación web.

3.2.3. Componente Home-page

La vista de la página principal se implementó utilizando HTML y JavaScript, enconjunto con CSS para el maquetado visual, siendo estas tecnologías el estándar actualpara el desarrollo de una página Web.

8Sitio web de Bootstrap: http://getbootstrap.com/9Sitio web de JSON: http://www.json.org/

10Sitio web de GIT: https://git-scm.com/11Sitio web de Bower:https://bower.io/12Sitio web de Grunt :http://gruntjs.com/13Sitio web de npm: https://www.npmjs.com/


El lado del servidor, es el que almacena y suministra la información de la páginaweb. Debido a que el mismo no posee funcionalidades complejas (sólo tiene que ad-ministrar las peticiones de información del cliente) se utilizó Node.js 14. Node.js es unentorno de programación en la capa del servidor basado en el lenguaje de programa-ción JavaScript, con Entrada/Salida de datos en una arquitectura orientada a eventos,que permite construir un servidor HTTP básico, de fácil desarrollo e implementación.

Para la estructura de la página web, se priorizó un diseño simple, de tal formaque la navegación del mismo sea intuitiva y sencilla para el usuario. En la Figura 3.7se muestra una captura de la pantalla principal. Allí es posible observar cómo estáorganizado el esquema de distribución de los elementos (layout). El diseño de la páginaweb consiste en una cabecera, un cuerpo y un pie de página. El contenido del cuerpo sepresenta mediante un diseño de columna simple centrada horizontalmente. Si el anchode la pantalla supera el ancho establecido de la región de contenidos, los márgenes delos costados se agrandan.

La pantalla principal presenta una introducción al proyecto y, más abajo, muestrauna lista con los diferentes tipos de modelos (frames) con los que el usuario puedetrabajar.

3.2.4. Componente Editor

La Figura 3.8 muestra un diagrama de componentes UML del Editor, donde es posi-ble observar los distintos subcomponentes que lo definen. Cada uno de los componen-tes responden a una arquitectura MVC y posee una funcionalidad específica. El compo-nente logicWorld se encarga de realizar la ”comunicación” con el servidor para analizarla validez de las diferentes sentencias. Además, también se relaciona con el compo-nente sentencias, encargado de administrar la definición de sentencias; el componenteelementos, encargado de administrar los elementos que forman parte de la instancia deldominio y; el componente frame es el encargado de la funcionalidad asociada al tablerode trabajo donde se define un dominio. Por otro lado, el componente frame se comunicacon el componente elementos debido a que a partir de la vista del primero se crean losnuevos elementos y se modifican los elementos ya instanciados.

Desde otro punto de vista, en la Figura 3.9 es posible distinguir las diferentes regio-nes de la interfaz gráfica que se le presenta al usuario. El objetivo es definir la estructurade la página, en la cual se distingue la cabecera (<Región 1>) y una zona de conteni-dos (<Region 2>). Las diferentes vistas que forman parte de la aplicación poseen unaregión específica identificada con un número dentro de la figura, y es en dicha regióndonde cada vista es dibujada.

A continuación se desarrolla de forma más detallada cada uno de los diferentessubcomponentes especificados y se profundiza respecto a la asociación que existe entrelas regiones y las vistas.

Componente LogicWorld

El componente logicWorld contiene el módulo logicWorld.controller, encargado de ad-ministrar e inicializar los otros componentes, y el módulo logicWorld.view, el cual gene-ra la interfaz visual. La vista de este componente se muestra en la <Región 2> dentro dela Figura 3.9 y es dentro de esta región que se dibujan las otras vistas. Este componenteno posee un modelo (módulo de datos), debido a que su visualización es independientede la semántica a mostrar y no posee información que sea necesario instanciar.

14Sitio web Node.js: https://nodejs.org/


FIGURA 3.8: Diagrama UML de Componentes dentro del Editor. Cadauno de ellos implementa la arquitectura MVC, agrupando funcionalidad

relacionadas

En la Figura 3.10 se muestra un diagrama UML de paquetes de la aplicación delcliente, dentro del paquete app es posible ver las diferentes clases que conforman almódulo de logicWorld.

El componente logicWorld posee una fuerte dependencia del archivo semantica.config.Si bien dicho archivo no es necesario para la visualización y la interacción del estudian-te con la herramienta, resulta fundamental al momento de realizar la verificación de lavalidez de las diferentes sentencias escritas. Dentro del archivo de configuración seencuentra la definición formal de la semántica que implementa la interfaz visual.

Componente Sentencias

Una sentencia está definida por un identificador, el texto que especifica la sentenciaen sí misma, un valor de verdad si es que ya fue evaluada y un mensaje de error en casode que la misma esté mal definida. Todos estos elementos forman parte de la definiciónde la clase sentencia.model ya que ésta encapsula la información propia de una sentencia.Cada vez que se agrega una nueva sentencia se define una nueva instancia de la clasesentencia.model.

La aplicación permite evaluar más de una sentencia en simultáneo, por lo que sedefine una colección de sentencias (sentencias.collection) para agruparlas en una mismaestructura en forma de lista.

La clase sentencias.controller es el controlador del componente encargado de admi-nistrar la comunicación interna entre los módulos y hacia afuera con los otros compo-nentes.

La clase sentencia.template consiste en una plantilla o template en código html quedefine como se van a mostrar los datos almacenados en la clase sentencia.model. La clase


FIGURA 3.9: Regiones de la interfaz visual del Cliente. (1) cabecera de laweb; (2) área del cuerpo o contenido de la web; (3) región asociada a laescritura de sentencias; (4) región del componente frame, diferenciandoun menú de botones (4.1) de la pizarra de trabajo (4.2); (5) inserción de

un elemento

sentencia.template es fundamental debido a que permite definir variables que son ins-tanciadas utilizando un modelo (los datos) y mostrarlos en la vista.

Por último, están las dos clases correspondientes a las vistas (sentencia.view y collec-tion.view). Así como sentencia.controller agrupa en una colección las diferentes instanciasde los modelos, es posible decir que collection.view agrupa las diferentes instancias delas vistas asociadas a cada uno de esos modelo. La vista de la colección en conjunto conlas vistas de las sentencias que la componen se dibujan en la <Región 3> dentro de laFigura 3.9.

Componente Frame

El componente frame encapsula las vistas y la lógica asociadas a la generación deherramientas utilizadas por el usuario para crear elementos y definir la instancia de undominio. Dentro de este componente es posible identificar dos módulos que están fuer-temente relacionados. Por un lado, un menú que permite al usuario definir o editar unelemento. Por el otro, una pizarra sobre la que se agregan y reposicionan los diferenteselementos agregados. Estos dos módulos son administrados por un único controlador(la clase frame.controller).

El menú esta conformado por dos clases. La clase panel.template y la clase panel.view,este módulo no define una clase que estructure los datos debido a que instancia laplantilla por medio de la configuración establecida en el archivo panel.config. En dichoarchivo de configuración se especifican las imágenes a mostrar, la lista de posibles ele-mentos a definir y los atributos que éstos poseen. La vista del panel de herramientas (eldenominado menú) se dibuja en la <Región 4.1> dentro de la Figura 3.9. Por cada tipode elemento se genera una nueva pestaña y dentro de cada pestaña es posible accedera botones desplegables que facilitan la elección de las diferentes opciones que presentacada atributo.


FIGURA 3.10: Diagrama UML - Paquetes dentro del Cliente

La pizarra de trabajo (<board>) está conformada por un modelo (board.model), unaplantilla (board.template) y la vista correspondiente (board.view). Consiste en una imagenque se le muestra al usuario, sobre la que es posible posicionar elementos. La imagendefine el contexto y el lugar donde se coloca un elemento modifican los atributos deestos. La vista de la pizarra (board.view) se dibuja en la <Región 4.2> dentro de la Fi-gura 3.9. Se definen dos tipos de board posibles: aquellos que utilizan la posición x ey como un par para definir un atributo dentro de los elementos (por ejemplo, el boardGranja); y aquellos que manejan las coordenadas de posición relativas como atributospor separado, es decir utilizan la posición x para definir un atributo y la posición y pa-ra definir otro (por ejemplo: el board de un tablero, donde se poseen los atributos filay columna). Dentro de este módulo, el archivo de configuración board.config define laimagen que se muestra como fondo en la vista, el tipo de atributo que se define a travésde la posición (si se trabaja con las coordenadas tomándolas de a par o por separado) ylos valores que debe tomar el o los atributos definidos.

Componente Elementos

Un elemento está definido por un conjunto de atributos, algunos de los cuales yase encuentran preconfigurados por defecto y otros pueden ser personalizados cuandose define una semántica. De los primeros es posible decir que todo elemento, indepen-dientemente del frame al que pertenezca, poseen: un tipo (es un chancho, una gallina,un auto u otro tipo); un nombre (el cual lo distinga de los otros elementos que confor-man el dominio); una imagen (que se utiliza para poder mostrarlo gráficamente); y unpar de coordenadas que lo posicionan dentro del board. Por lo tanto, se interpreta queun atributo es una variable que toma un valor de una cantidad dada de opciones posi-bles. La clase elemento.model encapsula todos estos atributos, los definidos por defectoy los definidos dinámicamente.


FIGURA 3.11: Pantalla del Editor - Sin seleccionar un frame. Se muestrala vista del editor sin cargar una semántica, es por ello que no se ven los

elementos posibles a instanciar ni el fondo sobre el que se trabaja.

Los elementos agregados dentro del board tienen la particularidad de ser objetosque pueden ser arrastrados dentro de la pizarra de trabajo. Cuando se crea una nuevainstancia de la clase elemento.view la misma se agrega en la esquina superior izquierdadentro de la <Region 4.2> y mediante la utilización del cursor puede ser reposicionada.Además, el tamaño de la región que ocupa cada una de las diferentes vistas de loselementos queda determinado de forma directa por el tamaño de la imagen asociadaal modelo (datos) correspondiente.

La plantilla utilizada para mostrar los elementos (elemento.template) define los datosdel modelo que se le presentan visualmente al usuario, en la vista de un elemento semuestra la imagen que lo define, un botón para eliminarlo, el nombre que lo distingue,y un campo editable para modificar dicho String.

Como en los otros componentes, la clase elementos.controller es el controlador en-cargado de administrar la comunicación (interna y externa), la clase elementos.collectiones utilizada como una estructura mediante la cual se agrupan los diferentes elementosinstanciados que conforman la instancia del dominio, y la clase collection.view es la vistaque agrupa las diferentes instancias de la clase elemento.view

Archivos de Configuración

En la Figura 3.11 se observa una imagen de la aplicación que no posee definidolos respectivos archivos de configuración. Para que la aplicación muestre la semánticade un modelo requiere de los tres archivos que aparecen como dependencias dentrodel diagrama UML de componentes ( Figura 3.4 ). El archivo semantica.config define eltipo de dominio, las funciones y los predicados con los que se puede trabajar en undeterminado frame. El archivo board.config define el fondo del panel de trabajo y losatributos que éste modifica dentro de los elementos. Por último, el archivo panel.configdefine el menú que se muestra sobre el panel de trabajo mediante el cual se generannuevos elementos. En la Figura 3.10 se ve un directorio denominado modelos, dentro delmismo se define una carpeta por cada frame distinto implementado y dentro de cadauna se encuentran los tres archivos de configuración y las imágenes necesarias paravisualizar el modelo.


3.2.5. Usabilidad

Además de las pautas presentadas en la Sección 3.1.4, se tuvieron en cuenta lassiguientes cuestiones especificas:

Se apuntó a un diseño minimalista sin gráficos pesados. El mismo posee estilovisual y un formato de contenido estandarizado;

Dentro de la aplicación se maneja un lenguaje con el que el usuario está acos-tumbrado, con términos cotidianos y comprensibles utilizando también la mismaterminología que se utiliza en la cátedra.

Se utilizaron colores que son fácilmente interpretables al momento de definir laiconografía. Por ejemplo, el ícono que representa el resultado de una verificaciónes de color rojo para falso, ícono verde para verdadero e ícono amarillo para loscasos en los que ocurre un error.

Se definió una estructura de contenido que agrupa funcionalidades y contenidorelacionado, de esta forma se pretende que la aplicación sea intuitiva y no requie-ra de un proceso de aprendizaje para ser utilizada eficientemente. Por ejemplo,diferentes componentes que trabajan en conjunto se encuentran enmarcados porun borde.

Se procuró no utilizar pop-ups como medio de notificación de mensajes entre laherramienta y el usuario. Por ejemplo: cuando el usuario realiza una verificación,el resultado se le presenta modificando un ícono al lado de cada sentencia; si unasentencia tiene un error, el mensaje sólo se muestra si se pasa el cursor sobre lasentencia en cuestión.

Se intentó minimizar la cantidad de texto y en su lugar utilizar logos e iconos quesean representativos y fácilmente interpretables. Por ejemplo, para eliminar unasentencia basta con hacer clic en el cesto de basura a su derecha; para eliminar unelemento se hace clic en la cruz roja que aparece al pasar el cursor sobre él.

Cuando el usuario hace un clic en los diferentes botones, pestañas, inputs u otrotipo de elementos, los mismos se resaltan visualmente. Mediante esto se está pro-veyendo al usuario de feedback, en el sentido de que puede ver qué componenteposee seleccionado o cuál utilizó por última vez.

Con el fin de no complicar la escritura de las sentencias, se le proporciona al usua-rio una botonera que posee los caracteres especiales (los cuales se insertan en laposición del cursor dentro de la sentencia que está en foco). Además, se definie-ron alternativas a dichos caracteres especiales, para que una sentencia tambiénpueda ser escrita utilizando como elemento de entrada únicamente el teclado.

Se pretendió presentar una interfaz lo más limpia y simple posible, para ello seintentó no sobrecargar con la información y con las posibilidades de acción queposee el usuario. Por ejemplo, el mensaje de error en una sentencia verificada yel botón para eliminar los elementos sólo son visibles si se pasa por arriba delos mismos. Así también, se comprende que algunas cosas siempre deben estarvisibles al usuario. Por ejemplo, los nombres de los elementos instanciados.

Se debe permitir el acceso a la página de inicio desde cualquiera de los diferentesmodelos dada la estructura del sitio (para cambiar la semántica con la que se está


trabajando es necesario regresar a la página de inicio). Por ello, se hizo que seretorne al home page cuando se hace click en el logo de la herramienta.

Durante el desarrollo de la aplicación se utilizó el navegador Google Chrome,pero la misma también fue testeada en Mozilla Firefox e Internet Explorer paraasegurar su correcto funcionamiento.

3.3. Servidor

En esta sección se describen los requerimientos funcionales y no funcionales delservidor. Se introduce al lector en la tecnología utilizada, para luego presentar los com-ponentes principales que lo conforman detallando el diseño e implementación de losmismos.

3.3.1. Requerimientos

A nivel funcional, la aplicación servidor debe:

1. permitir trabajar con diferentes semánticas y sentencias;

2. permitir evaluar la validez de una sentencia en un modelo (generado a partir deun frame pre definido);

3. generar, en el caso de que una sentencia posea algún error, un mensaje de errorque permita identificarlo;

4. permitir instanciar los diferentes tipos de elementos que pueden conformar unmodelo, valiéndose de la representación de los mismos mediante un archivo deconfiguración;

5. permitir instanciar de forma dinámica diferentes predicados y funciones, los cua-les pueden variar en cantidad de atributos (argumentos);

A nivel no funcional:

1. debe ser capaz de analizar las sentencias en un tiempo aceptable, reduciendo laespera de la respuesta a menos de 5 segundos (eficiencia).

2. el motor de inferencia debe proporcionar mensajes de error que sean informativosy orientados al usuario (usabilidad).

3. debe proveer mecanismos bien definidos que permitan interactuar con los otroselementos del sistema (interoperabilidad);

4. debe poseer una documentación en la que se explique cómo se interpretan losarchivos de configuración que especifican la definición de una semántica;

5. debe proveer la posibilidad de que un usuario del lenguaje JAVA extienda la fun-cionalidad de los subcomponentes que lo conforman (extensibilidad).


FIGURA 3.12: Diagrama de Componentes y Capas del Servidor. Presen-ta los subcomponentes que lo conforman, cómo interactúan y las depen-

dencias que los mismos poseen

3.3.2. Capa Presentation

Para el desarrollo del servidor se utilizó Spring MVC, un framework para el desa-rrollo de aplicaciones Java basadas en web, que responde al patrón de diseño MVCdentro de la capa de presentación. La Figura 3.12 muestra el diagrama de Componen-tes UML.

El componente FrontController define un punto de entrada único a nuestras peticio-nes desde los diferentes clientes. De esta manera, todas las peticiones que se le realizanal servidor pasan por dicho componente, el cual se encarga de gestionar la lógica inter-na. El componente Controller, administra las peticiones y mapea la información recibiday a enviar en los diferentes objetos lógicos. Además, es el encargado de comunicarsecon el motor de inferencia (ubicado en la capa siguiente). Por último, el componentemodel encapsula las diferentes estructuras a través de las cuales el cliente puede comu-nicarse con el servidor. Cuando el cliente se comunica con el servidor, éste le envía: ladefinición de una semántica, la instancia específica de un modelo (frame) y un conjuntode sentencias. El servidor mapea cada uno de estos mensajes en una estructura interna.

3.3.3. Capa Business

El Motor de inferencia que se encuentra dentro de la capa de negocios, se desarrollóen el lenguaje Java, utilizando el entorno de desarrollo Netbeans 8.0. Este lenguaje seeligió principalmente debido a la portabilidad que provee, y debido a la simplicidadpara extender los diferentes componentes que lo conforman. Además, se contaba conexperiencia previa en el lenguaje de programación. El diseño está basado en el para-digma de programación orientada a objetos (Jacobson, 1992) para la modelización delas sentencias, de los modelos y su contenido.

El componente en cuestión hace uso de dos bibliotecas externas:


FIGURA 3.13: Pre proyecto - Generación de AL y AS. Utilizando las li-brerías correspondientes, y valiéndose de los archivos que especificanlas reglas, se generan las clases Java necesarias que luego son importa-

das dentro del proyecto del Motor de Inferencia.

JSON-Simple 15 biblioteca ligera de Java para la manipulación de texto en forma-to JSON que posee pleno cumplimiento de la especificación JSON (RFC4627) 16.Esta proporciona un conjunto de herramientas que permiten, de forma simple,codificar, decodificar y parsear texto en JSON. Los archivos de configuración quedefinen la semántica de un modelo se especifican en dicho formato.

CUP 17 es un generador de analizadores sintácticos para JAVA, que permitió sim-plificar en gran medida la manipulación de las sentencias, para su posterior aná-lisis de validez. El uso de esta librería implica la especificación de una gramáticajunto con la construcción de un escáner (<Analizador Léxico>) capaz de leer loscaracteres de entrada y generar los tokens correspondientes (palabras claves, nú-meros y símbolos especiales).

Adicionalmente, y en una instancia previa, se realizó un pequeño proyecto encarga-do de la generación de un analizador léxico (AL) y un analizador sintáctico (AS). Estasclases son independientes de la semántica utilizada en los diferentes modelos. Dichoproyecto utilizó el generador de analizadores léxicos JFlex 18, en conjunto con el genera-dor de analizadores sintácticos CUP. Este pequeño proyecto también fue desarrolladoen el lenguaje Java utilizando el IDE Netbeans. A grandes rasgos utiliza como entradados archivos: uno que especifica los diferentes Tokens a reconocer por el analizadorléxico y otro que define la gramática (especificación del analizador sintáctico) y generacomo salida las clases Java requeridas (Figura 3.13). Para una descripción completa delos archivos utilizados como entrada para la generación de ambos analizadores, con-sultar los Apéndices A y B respectivamente.

La Figura 3.14 muestra el diagrama de paquetes UML del componente. El paque-te LexicoySintactico transforma una entrada de texto en una estructura de datos (unainstancia de una Fórmula) que posteriormente será procesada para analizar su validez.En simultáneo, mientras se realiza la construcción de dicho objeto, se analizan algu-nos de los posibles errores que pueden ser detectados en esta etapa. La validez de unaFórmula se analiza en función de un determinado modelo y es el paquete Modelado elque define los componentes necesarios para realizar una representación interna de unframe (instancia de un dominio). Además, proporciona un objeto que encapsula toda

15Sitio Web del proyecto JSON: https://code.google.com/archive/p/json-simple/16JSON specification : http://www.ietf.org/rfc/rfc4627.txt17Sitio Web del proyecto CUP: http://www2.cs.tum.edu/projects/cup/18Sitio Web del proyecto JFlex: http://jflex.de/


FIGURA 3.14: Diagrama UML de Paquetes - Motor de inferencia

la información de un error en las sentencias y provee las funcionalidades necesariaspara poder evaluar la validez. Por otro lado, el paquete Generadores es el que permitedefinir diferentes tipos de modelos a partir de los archivos de configuración especifica-dos en formato JSON. A continuación se describe cada uno de los diferentes paquetesdesarrollados.

Paquete Fórmula

En la Figura 3.15 se presenta un diagrama de clases del paquete Fórmula, con elobjetivo de mostrar su composición y las relaciones entre las clases. El mismo modelala estructura de una fórmula en LPO, como un árbol descendente recursivo.

La interfaz Fórmula es la clase principal (o clase base) dentro de la jerarquía, la mis-ma define que toda fórmula puede ser verificada, independientemente de qué subclasela implemente. Al verificar una fórmula en un determinado dominio es posible obtenerel valor de verdad de la misma. De las clases que implementan la interfaz es posiblediferenciar: por un lado aquellas que incorporan operadores lógicos y cuantificadoresa una sentencia (compuestas por otras Fórmulas) de los Predicados (compuestos por Tér-minos).

Por otro lado es posible definir dos tipos de Términos: Variable o Función. Un Tér-mino, a diferencia de una Fórmula, es evaluado. Cuando se evalúa una variable se ve-rifica que la misma forme parte del dominio (ya sea porque se analiza la dependenciacon un cuantificador o porque en realidad resulte ser una constante). Cuando se evalúa


FIGURA 3.15: Diagrama UML de Clases - Paquete Formula

FIGURA 3.16: Ejemplo de una formula y su estructura de árbol asociado

una función, se obtiene como resultado el elemento que la cumple, es decir, se con-sulta al modelo por la constante que está asociada a dicha función con determinadosargumentos.

Paquete LexicoySintactico

Como su nombre lo indica, este paquete encapsula las clases encargadas de realizarel análisis léxico y sintáctico. El analizador léxico recibe una secuencia de caracteres yproduce una salida compuesta de tokens (componentes léxicos); esos tokens son proce-sados por el analizador sintáctico para construir una estructura de datos o representa-ción interna que corresponda con la sentencia analizada (generalmente una estructuracon forma de árbol). Las clases definidas dentro de este paquete toman como entradauna formula lógica escrita como una secuencia de caracteres y generan una instanciade una Fórmula equivalente (Figura 3.16).

En el caso de la clase Aléxico, lee los caracteres uno a uno desde la entrada (el stringque define la sentencia a verificar) y va formando los diferentes tokens definidos. Es-ta etapa puede ser comprendida como una máquina de estados finitos. Esta máquina


contiene la información de las posibles secuencias de caracteres que puede conformarcualquier token que sea parte del lenguaje (en nuestro caso la definición de una sen-tencia en LPO). De igual forma, se encarga de encontrar los errores léxicos que se pue-den detectar durante la construcción de dichos tokens. Por ejemplo, el nombre de unafunción siempre debe estar escrito en letras mayúsculas y por otro lado el id de unavariable siempre es escrito con letras en minúscula. Si el analizador léxico detecta unacadena de caracteres consecutivos que en el centro de la misma posee algún número,como dicha cadena no corresponde con ninguno de los tokens definidos, reporta unerror léxico.

El analizador sintáctico (la clase ASintactico) toma como entrada los diferentes to-kens detectados y los agrupa siguiendo un conjunto de reglas, comprobando que elorden en que le son entregados es válido. Además, en simultáneo construye una es-tructura para el análisis posterior. Las reglas que describen la estructura sintáctica delos elementos que queremos detectar pueden especificarse por medio de una gramáticalibre de contexto. Esta gramática define dicha estructura (especificando una sentenciabien formada en LPO) aceptando lo que es válido sintácticamente y rechazando lo queno lo es. Por ejemplo, un cuantificador (universal o existencial) siempre es seguido deun token que define el Id de una variable; los tokens que representan a los parénte-sis siempre se utilizan de a pares, y siempre se utiliza primero uno de apertura paradespués encontrar un token de cierre. Con respecto a la construcción en simultáneode la estructura de datos, cada una de las reglas de la gramática define algún tipo dedependencia entre los elementos que las conforman. Por lo tanto es posible estableceruna asociación uno a uno entre las reglas de la gramática y las clases definidas en el pa-quete Fórmula. Cada vez que una regla es aceptada se genera una instancia de la claseasociada con los diferentes parámetros establecidos en dicha regla.

Por último, la clase sym define un enumerado que representa todos los diferentestokens que puede llegar a detectar el analizador léxico y recibir el analizador sintáctico.

Paquete Relaciones

El paquete Relaciones contiene las clases abstractas Verificador y Evaluador, de estasclases heredan las que se ven en la Figura 3.17. Estas son utilizadas para modelar lospredicados y las funciones. Una función se evalúa y retorna como resultado un elemen-to del dominio, mientras que un predicado se verifica, retornando un valor de verdad.

Un Verificador se utiliza para consultar el valor de verdad del predicado que éste re-presenta, pasando como parámetro a la función verificar los argumentos cada vez que selo utiliza. Todo predicado se define como una composición de las clases que extiendena Verificador. Por un lado están aquellos que comparan un valor con otro valor; y porel otro, están aquellos que a través de conectores lógicos relacionan el resultado de losanteriores. La cantidad de predicados posibles a definir en un frame está limitada por lacombinatoria entre comparaciones simples, operadores lógicos, cantidad de atributosde los elementos y opciones de valores que pueden tomar dichos atributos.

Por otro lado, un Evaluador se define instanciando sólo una de las clases que lo im-plementan. Las funciones, dentro de un modelo, tienen que ser totales, es decir dadoun elemento del dominio, una función deberá devolver (siempre) otro elemento deldominio. Por esta particularidad se optó por definir un conjunto de funciones pre es-tablecidas, que puedan ser utilizadas en cualquier modelo de forma independiente delframe definido. Para ello se utiliza un atributo que todo frame posee, la posición relati-va dentro del tablero de trabajo y la proximidad que posee un elemento con los otros.Cuando se define la semántica de un modelo es posible determinar si se desea que el


FIGURA 3.17: Diagrama UML de Clases - Paquetes Relaciones. Se obser-va la jerarquía de las diferentes clases que lo conforman. Un verificadorsimple compara atributos, uno compuesto opera entre dos verificadores

y un evaluador instancia algunas de las posibles funciones.

mismo posea alguna, ninguna o todas las ”funciones” que implementan la clase Eva-luador.

Paquete Generadores

En el paquete Generadores se encuentran dos clases, EstructuraElemento y Estructu-raModelo, las cuales son utilizadas por la clase Modelo para completar las tareas relacio-nadas con la verificación y evaluación de las sentencias y términos durante el análisisde una sentencia.

EstructuraElemento se utiliza para definir de forma dinámica cómo están conforma-dos los diferentes elementos que pertenecen al dominio de un frame. Una instancia deesta clase está conformada por los nombres de los atributos que posee un elemento ylas opciones que pueden tomar cada uno de ellos.

EstructuraModelo (Figura 3.18) es una estructura que encapsula la definición de lasemántica de un modelo. Para ello, hace uso de la biblioteca Json-simple para poderdecodificar (parsear) el archivo que la define. Además, hace uso del paquete Relacionespara instanciar los distintos predicados y funciones que pueden ser utilizados. Interna-menta la clase está compuesta por tres mapas: los predicados, las funciones y los tiposde elementos (instancias de EstructuraElemento).

Algunas de las funcionalidades que la clase posee, son: la posibilidad de consultar siun predicado o una función pertenecen al frame; un método que permite solicitar unafunción o un predicado específico para que el Modelo lo pueda utilizar; y un métodopara solicitar la estructura de un tipo de elemento (por ejemplo, usada para ver si laopción de un atributo es valida o no).


FIGURA 3.18: Clase Estructura. Un objeto estructura se instancia a partirde la definición de una semántica y encapsula las diferentes partes que

la definen

Paquete Modelado

Este paquete encapsula las clases necesarias para modelar un problema de LPO.Dentro del mismo se encuentra la clase ErrorM, que define los posibles errores quepueden ocurrir durante la evaluación de una sentencia. Por otro lado, la clase Modeloes la composición de dos objetos: la instancia de una estructura (utilizada para definir lasemántica del modelo) y una lista de ElementoM (utilizada para instanciar un frame, esdecir, la instancia de un dominio particular). El modelo es el objeto que verifica las sen-tencias, evalúa las funciones, verifica los errores de aridad, analiza que los elementosestén bien definidos, etc.

El algoritmo de evaluación de una sentencia está basado en el presentado en Ger-vasoni y col., 2012, adaptando el mismo para trabajar con las estructuras propias delpresente desarrollo y además contemplando la definición dinámica de diferentes fra-mes. La estrategia consiste en realizar un recorrido post-orden de la estructura formula,la cual representa a una sentencia a verificar. Durante el recorrido primero se evalúanlos términos, para posteriormente verificar los predicados que los contienen, y másadelante se aplican los diferentes operadores lógicos de los distintos nodos hasta llegaral elemento raíz de la estructura. Cuando uno de los nodos de la estructura define uncuantificador, se repite el recorrido post-orden en el subárbol que cuelga de él. La va-riable cuantificada se instancia con diferentes valores del dominio a hasta que: si es uncuantificador existencial, se encuentra un elemento que lo haga verdadero o se terminade analizar todo el dominio; si es un cuantificador universal, hasta que se encuentrauno que lo haga falso o se analizan todos los elementos del dominio.

Capítulo 4

Instanciación del Framework

El framework desarrollado puede ser utilizado para definir el comportamiento bá-sico de diferentes modelos.

Para comprobar las capacidades del framework se decidió implementar algunosde los frames, tomando como base las herramientas similares que fueron relevadas enla Sección 2.4. El primer frame implementado es la Granja (Sección 4.2), el cual corres-ponde a la herramienta FOLST (Mauco y col., 2012a). El segundo frame, denominadoFiguras Geométricas (Sección 4.3), está inspirado en el popular Tarski’s World de la Uni-versidad de Stanford (Barker-Plummer, Barwise y Etchemendy, 2007).

4.1. Estrategia Basada en Archivos de Configuración

Al momento de definir un nuevo frame, no es necesario desarrollar nuevo código, nimodificar el código preexistente. Además, el programa resultantes es mucho más claro,ya que se asegura que toda la configuración se encuentra en un único lugar y fácilmen-te localizable. No obstante, la mala implementación de este método puede acarrearinconvenientes importantes que tienen que ser considerados, como por ejemplo quelas especificaciones terminan siendo archivos complejos y muy largos.

La definición y configuración de un nuevo frame a incorporar en la aplicación Webse distribuye en varios archivos según su propósito. Los archivos contienen diferentesobjetos JSON, los cuales a su vez encapsulan los diferentes parámetros u opciones deconfiguración. Algunos de los parámetros pueden ser definidos mediante contenidopersonalizado, mientras que otros son seleccionando una de varias opciones a utilizarque proporciona el framework. En las siguientes subsecciones se muestran los diversosarchivos de configuración analizando la especificación y la funcionalidad de cada uno.

4.1.1. Configuración de un Nuevo Frame

Para la especificación de un nuevo frame dentro del proyecto es necesario crear lossiguientes archivos de configuración :

Panel.config.json: es el archivo que utiliza la clase panel.view dentro de laaplicación para generar un menú (botonera) sobre el panel de trabajo. Este menúse utiliza para permitir al usuario definir y editar un elemento del dominio de unmodelo. El archivo especifica botones, atributos y opciones relacionados con loselementos de un determinado frame.

Board.config.json: contiene la definición del panel de trabajo. Además es elarchivo que especifica el tipo de board a utilizar: si el fondo está dividido en zonas(la posición x e y definen un atributo dentro de los elementos) o si se trabaja comoun tablero (el valor de x e y definen cada uno un atributo distinto dentro de los

49

50 Capítulo 4. Instanciación del Framework

elementos). En la Subsección 4.1.2 se incluye una descripción detallada sobre estetema.

Semantica.config.json: se trata del archivo que incluye la especificación se-mántica de un frame. Contiene la información que define el dominio, los predica-dos y las funciones, necesarios para evaluar las diferentes sentencias. La Subsec-ción 4.1.3 muestra en detalle la composición de este archivo.

Los archivos de configuración antes mencionados tienen que ser definidos dentrodel directorio logicWorld/mimodelo. Además, las diferentes imágenes necesarias pa-ra la visualización del modelo definido tienen que ser ubicadas dentro del directoriomimodelo/img.

La configuración se distribuye entre: la especificación de una semántica (utiliza-da para la validación dentro del servidor); la configuración visual de la aplicación (aldefinir los archivos necesarios para el frame.view); y por último los archivos de ayudapropios del frame especificado.

4.1.2. Configuración Visual de la Aplicación

La configuración visual de la aplicación es una de las partes más importantes detoda la configuración. Mediante la especificación de estos archivos se define qué ele-mentos se le van a presentar al usuario por medio de las correspondientes vistas de laaplicación. La configuración se distribuye entre dos archivos, Panel.config.json yBoard.config.json.

Configuración de la Pizarra de Trabajo

La primer configuración corresponde al archivo Board.config.json.

FIGURA 4.1: Archivo de configuración del Board - Código de configura-ción del archivo JSON

1 {2 "boardModel": {3 "img": "<mimodelo>/images/<imagen_fondo.png>",4 "img_mascara": "<mimodelo>/images/<mascara_fondo.png>",5 "tipo": "zona"6 },7 "boardMap": {8 "R<##>G<##>B<##>": "<zona1>",9 "R<##>G<##>B<##>": "<zona2>",...

10 }11 }

En la Figura 4.1 se muestra el código de un Board de tipo zona. Dentro del mismo,se puede observar que los String notados entre “ <> ” son los que el usuario docentepersonaliza. En el código se observa la definición de dos objetos JSON. El primero(linea 2 ) define: la ruta relativa de la imagen que se muestra al usuario como fondo enel panel de trabajo; la imagen utilizada como una máscara para detectar las diferenteszonas definidas para la imagen; y además especifica que el board es de tipo zona. Elsegundo objeto JSON (linea 7) lista las zonas que identifica la máscara en función delcódigo de color RGB con el que está pintada.

Capítulo 4. Instanciación del Framework 51

FIGURA 4.2: Fragmento del código - representación del Board tipo Ta-blero

4 ...5 "tipo": "tablero"6 },7 "boardMap": {8 "R<##>G<##>B<##>": {9 "<atributoA>": <ValorA1>,

10 "<atributoB>": <valorB1>11 },12 "R<##>G<##>B<##>": {13 "<atributoA>": <ValorA2>,14 "<atributoB>": <valorB2>15 },16 ...

En la Figura 4.2 se muestra el fragmento de código que es distinto cuando el boardes de tipo tablero. Se modifica el segundo objeto dentro del archivo de configuraciónespecificando, en este caso, dos atributos por color definido dentro de la máscara. Porejemplo, si la imagen es un tablero del estilo de ajedrez, en la máscara cada uno delos diferentes cuadrados está pintado con un color distinto y en boardMap los atributoscorresponderían con las filas (atributoA) y las columnas (atributoB) del mismo.

Configuración del Panel de Trabajo

Dentro de la definición de un frame se especifica una cierta cantidad de tipos deelementos. El usuario estudiante deberá instanciarlos al momento de generar el do-minio del modelo. Estos tipos encapsulan los diferentes atributos, sus respectivos va-lores y además poseen una imagen asociada. Por cuestiones de simplificación se op-tó por que cada posible combinación entre tipo de elemento y atributo-valor poseauna imagen asociada que lo representa visualmente. El código dentro del archivo Pa-nel.config.json es el que define lo mencionado anteriormente (Figura 4.3). Dentrodel mismo, se puede observar que los String notados entre “ <> ” son los que el usua-rio docente personaliza.

En el código de la Figura 4.3 se identifican 4 objetos JSON distintos, los cuales sedetallan a continuación:

elements (linea 2) está conformado por una lista de tipos de elementos. Cada unode los nodos de la lista define un tipo en particular, especificando: un identifica-dor; el tab al que hace referencia; y por último una imagen que se corresponda conel tipo definido. El tab utilizado en la definición de los nodos de esta lista (ej: linea4) tiene que coincidir con algunos de los definidos dentro de la lista tabs(linea 15).

tabs (linea 14) también es una lista, pero en este caso, los nodos definen los atri-butos que posee un tipo de elemento que hace referencia a él. Un atributo esdefinido mediante la especificación de un nombre y una lista de opciones (va-lores posibles que dicho atributo puede tomar). El id utilizado en cada uno delos nodos de la lista tabs, coincide con un TipoDominio especificado en el archivoSemantica.config.json el cual define los mismos atributos.

map (linea 26) es un mapa que indexa cada una de las posibles combinacionesentre tipos y opciones con la imagen que le corresponde.


keys (linea 32) es una lista que se utiliza para generar las claves del índice mapde forma dinámica dentro de la aplicación. En el mismo se especifican los dife-rentes Strings (atributos) a concatenar y el orden de los mismos para generar lasdistintas claves posibles.

FIGURA 4.3: Archivo de configuración del Panel - Código de configura-ción del archivo JSON

1 {2 "elements": [3 {4 "ref": "<tabs-x>",5 "id": "<tipo1>",6 "img": "<mimodelo>/images/<imagen_tipo1.png>"7 },8 {9 "ref": "<tabs-x>",

10 "id": "<tipo2>",11 "img": "<mimodelo>/images/<imagen_tipo2.png>"12 }...13 ],14 "tabs":15 [{ "id": "<tabs-x>",16 "att":17 [ { "name": "<att1>",18 "opciones":19 [ {"estado": "<valor1>"},20 {"estado": "<valor2>"},...21 ]22 }...23 ]24 }...25 ],26 "map": {27 "<tipo1valor1>": "<mimodelo>/images/<imagen1.png>",28 "<tipo1valor2>": "<mimodelo>/images/<imagen2.png>",29 "<tipo2valor1>": "<mimodelo>/images/<imagen3.png>",30 "<tipo2valor2>": "<mimodelo>/images/<imagen4.png>", ...31 },32 "keys": [33 "tipo",34 "<att1>"35 ]36 }

4.1.3. Configuración de la Semántica

Inicialmente los frames no poseen una configuración semántica propia y es por elloque la definición del archivo Semantica.config.json es una dependencia necesa-ria del Motor de Inferencia (componente del servidor). Como se puede suponer, este


archivo de configuración también se encuentra en el directorio logicWorld/mimodelojunto con los otros.

FIGURA 4.4: Archivo de configuración Semantica - Código de configu-ración del archivo JSON

1 {2 "Elemento": [3 { "TipoDominio": "<d1>",4 "ListAtributos": [5 { "Atributo": "tipo",6 "Opciones": [ "<tipo1>", "<tipo2>", ...]7 },8 { "Atributo": "zona",9 "Opciones": ["<zona1>","<zona2>", ...]

10 },11 { "Atributo": "<atributoA>",12 "Opciones": ["<valorA1>", ...13 ]14 }, ...15 ]16 }17 ],18 "Funcion": [19 { "Rename": "<nombreFuncion1>",20 "Class": "ElMasLejano"21 }, ...22 ],23 "Predicado": [24 { "NombrePred": "<nombrePredicado1>",25 "CantParam": <#>,26 "Componentes": [27 //-- clase del predicado --//28 //-- pos del parametro a utilizar --//29 //-- atributos u opciones a comparar --//30 ]31 }, ...32 ]33 }

En la Figura 4.4 se observa parte del código del archivo Semantica.config.json cuando el frame utiliza un Board de tipo Zonas. El archivo JSON se utiliza paraespecificar tres listas distintas: la lista Elementos (linea 2), la lista Funciones (linea 18) yla lista Predicados (linea 23), donde cada una encapsula la información necesaria paradefinir los componentes correspondientes. Para facilitar la comprensión del mismo, sereemplazó una fracción del código (la especificación de los componentes dentro de lospredicados) por un comentario, el código reemplazado se explica en una subsecciónaparte (Subsección 4.1.3).

Un nodo de la lista Elementos está definido por el tipo de dominio al que pertenece(d1), y los atributos que lo definen (ListAtributos). Los diferentes tipos de elementos a


definir, que posean los mismos atributos dentro de un frame, comparten el tipo de do-minio. Dentro de la lista de atributos se detallan todos los atributos que un elementopuede poseer: los tipos de elementos (definidos dentro de Panel.config), las dife-rentes zonas (definidas dentro de Board.config) y el resto de los atributos. Por otrolado, cuando el frame a definir es de tipo tablero, en lugar del atributo zona se utilizanlos nombres de los atributos especificados en el archivo Board.config correspon-diente.

La lista opciones, además de definir los valores que puede tomar un atributo tambiénlos “enumera". Es por ello que el orden en el que los mismos son definidos es algoque el usuario docente debe tener presente. Sin profundizar demasiado en el tema, seaclara que dentro de la especificación de los predicados se comparan valores numéricos(posiciones dentro de la lista) en lugar de las palabras que la componen.

La lista de las Funciones es utilizada para incorporar o no las funciones implemen-tadas dentro de la aplicación. Además puede utilizarse para renombralas.

Los nodos de la lista de Predicados encapsulan el nombre que los identifica (Nombre-Pred), un número entero que equivale a la cantidad de argumentos con los que se utilizaal predicado (CantParam) y un objeto JSON denominado componentes mediante el cualse especifica la lógica interna del predicado definido, explicado con mayor detalle en laSubsección siguiente.

Configuración de Predicados

Dentro de la configuración de un predicado se especifica: el nombre, la cantidadde argumentos y las Componentes del mismo. Las Componentes de un predicado definencómo se utilizan los diferentes argumentos. Es una lista de objetos JSON, en dondecada uno de sus nodos se corresponde con una clase que implementa la clase abstractaVerificador (Subsección 3.2.4).

En la Figura 4.5 se puede observar cómo está definida la lista de Componentes cuan-do el predicado a especificar utiliza una clase Simple. En este caso puntual, el predicadocompara que los supuestos dos argumentos (linea 4) posean el mismo valor dentro delmismo atributo; comparando utilizando un verificador de IGUAL(linea 6).

FIGURA 4.5: Fragmento de Código JSON - Componentes de un Predica-do Simple comparando atributos

1 {2 ...3 { "NombrePred": "<nombrePredicado1>",4 "CantParam": <2>5 "Componentes": [6 { "Clase":"<IGUAL>",7 "ParametroI":<0>, "AtributoI":"<atributo>",8 "ParametroD":<1>, "AtributoD":"<atributo>"9 }]

10 },...11

12 }

En la Figura 4.6 se muestra cómo cambia la especificación del nodo dentro de lalista Componentes si en lugar de comparar los valores de dos elementos se compara elvalor de un elemento con una opción en particular.


FIGURA 4.6: Fragmento de Código JSON - Componentes de un Predica-do Simple comparando un atributo con un valor

1 {2 ...3 { "NombrePred": "<nombrePredicado2>",4 "CantParam": <1>5 "Componentes": [6 { "Clase":"<IGUAL>",7 "ParametroI":<0>, "AtributoI":"<tipo>",8 "ParametroD":<#>, "AtributoD":"_constante"9 }]

10 },...11

12 }

La diferencia principal entre esta especificación y el ejemplo anterior se observaen la linea 8. Al comparar el valor de un atributo con un valor específico, el segundoparámetro termina siendo una constante (especificado mediante el String “ _constante”). Además, el “ <#> ” corresponde a la posición del valor específico a comparar dentrode la lista de opciones cuando se define el atributo en cuestión.

Los nodos dentro de la lista Componentes previamente explicados hacen referenciaa las clases simples (Menor, Mayor o Igual). Para la especificación de predicados máscomplejos, en los que intervienen las clases compuestas (And y Or), se utiliza la nota-ción polaca inversa, donde los nodos “simples” son interpretados como operandos ylos “compuestos” como operadores. En la Figura 4.7 se puede observar el fragmentode código en cuestión. La lista Componentes está conformada por tres nodos, donde losprimeros dos son nodos “simples” y el tercero es un nodo “compuesto” que realiza elOr del resultado de los primeros.

FIGURA 4.7: Fragmento de Código JSON - Componentes de un Predica-do Compuesto

1 {2 ...3 { "NombrePred": "<nombrePredicado3>",4 ...5 "Componentes": [6 { "Clase":"<IGUAL>",7 "ParametroI":<0>, "AtributoI":"<atributo1>",8 "ParametroD":<#_1>, "AtributoD":"_constante"9 },

10 { "Clase":"<IGUAL>",11 "ParametroI":<1>, "AtributoI":"<atributo2>",12 "ParametroD":<#_2>, "AtributoD":"<_constante>"13 }14 {15 "Clase":"<OR>"16 }]17 },...18

19 }


4.2. Frame Granja

En la sección anterior, se presentó una descripción completa de los archivos de con-figuración que deben ser especificados por el usuario docente para definir un nuevoframe. En esta Sección, ilustraremos el uso del framework detallando la instanciaciónde un frame en particular: el frame Granja. Para ello, se explica cómo se especifican losarchivos de configuración, para finalmente, realizar una comparación entre el frameespecificado mediante el framework desarrollado y el frame implementado por la he-rramienta FOLST (Figura 4.1).

La Granja es uno de los frames implementados en la herramienta FOLST, presentadahace algunos años en (Mauco y col., 2012a). El mismo consiste en una imagen de unagranja, sobre la cual se pueden agregar diferentes animales en distintos lugares. Cadaanimal tiene sus propios atributos: la especie (el atributo tipo); la ubicación en la imagen(dentro de una zona); y si es que está dormido o despierto. Además, el frame de dichaherramienta establece un conjunto de predicados y define una función para trabajarsobre los dominios que es posible definir.

FIGURA 4.1: Captura de pantalla del frame Granja implementado en laherramienta FOLST

4.2.1. Especificación de la Pizarra de trabajo

Para la especificación del archivo Board.config.json se utilizan dos imágenes:la imagen de la granja (Figura 4.2(a)), y una máscara que permite identificar las dife-rentes regiones de la imagen (Figura 4.2(b)). De las imágenes se detalla que: posee elmismo ratio entre altura y ancho; en este frame en particular, son del mismo tamaño (laimagen que se le muestra al usuario se redimensiona de forma automática en la venta-na del navegador WEB). La imagen que corresponde a la máscara de la granja utilizadiferentes colores para definir y pintar las diferentes regiones del frame (opciones delatributo zona).

Por otro lado, se genera el mapa que indexa las diferentes zonas en función de los co-lores utilizados dentro de la imagen utilizada como máscara. En la Figura 4.8 se puedeobservar el mapa boardMap de la granja.


(a) Imagen de la Granja (b) Máscara de la Granja

FIGURA 4.2: Imágenes utilizadas para la definición del archivo de con-figuración Board.config.json. A la izq. se muestra el fondo que seutiliza en la pizarra de trabajo; a la der. se presenta la máscara que define

y delimita las diferentes regiones (opciones del atributo zona)

FIGURA 4.8: Fragmento de Código JSON - especificación del boardMap,dentro del board.config del frame Granja

1 {...2 "boardMap" : {3 "R63G72B204" : "aire", //--azul --//4 "R34G177B76" : "bosque", //--verde --//5 "R255G242B0" : "granero", //--amarillo --//6 "R255G174B201" : "pasto", //--rosa --//7 "R237G28B36": "corral" //--rojo --//8 }9 }

4.2.2. Especificación del Panel de trabajo

Para la especificación del archivo Panel.config.json se utiliza una imagen porcada posible combinación entre tipo de elemento y atributo-valor, tal como se indicó enla sección 4.1.2. En particular, el frame Granja posee cuatro tipos de elementos: chan-cho (Figura 4.3(a)), gallina (Figura 4.3(b)), vaca (Figura 4.3(c)) y pato (Figura 4.3(d)).Todos los elementos poseen dos estados diferentes, pudiendo encontrarse despiertos odormidos.

(a) Chancho (b) Gallina (c) Vaca (d) Pato

FIGURA 4.3: Imágenes de los diferentes elementos y sus estados del fra-me Granja

Mediante el archivo de configuración se especifican: cuatro tipos de elementos, den-tro de la lista elements; un único tipo de dominio, un solo elemento dentro de la lista


tabs; el mapa que indexa las imágenes y el arreglo que genera las claves correspondien-tes. Los diferentes tipos de elementos definidos poseen los mismos tipos de atributos(forman parte del mismo tipo de dominio) y es por ello que todos hacen referencia almismo tab.

4.2.3. Especificación de la Semántica [Granja]

Dentro del archivo Semantica.config.json se especifican los elementos, lasfunciones y los predicados:

Elementos: Todos los elementos posee los mismo atributos: el tipo, la zona en laque se lo ubica, y si está dormido o despierto.

Funciones: Los nombres de las funciones deben estar escritos con letras mayús-culas (Sección 3.3.3). En la herramienta FOLST, el frame Granja tomado comobase, implementa una función nombrada como ELMASCERCANO, que retornael elemento más próximo a un elemento “x”. En este caso, se renombra la fun-ción “ElMasCercano” (proporcionada por el Motor de Inferencia), con el nombre“ELMASCERCANO”.

Predicados:

• EsVaca(x)

• EsChancho(x)

• EsPato(x)

• EsGallina(x)

• MismaEspecie(x, y)

• EsMamifero(x)

• EsAve(x)

• EstaDormido(x)

• EstaEnElCorral(x)

• EstaEnElBosque(x)

• EstaEnElPasto(x)

• EstaEnElAire(x)

• EstaEnElGranero(x)

• MismoLugar(x, y)

4.2.4. Frame Instanciado

En la Figura 4.4 se observa cómo queda instanciado el frame de la Granja utilizandoel framework desarrollado. El mismo implementa de forma exitosa todas las funcio-nalidades y características del frame tomado como base (es decir, del frame Granja deFOLST).

En la misma imagen se muestra un ejemplo de cómo utilizar el frame resultante paraespecificar y evaluar problemas de LPO. En un costado se define una instancia de undominio conformado por seis diferentes animales, con diferentes nombres, en diferen-tes lugares y con diferentes estados. En el otro lado es posible observar la definición decuatro fórmulas diferentes ya evaluadas.

Las fórmulas evaluadas y sus respectivos resultados de evaluación son los siguien-tes:

∀xEsPato(x)

El resultado de la sentencia es falso ya que dentro del dominio se encuentrandefinidos otros elementos que no son del tipo pato.


FIGURA 4.4: Captura de pantalla del frame Granja Implementado

∀x(EsV aca(x) EstaEnElBosque(x))

Luego de verificar las sentencias, se muestra al usuario un ícono de error en elcostado derecho de esta sentencia, el mismo corresponde a un error sintácticodentro de la fórmula. En este caso en particular el error corresponde a la falta deun conector lógico entre los dos predicados utilizados.

∀yEsV acaa(y)

Al verificar la sentencia da como resultado un error. En este caso el mismo sedebe a que el predicado EsVaca está mal escrito, como es posible observar en elmensaje de error mostrado en la imagen al pasar el cursor sobre la sentencia encuestión.

∃z(EsChancho(z) ∧ EstaEnElCorral(z))

La verificación de la sentencia en el modelo da como resultado verdadero. Debidoa que existe un chancho que se encuentra dentro del corral, el elemento e6

Para mayor información acerca de como quedaron los archivos de configuracióncompletos del frame instanciado, el lector puede consultar el Apéndice C.

4.3. Frame Figuras Geométricas

En la sección anterior se detalló la implementación del frame Granja. En dicho fra-me, existe un conjunto de funcionalidades brindadas por nuestro framework que noson utilizadas. Para ejemplificar las mismas se implementa el frame Figuras Geométri-cas, inspirado en una de las herramientas analizadas en la Sección 2.4 conocida comoTarski’s World y desarrollada en la Universidad de Stanford (Barker-Plummer, Barwisey Etchemendy, 2007).

El frame Figuras geométricas consiste en la imagen de un tablero, el cual está di-vidido en una cantidad determinada de filas y columnas. Sobre el tablero se puedenagregar diferentes figuras, que pueden tener tres tamaños distintos (chicas, medianas ograndes). Al igual que en el caso anterior, aquí se pretende especificar un frame que re-plique los elementos, predicados y funciones definidos en la herramienta tomada comobase (en este caso, Tarski’s World).


4.3.1. Especificación de la Pizarra de Trabajo

En el archivo Board.config.json del frame figuras se utilizan: una imagen deun tablero como fondo (Figura 4.5(a)), y una máscara que permite identificar inequívo-camente cada uno de los casilleros del mismo (Figura 4.5(b)). Las dos imágenes poseenel mismo tamaño. Cada uno de los casilleros del tablero es pintado con un color dife-rentes dentro de la máscara, y cada color es utilizado para definir el mapa que asignalos atributos fila y columna (Figura 4.9).

(a) Imagen del Tablero (b) Máscara del Tablero

FIGURA 4.5: Imágenes utilizadas para la definición del archivo de con-figuración Board.config.json. A la izq. se muestra el fondo que semuestra en la pizarra de trabajo; a la der. se presenta la máscara que

define las diferentes regiones.

FIGURA 4.9: Fragmento de Código JSON - especificación del boardMap,dentro del board.config del frame Figuras

1 {...2 "boardMap" : { //--cuadrados violetas--//3 "R23G11B40" : {"fila": 1 , "col": 1 },4 "R45G22B80" : {"fila": 1 , "col": 2 },5 "R68G33B120" : {"fila": 1 , "col": 3 },6 "R90G44B160" : {"fila": 1 , "col": 4 },7 "R113G55B200": {"fila": 1 , "col": 5 },8 "R141G95B211": {"fila": 1 , "col": 6 },9 //--cuadrados celestes--//

10 "R11G34B40" : {"fila": 2 , "col": 1 },11 ...12 }13 }

4.3.2. Especificación del Panel de Trabajo

Dentro de la especificación del archivo Panel.config.json correspondiente pa-ra este frame, se definen los tres elementos: circulo (Figura 4.6(a)), estrella (Figura 4.6(b))y pentágono (Figura 4.6(c)) en conjunto con los tres tamaños que los mismos puedentener (Chico, Mediano o Grande).


(a) Circulo (b) Estrella (c) Pentágono

FIGURA 4.6: Imágenes de los diferentes elementos y sus estados del fra-me Figuras Geométricas

4.3.3. Especificación de la Semántica [Figuras]

Por último, se especifican los elementos, funciones y predicados dentro del archivoSemantica.config.json:

Elementos: en este frame, todos los elementos poseen los mismos atributos: eltipo, la ubicación espacial dentro del tablero (atributo fila y columna), y uno de tresposibles tamaños.

Funciones: El frame tomado como base no posee funciones definidos, por lo quela especificación del campo correspondiente dentro del archivo queda vacía.

Predicados:

• Estrella(x)

• Pentagono(x)

• Circulo(x)

• Chico(x)

• Mediano(x)

• Grande(x)

• MasChico(x, y)

• MasGrande(x, y)

• Entre(x, y, z)

• IzqDe(x, y)

• DerDe(x, y)

• ArribaDe(x, y)

• AbajoDe(x, y)

• MismaFila(x, y)

• MismaColumna(x, y)

• MismoTamaño(x, y)

• MismaFigura(x, y)

4.3.4. Frame Instanciado

En la Figura 4.7 se observa cómo queda instanciado el frame del tablero de FigurasGeométricas utilizando el framework desarrollado, y además, se ejemplifica como uti-lizar el mismo. Dentro de la imagen es posible ver la instanciación de un dominio y unconjunto de sentencias analizadas.

El dominio del modelo consta de cuatro elementos: dos estrellas chicas, un circulo me-diano y un pentágono grande; todos ellos se encuentran ubicados en diferentes casillerosdel tablero.

Las sentencias verificadas son las siguientes:

∀x∀y(¬(Estrella(x) ∧ Estrella(y)) ∨MismaColumna(x, y))

La verificación de la sentencia en el modelo da como resultado falso, debido aque las dos estrellas existentes dentro del dominio no se encuentran en la mismacolumna.


FIGURA 4.7: Captura de pantalla del frame Figuras Geométricas imple-mentado

∀x∀y(¬(Estrella(x) ∧ Estrella(y)) ∨MismaFila(x, y))

La verificación de la sentencia en el modelo da como resultado verdadero ya quelas únicas dos estrellas definidas dentro del dominio están en la misma fila.

∃xDerDe(e4, x)

El resultado de verificar la sentencia da verdadero. Existe al menos un elementoque está ubicado a la derecha del elemento e4; por ejemplo, el elemento e2.

Para mayor información acerca de como quedaron los archivos de configuracióncompletos del frame instanciado, el lector puede consultar el Apéndice D.

Capítulo 5

Conclusiones

En este trabajo de presentó una herramienta Web para la enseñanza/aprendizaje deLógica de Predicados de Primer Orden mediante la cual es posible modelar y resolverproblemas semánticos. A partir de las herramientas existentes en la actualidad, y lascaracterísticas de las aplicaciones educativas para la enseñanza de lógica, se propusoel desarrollo de una herramienta visualmente atractiva, amigable, intuitiva, extensibley configurable, con el fin de superar varias de las limitaciones presentadas por herra-mientas similares, y unificarlas dentro de una única aplicación. Con esta finalidad, sedesarrolló LogicWorld, un framework que permite definir e incorporar nuevos frames,los cuales proporcionan un “marco de trabajo” en el que es posible definir infinidad demodelos.

Para poder desarrollar la herramienta, se realizó un diseño basado en el patrón ar-quitectónico Cliente-Servidor utilizando una Single Page Application, la cual proporcionauna experiencia de usuario mas fluida dentro de la interfaz visual construida en elcliente; “conectada” a una API RESTfull, para intercambiar datos entre el cliente y elservidor.

El usuario interactúa con el cliente, mientras que el procesamiento de los datoses llevado a cabo en el servidor. Ante la necesidad de manipular diferentes framesdefinidos por el usuario dentro del servidor, se implementó un motor de inferenciamodular, encargado de realizar la verificación de las fórmulas, que permite ademásparametrizar dichas definiciones. Este diseño permite intercambiar el componente porotro motor de inferencia personalizado, o extender el existente.

El potencial del framework fue demostrado por medio de la instanciación de dosframes diferentes. El primero consiste en la implementación de un frame del tipo zonacon el propósito de demostrar que el framework permite especificar de manera rápida ysencilla diferentes tipos de elementos, funciones y predicados simples. El frame en cues-tión está basado en el frame “Granja” de la herramienta FOLST (Mauco y col., 2012a), elcual define cuatro tipos de elementos (“chancho”, “gallina”, “vaca” y “pato”) con dosatributos (la “zona” en la que están ubicados y si está “dormido” o “despierto”), unafunción y catorce predicados diferentes. Para realizar dicha especificación se definieronlos tres archivos de configuración correspondientes y se crearon las diferentes imáge-nes a mostrar (fondo del panel de trabajo, mascara del panel de trabajo e imágenes delos diferentes elementos)

Mediante el segundo frame implementado, se buscó ejemplificar la definición deun frame del tipo tablero, así también como la definición de predicados más complejos(en los cuales intervenga más de una instancia de la clase verificador). Para ello, se uti-lizó como referencia el frame “Figuras Geométricas” implementado en la herramientaTarski’s World (Barker-Plummer, Barwise y Etchemendy, 2007). Esta aplicación didác-tica permite la definición de modelos que posean tres tipos de elementos (“triángulos”,“cuadrados” y “círculos”) instanciados en tres tamaños diferentes (“chico”, “mediano”

63

64 Capítulo 5. Conclusiones

o “grande”) y dieciocho predicados. Para realizar la instanciación del frame se crearondiversas imágenes a mostrar (los elementos, el tablero y la mascara del fondo) y se espe-cificaron los archivos de configuración, adaptando los archivos definidos en el ejemploanterior. Al ser de tipo tablero, este frame cuenta con dos atributos a través de la ima-gen de fondo (la “fila” y la “columna” en la cual se posiciona cada elemento). Por otrolado, posee un predicado que compara con conectores lógicos (“and” y “or”) el resul-tado de otros verificadores. En este caso en particular, utilizar un conjunto de archivospreviamente instanciados simplificó considerablemente la tarea de especificación.

Al momento de comparar los frames originales con los resultados obtenidos a travésde la utilización del framework, es posible observar que se logró implementar exitosa-mente todas las funcionalidades y características de las aplicaciones utilizadas comoreferencia.

5.1. Contribuciones

A continuación se listan algunas de las contribuciones más importantes de la solu-ción propuesta:

La herramienta es una aplicación web que permite modelar problemas de semán-tica en LPO. Si bien existen algunas herramientas educativas para la evaluaciónsemántica de fórmulas en LPO (en las cuales los usuarios tienen la posibilidadde definir distintos modelos), todas trabajan sobre un dominio preestablecido,con relaciones y funciones también preestablecidas y son aplicaciones standalone.Luego de un profundo análisis de las herramientas existentes, en este trabajo seidentificaron puntos en común entre ellas que fueron abstraídos y resultaron en eldiseño de LogicWorld, que permite encapsular diversos dominios y frames dentrode una misma aplicación.

El framework permite definir nuevas semánticas de modelos de forma sencilla. Elusuario sólo tiene que especificar un conjunto de archivos de configuración y ad-juntar las diferentes imágenes que son requeridas, obteniendo como resultado unnuevo frame y evitándose cuestiones tecnológicas y de programación avanzadas.

Los frames especificados son utilizados para instanciar la vista del editor dentrode la aplicación, la cual es siempre es la misma. La aplicación centraliza y estan-dariza los diferentes marcos de trabajo. Su funcionalidad y las zonas donde seubican los diversos elementos son independientes del frame con el que se deseatrabajar. Si bien las imágenes y la semántica del modelo cambian, el usuario con-tinúa desenvolviéndose en el mismo ambiente de trabajo dentro de la aplicación.

LogicWorld es Software Libre. El Software Libre (entendido como aquellos pro-gramas en donde el usuario tiene libertad de usarlo, acceder al código fuente,copiarlo y mejorarlo) puede ser de gran utilidad en los procesos de enseñanza/a-prendizaje por varios motivos. Al utilizar software libre se elimina la dependen-cia hacia programas privativos, y el usuario se despreocupa de cuestiones rela-cionadas con la fecha de caducidad de una licencia de un programa. El softwarelibre es siempre libre en todos los sentidos. Todos los estudiantes tienen acceso ala aplicación de forma legal. Incluso, los estudiantes y otros docentes pueden serpartícipes de la construcción de sus propias herramientas ya que permite explorarcómo fue desarrollada y analizar los diferentes componentes que la conforman.

Capítulo 5. Conclusiones 65

5.2. Limitaciones

Al finalizar el desarrollo de la herramienta y luego de implementar los diferentesframes, se identificaron las siguientes limitaciones del proyecto:

Si bien es posible definir una gran cantidad de modelos y sentencias a evaluarmediante el uso de la aplicación, faltaría una opción que permita al usuario guar-dar y cargar (hacia y desde la PC) un modelo o un conjunto de sentencias. Sinembargo, pese a que esta funcionalidad no se encuentra implementada en estosmomentos en la vista del cliente, como se utilizó el patrón de diseño MVC, esfactible y sencillo agregar dicha característica a través de la serialización de lasestructuras que almacenan la información correspondiente a las vistas.

Para la especificación de los archivos de configuración se utilizó el lenguaje JSON.Al utilizar dicho lenguaje, el usuario puede escribir e interpretar de forma sen-cilla y rápida los diferentes objetos que especifican un frame. No obstante, estopuede traer como consecuencia que dicha tarea sea monótona o incluso complejasi el frame a definir posee demasiados componentes a especificar. En este sentido,contar con un asistente visual que acompañe al usuario en el momento de generarnuevos frames podría resultar de gran ayuda.

Los frames implementados fueron evaluados informalmente por ex-alumnos dela cátedra Ciencias de la Computación II de la Facultad de Ciencias Exactas de laUNICEN, quienes ya se encontraban familiarizados con una de las herramientaspre-existentes (FOLST). Pese a que el feedback obtenido fue positivo, no se llevóa cabo una tarea sistemática de cuantificación de las opiniones en términos deusabilidad, calidad de la interfaz de usuario, etc. Queda pendiente una evalua-ción sistemática de los frames implementados, estudiando el impacto del uso dela herramienta en distintos cursos introductorios de lógica.

5.3. Trabajos Futuros

Un posible trabajo que puede desprenderse de esta tesis es el desarrollo de un sis-tema de logueo en el cual los diferentes usuarios de la herramienta deban registrarsey, de esta forma, sea posible realizar un seguimiento sobre las diferentes actividadesrealizadas dentro de la aplicación. En este sentido, y para avanzar sobre una de las li-mitaciones identificadas, podría resultar interesante generar (dentro de las cuentas delos usuarios) un apartado que permita almacenar o cargar diferentes estados de losframes con los que se está trabajando, permitiendo de esta forma retomar actividadespausadas.

Por otro lado, el desarrollo de un manual o libro que pueda ser utilizado en conjuntocon la herramienta, potenciaría la adopción de la misma por cátedras de lógica dictadasen otras instituciones. El mismo puede contener explicaciones, actividades e inclusoautoevaluaciones en función de los diferentes frames implementados. En paralelo, paradarle masividad al proyecto, sería conveniente desarrollar una plataforma wiki quepermita el intercambio de propuestas, comentarios y frames entre diferentes docentesde diferentes cursos de lógica que puedan llegar a utilizar la herramienta.

Apéndice A

JFlex - Analizador Léxico

JFlex es un metacompilador que permite generar rápidamente analizadores léxicosque se integran a proyectos desarrollados en el lenguaje Java. Provee soporte completocon caracteres unicode, tiene una sintaxis cómoda de manipular y fácil de interpretar,es independiente de la plataforma debido a que está diseñado para ser integrado conJava, y además permite la integración con CUP (Analizador sintáctico).

Un archivo JFex esta dividido en 3 secciones:

Opciones y declaraciones La primera parte del archivo es el bloque donde seimportarán los paquetes que se van a utilizar para nuestro analizador, seguidode un par de signos de porcentaje ( %) para indicar que empezará la definicióndel bloque de configuración del analizador.

Código de usuario Dentro de esta sección se escribe el código Java que se va autilizar dentro del analizador, cabe notar que el código definido será incluido tex-tual dentro del resultado de la clase Java resultante. Todo el código desarrolladodebe estar enmarcado por las etiquetas %{ al ninico y %} al final del mismo.

Reglas lexicográficas En esta sección se define el conjunto de expresiones regula-res a utilizar durante el proceso de análisis.

A.1. Reglas lexicográficas

Un salto de linea es un \n, \r o \r\n dependiendo del SO.

Salto = \r|\n|\r\n

Un espacio es un espacio en blanco, tabulador \t, salto de linea “Salto” o avancede pagina \f. Normalmente son ignorados

Espacio = Salto |[\t\f]

Identificadores de Variables. Los nombres de las variables siempre están escritosen letras minúsculas.

Idvariable = [a− z][a− z]*[0− 9]*

Identificadores de Funciones. Los nombres de las funciones siempre están escritosen mayúsculas.

Idfuncion = [A− Z][A− Z]*

Identificadores de Predicados. Los nombres de los predicados siempre comienzancon una mayúscula y tienen al menos una letra en minúscula

Idpredicado = [A− Z][a− z][a− zA− Z]*

67

68 Apéndice A. JFlex - Analizador Léxico

A.2. Reglas léxicas

Las reglas léxicas contienen expresiones regulares y acciones. Las acciones son có-digo en Java que se ejecutará cuando se encuentre una entrada válida para la expresiónregular correspondiente. Para la configuración del escáner, se definen los tokens queidentifican los operadores lógicos, los diferentes tipos de ids y demás caracteres nece-sarios (paréntesis, comas).

Las cadenas de caracteres leídas por el analizador léxico, tienen que coincidir conalguno de los tokens especificados (Tabla A.1), en el caso de que el contenido de laentrada no coincida con ninguna regla entonces se marca como un token ilegal y sedetecta un error léxico.

TABLA A.1: Reglas léxicas -

Simbolo Token RetornadoCuantificador Universal "@"| "∀" sym.PARATODOCuantificador Existencia "#"| "∃" sym.EXISTENegacion "¬"|"∼" sym.NEGACIONDisyuncion "|"|"∨" sym.DISYUNCIONConjuncion "^"|"&"|"∧" sym.CONJUNCIONImplicacion "=>"|"−>"| "→" sym.IMPLICACIONComa "," sym.COMAParéntesis Abierto "(" sym.PAParéntesis Cerado ")" sym.PCIdentificador de Variable {Idvariable} sym.IDVARIdentificador de Función {Idfuncion} sym.IDFUNCIdentificador de Predicado {Idpredicado} sym.IDPRED—– {Espacio} /* ignora los espacios */

Apéndice B

CUP - Analizador Sintáctico

CUP es un metacompilador utilizado para generar analizadores sintácticos ascen-dentes con algoritmos LALR. Un archivo de entrada CUP consta de las siguientes cincopartes:

1. Definición de paquete y sentencias import En la primera parte del archivo seespecifica el paquete al que pertenecerá la clase Java generada y se importaránlas clases o paquetes a utilizar dentro del analizador.

2. Sección de código de usuario En este bloque pueden declararse variables, fun-ciones, etc. pero todos los elementos declarados tiene que ser de tipo estático.Todo lo que se declare en este segmento será accesible a las acciones semánticas.

3. Declaración de símbolos terminales y no terminales. Seguido de las declaracio-nes de código de usuario se listan los símbolos terminales y no terminales queaparecen en la gramática, agrupando los elementos por tipo y asignándole a cadalista el que le corresponde.

4. Declaraciones de precedencia Dentro de esta sección se define la precedenciaque existe entre los símbolos no terminales especificados en la sección anterior.Además, se indica si los mismos poseen asociación a izquierda o a derecha.

5. Definición del símbolo inicial de la gramática y reglas de producción Como sunombre lo indica en esta sección se especifican las reglas que definen la gramáticadel lenguaje a analizar, notadas como una gramática independiente del contexto.En cada regla de producción es posible definir un código Java asociado a ella.

B.1. Símbolos terminales y no terminales

En la Tabla B.1 se listan los diferentes símbolos que forman parte de la gramática.Primero se listan los terminales que no poseen un valor, seguido de los terminales queposeen un valor (ej: los identificadores). Después se listan los no terminales que tienenun valor Object y finalmente se listan los no terminales que tienen un tipo específicoasociado.

Cuando se dice que un no terminal posee un valor Object, hace referencia a queno posee tipo predefinido o el tipo puede ser distinto dependiendo la regla por la quereduce.

69

70 Apéndice B. CUP - Analizador Sintáctico

TABLA B.1: Declaración de símbolos terminales y no terminales

Tipo Tokens

terminal -EXISTE, PARATODO, NEGACION,

DISYUNCION, CONJUNCION,IMPLICACION, PA, PC, COMA;

terminal String IDVAR, IDFUNC, IDPRED, ERROR;non terminal Object -non terminal Formula comienzo, cond, disy, conj, factor, pred;non terminal ArrayList <Termino> listaTerm;non terminal Termino term;

B.2. Gramática del analizador sintáctico

En la Figura B.1 se presenta la gramática empleada para configurar el parser. Porcuestiones de legibilidad se optó por eliminar el código Java asociado a cada una de lasreglas.

Cada una de las reglas define un único elemento del lado izquierdo y una lista determinales o no terminales del lado derecho, además es posible que una regla tenga másde una opción. El símbolo “|” se utiliza para indicar que una regla utiliza una produc-ción u otra. Las reglas de producción se utilizan para pasar de símbolos no terminaleshasta llegar a símbolos terminales.

FIGURA B.1: Gramática del analizador sintáctico

1 comienzo ::= cond2 ;3 cond ::= disy IMPLICACION cond4 | disy5 ;6 disy ::= conj DISYUNCION disy7 | conj8 ;9 conj ::= factor CONJUNCION conj

10 | factor11 ;12 factor ::= PARATODO IDVAR factor13 | EXISTE IDVAR factor14 | NEGACION factor15 | PA cond PC16 | pred17 ;18 pred ::= IDPRED PA listaTerm PC19 ;20 listaTerm ::= term21 | listaTerm COMA term22 ;23 term ::= IDVAR24 | IDFUNC PA listaTerm PC25 ;

Apéndice C

Archivos de configuración - FrameGranja

C.1. Panel.config.json

FIGURA C.1: Archivo de configuración del panel de trabajo del frameGranja

1 {2 "elements":[3 {"ref":"animal",4 "id":"tipo1",5 "img":"granja/images/chancho.png"},6

7 {"ref":"animal",8 "id":"tipo2",9 "img":"granja/images/gallina.png"},

10

11 {"ref":"animal",12 "id":"tipo3",13 "img":"granja/images/pato.png"},14

15 {"ref":"animal",16 "id":"tipo4",17 "img":"granja/images/vaca.png"}18 ],19

20 "tabs":[21 {"id":"animal" ,"att" : [22 {"name":"att1", "op":[23 {"estado":"Despierto"},24 {"estado":"Dormido"}25 ]}26 ]}27 ],28

29 "map" : {30 "tipo1Despierto":"granja/images/chancho.png",31 "tipo2Despierto":"granja/images/gallina.png",32 "tipo3Despierto":"granja/images/pato.png",

71

72 Apéndice C. Archivos de configuración - Frame Granja

33 "tipo4Despierto":"granja/images/vaca.png",34 "tipo1Dormido":"granja/images/chanchoDormido.png",35 "tipo2Dormido":"granja/images/gallinaDormido.png",36 "tipo3Dormido":"granja/images/patoDormido.png",37 "tipo4Dormido":"granja/images/vacaDormido.png"38 },39 "keys" : ["tipo", "att1"]40 }

C.2. Board.config.json

FIGURA C.2: Archivo de configuración del board del frame Granja

1 {2 "boardModel" : {3 "img": "granja/images/granja.png",4 "img_mascara":"granja/images/mascara.png",5 "tipo": "zona"6

7 },8 "boardMap" : {9 "R63G72B204" : "aire",

10 "R34G177B76" : "bosque",11 "R255G242B0" : "granero",12 "R255G174B201" : "pasto",13 "R237G28B36" : "corral"14 }15 }

C.3. Semantica.config.json

FIGURA C.3: Archivo de configuración de la semántica del frame Granja

1 {"Predicado":[2 {"NombrePred":"Dormido",3 "CantParam":1,4 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "

AtributoI":"att1", "ParametroD":1, "AtributoD":"_constante"}

5 ]},6 {"NombrePred":"EsChancho",7 "CantParam":1,8 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "

AtributoI":"tipo", "ParametroD":0, "AtributoD":"_constante"}

9 ]},10 {"NombrePred":"EsGallina",11 "CantParam":1,

Apéndice C. Archivos de configuración - Frame Granja 73

12 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "AtributoI":"tipo", "ParametroD":1, "AtributoD":"_constante"}

13 ]},14 {"NombrePred":"EsPato",15 "CantParam":1,16 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "


17 ]},18 {"NombrePred":"EsVaca",19 "CantParam":1,20 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "


21 ]},22 {"NombrePred":"EstaEnElAire",23 "CantParam":1,24 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "

AtributoI":"zona", "ParametroD":0, "AtributoD":"_constante"}

25 ]},26 {"NombrePred":"EstaEnElBosque",27 "CantParam":1,28 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "


29 ]},30 {"NombrePred":"EstaEnElPasto",31 "CantParam":1,32 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "


33 ]},34 {"NombrePred":"EstaEnElGranero",35 "CantParam":1,36 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "


37 ]},38 {"NombrePred":"EstaEnElCorral",39 "CantParam":1,40 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "


41 ]},42 {"NombrePred":"EsAve",43 "CantParam":1,44 "Componentes" :[

74 Apéndice C. Archivos de configuración - Frame Granja

45 {"Clase":"IGUAL", "ParametroI":0, "AtributoI":"tipo", "ParametroD":1, "AtributoD":"_constante"},


47 {"Clase":"OR"}48 ]},49 {"NombrePred":"EsMamifero",50 "CantParam":1,51 "Componentes" :[52 {"Clase":"IGUAL", "ParametroI":0, "AtributoI":"

tipo", "ParametroD":0, "AtributoD":"_constante"},


54 {"Clase":"OR"}55 ]},56 {"NombrePred":"MismoLugar",57 "CantParam":2,58 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "

AtributoI":"zona", "ParametroD":1, "AtributoD":"zona"}

59 ]},60 {"NombrePred":"MismaEspecie",61 "CantParam":2,62 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "

AtributoI":"tipo", "ParametroD":1, "AtributoD":"tipo"}

63 ]}64 ],65

66 "Funcion":[67 {"Rename":"ELMASCERCANO","Class":"ElMasCercano"}68 ],69

70 "Elemento":[{71 "Dominio":"animal",72 "ListAtributos":[73 {"Atributo":"tipo",74 "Opciones":["tipo1","tipo2","tipo3", "tipo4"]},75

76 {"Atributo":"att1",77 "Opciones":["Despierto","Dormido"]},78

79 {"Atributo":"zona",80 "Opciones":["aire","bosque","pasto","granero","corral"

]}]81 }]82 }

Apéndice D

Archivos de configuración - FrameFiguras Geométricas

D.1. Panel.config.json

FIGURA D.1: Archivo de configuración del panel de trabajo del frameFiguras Geométricas

1 {2 "elements":[3 {"ref":"figura",4 "id":"tipo1",5 "img":"tableroFiguras/images/icon_estre.png"},6

7 {"ref":"figura",8 "id":"tipo2",9 "img":"tableroFiguras/images/icon_circ.png"},

10

11 {"ref":"figura",12 "id":"tipo3",13 "img":"tableroFiguras/images/icon_penta.png"}14 ],15

16 "tabs":[17 {"id":"figura","att" : [18 {"name":"att1", "op":[19 {"estado":"Chico"},20 {"estado":"Mediano"},21 {"estado":"Grande"}22 ]}23 ]}24 ],25

26 "map" : {27 "tipo1Chico":"tableroFiguras/images/estrellaChico.png",28 "tipo1Mediano":"tableroFiguras/images/estrellaMediano.png",29 "tipo1Grande":"tableroFiguras/images/estrellaGrande.png",30 "tipo2Chico":"tableroFiguras/images/circuloChico.png",31 "tipo2Mediano":"tableroFiguras/images/circuloMediano.png",32 "tipo2Grande":"tableroFiguras/images/circuloGrande.png",

75

76 Apéndice D. Archivos de configuración - Frame Figuras Geométricas

33 "tipo3Chico":"tableroFiguras/images/pentagonoChico.png",34 "tipo3Mediano":"tableroFiguras/images/pentagonoMediano.png",35 "tipo3Grande":"tableroFiguras/images/pentagonoGrande.png"36 },37

38 "keys" : ["tipo", "att1"]39 }

D.2. Board.config.json

FIGURA D.2: Archivo de configuración del board del frame Figuras Geo-métricas

1 {2 "boardModel" : {3 "img": "tableroFiguras/images/tablero.png",4 "img_mascara":"tableroFiguras/images/mascara.png",5 "tipo": "tablero"6 },7

8 "boardMap" : {9 "R23G11B40": {"fila": 1 , "col": 1 },

10 "R45G22B80": {"fila": 1 , "col": 2 },11 "R68G33B120": {"fila": 1 , "col": 3 },12 "R90G44B160": {"fila": 1 , "col": 4 },13 "R113G55B200": {"fila": 1 , "col": 5 },14 "R141G95B211": {"fila": 1 , "col": 6 },15

16 "R11G34B40": {"fila": 2 , "col": 1 },17 "R22G68B80": {"fila": 2 , "col": 2 },18 "R33G103B120": {"fila": 2 , "col": 3 },19 "R44G137B160": {"fila": 2 , "col": 4 },20 "R55G171B200": {"fila": 2 , "col": 5 },21 "R135G205B222": {"fila": 2 , "col": 6 },22



Apéndice D. Archivos de configuración - Frame Figuras Geométricas 77

37 "R40G11B11": {"fila": 5 , "col": 1 },38 "R80G22B22": {"fila": 5 , "col": 2 },39 "R120G33B33": {"fila": 5 , "col": 3 },40 "R160G44B44": {"fila": 5 , "col": 4 },41 "R211G95B95": {"fila": 5 , "col": 5 },42 "R222G135B135": {"fila": 5 , "col": 6 }43

44 }45 }

D.3. Semantica.config.json

FIGURA D.3: Archivo de configuración de la semántica del frame Figu-ras Geométricas

1 {"Predicado":[2 {"NombrePred":"Chico",3 "CantParam":1,4 "Componentes" :[{5 "Clase":"IGUAL", "ParametroI":0, "AtributoI":"att1", "

ParametroD":0, "AtributoD":"_constante"}6 ]},7 {"NombrePred":"Mediano",8 "CantParam":1,9 "Componentes" :[{

10 "Clase":"IGUAL", "ParametroI":0, "AtributoI":"att1", "ParametroD":1, "AtributoD":"_constante"}

11 ]},12 {"NombrePred":"Grande",13 "CantParam":1,14 "Componentes" :[{15 "Clase":"IGUAL", "ParametroI":0, "AtributoI":"att1", "

ParametroD":2, "AtributoD":"_constante"}16 ]},17

18 {"NombrePred":"Estrella",19 "CantParam":1,20 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "


21 ]},22 {"NombrePred":"Pentagono",23 "CantParam":1,24 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "


25 ]},26 {"NombrePred":"Circulo",27 "CantParam":1,


28 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "AtributoI":"tipo", "ParametroD":2, "AtributoD":"_constante"}

29 ]},30

31 {"NombrePred":"IzqDe",32 "CantParam":2,33 "Componentes" :[{"Clase":"MENOR", "ParametroI":0, "

AtributoI":"col", "ParametroD":1, "AtributoD":"col"}34 ]},35 {"NombrePred":"DerDe",36 "CantParam":2,37 "Componentes" :[{"Clase":"MAYOR", "ParametroI":0, "

AtributoI":"col", "ParametroD":1, "AtributoD":"col"}38 ]},39 {"NombrePred":"ArrivaDe",40 "CantParam":2,41 "Componentes" :[{"Clase":"MENOR", "ParametroI":0, "

AtributoI":"fila", "ParametroD":1, "AtributoD":"fila"}42 ]},43 {"NombrePred":"AbajoDe",44 "CantParam":2,45 "Componentes" :[{"Clase":"MAYOR", "ParametroI":0, "

AtributoI":"fila", "ParametroD":1, "AtributoD":"fila"}46 ]},47

48 {"NombrePred":"MismaFila",49 "CantParam":2,50 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "

AtributoI":"fila", "ParametroD":1, "AtributoD":"fila"}51 ]},52 {"NombrePred":"MismaColumna",53 "CantParam":2,54 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "

AtributoI":"col", "ParametroD":1, "AtributoD":"col"}55 ]},56 {"NombrePred":"MismoTamanio",57 "CantParam":2,58 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "

AtributoI":"att1", "ParametroD":1, "AtributoD":"att1"}59 ]},60 {"NombrePred":"MismaFigura",61 "CantParam":2,62 "Componentes" :[{"Clase":"IGUAL", "ParametroI":0, "

AtributoI":"tipo", "ParametroD":1, "AtributoD":"tipo"}63 ]},64 {"NombrePred":"MasChico",65 "CantParam":2,66 "Componentes" :[{"Clase":"MENOR", "ParametroI":0, "

AtributoI":"att1", "ParametroD":1, "AtributoD":"att1"}

Apéndice D. Archivos de configuración - Frame Figuras Geométricas 79

67 ]},68 {"NombrePred":"MasGrande",69 "CantParam":2,70 "Componentes" :[{"Clase":"MAYOR", "ParametroI":0, "

AtributoI":"att1", "ParametroD":1, "AtributoD":"att1"}71 ]},72

73 {"NombrePred":"Entre",74 "CantParam":3,75 "Componentes" :[76 {"Clase":"MAYOR", "ParametroI":1, "AtributoI":"col", "

ParametroD":0, "AtributoD":"col"},77 {"Clase":"MAYOR", "ParametroI":0, "AtributoI":"col", "

ParametroD":2, "AtributoD":"col"},78 {"Clase":"AND"},79

80 {"Clase":"MAYOR", "ParametroI":1, "AtributoI":"fila","ParametroD":0, "AtributoD":"fila"},

81 {"Clase":"MAYOR", "ParametroI":0, "AtributoI":"fila","ParametroD":2, "AtributoD":"fila"},

82 {"Clase":"AND"},83

84 {"Clase":"OR"},85

86 {"Clase":"MENOR", "ParametroI":1, "AtributoI":"col", "ParametroD":0, "AtributoD":"col"},

87 {"Clase":"MENOR", "ParametroI":0, "AtributoI":"col", "ParametroD":2, "AtributoD":"col"},

88 {"Clase":"AND"},89

90 {"Clase":"MENOR", "ParametroI":1, "AtributoI":"fila","ParametroD":0, "AtributoD":"fila"},

91 {"Clase":"MENOR", "ParametroI":0, "AtributoI":"fila","ParametroD":2, "AtributoD":"fila"},

92 {"Clase":"AND"},93

94 {"Clase":"OR"},95 {"Clase":"OR"}96 ]}97 ],98

99 "Funcion":[],100

101 "Elemento":[{102 "Dominio":"figura",103 "ListAtributos":[104 {"Atributo":"tipo",105 "Opciones":["tipo1","tipo2","tipo3", "tipo4"]},106

107 {"Atributo":"att1",


108 "Opciones":["chico","mediano","grande"]},109

110 {"Atributo":"fila",111 "Opciones":["1", "2", "3", "4", "5"]},112

113 {"Atributo":"col",114 "Opciones":["1", "2", "3", "4", "5", "6"]}115 ]116 }]117 }

Bibliografía

Allen, Colin y Michael Hand (2001). Logic Primer - 2nd Edition. A Bradford Book. ISBN:0262511266.

Alonso, Jos A, Gonzalo A Aranda y Francisco J Martn-Mateos (2007). «KRRT: Knowled-ge representation and reasoning tutor system». En: Computer Aided Systems Theory–EUROCAST 2007. Springer, págs. 400-407.

Álvarez, Roberto Baelo (2009). «El e-learning, una respuesta educativa a las deman-das de las sociedades del siglo XXI». En: Pixel-Bit: Revista de medios y educación 35,págs. 87-96.

Audi, Robert (1999). The Cambridge dictionary of philosophy. Cambridge university press.Barker-Plummer, David, Jon Barwise y John Etchemendy (2007). Tarski’s World: Revised

and Expanded.Bartó, Carlos A y Juan F Weber (2013). «El déficit en formación lógico-formal como

factor de riesgo en el desempeño en Informática». En: Latin American and CaribbeanJournal of Engineering Education 2.1.

Barwise, Jon y John Etchemendy (1993). «The Language of First-Order Logic Includingthe Macintosh Version of Tarski’s World 4.0». En:

— (1994). «Hyperproof: for Macintosh». En:Ben-Ari, M. (2001). Mathematical Logic for Computer Science. Prentice-Hall international

series in computer science. Springer. ISBN: 9781852333195.Bergmann, Merrie, James Moor y Jack Nelson (1990). The logic book. Vol. 3. McGraw-Hill

New York.Berson, Alex (1996). Client/server architecture. McGraw-Hill, Inc.Blackburn, Simon (2005). The Oxford dictionary of philosophy. Oxford University Press.Bornat, Richard y Bernard Sufrin (1999). «Animating formal proof at the surface: the

Jape proof calculator». En: The Computer Journal 42.3, págs. 177-192.Broda, Krysia y col. (2007). «Pandora: A reasoning toolbox using natural deduction

style». En: Logic Journal of IGPL 15.4, págs. 293-304.Burris, Stanley N. (1997). Logic for Mathematics and Computer Science. Prentice Hall. ISBN:

0132859742.Castillo, Carlos Ivorra (2010). Lógica matemática.Chandy, K Mani (2006). «Event-driven applications: Costs, benefits and design approa-

ches». En: Gartner Application Integration and Web Services Summit 2006.Davis, Martin (1995). «Influences of mathematical logic on computer science». En: The

Universal Turing Machine A Half-Century Survey, págs. 289-299.Davis, Martin e Hilary Putnam (1960). «A computing procedure for quantification theory».

En: Journal of the ACM (JACM) 7.3, págs. 201-215.Ditmarsc, Hans Van (2009). List of logic courseware. [Web; Educational Logic Software;

accedido el 12-10-2015].Eckerson, Wayne W (1995). «Three tier client/server architectures: achieving scalabi-

lity, performance, and efficiency in client/server applications». En: Open InformationSystems 3.20, págs. 46-50.

81

82 BIBLIOGRAFÍA

Endriss, Ulrich (2000). «The interactive learning environment winke for teaching de-ductive reasoning». En: First International Congress on Tools for Teaching Logic: procee-dings: University of Salamanca, June 2000. Universidad de Salamanca, págs. 23-27.

Etchemendy, John y Jon Barwise (1992). «The language of first-order logic». En: CSLILecture Notes 34.

Fernández-Pampillón Cesteros, Ana (2009). «Las plataformas e-learning para la ense-ñanza y el aprendizaje universitario en Internet». En:

García, Felipe y col. (2007). «Nativos digitales y modelos de aprendizaje.» En: SPDECE.Gervasoni, Luciano y col. (2012). «FOLST: Una Herramienta Didáctica para la Lógica

de Predicados de Primer Orden». En: 15 Concurso de Trabajos Estudiantiles, EST 41JAIIO, págs. 405-415. ISSN: 1850–2946.

Gutiérrez, Gabriel Arrieta (2000). Introducción a la lógica. Pearson Educación.Halpin, John F. (1995/2006). The Logic Café. "[Web; Logic’s Virtual TA and Online Text-

book; accedido el 12-10-2015]".Hausman, Alan, Howard Kahane y Paul Tidman (2012). CourseMate (with Logic Coach)

for Logic and Philosophy: A Modern Introduction, 12th Edition. Wadsworth Publishing.ISBN: 113305000X.

Huertas, Antonia (2011). «Ten years of computer-based tutors for teaching logic 2000-2010: lessons learned». En: Tools for Teaching Logic. Springer, págs. 131-140.

Hurley, Patrick J. (2011). A Concise Introduction to Logic (with Stand Alone Rules and Argu-ment Forms Card) (Available Titles Aplia). Wadsworth Publishing. ISBN: 0840034172.

Jacobson, Ivar (1992). «Object oriented software engineering: a use case driven ap-proach». En:

Kenny, Claire y Claus Pahl (2009). «Intelligent and adaptive tutoring for active learningand training environments». En: Interactive Learning Environments 17.2, págs. 181-195.

Kowalski, Robert A (1988). «The early years of logic programming». En: Communica-tions of the ACM 31.1, págs. 38-43.

Layman, C Stephen (2004). The Power of Logic. 3rd edition. McGraw-Hill Humanities/-Social Sciences/Languages. ISBN: 0072875879.

Maniega-Legarda, David (2006). «Aplicación de criterios de usabilidad en sitios web:consejos y pautas para una correcta interpretación». En: Observatorio TIC: REBIUNRed de Bibliotecas Universitarias.

Mauco, María Virginia y col. (2012a). «FOLST: A Didactic Tool to Support First OrderLogic Semantics Learning». En: Lecture Notes in Information Technology 23, pág. 302.

Mauco, María Virginia y col. (2012b). «LogicChess: Herramienta Didáctica para la Ejer-citación en Lógica de Predicados de Primer Orden.» En:

Mauco, Virginia, Enzo Ferrante y Laura Felice (2014). «Educational Software for FirstOrder Logic Semantics in Introductory Logic Courses». En: Information Systems Edu-cation Journal 12.6, pág. 15.

Melis, Erica y Carsten Ullrich (2003). «Local and global feedback». En: Proceedings ofAIED2003, 11th International Conference in Artificial Intelligence in Education, Sydney,Australia, págs. 476-478.

Moreno, Antonio y Neus Budesca (2000). «Mathematical Logic Tutor-Propositional Cal-culus». En: First International Congress on Tools for Teaching Logic, págs. 99-106.

Murray, Thomas, Stephen Blessing y Shaaron Ainsworth (2003). Authoring tools for ad-vanced technology learning environments: Toward cost-effective adaptive, interactive andintelligent educational software. Springer Science & Business Media.

Nielsen, Jakob (1994). Usability engineering. Elsevier.— (2000). «Usabilidad. Diseño de páginas Web». En: DE INFORMACIÓN:

BIBLIOGRAFÍA 83

Nielsen, Jakob y Hoa Loranger (2006). «Usabilidad, prioridad en el diseño web, Ma-drid, Ediciones Anaya Multimedia.¿» En: Una sociedad de la información en igualdadde condiciones? Evaluación al grado de inclusión social-digital que ofrecen las TIC 267.

Posso, Abel Enrique, José Del Carmen Gómez y Vivian Libeth Uzuriaga (2007). «Di-ficultades que aparecen en el proceso enseñanza-aprendizaje de la matemática alpasar del bachillerato a la universidad». En: Scientia et technica 1.34.

Seese D., Lloyd JW (1984). «Foundations of Logic Programming (Symbolic Compu-tation / Artificial Intelligence)». En: Biometrical Journal - Springer-Verlag, Berlin–HeidelbergNew York–Tokyo 30.2, págs. 156-156.

Shannon, Claude Elwood (1938). «A symbolic analysis of relay and switching circuits».En: American Institute of Electrical Engineers, Transactions of the 57.12, págs. 713-723.

Wikipedians, B. Logic and Metalogic. PediaPress.Zenker, Frank y col. (2011). «Designing an introductory course to elementary symbolic

logic within the blackboard E-learning environment». En: Tools for Teaching Logic.Springer, págs. 249-255.

una herramienta didáctica para el aprendizaje de semántica

Documents