1. Uso de métodos formales para desarrollar un sistema de información ATC Raúl Alonso Álvarez Roberto Bernárdez Vázquez Xabier Fernández López

2. Introducción El equipo Praxis utiliza usa métodos formales para ayudar el desarrollo de CDIS, que consiste en una gran pantalla de información dentro de un sistema ATC de apoyo del sistema.

3. CDIS Informa a los controladores de vuelos de llegada y salida. Condiciones meteorológicas. Estado del equipo en los aeropuertos. Otra información introducida por el personal. Información en tiempo real de su estado.

4. Equipo Trabajo

5. Requisitos

6. Desarrollo de CDIS 1989 definición de requisitos y la ejecución se produjo en 1992. El proyecto tiene 5 fase: Especificación del sistema. Diseño del software. Pruebas de código y unidad. Pruebas del sistema Pruebas de aceptación. Código y pruebas se hacen por separado en 2 equipos: Eq1:codoficación y pruebas de unidad Eq2:integración y pruebas del sistema de caja negra y pruebas de aceptación. Implementación incremental en 6 etapas del software.

7. Requisitos funcionales 3 técnicas: Análisis Entidad-Relación. Diagrama de flujo de datos persiguiendo un método de análisis estructurado en tiempo real, para la definición del proceso. VDM es un leguaje de especificación formal para la definición de operaciones de CDIS de manera precisa. Esta etapa es de uso parcial donde se incluyen las estructuras mas importantes y las operaciones más críticas.

8. Notaciones formales y semiformales. Primero piensan: diagrama de flujo para cada operación y especificación formal para procesos de más bajo nivel. Mal por 2 razones Descomponer una operación en niveles más bajos de diseño no especifica operaciones solo da un boceto. Especificación de procesos en flujos de datos no especifican claramente el diagrama como un conjunto, porque el significado de los diagramas de flujo esta sin definir. Se decide usar especificación formal en el nivel superior. Definen un estado que representa el sistema CDIS como un conjunto, y las operaciones individuales de VDM se corresponden con operaciones a nivel de usuario. Los estados VDM están relacionados como modelo E/R. Es posible derivar del modelo E/R pero VDM es más rico y es mejor para sustituir algunas construcciones E/R por ser más simple y tener representaciones formales más directas

9. Tipos de especificaciones

10. Tipos de especificaciones El flujo de datos no es satisfactorio como requisito declarativo debido a que : No aclara que hace la validación o que hacer en caso de fallo. La difusión de un mensaje como hace la pantalla es cosa de diseño que no interesa al usuario, y es prematuro suponer la implementación como una estrategia en la etapa de requisitos. Si se especifica los procesos en el diagrama, menos que el resultado de las especificaciones de bajo nivel no ayudan al usuario a entender el efecto del proceso de mensajes.

11. Especificación VDM Para escribir una especificación VDM de la operación. Primero modelaremos el estado de los diagramas entidad-relaciónalos VDM. VDM utiliza como notaciones la lógica usual y la teoría de conjuntos Y además…

12. Especificación VDM Y además usa las siguientes notaciones: estado: declaración de los componentes de estado inv: restricciones sobre el estado operaciones: operaciones en el estado ext: estado externo afectado por una operación post: poscondición definiendo el efecto de una operación data: valor de los datos antes de la operación

13. Versión simplificada del estado VDM Especificación de operaciones en VDM

14. Especificación VDM Mejoras utilizando VDM: representa la secuencia de aproximación directamente por una secuencia de vuelos relacionados con el complejo del aeropuerto principal esto expresa que, para un vuelo que está en la secuencia de aproximación para complejo del aeropuerto principal, esta debe estar encabezada por un aeropuerto asociado con ese complejo. Este hecho no se puede expresar en una notación entidad-relación.

