USOS PEDAGOGICOS DE LOGS

ADRIANA CAROLINA ROTHSCHILD

Asesor: RODRIGO CARDOSO

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN JUNIO DE 2006

Agradecimientos Agradezco, principalmente, a Rodrigo Cardoso, quien como asesor de tesis me guió en el proceso para llegar hasta este momento. A Rafael García, por decirme que este proyecto era apropiado para mí y por aceptarme para seguir el proceso que se venía desarrollando sobre LOGS. A Alejandro Sotelo, quien aunque ya había terminado su trabajo en LOGS me apoyó durante todo mi proceso y me ayudó siempre que lo necesité. También le agradezco al Laboratorio de Informática Educativa de la Universidad (LIDIE), en especial, a Gerardo Tibaná, a Gary Cifuentes y a Martha Luz Arango, quienes me ayudaron a encaminar el proyecto e hicieron un seguimiento del trabajo realizado. Por último agradezco a Camilo Nieto, por ayudarme en la revisión del tutorial.

3

Contenido

Cóm o leer este documento........................................................................................5

0. Introducción ...........................................................................................................6

1. LOGS........................................................................................................................8

2. Trabajo de análisis con LIDIE............................................................................9 2.1 Motivac ión y modo de trabajo ...........................................................................9 2.2 Propuestas del proyecto ....................................................................................9 2.3 Propuestas del LIDIE........................................................................................10 2.4 Decis iones sobre las propuestas y resultados .............................................10

3. Uso de LOGS en HDF en el semestre 2006-1 ..............................................12 3.1 Plan .....................................................................................................................12 3.2 Monitor ías...........................................................................................................12 3.3 Resultados .........................................................................................................13 3.4 Propuestas para el futuro ................................................................................15

4. Manual....................................................................................................................16 4.1 Diseño.................................................................................................................16 4.2 JavaHelp.............................................................................................................16

5. Tutorial...................................................................................................................20 5.1 Diseño.................................................................................................................20 5.2 Captivate ............................................................................................................20

6. Propuestas Entrega de Tareas........................................................................22 6.1 Motivac ión y Factores a Tener en Cuenta ....................................................22 6.2 Posibilidades con LOGS2005 .........................................................................22 6.3 Posibilidades con cambios a LOGS2005......................................................23 6.4 Propuesta Final .................................................................................................24

7. Conclusiones .......................................................................................................26

ANEXOS ........................................................................................................................27

A. Valoración del LIDIE..............................................................................................27 PROYECTO AVA UNIVERSIDAD DE LOS ANDES ...........................................27 VALORACIÓN SISTÉMICA DE SOFTWARE EDUCATIVO..............................27 DATOS BÁSICOS .....................................................................................................27

Documento Propuesta Ciclo Terminal 1....................¡Error! Marcador no definido.

B. Guía par a las Monitorías de Capacitación en LOGS para HDF 2006-1 ...30

C. Helpset del Manual................................................................................................33

D. Mapa del Manual ....................................................................................................34

E. Tabla de Contenidos del Manual (TOC)...........................................................34

4

Bibliografía ...................................................................................................................38

5

Cómo leer este documento Este documento está estructurado por capítulos, en los que se muestran los diferentes desarrollos realizados durante el trabajo de tesis. Para facilitar la lectura y la comprensión del documento se han definido niveles de complejidad de lectura, así:

Nivel 0: Visión global del proyecto. Se deben leer el capítulo 0 (Introducción) y el capítulo 7 (Conclusiones).

Nivel 1: Nivel 0 más la lectura del resumen de todos los capítulos que se encuentra al inicio de cada uno.

Nivel 2: Nivel 1 mas la lectura del capitulo 1 (LOGS), el capítulo 2 (Trabajo de Análisis con el LIDIE) y el anexo A.

Nivel 3: Nivel 2 mas la lectura del capítulo 3 (Uso de LOGS en HDF en el semestre 2006-1), el Anexo B y el capítulo 6 (Entrega de Tareas).

Nivel 4: Lectura de todo el documento.

6

0. Introducción

Se muestra una idea global de los antecedentes que llevaron a la realización del proyecto, y se explica brevemente el trabajo en general.

En 1999 se ingresaron al currículo de la carrera de Ingeniería de Sistemas y Computación de la Universidad de los Andes las asignaturas “Herramientas de Deducción Formal” (HDF) y “Fundamentos de las Ciencias de la Computación” (FCC), en las cuales se estudia cómo la lógica puede ser una herramienta útil para la programación. Para estos cursos se decidió usar como texto guía [Gri1993], el cual desarrolla estas ideas desde un punto de vista de lógica ecuacional. En el grupo de Métodos Formales, que usualmente administra estos cursos, se inició un proyecto que tenía como fin desarrollar una herramienta computacional que apoyara a estudiantes y profesores en la enseñanza y en el aprendizaje de la materia. La herramienta se denominó LOGS, nombre que proviene de “LÓgica de Gries y Schneider” dado que se basa en [Gri1993]. Se dio inicio al proyecto con la tesis de Carlos Noguera, Camilo Sarmiento y Carlos Tovar el 2001, “LOGS: Editor de Demostraciones en Lógica Ecuacional” [Nog2001], en el cual se dio el primer paso para el desarrollo de la herramienta utilizando lo básico de la lógica ecuacional. Al año siguiente, en el 2002, se prosiguió con la tesis de Andrea Rubiano, “LOGS: revisión y reingeniería de la aplicación” [Rub2002], en le que se realizó una reingeniería de la aplicación, revisando los módulos existentes e insertando un nuevo módulo que trabajara con lógica proposicional. En el año 2005 Alejandro Sotelo retomó el trabajo previo y en su tesis “LOGS2005: Editor de Demostraciones en Lógica Ecuacional” [Sot2006] rediseñó la herramienta de manera que se hizo posible su uso en la enseñanza y el aprendizaje de los cursos. Teniendo el resultado de [Sot2006] se encontró la necesidad de establecer procedimientos para adaptar la aplicación para ser usada en HDF y FCC. Esto condujo a pensar en formas de acercar los estudiantes a la herramienta de forma que la usaran para estudiar y hacer tareas y, eventualmente, utilizarla como medio de presentación de trabajos. Teniendo en cuenta estas inquietudes, se planteó la necesidad de hacer pruebas en los cursos de forma que se viera el impacto que podía tener el uso de LOGS en ellos, empezando por el más básico que es HDF. Uno de los usos principales para LOGS es el de ser un apoyo para la principal forma de trabajo que se ha utilizado en los cursos, la cual es la entrega de tareas. Por esta razón también era necesario definir formas de presentar las tareas que se asignaran durante los semestres, incluyendo cómo presentar los enunciados y las tareas resueltas por los alumnos.

7

Por otro lado, para facilitar el acercamiento a la aplicación se decidió proveer un manual y un tutorial que guiaran al estudiante durante el proceso de aprendizaje de LOGS. El manual, en lo posible, debía estar en línea. A través del documento se explica cómo se desarrollaron soluciones para resolver estas necesidades y cuáles fueron los resultados del trabajo realizado. En el capítulo 1 se resumen las principales características de LOGS2005, la herramienta desarrollada en [Sot 2006] en la que se basó este proyecto. En el capitulo 2 se muestra el análisis que se realizó para definir el alcance del proyecto. En el capítulo 3 se muestran y recopilan los resultados del uso de LOGS en HDF durante el semestre 2006-1. En el capítulo 4 se explica la estructura y el contenido del manual, así como su metodología de construcción. En el capítulo 5 se explica como se realizó el tutorial. Por último, en el capítulo 6 se definen diferentes formas de entregar las tareas apoyados por LOGS y cual es la mejor de todas.

