Presentacion

346 views
231 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
346
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Presentacion

  1. 1. Uso de métodos formales para desarrollar un sistema de información ATC<br />Raúl Alonso Álvarez<br />Roberto Bernárdez Vázquez<br />Xabier Fernández López<br />
  2. 2. Introducción<br />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. <br />
  3. 3. CDIS<br />Informa a los controladores de vuelos de llegada y salida.<br />Condiciones meteorológicas.<br />Estado del equipo en los aeropuertos.<br />Otra información introducida por el personal.<br />Información en tiempo real de su estado.<br />
  4. 4. Equipo Trabajo<br />
  5. 5. Requisitos<br />
  6. 6. Desarrollo de CDIS<br />1989 definición de requisitos y la ejecución se produjo en 1992.<br />El proyecto tiene 5 fase:<br />Especificación del sistema.<br />Diseño del software.<br />Pruebas de código y unidad.<br />Pruebas del sistema<br />Pruebas de aceptación.<br />Código y pruebas se hacen por separado en 2 equipos:<br />Eq1:codoficación y pruebas de unidad<br />Eq2:integración y pruebas del sistema de caja negra y pruebas de aceptación.<br />Implementación incremental en 6 etapas del software.<br />
  7. 7. Requisitos funcionales<br />3 técnicas:<br />Análisis Entidad-Relación.<br />Diagrama de flujo de datos persiguiendo un método de análisis estructurado en tiempo real, para la definición del proceso.<br />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.<br />
  8. 8. Notaciones formales y semiformales.<br />Primero piensan: diagrama de flujo para cada operación y especificación formal para procesos de más bajo nivel. Mal por 2 razones<br />Descomponer una operación en niveles más bajos de diseño no especifica operaciones solo da un boceto.<br />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. <br />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.<br />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<br />
  9. 9. Tipos de especificaciones<br />
  10. 10. Tipos de especificaciones<br />El flujo de datos no es satisfactorio como requisito declarativo debido a que :<br />No aclara que hace la validación o que hacer en caso de fallo.<br />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.<br />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.<br />
  11. 11. Especificación VDM<br />Para escribir una especificación VDM de la operación. Primero modelaremos el estado de los diagramas entidad-relaciónalos VDM.<br />VDM utiliza como notaciones la lógica usual y la teoría de conjuntos<br />Y además…<br />
  12. 12. Especificación VDM<br />Y además usa las siguientes notaciones:<br />estado: declaración de los componentes de estado<br />inv: restricciones sobre el estado<br />operaciones: operaciones en el estado<br />ext: estado externo afectado por una operación<br />post: poscondición definiendo el efecto de una operación<br />data: valor de los datos antes de la operación<br />
  13. 13. Versión simplificada del estado VDM<br />Especificación de operaciones en VDM<br />
  14. 14. Especificación VDM<br />Mejoras utilizando VDM:<br />representa la secuencia de aproximación directamente por una secuencia de vuelos relacionados con el complejo del aeropuerto principal<br />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. <br />
  15. 15. Especificación VDM<br />Conclusiones:<br />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<br />Esta creencia se confirma en la práctica<br />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<br />Sin embargo tiene varios problemas.<br />
  16. 16. Problemas<br />Este tipo de especificación funcional no puede distinguir entre los requisitos esenciales de los que son simplemente deseables.<br />No puede representar los requisitos que expresan términos globales. Ej: que todas las operaciones sean reversibles<br />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 <br />
  17. 17. Especificación del sistema<br />En el comienzo de la implementación, se decidió producir una especificación completa de CDIS que sirva de base para el diseño<br />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.<br />
  18. 18. Especificación del sistema<br />Sin embargo, una especificación en su totalidad en VDM no habría sido adecuado por dos razones principales:<br />VDM no proporciona ninguna ayuda real para especificar los detalles de la interfaz de usuario, uno de los aspectos más importantes del CDIS.<br />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.<br />
  19. 19. Especificación del sistema<br />Se divide la especificación del sistema en 3 partes: <br />Corespecification<br />Userinterfacedefinitions<br />Concurrencyspecification<br />Las especificaciones constituyen tres puntos de vista diferentes del sistema<br />
  20. 20.
  21. 21. Especificación del sistema<br />La especificación principal describe los datos gestionados por CDIS y todas las operaciones que podría realizar CDIS.<br />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.<br />Para cada operación en la especificación básica, se produjo la correspondiente definición de la interfaz de usuario<br />La especificación de concurrencia mostró que procesos del mundo real podrían llevar a cabo las operaciones<br />
  22. 22. Corespecification<br />Estos módulos no son independientes y las operaciones típicas afectan el estado de varios módulos.<br />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.<br />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.<br />
  23. 23. Corespecification<br />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.<br />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.<br />
  24. 24. Corespecification<br />Se consideraron tres alternativas:<br />VDM, que no tienen un mecanismo de modularización útil<br />Z, que parecía ofrecer el tipo de estructuración que necesitábamos<br />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<br />
  25. 25. Corespecification<br />¿por qué elegimos VDM?<br />Debido a que habíamos utilizado VDM durante el análisis de requerimientos.<br />El manejo de errores en convenciones Z son torpes en comparación con los de VVSL.<br />
  26. 26. Definiciones de interfaz de usuario<br />Contienen dos tipos de información:<br />Apariencia física de la interfaz<br />Sintaxis de los diálogos de usuario<br />Cada operación de la corespecificationtiene una especificación concreta en la interfaz de usuario<br />Problema: El nivel de abstracción no es uniforme, depende de la complejidad e importancia de las operaciones<br />
  27. 27. Concurrencyspecification<br />Describe la concurrencia inherente al entorno CDIS, los procesos que podrían ejecutarse concurrentemente en el mundo real.<br />Cada proceso fue definido en el lenguaje CSP.<br />El alfabeto de cada proceso fue el conjunto de las operaciones VVSL disponibles para el<br />Los procesos se representan por diagramas de flujo <br />
  28. 28. DISEÑO<br />Se dividió en 4 partes:<br />Diseño funcional<br />Proceso de diseño <br />Diseño de interfaz de usuario<br />Diseño de infraestructura<br />
  29. 29. DISEÑO<br />La relación entre los distintos componentes de diseño produce la división:<br />Del software en subsistemas<br />Del esfuerzo entre los equipos de desarrollo<br />Cada parte requiere distintas anotaciones<br />
  30. 30. DISEÑO FUNCIONAL<br />Diseño de los módulos de la aplicación<br />Inicialmente se esperaba especificar los módulos con VVSL como mejora<br />No se hizo por la dificultad de las notaciones y la dificultad de escribir las relaciones de refinamiento con VVSL<br />
  31. 31. DISEÑO FUNCIONAL<br />Diseño de los módulos de la aplicación<br />Inicialmente se esperaba especificar los módulos con VVSL como mejora<br />No se hizo por la dificultad de las notaciones y la dificultad de escribir las relaciones de refinamiento con VVSL<br />
  32. 32. DISEÑO FUNCIONAL<br />Problemas:<br />Muchos estados del CDIS se ven afectados<br />La especificación de una operación de usuario se define como un conjunto de transacciones entre operaciones de otros módulos<br />Abandono de relación formal entre especificación y diseño<br />
  33. 33. PROCESO DE DISEÑO<br />Identificación de procesos y mecanismos de comunicación e intercambio de datos<br />Documentación con diagramas de flujo<br />Para diagramas de proceso de diseño se usan autómatas de estados finitos<br />
  34. 34. DISEÑO DE INTERFAZ DE USUARIO<br />Derivada de interfaz de usuario y otros módulos de servicios de la aplicación<br />Se definen mensajes y respuestas de cada proceso<br />
  35. 35. INFRAESTRUCTURA<br />Constituida por software LAN<br />Requisitos muy estrictos<br />Definidos con VVSL<br />
  36. 36. Problemas:<br />Comportamiento dinámico de protocolos LAN y relaciones entre extremos difíciles de capturar<br />Se necesitó usar notación que soportase concurrencia.(Sistema de Cálculo de Comunicaciones, CCS)<br />
  37. 37. RESULTADOS<br />Problemas con nivel de formalidad:<br />Muy formal: la especificación formal puede ser tan complicada como el código en sí mismo<br />Poco formal: desarrolladores sin información suficiente de las definiciones de la operaciones<br />
  38. 38. Causas de fallos puede deberse a incorrecta relación entre especificación y diseño<br />Uso de métodos formales mejora trazabilidad<br />
  39. 39. Coste de no realizar una prueba =<br />a la probabilidad de que exista un error que sólo se detecta con la prueba <br />+<br />coste del error<br />Si coste de pruebas es menor que el coste de no realizarlas entonces estarán justificadas<br />
  40. 40. PUNTO DE VISTA DEL CLIENTE<br />Ventajas de uso de métodos formales en especificación del sistema:<br />Comprensible<br />Precisa<br />El CAA podía ver el nivel de capacidad del CDIS en cualquier momento<br />
  41. 41. Desventajas de uso de métodos formales:<br />Equipo de CAA tenían que interpretar la especificación para el resto del personal<br />Especificación de interfaz de usuario menos precisa y completa que la del núcleo<br />Especificaciones poco claras en determinados puntos<br />
  42. 42. CONCLUSIONES<br />Especificación formal debe ir acompaña de información explicativa (texto, diagramas, anotaciones…)<br />Interfaz de usuario debe ser más precisa y completa<br />Uso de métodos formales ahorró costes, no esfuerzo<br />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.<br />
  43. 43. Fallos insignificantes relacionados con los problemas de especificación <br />Permite construir sistema correcto sin coste extra<br />No práctico pero sí beneficioso en proyectos de gran escala<br />Escribir la especificación fue un ejercicio útil en sí mismo<br />
  44. 44. La especificación fue base para el diseño, implementación y pruebas<br />Se utilizó para las pruebas de caja negra<br />Sirvió de base para la documentación.<br />Nos ha ayudado a aclarar los requisitos de forma precisa. Gracias a la formalidad de la notación.<br />
  45. 45. Ingenieros deben preguntarse:<br />NO si deben usar método formales<br />sino<br />CÓMO beneficiarse de estos métodos como parte de un completo enfoque de ingeniería del software<br />

×