15. Especificación VDM Conclusiones: Usamos VDM como una parte del análisis de requisitos porque creemos que su precisión ayuda a aclarar nuestra comprensión de los requisitos y los hace completos y no ambiguos Esta creencia se confirma en la práctica Durante el estudio respondemos un montón de preguntas, muchas de ellas son el resultado de tratar de formalizar ciertos requisitos, y eso nos proporciona una buena comprensión de lo que el sistema estaba destinado a hacer Sin embargo tiene varios problemas.

16. Problemas Este tipo de especificación funcional no puede distinguir entre los requisitos esenciales de los que son simplemente deseables. No puede representar los requisitos que expresan términos globales. Ej: que todas las operaciones sean reversibles Sólo los requisitos funcionales pueden ser capturadas con este tipo de especificación, la facilidad de uso, rendimiento, fiabilidad, y los aspectos de seguridad están fuera de su alcance

17. Especificación del sistema En el comienzo de la implementación, se decidió producir una especificación completa de CDIS que sirva de base para el diseño Gracias a nuestra experiencia en el estudio de requisitos, abandonamos el uso de diagramas de flujo de datos y basamos la especificación sobre todo en la notación formal.

18. Especificación del sistema Sin embargo, una especificación en su totalidad en VDM no habría sido adecuado por dos razones principales: VDM no proporciona ninguna ayuda real para especificar los detalles de la interfaz de usuario, uno de los aspectos más importantes del CDIS. La especificación VDM sólo se describen los aspectos secuenciales del comportamiento. CDIS procesa muchas entradas concurrentemente, y teníamos que saber qué operaciones pueden ocurrir concurrentemente y la forma en que pueden interferir unas con otras.

19. Especificación del sistema Se divide la especificación del sistema en 3 partes: Corespecification Userinterfacedefinitions Concurrencyspecification Las especificaciones constituyen tres puntos de vista diferentes del sistema

21. Especificación del sistema La especificación principal describe los datos gestionados por CDIS y todas las operaciones que podría realizar CDIS. Cada operación se ha especificado en un nivel semántico mediante la definición de sus entradas, salidas, y el efecto sobre el estado. Para cada operación en la especificación básica, se produjo la correspondiente definición de la interfaz de usuario La especificación de concurrencia mostró que procesos del mundo real podrían llevar a cabo las operaciones

22. Corespecification Estos módulos no son independientes y las operaciones típicas afectan el estado de varios módulos. Por ejemplo, ciertos errores en los enlaces externos causan que las comunicaciones con el Sistema de Espacio Aéreo Nacional se pierda; las porciones de la base de datos de llegadas por lo tanto dejan de ser válidos y producen cambios en las pantallas del controlador. Para expresar claramente este tipo de comportamiento, necesitamos un mecanismo de modularización que nos permita escribir las operaciones que afectan al estado de varios módulos de forma natural.

23. Corespecification Debido a que CDIS tiene cerca de 150 operaciones de especificación de nivel, nos enfrentamos al problema de cómo estructurar la especificación en módulos entendibles. Los módulos de alto nivel están relacionados con las principales áreas de funcionalidad: llegadas, salidas, los aeropuertos, las pantallas y las páginas, las comunicaciones, y dirección de ingeniería.

24. Corespecification Se consideraron tres alternativas: VDM, que no tienen un mecanismo de modularización útil Z, que parecía ofrecer el tipo de estructuración que necesitábamos y VVSL, un lenguaje con una sintaxis similar a VDM y una estructura de módulos bien desarrollada, que proporcionan la mayor parte de las facilidades que necesitábamos

25. Corespecification ¿por qué elegimos VDM? Debido a que habíamos utilizado VDM durante el análisis de requerimientos. El manejo de errores en convenciones Z son torpes en comparación con los de VVSL.

26. Definiciones de interfaz de usuario Contienen dos tipos de información: Apariencia física de la interfaz Sintaxis de los diálogos de usuario Cada operación de la corespecificationtiene una especificación concreta en la interfaz de usuario Problema: El nivel de abstracción no es uniforme, depende de la complejidad e importancia de las operaciones