8

1. LOGS

LOGS2005 es la última versión de LOGS, resultado de [Sot2006]. Se presentan las características y funcionalidades que la aplicación presenta, y que sirvieron como base para el desarrollo de este proyecto.

Teniendo en cuenta que para las materias HDF y FCC es necesario el uso de LOGS2005, la herramienta ofrece la posibilidad al usuario de crear tipos, es decir, conjuntos de valores que puede tomar una variable. Los tipos pueden tener las siguientes características:

• Ser genéricos, es decir, no se sabe exactamente que tipos son hasta que sean usados.

• Representar conjuntos o bolsas y permitir que se puedan escribir por enumeración o por comprensión.

• Contener constantes. • Tener asociadas funciones que a partir de otros tipos construyan una

parte de sus elementos. Por otro lado, se pueden crear teorías relativas a los tipos en las que se pueden definir:

• Operadores con algunas propiedades que pueden ser usadas sin necesidad de axiomas como, por ejemplo, la simetría.

• Axiomas y teoremas relativos al tipo correspondiente, y las demostraciones de estos teoremas.

• Si una teoría es genérica, es decir, es válida para diferentes tipos, se pueden declarar tipos y funciones genéricas que la soporten.

En cuanto a las demostraciones, LOGS2005 contiene las siguientes funcionalidades:

• Demostraciones para el cálculo proposicional y el cálculo de predicados. • Pruebas que usen las técnicas del capítulo 4 de [Gri1993] • Permite al usuario introducir pasos que no están soportados por LOGS

mediante el uso de operadores transitivos, por ejemplo, decir que al pasar de una expresión a otra por “Aritmética” es válido.

• Por medio de semáforos (imágenes de círculos de colores) indicar el estado de una demostración.

• No permite al usuario cometer el error de realizar demostraciones circulares, es decir, demostraciones en las que se use un teorema en el cual se usó el teorema que se está demostrando.

• Exportar una demostración a formato HTML. También permite usar caracteres que el usuario necesite y administrarlos definiendo categorías.

9

2. Trabajo de análisis con LIDIE

El Laboratorio de Investigación y Desarrollo sobre Informática Educativa de la Universidad de los Andes (LIDIE) apoyó en el análisis de la herramienta LOGS con el objetivo de usar la aplicación en la enseñanza y el aprendizaje de HDF. Se muestran los resultados del análisis de LIDIE y las propuestas que hicieron, así como los resultados propios del presente este trabajo. Finalmente, se explican las conclusiones a las que se llegó y por qué se tomaron las decisiones que definieron el uso que se quiere para LOGS como apoyo al curso HDF.

2.1 M otivación y modo de trabajo El Laboratorio de Investigación y Desarrollo sobre Informática Educativa de la Universidad de los Andes (LIDIE) a través de su proyecto de Ambientes Virtuales de Aprendizaje (AVA) se encarga de crear herramientas computacionales de apoyo a los cursos de la universidad. Por esta razón, el grupo de Métodos Formales buscó el apoyo de LIDIE en el desarrollo de este proyecto dado que ellos tienen experiencia en temas de educación apoyada por aplicaciones informáticas. Durante el semestre 2005-2 se realizó un análisis de LOGS conjunto con LIDIE, en el que se evaluó la herramienta y se plantearon usos de la aplicación en el curso HDF. Durante el 2006-1, LIDIE apoyó al proyecto en la revisión del manual y el tutorial, e hizo un seguimiento del uso que se le dio a la aplicación durante el semestre.

2.2 Propuestas del proyecto Las propuestas que se hicieron para el proyecto fueron:

• Manual y Tutorial: Realizar un manual y un tutorial que apoyen a los usuarios en el aprendizaje y en el uso de la herramienta.

• Importación de librerías: [Gri1993] se aborda por temas durante el curso; por lo tanto, es importante poder importar las librerías (de las que se hablará mas adelante) incrementalmente, de acuerdo con el tema del curso en el que el usuario esté trabajando.

• Versión profesor: Modificar LOGS2005 de forma que permita al profesor plantear ejercicios con enunciados no modificables, para evitar malos usos de la herramienta al resolver los problemas planteados.

• Documentación del código: El código de LOGS2005 no está suficientemente documentado, por lo que es difícil de mantener. Por lo tanto debe documentarse.

10

• Propuesta de tareas: Analizar formas de realizar las tareas y proponer una como la mejor opción.

• Exportación de documentos: Reparar las fallas que existen en la exportación de documentos de LOGS2005 a formatos pdf, rtf y html.

• Librerías: Crear librerías con los axiomas y teoremas de [Gri1993] para que se puedan usar en los ejercicios sin tener que introducirlas ni probarlas manualmente.

2.3 Propuestas del LIDIE Las personas que designó el LIDIE para este proyecto fueron Martha Luz Arango del grupo pedagógico, y Gerardo Tibaná del grupo de diseño institucional. Luego del trabajo de análisis conjunto que se realizó entregaron una valoración en donde muestran que se debe mejorar según su criterio. El Anexo A contiene el reporte de esta valoración. Las conclusiones fueron las siguientes:

• Pantallazos sobrecargados: En LOGS, cuando se desea ver la definición o el contenido de un objeto este abre una nueva ventana en el área de trabajo de la aplicación. Por esta razón el número de ventanas puede llegar a ser alto y no hay forma de volver a las ventanas que están mas abajo directamente.

• Textos del programa editables, documentar código: El código no tiene documentación, por lo tanto no se sabe donde se crean los textos y esto causa que no sea fácil hacer cambios cuando sea necesario.

• Funciones de apoyo al profesor: Se pensó en la posibilidad de crear una versión de LOGS en la que el profesor pueda crear los enunciados de las tareas de forma que se minimice la posibilidad de fraude y copia, a partir de las propuestas anteriormente citadas en 2.2.

• Librerías no disponibles: Dado que al desarrollar ejercicios en LOGS se usan los axiomas y teoremas del libro [Gri1993], debería existir una forma de obtenerlos sin tener que escribirlos manualmente.

• Manual y tutoriales: Hace falta un manual que explique la aplicación y un tutorial que guíe en el proceso a los usuarios.

2.4 Decisiones sobre las propuestas y resultados Después de tener las propuestas y durante el tiempo que duró el proyecto se encontraron puntos que no eran pertinentes para el proyecto. A continuación se muestran las propuestas que se desarrollaron y sus resultados, y el porque de no desarrollar las otras propuestas.

2.4.1 Propuestas desarrolladas • Creación de librerías: Fueron creadas las librerías de los capítulos 3, 8 y

9 de [Gri1993].

11

• Manuales y tutoriales: Se desarrollo un manual y un tutorial. El desarrollo de estos se explican en los capítulos 4 y 5 de este documento.

• Importación de documentos y versión profesor: Dado que la implementación de estas 2 propuestas dependía de la propuesta de entrega de tareas, se desarrollaron como parte de este análisis. Se explican en el capítulo 6 de este documento, en la tercera parte del capítulo.

• Exportación de documentos: Durante el desarrollo de este proyecto, Alejandro Sotelo se encargó de arreglar los problemas que tenía esta funcionalidad.

2.4.1 Propuestas no desarrolladas • Pantallazos sobrecargados: Al ir abriendo las diferentes ventanas en

