Grupo 16: Enseñanza de IS con MF Ejemplo de especificación de un sistema en Z durante un curso académico Realizado por: Adrián Tubío Noya Mª Esther Saavedra Martínez
Introducción al Proyecto Se propone la realización de un proyecto de 4 meses de duración, sobre la especificación formal y el diseño de una situación real. En este proyecto será necesario utilizar: Z: lenguaje de especificación formal basado en un conjunto de teorías y lógica de primer orden. Compuesto de un conjunto de estructuras denominadas schemas. Schema Calculus : Composición de esquemas. Larch: Familias de lenguajes de especificación, compuesto de 2 capas con notaciones diferentes: LSL (librerías de tipos abstractos). LIL (Librerías de módulos de interfaces, dependiente del lenguaje de programación). Conjunto de Herramientas: Comprobadores de tipos, comprobadores de teoremas, animadores (interpretes), generadores de casos de prueba, uso de métricas. Adrián Tubío Noya - Esther Saavedra Martínez
Requerimientos Informales del Proyecto Profesores: 1ª Especificación Informal Requerimientos Informales Estudiantes: 3 semanas estudio y mejoras Profesores y Estudiantes: discuten las mejoras Especificación Formal Diseño Formal: LSL y LIL Borrador Final de los Requerimientos Informales Adrián Tubío Noya - Esther Saavedra Martínez
Ejemplo: Requerimientos Informales Documento de requerimientos informales para un juego de ajedrez online (ChessNet). El servicio debe ofrecer: Conexión remota protegida por contraseña. Visualización de los usuarios conectados y sus atributos. Visualización de cualquier partida en curso. Utilización de interfaz gráfica capaz de control de tiempos y legalidad de movimientos. Enviar los resultados de cada partida por email a ambos jugadores y a los observadores..
Especificación Formal en Z Estudiantes: Reciben Borrador Final Requerimientos Informales Estudiantes: Generan Especificación Formal en Z. Comprueban resultados con Fuzz Estudiantes: Comparan con otros proyectos (Revisión Cruzada) Se selecciona el mejor proyecto que será utilizado como documento de referencia. Requerimientos Informales Especificación Formal Diseño Formal: LSL y LIL Generación del gráfico de relaciones entre esquemas Adrián Tubío Noya - Esther Saavedra Martínez
Ejemplos Especificación Formal en Z Esquema que representa el estado abstracto de un tablero de ajedrez. Esquema que indica el estado de la pantalla de un cliente. Configuración actual de la tabla, color, partidas observadas y mensajes recibidos de los canales seleccionados.
Relaciones entre schemas La imagen muestra como los esquemas de operaciones están encapsulados utilizando inclusión de schemas y schema calculus. Muestra los enlaces entre schemas de operación y schemas de estados. Esta representación es el punto de partida para la fase de diseño Las líneas de puntos indican que todos los schemas de operaciones utilizan las variables de SERVER pero no las modifican, mientras que las líneas continuas sí las modifican.
Diseño Formal: Larch (LSL y LIL) LSL : Larch Shared Language, usado para definir librerias de tipos de datos abstractos. LIL: Larch Interface Language, usado para definir las interfaces de los modulos. LSL define los tipos de datos abstractos y los operadores algebraicos cuya semantica será definida más tarde con LIL. Requerimientos Informales Especificación Formal Diseño Formal: LSL y LIL Una vez terminado el diseño los estudiantes tendrán que utilizar Larch Prover (LP) para comprobar las propiedades de los tipos de d a to s a b s tra c to s.
Ejemplo LSL y LIL LSL LIL
Ejemplo LP (Larch Prover)
Debate OBJETIVOS CUMPLIDOS: Mostrar a los estudiantes las diferencias entre especificar, diseñar, y programar, que son distintas actividades que requieren habilidades diferentes y las herramientas adecuadas. Los estudiantes han aprendido a utilizar una gran variedad de herramientas. Los estudiantes aprecian como de costoso puede llegar a ser un desarrollo y como de útiles pueden llegar a ser algunas herramientas. Los estudiantes entendieron muy bien los objetivos de las diferentes fases y los documentos resultantes. Los estudiantes encontraron muy importante la comprobación de propiedades con Larch Prover, pero fue la parte mas dificil y la que más tiempo consumió PROBLEMAS ENCONTRADOS: Menor éxito enseñando la parte de diseño que la parte de especificación. El schema calculus fue apenas utilizado, comentarios casi ausentes. Casi nadie intentó probar de motu propio propiedades de los sistemas abstractos, tuvieron que ser obligados. Un excesivo uso de LSL provocó escasas especificaciones reusables. SUGERENCIAS DE FUTURO: Intentarán poner más énfasis en orientación a objetos y patrones de diseño. Adrián Tubío Noya - Esther Saavedra Martínez
Conclusiones Personales La revisión cruzada es una herramienta muy útil en el proceso de aprendizaje. El hecho de realizar las especificación utilizando métodos formales nos permitirá: Evitar ambigüedades. Evitar problemas de comunicación. Utilizar herramientas para probar la corrección de las especificaciones. El hecho de partir siempre de un documento común en cada fase del desarrollo, permite que los grupos de trabajo no arrastren los errores propios del aprendizaje en cada fase del desarrollo a las fases siguientes. La mejor manera de aprender un lenguaje de especificación, el uso de herramientas, y formalizar un proceso de desarrollo es mediante la aplicación práctica de todos estos conocimientos en un caso real.
Pregunta 1 Cúal es la utilidad de la revisión cruzada? A) Reutilizar código de otros proyectos B) Comprobar errores y aprender de otras especificaciones las mejores maneras de utilizar las opciones que tenemos. C) Evaluar otros trabajos con el fin de ponerle una nota final D) Recoger las mejores partes de cada especificación y ponerlas juntas en un solo documento.
Respuesta Pregunta 1 La respuesta correcta es la B) Justificación: A) La revisión cruzada se realiza antes de corregir los proyectos, luego no tiene sentido reutilizar un código que no sabemos si va a ser correcto. B) Esta es la respuesta correcta. La idea de la revisión cruzada, es que cada grupo compruebe sus especificaciones, comparándolas con sus compañeros, y en función de esto, aprender si existe una manera mejor de hacer la misma especificación. C) Los alumnos no son profesores, y no deben tener el deber de ponerse en la tesitura de calificar a sus compañeros. Eso es tarea del profesor. D)Una vez que la revisión cruzada tiene lugar, se discuten las mejores implementaciones y se realiza un documento común.
Pregunta 2 Para qué se utiliza Larch? A) Para la especificación de requerimientos B) Para especificar la arquitectura C) Para el diseño formal D) Todas las anteriores
Respuesta Pregunta 2 La respuesta correcta es la B) Justificación: A) Para la especificación de requerimientos utilizaremos Z, o bien una herramienta de similares características. B) Larch no permite especificar nada referente a la arquitectura, si es cierto, que muchas veces especificamos el diseño pensando en la arquitectura que utilizaremos más adelante. C) Esta es la respuesta correcta. Se usa para la especificación del diseño formal. D) Tanto la A como la B son incorrectas, luego esta respuesta es incorrecta también.
Pregunta 3 Z es A) un lenguaje utilizado para la especificación forma del requisitos. B) una herramienta de diseño C) una metodología de análisis de requisitos. D) una familia de lenguajes de especificación.
Respuesta Pregunta 3 La respuesta correcta es la A) Justificación: A) Esta es la respuesta correcta. B) Para especificar el diseño formal, utilizaremos herramientas del tipo de Larch. Z no permite especificar detalles de como se debe realizar la implementación. C) Z no es una metodología, es una herramienta que quizás nos permite aplicar ciertas metodologías para la especificación de requisitos. Pero no marca ninguna directriz específica para realizar la implementación. D) No es una familia de lenguajes de especificación, sólo es un lenguaje, y esto es debido a que no depende de ningún lenguaje o bien de programación o bien de diseño.
Pregunta 4 De que dos niveles se compone Larch? A) Z y LP. B) Z y LSL. C) LP y LIL D) LSL y LIL
Respuesta Pregunta 4 La respuesta correcta es la D) Justificación: A) Z es un lenguaje de especificación de requisitos, no forma parte de Larch, lo mismo ocurre con LP, que es una herramienta que comprueba los tipos abstractos de datos para Larch. B) Z es un lenguaje de especificación de requisitos, no forma parte de Larch. C)LP es una herramienta que comprueba los tipos abstractos de datos para Larch, pero no forma parte de Larch. D) Es la respuesta correcta. LSL (Larch Shared Language) y LIL (Larch Interface Language) son los 2 niveles de Larch.
Pregunta 5 Cuál es la función del gráfico de relaciones entre schemas? A) Ayudarnos a realizar una buena especificación formal de requisitos B) Es un documento creado al final de la especificación formal de requerimientos, que es la base del desarrollo del diseño formal. C) Es el resultado de la fase de diseño formal. D) Se utiliza para comprobar la corrección del documento de especificación formal en Z.
Respuesta Pregunta 5 La respuesta correcta es la B) Justificación: A) El gráfico de relaciones entre esquemas se crea una vez hemos terminado el documentos de especificación de requisitos. B) Es la respuesta correcta. El gráfico de relaciones entre esquemas se crea al final de la fase de especificación formal de requisitos, y su función es servirnos de ayuda para la fase de diseño. C) Este gráfico de relaciones entre esquemas es el documento base para el diseño junto con la especificación formal de requisitos. El resultado de la fase de diseño, es el propio documento de diseño y el documento de la arquitectura software. D) Para comprobar la corrección de la especificación formal de requerimientos en Z, se pueden utilizar diversas herramientas. Como por ejemplo: Fuzz o LaTEX 2e y ZTC.