27. Concurrencyspecification Describe la concurrencia inherente al entorno CDIS, los procesos que podrían ejecutarse concurrentemente en el mundo real. Cada proceso fue definido en el lenguaje CSP. El alfabeto de cada proceso fue el conjunto de las operaciones VVSL disponibles para el Los procesos se representan por diagramas de flujo

28. DISEÑO Se dividió en 4 partes: Diseño funcional Proceso de diseño Diseño de interfaz de usuario Diseño de infraestructura

29. DISEÑO La relación entre los distintos componentes de diseño produce la división: Del software en subsistemas Del esfuerzo entre los equipos de desarrollo Cada parte requiere distintas anotaciones

30. DISEÑO FUNCIONAL Diseño de los módulos de la aplicación Inicialmente se esperaba especificar los módulos con VVSL como mejora No se hizo por la dificultad de las notaciones y la dificultad de escribir las relaciones de refinamiento con VVSL

31. DISEÑO FUNCIONAL Diseño de los módulos de la aplicación Inicialmente se esperaba especificar los módulos con VVSL como mejora No se hizo por la dificultad de las notaciones y la dificultad de escribir las relaciones de refinamiento con VVSL

32. DISEÑO FUNCIONAL Problemas: Muchos estados del CDIS se ven afectados La especificación de una operación de usuario se define como un conjunto de transacciones entre operaciones de otros módulos Abandono de relación formal entre especificación y diseño

33. PROCESO DE DISEÑO Identificación de procesos y mecanismos de comunicación e intercambio de datos Documentación con diagramas de flujo Para diagramas de proceso de diseño se usan autómatas de estados finitos

34. DISEÑO DE INTERFAZ DE USUARIO Derivada de interfaz de usuario y otros módulos de servicios de la aplicación Se definen mensajes y respuestas de cada proceso

35. INFRAESTRUCTURA Constituida por software LAN Requisitos muy estrictos Definidos con VVSL

36. Problemas: Comportamiento dinámico de protocolos LAN y relaciones entre extremos difíciles de capturar Se necesitó usar notación que soportase concurrencia.(Sistema de Cálculo de Comunicaciones, CCS)

37. RESULTADOS Problemas con nivel de formalidad: Muy formal: la especificación formal puede ser tan complicada como el código en sí mismo Poco formal: desarrolladores sin información suficiente de las definiciones de la operaciones

38. Causas de fallos puede deberse a incorrecta relación entre especificación y diseño Uso de métodos formales mejora trazabilidad

39. Coste de no realizar una prueba = a la probabilidad de que exista un error que sólo se detecta con la prueba + coste del error Si coste de pruebas es menor que el coste de no realizarlas entonces estarán justificadas

40. PUNTO DE VISTA DEL CLIENTE Ventajas de uso de métodos formales en especificación del sistema: Comprensible Precisa El CAA podía ver el nivel de capacidad del CDIS en cualquier momento

41. Desventajas de uso de métodos formales: Equipo de CAA tenían que interpretar la especificación para el resto del personal Especificación de interfaz de usuario menos precisa y completa que la del núcleo Especificaciones poco claras en determinados puntos

42. CONCLUSIONES Especificación formal debe ir acompaña de información explicativa (texto, diagramas, anotaciones…) Interfaz de usuario debe ser más precisa y completa Uso de métodos formales ahorró costes, no esfuerzo La fase de especificación se ha realizado correctamente. Se define la funcionalidad CDIS con precisión y se proporciona una base sólida para el proyecto.

43. Fallos insignificantes relacionados con los problemas de especificación Permite construir sistema correcto sin coste extra No práctico pero sí beneficioso en proyectos de gran escala Escribir la especificación fue un ejercicio útil en sí mismo

44. La especificación fue base para el diseño, implementación y pruebas Se utilizó para las pruebas de caja negra Sirvió de base para la documentación. Nos ha ayudado a aclarar los requisitos de forma precisa. Gracias a la formalidad de la notación.

45. Ingenieros deben preguntarse: NO si deben usar método formales sino CÓMO beneficiarse de estos métodos como parte de un completo enfoque de ingeniería del software