LOGS se desarrolla una linealidad. Por esta razón el proceso normal es que una ventana anterior se necesita solo luego de terminar con la que se abrió posteriormente. Por lo tanto este punto no era crucial.

• Documentación del código: El código de LOGS2005 fue desarrollado por Alejandro Sotelo en [Sot2006] y por esta razón el es quien realmente puede hacer una buena documentación del código de la aplicación.

12

3. Uso de LOGS en HDF en el semestre 2006-1

En el semestre 2006-1 se hizo una primera prueba del uso de LOGS en HDF. Con LOGS2005, es decir, la versión resultado de [Sot2006], y una primera versión del manual y se ofreció la oportunidad de usar la aplicación para la entrega de tareas. Se muestra el proceso que se llevó a cabo durante el semestre, en qué consistieron las monitorías que se realizaron, cómo funcionó la prueba y cuáles fueron los resultados que se obtuvieron al finalizar el semestre, incluyendo los resultados obtenidos por LIDIE.

3.1 Plan Parte del resultado que se quería obtener a partir de este proyecto era ver como se podía usar la aplicación para la entrega de las tareas en HDF. De esa forma se hace posible corregir los errores que se hayan presentado, y eventualmente poder usarla en FCC. El uso de LOGS no es intuitivo. Dado que su funcionalidad es técnica, adaptarse a él se puede volver complicado. Por esta razón era importante dar a los usuarios, que en este caso eran los alumnos, ayudas y capacitaciones que los iniciaran en el uso de la herramienta. El manual y el tutorial son las ayudas permanentes que van a tener los usuarios de LOGS, pero como al iniciar el semestre estas ayudas todavía estaban en versiones preliminares, era importante ofrecer las capacitaciones. Para eso se decidió que los monitores ofrecieran monitorías. Después de las monitorías se propuso un foro en el sistema de cursos de la universidad (SICUA), el cual fuera moderado por una persona que conociera apropiadamente la herramienta. En este foro los alumnos podían resolver todas las dudas que surgieran al usar LOGS. Dado que el uso de la aplicación durante el semestre era una prueba, se dio la oportunidad a los alumnos de escoger entre el uso de LOGS y el uso del método tradicional, es decir, resolver las tareas en Word.

3.2 Monitorías

3.2.1 Planeación previa Para poder desarrollar las monitorías era importante hacer una planeación previa. Esta planeación consistió en revisar las funcionalidades básicas de LOGS y lo que debe conocer un usuario primerizo para poder usar el programa; a partir de estas funcionalidades se procedió a hacer una lista de prioridades entre ellas y desarrollar una forma de explicarlas de la manera más fácil posible. El resultado de esa planeación fue una serie de pasos que se debían seguir durante el desarrollo de la monitoría. Los pasos fueron los siguientes:

13

• Explicar que hay en la pantalla inicial. • Adicionar un nuevo mundo. • Adicionar un nuevo tipo. • Adicionar una nueva teoría. • Adicionar una nueva función. • Explicar tipos y funciones parámetro. • Adicionar nueva carpeta. • Crear nuevos axiomas y teoremas. • Explicar como funcionan los semáforos. • Resolver ejercicios.

3.2.2 Monitoría para monitores Para el semestre 2006-1 se dictaron 4 secciones de HDF, en las que ayudaron 4 monitores. Estos monitores se debían encargar de las monitorías para los alumnos, pero como LOGS es una herramienta nueva 2 de los monitores y la profesora de las clases complementarias de la materia tampoco la conocían. Por esta razón se decidió hacer unas capacitaciones previas a estas 3 personas, lo que sirvió para probar la planeación que se tenía antes de usarla con los alumnos, quienes finalmente eran los que iban a usar la herramienta

3.2.3 Planeación final Sobre la planeación previa se encontró que hacía falta explicar cómo funciona el administrador de caracteres, por lo que primero se insertó entre las explicaciones de los tipos y las teorías, pero al probarlo se vio que era necesario explicarlo antes de adicionar los tipos ya que al trabajar con ellos se usan caracteres especiales obtenidos de las teorías. Para los monitores que solo habían tenido acercamientos a LOGS por medio de las monitorías para monitores era difícil seguir solos esos pasos. Para ayudarlos en el proceso se diseñó una guía apoyado por la versión 0 del tutorial, que al haber sido hecha a partir de la planeación previa de las monitorías, abarcaba los mismos puntos. La guía que se les entregó a los monitores se encuentra en el anexo B. En ella se habla de un video. Ese video es la versión 0 del tutorial. El lenguaje es un lenguaje cotidiano para que los monitores no se sientan intimidados, esto por su poco conocimiento de la herramienta. Al hacer la guía en lenguaje cotidiano le da un aire de familiaridad que permite su aceptación.

3.3 Resultados En un principio se planeó que cada monitor dictara una sola monitoría, pero finalmente se dictaron 9 monitorías en total distribuidas entre los 4 monitores. Las monitorías extras se dictaron por la falta de asistencia de los alumnos dado que a la monitoría a la que mas personas fueron tuvo 10 asistentes. La razón principal de la falta de asistencia fue la dificultad con los horarios, es decir, los horarios en que se programaron las monitorías, aunque eran variados, no les

14

sirvieron a algunas personas porque tenían clase a esas horas. Se propuso crear una conversación en el foro para proponer horarios para nuevas monitorías, pero solo respondieron 2 personas y pidiendo horarios diferentes. Gary Cifuentes, del grupo de evaluación del LIDIE, hizo una encuesta sobre el impacto de LOGS en la materia. Las preguntas de la encuesta fueron:

1. ¿Considera que la capacitación en la herramienta LOGS a comienzos del semestre, le sirvió para comprender su objetivo y la forma correcta de usarla para realizar las actividades del curso?

2. La herramienta LOGS permite contar con un editor de texto que le facilita la creación de un banco de caracteres común y eficiente para la presentación de trabajos. ¿Tenía conocimiento de esta funcionalidad? De ser así, ¿Cómo fue su uso? ¿Un banco para cada taller o se iba construyendo sobre un banco inicial?

3. ¿De qué manera cree que el uso de LOGS pudo influir en el desarrollo o la adquisición de habilidades necesarias para el entendimiento y aprobación del curso?

4. ¿Considera que los indicadores de demostración (por colores) eran una buena retroalimentación del proceso de demostración que usted llevaba a cabo?

5. ¿Consultó usted alguna vez el manual de usuario y/o el Tutorial de la herramienta LOGS? Si fue así ¿Qué aporte le brindaron?

6. Si alguna vez lo intentó, ¿Tuvo dificultades para subir/exportar los mundos que usted creaba por medio de LOGS?

7. ¿Cuál es su opinión personal sobre la herramienta?

Aunque los resultados de la encuesta no estuvieron listos al finalizar este proyecto, a partir de las respuestas de los alumnos y las preguntas que hicieron en el foro podemos ver algunas opiniones comunes, con las que se puede llegar a las siguientes conclusiones que muestran las dificultades que se presentaron:

• Para demostrar un teorema se usan axiomas o teoremas, y estos últimos deben ser demostrados previamente. Al hacer las tareas no se exige mostrar las demostraciones de los teoremas que se usan, solo que su uso sea pertinente y de el resultado esperado. Por el mecanismo de semáforos de la herramienta los alumnos creían que al hacer las tareas en LOGS debían demostrar todos los teoremas y esto les implicaba mucho trabajo extra. Esta creencia se daba porque al no haber demostrado el teorema usado la demostración no quedaba verde, pero esto no era necesario.

• Como la versión 0 del tutorial era una ayuda para las monitorías, solo se distribuyó en estas por lo que muchas personas no conocían su existencia. Quienes si lo usaron sintieron los beneficios de tenerlo.

15

• El uso del manual fue muy bajo, y aunque algunas personas si se beneficiaron por su existencia, la mayoría de las opiniones fueron negativas dado esas personas solo tuvieron acceso al manual y no fueron a las monitorías, y al ser una versión preliminar era muy técnico y sin ejemplos.

• Al no ser obligatorio el uso de LOGS para la entrega de tareas, las personas que usaron la aplicación preferían cambiar de herramienta a la primera dificultad, que seguir intentando.

• Como las monitorías se centraron en lo básico de la herramienta, cuando el tema de la materia se tornó mas complicado los alumnos no sabían como usarla.

3.4 Propuestas para el futuro Para futuros semestres se propone hacer obligatorio el uso, para de esa forma alentar a los alumnos a aprender a usar la herramienta. También se recomienda, además de las monitorías iniciales, al iniciar el tema de cuantificaciones hacer una explicación de cómo escribirlas en LOGS. No necesariamente se tienen que hacer en monitorías, se puede explicar en las clases dado que es un tema corto. Por último, al usar LOGS para diseñar las clases magistrales y los enunciados y soluciones de las tareas, los alumnos pueden ver para que sirve la herramienta y eso les puede dar una guía y motivación para usarla. Sobre la forma de entregar las tareas se habla en el capítulo 6.

16

4. Manual

En este capítulo veremos los pasos que se realizaron para el diseño y la elaboración del manual de LOGS, como se usa la herramienta JavaHelp y porque se usó para la elaboración del manual y el resultado obtenido.

4.1 Diseño Para hacer el manual de LOGS se dividió el proceso en 3 fases. La primera fase consistió en tomar la planeación previa que se realizó para las monitorías de capacitación en LOGS (Sección 3.2.1) y a partir de ese plan se diseñó una serie de archivos en formato HTML que mostrara las partes básicas del plan sin mostrar ningún ejemplo. Esta versión del manual se llamó la versión 0. La siguiente fase consistió en adaptar la segunda versión de tal forma que se pudiera ver directamente desde la aplicación. Para esto se usó la herramienta JavaHelp de la que se hablará mas adelante. En la última fase se arreglaron los contenidos de la versión 0 del manual para dejar una versión definitiva. Después de una evaluación hecha por Gerardo Tibaná del LIDIE, se hicieron cambios al contenido de tal forma que mostrara de manera mas eficaz lo que se quería decir, y se cambiaron los HTML de herramienta dado que en un principio se realizaron en Word y esta agrega tags propios que sobran al usarlos en JavaHelp. Se decidió realizarlos en Dreamweaver.

4.2 JavaHelp

4.2.1 Motivación JavaHelp es una herramienta realizada por Sun [JavaHelp], que permite hacer manuales para aplicaciones y adaptarlos a la aplicación. Dado que LOGS es una herramienta hecha en Java, JavaHelp era una buena opción para adaptar el manual de la herramienta. Para crear un manual solo se necesitan archivos en formato XML que definen la organización del manual (Para el manual de LOGS se usaron el helpset, el mapa, la tabla de contenidos y el índice), los archivos en formato HTML que presentan el contenido y unas pocas líneas de código en el código de la herramienta para que esta despliegue el manual. También permite ayudas relativas al contexto, es decir, relacionadas con las actividades que realiza el usuario, pero no se usaron en este caso. Cualquier información extra se encuentra en el manual que viene con JavaHelp. Este se puede bajar de la página oficial [JavaHelp]. La versión que se usó para hacer el manual de LOGS es la versión 2.0.

17

4.2.2 Helpset El archivo helpset es el archivo que identifica que tiene el manual. Por medio de tags XML se puede decir que vistas debe tener y donde encontrarlas. Las vistas que pueden tener son una tabla de contenidos, un índice, una búsqueda, un glosario, y una página de favoritos. También debe tener un tag que defina donde está el mapa de los HTMLs con el contenido del manual. El helpset para el manual de LOGS se puede ver en el anexo C. Este muestra el título, donde encontrar el mapa, la tabla de contenidos y el índice. La siguiente imagen muestra como se ve la ayuda de LOGS:

4.2.3 Mapa El mapa contiene referencias a los archivos HTML y a partes específicas de estos a los que se les asignan nombres para referirse a ellos en la tabla de contenidos, el índice, el glosario y los favoritos. El mapa del manual de LOGS se puede ver en el anexo D.

4.2.4 Tabla de Contenidos (TOC) A la tabla de contenidos se le llama TOC por sus siglas en inglés (Table Of Contents). En ella se despliegan los contenidos del manual en forma de árbol. A cada uno de los elementos del TOC se le asigna un texto y una referencia del mapa. Estos pueden abrirse en más tópicos que se designan de la misma forma.

18

El TOC del manual de LOGS se puede ver en el anexo E. La siguiente imagen muestra la tabla de contenidos del manual:

4.2.5 Índice El índice presenta una serie de temas que pueden interesar al usuario. Estos se designan de la misma forma que en el TOC, asignándoles un texto y una referencia del mapa. El índice del manual de LOGS se puede ver en el anexo F. Este se ve en la siguiente imagen:

19

4.2.6 Integración a la aplicación Para integrar el manual a la aplicación se debe crear un item nuevo en el menú de esta que tenga un actionListener que despliegue el manual. El menú de LOGS está definido en la clase MyMenuBar. Esta tiene un arreglo de ítems al que se le añadió el item que desplegará el menú. Después de esto se añadió el siguiente código:

URL url = new URL("file:data/Manual/logshelpset.hs"); HelpSet hs = new HelpSet(null, url); HelpBroker hb = hs.createHelpBroker(); botones[9].addActionListener(new CSH.DisplayHelpFromSource(hb));

El atributo “url” corresponde a la dirección donde se encontrará el archivo con el helpset del manual, el atributo “hs” designa el helpset y el atributo “hb” es quien maneja que debe hacerse con el helpset para desplegar el manual. “botones[9]” es el item al que se va a asociar el menú y a este se le crea el actionListener. HelpSet, HelpBroker y CSH son clases del API de JavaHelp, por lo tanto de debe asociar la librería jhall.jar al proyecto. La librería se encuentra en el directorio %JavaHelp_Home%/javahelp/lib/. Las siguientes imágenes muestran el nuevo item del menú y como se ve la ayuda en LOGS:

20

5. Tutorial

Se muestran los pasos que se realizaron para el diseño y la elaboración del tutorial de LOGS, como se usa la herramienta Captivate y porque se usó para la elaboración del tutorial.

5.1 Diseño Para la realización del tutorial se usó la planeación final que se realizó para las monitorías de capacitación en LOGS que se dictaron durante el semestre 2006-1 para la materia HDF, que se encuentra en el Anexo B. Se decidió usar esta guía porque un tutorial es como una monitoría dictada por el computador. Se hizo una versión 0 que solamente mostraba lo que se debía hacer y no permitía interactividad del usuario. Esta versión se realizó para conocer el funcionamiento de la herramienta Captivate, de la cual se hablará mas adelante, y para el apoyo de las monitorías. Solo tuvieron acceso a este tutorial los monitores y las personas que asistieron a la monitorías dado que era un video de lo que se debía hacer en ella y solo lo podía entender alguien que conociera la herramienta previamente. Lo más importante a tener en cuenta para hacer esta versión era que siempre que se encuentren cosas nuevas las explicara, y que además mostrara un ejemplo de cada punto básico que debía mostrar el tutorial. Al analizar lo que pasó con las personas que usaron la versión 0 se encontró una falla del tutorial y es que el ejemplo que mostraba era un ejercicio del libro, por lo tanto no permitía usarlo para otras cosas durante el curso ni permitía al usuario resolverlo por su cuenta. Por esta razón se decidió cambiar el ejemplo por un ejercicio que estuviera desarrollado en el libro y de esta forma no se creaba conflicto entre el libro guía de la materia y de la herramienta con la herramienta. Al tener la idea final se pasó a realizar el tutorial en la herramienta escogida.

5.2 Captivate Captivate es una herramienta de Macromedia [Captivate] diseñada para grabar el funcionamiento de aplicaciones. Permite hacer demostraciones, tutoriales interactivos, cuestionarios, y los convierte en animaciones de Flash. Dado que Flash es una herramienta muy usada, Captivate era una excelente opción para desarrollar el tutorial de LOGS. Se supo de esta herramienta por recomendación de Gerardo Tibaná del LIDIE. Se optó por hacer un tutorial interactivo, es decir, que el usuario sea quien seleccione las cosas que se deben seleccionar, y no sea el tutorial quien se las muestre.

21

Captivate permite grabar la interacción con una herramienta guardándola en forma de slide show. Por cada interacción con el usuario se graba un snapshot, pero el desarrollador del tutorial puede capturar más snapshots con la tecla “Imprimir Pantalla”. Se permite cambiar el idioma de los textos, por lo que se escogió el español para el tutorial. Al haber escogido la opción de hacer el tutorial interactivo no se guardan los movimientos del mouse, como si se capturarían en una demostración como la que se hizo para la versión 0 del tutorial. También se crean espacios donde se debe hacer clic y 2 cuadros de texto que indican donde está ese espacio, uno que se muestra cuando el cursor está sobre el espacio, y otro que se muestra cuando se hace clic por fuera. Luego de capturar la animación esta se puede editar poniendo textos a los snapshots, añadir animaciones, imágenes, manejar tiempos, y muchas otras cosas. Para el tutorial de LOGS se usó el manejo de tiempos para que los textos pudieran ser leídos completamente. También se usó la opción de usar slides de PowerPoint para poner títulos e instrucciones para nuevos temas. Finalmente se reacomodaron los espacios autogenerados por Captivate y los cuadros de texto que decían donde hacer clic, y se agregaron bordes que resaltaran los espacios. La forma de trabajo escogida fue intercalar la grabación con la edición, de tal forma que el número de slides sin editar fuera manejable. Esto se debió a que al hacer una grabación se captura una gran cantidad de slides y esto causa problemas como, por ejemplo, cuando ocurre un error que no se notó al grabar, pero si se notó al editar, se hace necesario volver a grabar todos los slides se capturaron después del error.

22

6. Propuestas Entrega de Tareas

Se muestran las diferentes formas que se encontraron para realizar los enunciados y desarrollar las tareas, la forma que se decidió que sería la mejor para aplicar en un futuro y por que se tomó esa decisión.

6.1 M otivación y Factores a Tener en Cuenta La entrega de tareas de HDF era un tema muy importante para el proyecto. Por esta razón se evaluaron diferentes posibilidades que se tenían con LOGS2005, es decir, en el estado en el que estaba luego del desarrollo en [Sot2006]. También se evaluaron, a partir del análisis con el LIDIE (Capítulo 2), cambios posibles para la herramienta de manera que se pudiera hacer un mejor uso de ella para este propósito. El proceso de una tarea responde al siguiente flujo:

• Definición del enunciado, por el profesor. • Solución de la tarea, por el alumno. • Calificación, por el monitor.

Es importante tener en cuenta estos 3 pasos al pensar en cómo se puede usar LOGS en el proceso. Otro factor a tener en cuenta es qué usar cuando no se use LOGS. Esto pasa con algunos ejercicios que solo deben ser narrados y no resueltos en la forma que usan [Gri1993] y LOGS. La mejor opción sería usar un documento, ya sea en Word, pdf, LaTeX, o cualquier otra forma de escribir textos. Para referirse a estos se usará la palabra ”documento”.

6.2 Posibilidades con LOGS2005 A continuación se muestran las posibilidades que se evaluaron por niveles de acuerdo al uso de LOGS que se dé en cada una: No Enunciado Entrega 0 Documento con el enunciado de

todos los puntos. Documento con las respuestas del alumno.

1 Documento en el que se especifica que ejercicios se deben hacer LOGS y cuales no.

Los ejercicios que no se pueden hacer en LOGS se entregan en un documento y los que si se pueden hacer en LOGS se entregan en un mundo creado en LOGS.

2 Documento en el que se especifica que ejercicios que no se deben hacer en LOGS y un mundo de LOGS que

Los ejercicios que no se pueden hacer en LOGS se entregan en un documento y los que si se pueden hacer en LOGS se entregan en el

23

únicamente contiene los enunciados de los ejercicios a resolver.

mundo del enunciado con los ejercicios resueltos.

3 Documento en el que se especifica que ejercicios que no se deben hacer en LOGS y un mundo de LOGS que contiene los enunciados de los ejercicios a resolver y las librerías hasta el tema que corresponde.

Los ejercicios que no se pueden hacer en LOGS se entregan en un documento y los que si se pueden hacer en LOGS se entregan en el mundo del enunciado con los ejercicios resueltos.

La forma 0 es como se ha venido haciendo tradicionalmente la entrega de tareas desde que empezó a dictarse HDF y FCC y La forma 1 es la que se usó para la prueba que se hizo en el semestre 2006-1 en HDF conjunto con la forma 0 (Capítulo 3). La calificación se debería realizar de forma que lo que se halla entregado en un documento quede corregido en el mismo y se anexen comentarios con respecto a lo entregado en un mundo de LOGS. La principal ventaja para el monitor de calificar mundos en LOGS es la facilidad que presenta la herramienta para entender las demostraciones, ya que estas se realizan en formato único.

6.3 Posibilidades con cambios a LOGS2005 Las siguientes son posibles modificaciones a LOGS2005 que podrían eventualmente mejorar el proceso de entrega de las tareas.

6.3.1 Bloqueo de enunciados Bloquear los elementos que compongan el enunciado con el fin de eliminar la posibilidad de que sean modificados. Estos elementos serían principalmente los axiomas, teoremas y teoremas enunciado (ejercicios a resolver), pero también sería prudente bloquear los tipos y las teorías creadas por el profesor. Para este fin se puede usar una bandera (booleano) que indique si es modificable o no y replicar la misma forma en que los tipos booleanos, naturales y enteros positivos y la teoría “Expresiones Booleanas” se definen como predefinidos y no son modificables. Para que el profesor pueda bloquear los elementos que desee se debe crear una versión profesor, correspondiente a la nueva versión propuesta durante el análisis de LOGS hecha con el LIDIE (Capitulo 2). Esta tendrá un botón en cada uno de los administradores necesarios (Teorías, Tipos y en el árbol de Axiomas/Teoremas) que activa o desactiva la bandera de bloqueo del elemento en cuestión.

24

6.3.2 Inserción de un mundo en otro Insertando un mundo en otro mundo se pueden añadir los enunciados de las tareas a un mundo previamente creado. Estos mundos deben estar constituidos de forma que únicamente contenga lo necesario para que cada uno de los teoremas sea válido. La forma en que se debe insertar el mundo es la siguiente:

• Por cada elemento revisar si ya existe en el mundo. • Si no existe validar su posible ingreso. • Si no se puede ingresar se debe avisar al usuario cual fue el problema. • Si es posible, se debe permitir realizar los cambios necesarios para

poder añadir todo el enunciado. Por efectos de prevención de copia no se debe permitir insertar los documentos de demostración de un mundo en otro ya que esto les da la posibilidad a los alumnos de tomar las soluciones de sus compañeros e introducirlas en sus respuestas. Esta propuesta también permite insertar librerías a un mundo si se tienen las librerías formadas como mundos.

6.3.3 Operaciones Sobre Mundos Otra propuesta es hacer funciones que sumen y resten mundos. Sumar mundos consiste en tomar un mundo y añadirle elementos de otro mundo (El otro mundo puede no ser válido) revisando que toda inserción sea válida. Al restar un mundo de otro (Los 2 deben ser válidos) se debe obtener todos lo elementos que contenga un mundo y que no contenga el otro. Esto, al aplicarlo a la entrega de tareas se traduce en los siguientes pasos:

• El profesor crea el enunciado en un mundo de LOGS. • El alumno resuelve los ejercicios y al mundo con las respuestas le resta

el enunciado. Con esta resta obtiene únicamente los cambios que realizó y eso es lo que entrega al monitor.

• El monitor suma la tarea del alumno al enunciado y califica los cambios que se hicieron.

6.4 Propuesta Final En cuanto a las posibles formas de entregas de tareas con LOGS2005 y viendo los resultados obtenidos en el semestre 2006-1 y las respuestas a la encuesta que se realizó y a la cual se hace referencia en el capítulo 3, se define la forma 3 como la más completa y la que más puede aportar al alumno. Esto se da por que es más práctico para el alumno ver el enunciado en LOGS y resolverlo directamente, y además resuelve el problema que se presentó con la falta de librerías y que el LIDIE había presentado en su análisis (Capítulo 2).

25

Cuando el enunciado se componga de mundos de LOGS se recomienda que los problemas a resolver estén en una carpeta que diga claramente que su contenido son los enunciados de la tarea. Modificando LOGS2005 se ve que la mejor propuesta es la 3 dado que las propuestas 1 y 2 se necesitan mutuamente para poder suplir las principales necesidades que se quiere arreglar con las modificaciones. En cambio la propuesta 3 reduce la posibilidad de fraude dado que para el monitor es claro que cambios se hicieron al enunciado y es más fácil de comparar con otras tareas. Esta propuesta también hace posible insertar librerías sumándolas a otros mundos.

26

7. Conclusiones A partir del trabajo realizado con el LIDIE se estableció que, basándose en en los resultados obtenidos en [Sot2006], era necesario hacer pruebas de la aplicación en HDF, desarrollar un manual, un tutorial, y definir el desarrollo de las tareas con LOGS. El manual y el tutorial se diseñaron a partir de monitorías que se dieron a los estudiantes durante la prueba que se hizo en el semestre 2006-1. El diseño de las monitorías se realizó pensando en las funcionalidades básicas de LOGS y, definidos por estas funcionalidades, se pensó en los conocimientos básicos que se necesita saber para poder usar la herramienta. En el manual se logró desarrollar esas funcionalidades de forma clara. El manual implica un gran apoyo para el usuario de LOGS, dado que va a ser un apoyo constante en el que se encuentran las respuestas a las dudas que el usuario pueda generar a medida que usa la aplicación. También es importante agregar que al haber quedado embebido en la aplicación es la razón para que sea ese apoyo constante, dado que el acceso a este se facilitó. Con el tutorial el aprendizaje y la adaptación se hacen más fáciles. Al estar basado en el diseño que se hizo a partir de las funcionalidades básicas de la aplicación y de los conocimientos necesarios para usarla, hace que el usuario pierda el miedo que genera el uso de algo nuevo. Dado que el tutorial es interactivo, hace que el usuario sienta que está haciendo un uso guiado de la aplicación, como si estuviera en una monitoría personalizada, y de esa forma ya sabrá que hacer al usar la aplicación real. Por otro lado, después de un largo análisis sobre las formas en que se podía usar la herramienta y de idear mejoras posibles para hacer que la entrega de tareas sea más productiva, se llegó a una idea en la que se aminora la posibilidad de problemas en el diseño de los enunciados, el desarrollo y la corrección de las tareas. Para el futuro se debe desarrollar las 3 versiones definidas en el capítulo 6 para la entrega de las tareas (profesor, alumno y monitor), de tal forma que sea posible usar la mejora en los cursos. Al desarrollar estas versiones de LOGS se hace necesario modificar el manual para explicar las mejoras realizadas, idealmente en 3 versiones del manual correspondientes a las 3 versiones de la aplicación. El tutorial solo muestra las funcionalidades básicas de la aplicación, por lo que es importante realizar otros, que muestren funcionalidades mas avanzadas y que, además, cuando ya estén las 3 versiones de LOGS, muestren cómo usar las modificaciones hechas a la aplicación.

27

ANEXOS

A. Valoración del LIDIE

PROYECTO AVA UNIVERSIDAD DE LOS ANDES

VALORACIÓN SISTÉM ICA DE SOFTWARE EDUCATIVO1

DATOS BÁSICOS Titulo: LOG Autor: Versión: Revisores: Gerardo Tibaná y Martha Luz Arango Fecha de Revisión: Septiembre 2.005 C ontexto: El software LOG es el resultado del trabajo de tesis de pre-grado de 3 estudiantes de Ingeniería de Sistemas en momentos diferentes. El SW fue desarrollado para facilitar el aprendizaje de los estudiantes del curso Herramientas de Deducción Formal, ofrecido por el profesor Rodrigo Cardoso quién además ha sido el director de la tesis en sus distintos momentos. A criterio del profesor actualmente el SW se encuentra en un estado estable pero solicitó de LIDIE una revisión desde lo metodológico e informático para implementar los ajustes que propongan. Este último trabajo estará a cargo de la estudiante de tesis Adriana Rothschild. Es necesario mencionar que la siguiente valoración se realiza con base en el estado actual del SW. C onvenciones: Los criterios en rojo determinan los puntos de acción que se deben atender VALORACIÓN METO DO LÓ GICA Variables C riterios E B R M NA Objetivos que persigue Están claramente definidos y son

coherentes con la necesidad educativa

x

Sistema de motivación Es apropiada para la audiencia y mantiene el interés por lograr los objetivos

x

Sistema de refuerzo Corresponde a la expectativa x 1 Adaptado del libro Ingeniería de Software Educativo de Alvaro Galvis

28

creada y es clave para el logro de objetivos

Actividad del Usuario Favorece la participación del usuario mediante el planteamiento de situaciones problémicas.

x

Metodología utilizada Esta basada en una didáctica apropiada considerando las opciones que ofrece el curso

x

Orientación a las actividades del usuario

Da pistas claves para resolver el problema enunciado

x

Ayudas que ofrece Ofrece ayudas para el uso (teoría, metodología) de la herramienta

x

Interfaz de entrada Los comandos o mecanismos de control se adecuan a la experiencia del usuario (dispositivos de entrada).

x

Interfaz de salida Los elementos presentes en los dispositivos de salida son familiares y adecuados para el usuario (suficiente información, velocidad de despliegue, vocabulario, símbolos , íconos) Los pantallazos estan sobrecargados de información

x x

VALORACIÓN INFORMÁTICA E B R M NA Funciones para cada tipo de usuario

Las funciones de apoyo para el alumno son las previstas en el diseño Las funciones de apoyo para el profesor son las previstas en el diseño

x x

Interfaz Hace buen uso de las posibilidades de la plataforma, es eficiente en el intercambio de información entre el usuario y el programa y es consistente a lo largo del programa

x

Requerimientos de uso El tamaño de los archivos de datos es manejable y el sistema operacional requeridos esta disponible o se puede obtener. Las utilidades o librerías requeridas están disponibles o se pueden obtener

x x

Mantenimiento del paquete Los textos del programa (mensajes de advertencia, de error) son editables y el código esta documentado. El manual es suficientemente completo para dar

x

29

mantenimiento al programa Documentación del paquete El manual de uso del estudiante es

claro y suficiente. El manual de uso del profesor es claro y suficiente

x

Existen otros puntos en la valoración informática que no se incluyeron ya que no son pertinentes o no se tiene forma de valorarlos:

• Estructura lógica del material: Es modular, hay una clara separación entre la lógica y los datos del programa.

• Estructura de datos: Permite un manejo eficiente de los datos que utiliza el programa, tiene un límite de crecimiento apropiado de los requerimientos de uso y la organización y todo el acceso a los archivos favorece la ejecución

30

B. Guía para las Monitorías de Capacitación en LOGS para HDF 2006-1

MONITORIA LOGS 2006-1

Nota: intenten poner descripciones cada vez que puedan.

1. Correr LOGS. 2. Explicarles la pantalla inicial. Para esto se debe explicar los menús y su

relación con los botones de la izquierda, mostrar los administradores de tipos y de teorías, y por últim o señalar el área de trabajo. Si quieren pueden m ostrar las flechas que ocultan los administradores y las barras que modifican su tamaño.

3. Creen un nuevo m undo. 4. Expliquen el adm inistrador de caracteres. Muestren que se puede agrandar o

achicar el administrador con la flecha azul, que se puede m over a través de la pantalla, los com andos especiales ($bool, $eq, etc.), y la posibilidad de creación de nuevas categorías con caracteres propios.

5. El siguiente paso es explicar el administrador de tipos. Prim ero hay que decir que un tipo es un conjunto de valores que se pueden aplicar a una variable. Después, hay que explicarles los botones (dado que es la primera vez que aparecen) y los 3 tipos predefinidos.

6. Vamos a crear 2 tipos nuevos. Primero los enteros y después los conjuntos (ver video).

7. Ahora pasam os a explicar las teorías. Una teoría la definim os com o un conjunto de verdades aplicadas sobre un tipo. En este administrador aparece un nuevo botón y hay que explicarlo.

8. Vamos a trabajar sobre una nueva teoría así que hay que crearla. Se va a llamar “Cálculo Proposicional”.

9. En la ventana que se despliega prim ero explicamos que los tipos y las teorías parám etro son para generalizar y eso se ve en el capítulo 8.

10. Lo siguiente que se debe explicar son las funciones. Prim ero es bueno m ostrar que en la teoría predefinida (“Expresiones Booleanas”) tam bién hay funciones predefinidas y solo esas se puede usar hasta no definir nuevas. Para esto vamos a crear el no equivalente (ver video).

11. Ahora pasam os a la parte del árbol de axiomas y teoremas. Acá aparece un nuevo botón que usarem os para crear 2 carpetas: “axiomas” y “teorem as”. Es una buena idea que creen la carpeta teorem as dentro de la de axiomas para m ostrar que se pueden hacer subcarpetas y que se pueden arrastrar de un lado a otro.

12. Vamos a resolver el ejercicio 3.12 del libro, que consiste en dem ostrar el teorema 3.17 convirtiendo el teorem a en un teorem a de equivalencias y luego volver a las no equivalencias. Los axiom as que se van a usar son el 3.2, 3.9 y 3.10, los teoremas son el 3.14, 3.16, 3.17, así que hay que crearlos. Hagan el error del video (poner en alguno 2 símbolos pegados) para mostrar que siempre 2 sím bolos seguidos deben estar separados.

13. Los semáforos se explican de la siguiente forma: • Semáforo verde: Teorem a demostrado.

31

• Semáforo azul: Teorema demostrado en el que en algún paso se usó un teorema azul o se usó un paso no validado.

• Semáforo am arillo: Teorem a demostrado en el que en algún paso se usó un teorem a amarillo, o rojo.

• Semáforo rojo: Teorema no dem ostrado. 14. Cream os un documento de dem ostración nuevo que se llam e Ejercicio 3.12.

Cuando se despliegue la ventana explicamos que LOGS soporta el uso de lemas y mostramos que esto se maneja en la parte “Ramas”. Hay que explicar el nuevo botón que aparece en esta parte

15. A continuación m ostram os la parte de “Ram as abiertas” y hay que explicar para que sirven los botones que se m uestran acá (Todos son nuevos).

16. La demostración que vamos a hacer es la siguiente (Cortesía de LOGS):

INFORMACIÓN DEL TEOREMA DEMOSTRADO:

(3.17) Teorema, Asociatividad del ≢: ((p≢q)≢r)≡(p≢(q≢r))

RAMAS DEL DOCUMENTO DE DEMOSTRACIÓN:

RAMA PRINCIPAL Enunciado: ((p≢q)≢r)≡(p≢(q≢r)) La demostración de la rama está concluida DEMOSTRACIÓN: (p≢q)≢r = �Axioma Definición de ≢ (3.10): (p≢q)≡ ¬(p≡q)�

(¬(p≡q))≢r = �Teorema Simetría del ≢ (3.16): (p≢q)≡(q≢p)�

(r≢(¬(p≡q))) = �Teorema (3.14): (p≢q)≡ ¬p≡q�

¬r≡(¬(p≡q)) = �Axioma Simetria del ≡ (3.2): p≡q≡q≡p�

(¬(p≡q))≡ ¬r = �Axioma Distributividad del ¬ sobre la ≡ (3.9): ¬(p≡q)≡ ¬p≡q�

(¬p≡q)≡ ¬r = � Simetría, Asociatividad, Parentización�

¬p≡(q≡ ¬r) = �Teorema (3.14): (p≢q)≡ ¬p≡q�

(p≢(q≡ ¬r))

32

= �Axioma Simetria del ≡ (3.2): p≡q≡q≡p�

(p≢(¬r≡q)) = �Teorema (3.14): (p≢q)≡ ¬p≡q�

(p≢((r≢q))) = � Simetría, Asociatividad, Parentización�

p≢(q≢r)

Hay que explicar en todos los pasos en los que se usan simetrías que también es posible usar SAP (usen el que quieran). También omitan SAP para mostrar las locuras que pueden llegar a salir al no arreglar los paréntesis. Si quieren concluyan el teorema las 2 veces del video para mostrar que LOGS puede concluir en los 2 casos pero que es mejor que lo concluyan haciendo todos los pasos (Por cuestiones de facilidad en la calificación de las tareas).

17. Al terminar la demostración hay que mostrar como se exporta el documento a HTML.

18. Si queda tiem po se hacen las otras 2 demostraciones. La primera es para m ostrar com o se usan los pasos no validados, y la segunda es para mostrar como cambian los semáforos. (ver video).

19. En el teorema 3.14 pueden usar “Por Gries” o “Por el libro”. 20. La demostración del teorema 3.16 es la siguiente:

INFORMACIÓN DEL TEOREMA DEMOSTRADO:

(3.16) Teorema, Simetría del ≢: (p≢q)≡(q≢p)

RAMAS DEL DOCUMENTO DE DEMOSTRACIÓN:

RAMA PRINCIPAL Enunciado: (p≢q)≡(q≢p) La demostración de la rama está concluida DEMOSTRACIÓN: p≢q = �Axioma Definición de ≢ (3.10): (p≢q)≡ ¬(p≡q)�

¬(p≡q) = �Axioma Simetria del ≡ (3.2): p≡q≡q≡p�

¬(q≡p) = �Axioma Definición de ≢ (3.10): (p≢q)≡ ¬(p≡q)�

(q≢p)

También se puede usar SAP en el segundo paso, pero es mas rápido usar el teorema. Es bueno tener las ventanas dispuestas de tal modo que al concluir la demostración se vea el cambio en los semáforos.

33

C. Helpset del M anual <?xml version='1.0' encoding='ISO-8859-1' ?> <!DOCTYPE helpset PUBLIC "-//Sun Microsystems Inc.//DTD JavaHelp HelpSet Version 1.0//EN" "http://java.sun.com/products/javahelp/helpset_1_0.dtd"> <helpset version="1.0"> <!-- title --> <title>Manual de LOGS</title> <!-- maps --> <maps> <homeID>main</homeID> <mapref location="logshelpmap.jhm"/> </maps> <!-- view s --> <view > <name>TOC</name> <label>Contenidos</label> <type>javax.help.TOCView </type> <data>logstoc.xml</data> </view > <view > <name>Index</name> <label>Index</label> <type>javax.help.IndexView </type> <data>logsindex.xml</data> </view > </helpset>

34

D. M apa del Manual <?xml version='1.0' encoding='ISO-8859-1' ?> <!DOCTYPE map PUBLIC "-//Sun Microsystems Inc.//DTD JavaHelp Map Version 2.0//EN" "http://java.sun.com/products/javahelp/map_2_0.dtd"> <map version="2.0"> <mapID target="intro" url="HTMLs/Introduccion.htm" /> <mapID target="mundos" url="HTMLs/Mundos.htm" /> <mapID target="princ" url="HTMLs/VentanaPrincipal.htm" /> <mapID target="caracteres" url="HTMLs/Caracteres.htm" /> <mapID target="biblio" url="HTMLs/Bibliografia.htm" /> <mapID target="tipos" url="HTMLs/Tipos.htm" /> <mapID target="creartip" url="HTMLs/CrearTipos.htm" /> <mapID target="botones" url="HTMLs/Botones.htm" /> <mapID target="botonesp" url="HTMLs/BotonesPersistencia.htm" /> <mapID target="botonesa" url="HTMLs/BotonesAplicacion.htm" /> <mapID target="botonesd" url="HTMLs/BotonesDD.htm" /> <mapID target="teorias" url="HTMLs/Teorias.htm" /> <mapID target="contteo" url="HTMLs/ContenidosTeorias.htm" /> <mapID target="dd" url="HTMLs/DD.htm" /> </map>

35

E. Tabla de Contenidos del Manual (TOC) <?xml version='1.0' encoding='ISO-8859-1' ?> <!DOCTYPE toc PUBLIC "-//Sun Microsystems Inc.//DTD JavaHelp TOC Version 1.0//EN" "http://java.sun.com/products/javahelp/toc_1_0.dtd"> <toc version="1.0"> <tocitem text="LOGS"> <tocitem text="Introducción" target="intro"> <tocitem text="Ventana Principal" target="princ"/> <tocitem text="Mundos" target="mundos"/> </tocitem> <tocitem text="Tipos" target="tipos"> <tocitem text="Crear Tipos" target="creartip"/> </tocitem> <tocitem text="Teorias" target="teorias"> <tocitem text="Contenidos" target="contteo"/> <tocitem text="Documentos de Demostración" target="dd"/> </tocitem> <tocitem text="Botones" target="botones"> <tocitem text="Botones de la Aplicacion" target="creartip"/> <tocitem text="Botones Persistencia de Mundos" target="botonesa"/>

<tocitem text="Botones de los Documentos de Demostración" target="botonesd"/>

</tocitem> <tocitem text="Caracteres" target="caracteres"/> <tocitem text="Bibliografia" target="biblio"/> </tocitem> </toc>

36

F. Índice del Manual <?xml version='1.0' encoding='ISO-8859-1' ?> <!DOCTYPE index PUBLIC "-//Sun Microsystems Inc.//DTD JavaHelp Index Version 1.0//EN" "http://java.sun.com/products/javahelp/index_1_0.dtd"> <index version="2.0"> <indexitem text="Booleanos" target="mundos"/> <indexitem text="Bibliografía" target="biblio"/> <indexitem text="Caracteres" target="caracteres"/> <indexitem text="Descripción" target="intro"/> <indexitem text="Deshacer" target="princ"/> <indexitem text="Documentos de Demostracion" target="dd"/> <indexitem text="Expresiones Booleanas" target="mundos"/> <indexitem text="Enteros Positivos" target="mundos"/> <indexitem text="LOGS" target="intro"/> <indexitem text="Mundos" target="mundos"> <indexitem text="Que son" target="intro"/> <indexitem text="Crear" target="mundos"/> <indexitem text="Abrir" target="mundos"/> <indexitem text="Guardar" target="mundos"/> <indexitem text="Cerrar" target="mundos"/> </indexitem> <indexitem text="Naturales" target="mundos"/> <indexitem text="Ramas" target="dd"/> <indexitem text="Rehacer" target="princ"/> <indexitem text="Semaforos" target="dd"/> <indexitem text="Teorias" target="teorias"> <indexitem text="Que son" target="teorias"/> <indexitem text="Contenido" target="contteo"/> <indexitem text="Creación" target="contteo"/> </indexitem> <indexitem text="Tipos" target="tipos"> <indexitem text="Que son" target="tipos"/>

37

<indexitem text="Crear tipos" target="tipos"/> </indexitem> </index>

38

Bibliografía

[Gri1993] Gries, D., & Schneider, F. B. A Logical Approach to Discrete Math (1 Ed.) ,Springer Verlag, 1993.

[Nog2001] Noguera, C., Sarmiento, C.,Tovar, C., LOGS: Editor de demostraciones en lógica ecuacional, Tesis de pregrado, Facultad de Ingeniería, Departamento de Ingeniería de Sistemas y Computación, Universidad de los Andes. Bogotá, Colombia, 2001.

[Rub2002] Rubiano, A. C., LOGS: revisión y reingeniería de la aplicación, Tesis de pregrado, Facultad de Ingeniería, Departamento de Ingeniería de Sistemas y Computación, Universidad de los Andes, Bogotá, Colombia, 2002.

[Sot2006] Sotelo A. LOGS2005: Editor de demostraciones en lógica ecuacional, Tesis de pregrado, Facultad de Ingeniería, Departamento de Ingeniería de Sistemas y Computación, Universidad de los Andes. Bogotá, Colombia, 2006.

[LIDIE] http://lidie.uniandes.edu.co

[JavaHelp] http://java.sun.com/products/javahelp/

[Captivate] http://www.adobe.com/products/captivate/