Notas sobre el uso de Métodos formales en los procesos de

Notas sobre el uso de Métodos formales en los procesos de
desarrollo de software.
Hugo A. López A.
Abstract
Formal methods have emerged as analytical approaches where software programs can be verified
by means of powerful mathematical theories. This approach presents several advantages comparing
to informal methodologies, in terms of the quality of software, size of the proofs, reduced validation
cost and reduced time-to-market. However, these methods have not been successfully received by the
software development industry, and there exists several inconveniences that delay the acceptance in
the near future. This paper discuss some of the advantages of the use of formal methods as software
methodologies, as well as present current challenges that formal methods face in order to settle as
one recognized software methodology
Resumen
Los métodos formales han emergido como enfoques analı́ticos en donde el desarrollo de software
puede ser verificado por medio de poderosas teorı́as matemáticas, presentando ventajas en la calidad
del software, tiempo de desarrollo, tamaño y complejidad de las pruebas. Sin embargo, aún existen
muchos inconvenientes para la correcta implantación de los métodos formales como una métodologia
de desarrollo de software comúnmente aceptada en ingenierı́a de software. Este articulo discute
algunas de las ventajas del uso de métodos formales como metodologı́as de desarrollo, ası́ como
plantea los retos a vencer para una masificación de este enfoque.
1.
Introducción
La calidad del software es una de las problemáticas más importantes en los procesos de desarrollo de software. Garantizar el correcto funcionamiento bajo situaciones no determinadas es
una tarea que tiene que ser realizada con cuidado extremo. En algunos casos, este tipo de pruebas
son de mayor importancia, ya que involucran ambientes sensibles e información crı́tica en donde es necesario garantizar que cada uno de los componentes involucrados (hardware, software y
componentes humanos) actúe de manera correcta ante situaciones especı́ficas, con una variedad de
ejemplos que cubren áreas tan diversas como planeación de tráfico [2], aplicaciones militares [12] y
sistemas médicos [15], entre muchas otras [4].
Uno de los principales problemas que aqueja la ingenierı́a de software se sitúa en la definición
de requerimientos. Ambigüedad, vaguedad o incompompletitud en los requerimientos son siquiera
algunos de los retos que los desarrolladores tienen que enfrentar al hacer un análisis detallado del
sistema [23]. Los modelos formales presentan una alternativa práctica para solucionar estos problemas. Constituyen un enfoque analı́tico para la especificación, diseño y verificación de sistemas de
hardware y software. Su caracterı́stica principal es la rigurosidad en la que sus modelos se encuentran basados, con fundamentos en sólidos principios matemáticos que permiten definir con precisión
y sin temor a ambigüedades las necesidades de un sistema. Gracias a estos fundamentos, el software
generado mediante métodos formales puede ser verificado mediante el cumplimiento de propiedades
derivadas de la especificación. Este enfoque ha resultado ser exitoso frente a otras tendencias, encontrando errores en diseño que difı́cilmente habrı́an podido ser considerados usando otras técnicas.
Este artı́culo pretende introducir al lector en el uso de métodos formales para el desarrollo de
software, presentando una serie de consideraciones necesarias al tomar la decisión de incluir dichas
metodologı́as en el proceso de desarrollo de una organización. El artı́culo plantea la siguiente estructura: en el capitulo 2 se introducirán los métodos formales para el desarrollo de software, en el
capı́tulo 3 se presentará un comparativo entre las caracterı́sticas de los modelos formales en relación
al proceso de desarrollo de software. En el capitulo 4 se presentarán una serie de preguntas que
ayudarán a identificar al lector si las metodologı́as formales se ajustan a sus necesidades especificas.
Finalmente, en el capitulo 5 se presenta una discusión final.
2.
Qué son los métodos formales?
Los métodos formales (FM, por sus siglas en inglés) representan un conjunto de tendencias
de desarrollo de software y hardware en donde la especificación, verificación y diseño de componentes se realiza mediante notaciones, lenguajes, herramientas y técnicas basadas en teorı́as con
sólida fundamentación matemática. El uso de notaciones y lenguajes formales permite plantear de
manera clara los requerimientos de un sistema, generando especificaciones que definen el comportamiento en términos del ”qué debe hacer” y no del ”cómo lo hace”. Gracias al correcto proceso
de especificación, propiedades derivadas de cada modulo pueden ser verificadas mediante técnicas
de razonamiento asociadas a los modelos formales, como probadores de teoremas y verificadores de
modelos.
A partir de las especificaciones, la implementación de un sistema puede ser generada de manera
casi automática. Es necesario bajar en el grado de abstracción de las especificaciones mediante
técnicas como refinamiento o concretización (reification). En este proceso, denominado diseño formal, es necesario garantizar que cada nivel de abstracción generado cumple con las propiedades
verificadas en los grados en las abstracciones de más alto nivel. En los niveles más bajos es posible
encontrar notaciones y estructuras muy cercanas a los lenguajes de programación, generando del
último nivel una implementación que puede ser verificada e instanciada en un lenguaje de programación.
Teniendo en cuenta los niveles de abstracción y las caracterı́sticas propias de cada sistema,
una variedad significativa de modelos han sido propuestos. En los procesos de especificación, tres
grandes corrientes pueden ser identificadas: Lenguajes basados en modelos y estados (e.g., VDM
[16], Z [26] o sus posteriores extensiones en el método B [27]), Lenguajes de especificación para
sistemas concurrentes (el caso de CSP [13] o el cálculo π [21] ) o especificaciones para sistemas
temporales (e.g., TLZ[19], LOTOS [9] y los cálculos basados en tcc [25, 22]). Para los procesos
de verificación, dos grandes enfoques son reconocidos: los verificadores de modelos, que realizan
una busqueda exhaustiva sobre los estados posibles de una especificación para encontrar posibles
fallas no consideradas, y los probadores de teoremas, en donde la especificación y sus propiedades
deseables se formalizan como formulas lógicas, y se prueban mediante una serie de axiomas y reglas
de inferencia presentes en cada probador.
Los métodos formales difieren en la manera y tiempos de cada una de las fases del ciclo de vida
del software. Su utilización requiere mayor tiempo en el desarrollo de especificación y la construcción de diseños correctos, lo que aumenta el tiempo de las fases de análisis y diseño; sin embargo, los
2
métodos usados, ”correctos por construcción”, disminuyen el tiempo de verificación del software,
al requerir una cantidad de casos de prueba mucho más reducida que cubre todo el panorama de
prueba, a diferencia de validaciones en base a simulaciones que son incompletas e ineficientes.
3.
Ventajas e Inconvenientes
Si bien los métodos formales constituyen un acercamiento alternativo a las metodologı́as de
desarrollo de software, existen un número de diferencias significativas que deben de ser consideradas
al pensar en instaurar los métodos formales en un equipo de desarrollo de software:
3.1.
Entrenamiento
Los métodos formales requieren de un nivel avanzado en matemáticas. Más que seguir una
notación especı́fica, el mayor problema se presenta en los modelos mentales del equipo desarrollador.
Tı́picamente, los modelos de elicitación de requerimientos plantean sus metas en lenguaje natural,
en busca de un correcto entendimiento entre el cliente y el equipo de desarrollo. Sin embargo, la
traducción de los pliegos de requerimientos a especificaciones formales tienden a resultar fallidas,
generando sólo especificaciones ambigüas e incompletas. Es necesario un entrenamiento a nivel de
todo el equipo de desarrollo, de manera que cualquiera se encuentre en capacidad de definir y
entender especificaciones por si mismo.
3.2.
Pluralidad de Modelos
Una de las dificultades en usar modelos formales es la ausencia de una metodologı́a única para
el desarrollo de software. Diversos modelos han sido propuestos desde las matemáticas, cada uno
especialmente diseñado para las necesidades de un entorno especı́fico: Refinamiento y maquinas
de estados finitos para modelos secuenciales, redes de Petri y álgebras de procesos para computación distribuida, lógicas temporales lineales y ramificadas para computación dinámica y modelos
de eventos para computación en tiempo real son sólo algunas de las múltiples ramas existentes.
Esta multiplicidad de enfoques tiene ventajas y desventajas: Es posible aprovechar cada uno de los
formalismos para expresar con mayor nivel de claridad una especificación de un sistema; sin embargo, la misma pluralidad de modelos exige un conocimiento experto en cada uno de los modelos
existentes para lograr el mayor aprovechamiento de los metodos formales en la especificación de
dichos sistemas.
3.3.
El lado obscuro de las matemáticas.
Una de las mayores dificultades que han tenido que enfrentar los métodos formales para la
instauración dentro de los procesos productivos de la ingenierı́a de software tiene que ver con las
herramientas mismas. Las notaciones son difı́ciles de entender para la mayorı́a de los ingenieros involucrados y hasta el momento son pocas las herramientas con la madurez suficiente para modelar
sistemas realmente complejos. Actualmente existen esfuerzos para sobrellevar estos inconvenientes:
la integración de cálculos de procesos y UML parece una tendencia prometedora para que herramientas de tipo CASE puedan brindar entornos de verificación mucho más cercanos al común de
los ingenieros de software [18, 17, 7]. Sobre las herramientas para verificación, el proceso continuo
de desarrollo de frameworks como LOTOS, the Concurrency Workbench [5] o FDR[20] ha permitido que los errores presentes en versiones anteriores sean solucionados; sin embargo, es necesaria
3
un mayor uso por parte de la comunidad, de manera que la experiencia adquirida entre los usuarios finales y los desarrolladores permitan solucionar errores y plantear nuevas caracterı́sticas que
permitan cerrar el abismo existente entre ellos.
4.
Dos enfoques, una sola ingenierı́a
Ciertamente la inclusión de los modelos formales como metodologı́a de desarrollo de software
es hasta ahora, uno de los tópicos más discutidos en las ciencias de la computación. Dos grandes
corrientes pueden ser reconocidas actualmente. Los grupos a favor, plantean dentro de sus razones
más importantes la generación de sistemas correctos en ambientes en donde un fallo puede resultar
crı́tico para la estabilidad de un sistema, los beneficios de un costo ostensiblemente menor, el
aumento en la documentación, y la reducción de errores en los procesos de desarrollo de software.
Sus detractores plantean el aumento en el tiempo de producción, falta de experticia por parte del
personal, falta de usabilidad en las herramientas formales, y dificultad en aplicaciones con cambios
constantes en sus diseños. Si bien ambos grupos tienen razones de peso para plantear una posición,
y muchas de las virtudes encontradas en el uso de modelos formales pueden conseguirse bajo otros
modelos de desarrollo riguroso (the Capability Maturity Model Integration – CMMI [3] es un
ejemplo de ello), el uso de modelos formales en muchos casos puede o no ser conveniente. Para
esto es importante definir una serie de caracterı́sticas importantes en la escogencia del enfoque de
desarrollo para un sistema de software:
Modelo Fenomenológico: Identifica los fundamentos cientı́ficos de la aplicación a desarrollar de
acuerdo al fenómeno estudiado, de manera que el modelo formal pueda considerar sus aspectos
más relevantes en los procesos de abstracción. Por ejemplo: al desarrollar una aplicación para
balı́stica, el modelo fenomenológico esta guiado por la mecánica clásica. Mientras que una
aplicación de redes estará fundamentada en teorı́as de tráfico y Conmutación.
Modelo Computacional de la aplicación: Define la estructura en alto nivel en donde los procesos de cómputo se llevarán a cabo. Pueden identificarse modelos secuenciales, distribuidos,
concurrentes o de tiempo real. Los cuales identificarán el modelo formal más apropiado para
expresar la aplicación.
Caracterı́sticas del ambiente de ejecución: Identifica las caracterı́sticas fı́sicas y sociales en las
cuales el sistema debe estar en capacidad de operar, definiendo el nivel de detalle requerido
en la verificación del sistema. Por ejemplo, una aplicación relacionada con la seguridad debe
garantizar gran confianza respecto a los posibles ataques en su ambiente de ejecución, mientras
que una aplicación de realidad virtual debe permitir al usuario un amplio grado de interacción
con el sistema.
Aplicación Objetivo: Es necesario identificar cuál es la necesidad principal del sistema, como
criterio decisorio en la selección de los métodos formales: Aparentemente, el correcto funcionamiento, y el alto desempeño pueden verse beneficiados usando estas técnicas; sin embargo,
la facilidad de uso, o las aplicaciones con alta tendencia al cambio en sus requerimientos se
ven beneficiadas con otros modelos, como los modelos orientados a objetos.
5.
Discusión
Si bien el uso de los métodos formales presupone una rigurosidad en los procesos, es importante
aclarar que su uso no es el único que define un proceso maduro en el desarrollo de software; ası́ mismo, el simple hecho de usar modelos formales no garantiza que las implementaciones generadas
4
tengan la total confianza esperada, para esto es necesario seguir la rigurosidad de todo proceso de
desarrollo, verificando que los modelos cumplan con las propiedades especificadas. Actualmente,
los metodos formales han sido principalmente utilizados en las etapas de análisis y diseño. Existen
algunos casos documentados en donde el proceso completo de desarrollo ha sido guiado desde una
perspectiva formal: el sistema para tráfico aéreo CDIS [11], el sistema aeronáutico para Lookheed
[8] y la verificación de procesadores [1]. Sin embargo, podrı́a decirse que falta mucho para lograr
una aceptación general de estos métodos dentro del proceso de desarrollo. son necesarios métodos
integradores en donde el ingeniero de software pueda realizar especificaciones de manera intuitiva,
de manera que estos modelos puedan traducirse a formalismos matemáticos verificables. Adicionalmente, métodos formales en donde solo las partes más crı́ticas del sistema se vean beneficiadas por
las pruebas formales, sin afectar la consistencia del resto del sistema son deseables para facilitar
los procesos de desarrollo. Finalmente, una educación con mayor profundidad en habilidades matemáticas es necesaria para poder implantar los métodos formales como estándares de desarrollo
de software.
Referencias
[1] P. Black, K. Hall, M. Jones, T. Larson, and P. Windley. A brief introduction to formal methods.
In IEEE 1996 Custom Integrated Circuits Conference (CICC ’96), pages 377–380, May 1996.
[2] J. P. Bowen and M. G. Hinchey. The use of industrial-strength formal methods. pages 332–337,
13–15 August 1997.
[3] Mary Beth Chrissis, Mike Konrad, and Sandy Shrum. CMMI Guidlines for Process Integration
and Product Improvement. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA,
2003.
[4] E. M. Clarke and J.M. Wing. Formal methods: state of the art and future directions. ACM
Computing Surveys, 28(4):626–643, 1996.
[5] Rance Cleaveland, Joachim Parrow, and Bernhard Steffen. The concurrency workbench: a
semantics-based tool for the verification of concurrent systems. ACM Trans. Program. Lang.
Syst., 15(1):36–72, 1993.
[6] E. F. Codd. A relational model of data for large shared data banks. Commun. ACM, 26(1):64–
69, 1983.
[7] David Crocker. Perfect developer: A tool for object-oriented formal specification and refinement. In Tools Exhibition Notes at Formal Methods Europe, 2003.
[8] Martin Croxford and James Sutton. Breaking through the v and v bottleneck. In Ada-Europe,
pages 344–354, 1995.
[9] P. Van Eijk and Michel Diaz, editors. Formal Description Technique Lotos: Results of the
Esprit Sedos Project. Elsevier Science Inc., New York, NY, USA, 1989.
[10] Formal Methods Europe.
Choosing a formal
http://www.fmeurope.org/fme/choosing.htm, 2006.
method.
Available
at
[11] Anthony Hall. Using formal methods to develop an atc information system. IEEE Softw.,
13(2):66–76, 1996.
5
[12] Constance Heitmeyer, Dino Mandrioli, and Politecnico Milano. Formal Methods for Real-Time
Computing. John Wiley & Sons, Inc., New York, NY, USA, 1996.
[13] C. A. R. Hoare. Communicating Sequential Processes. Commun. ACM, 26(1):100–106, 1983.
[14] M. Jackson. Formal methods and traditional engineering. J. Syst. Softw., 40(3):191–194, 1998.
[15] Jonathan Jacky, Jonathan Unger, Michael Patrick, David Reid, and Ruedi Risler. Experience
with z developing a control program for a radiation therapy machine. In Jonathan P. Bowen,
Michael G. Hinchey, and David Till, editors, ZUM, volume 1212 of Lecture Notes in Computer
Science, pages 317–328. Springer, 1997.
[16] Cliff B. Jones. Systematic Software Development using VDM. Prentice-Hall, Upper Saddle
River, NJ 07458, USA, 1990.
[17] Katerina Korenblat and Corrado Priami. Extraction of pi-calculus specifications from uml
sequence and state diagrams. Technical report, University of Trento, 2003.
[18] Vitus S. W. Lam and Julian A. Padget. On execution semantics of uml statechart diagrams
using the pi-calculus. In Ban Al-Ani, Hamid R. Arabnia, and Youngsong Mun, editors, Software
Engineering Research and Practice, pages 877–882. CSREA Press, 2003.
[19] Leslie Lamport. Tlz. In Z User Workshop, pages 267–268, 1994.
[20] Gavin Lowe. Breaking and fixing the needham-schroeder public-key protocol using fdr. Software - Concepts and Tools, 17(3):93–102, 1996.
[21] Robin Milner. Communicating and Mobile systems. The Pi Calculus. Cambridge University
Press, 1999.
[22] Catuscia Palamidessi and Frank Valencia. A temporal concurrent constraint programming
calculus. In Toby Walsh, editor, Proc. of the 7th International Conference on Principles and
Practice of Constraint Programming, volume 2239, pages 302–316. LNCS, Springer-Verlag,
2001.
[23] Roger S. Pressman. Software Engineering: A Practitioner’s Approach. McGraw-Hill Higher
Education, 2000.
[24] Hossein Saiedian. An invitation to formal methods. Computer, 29(4):16–17, 1996.
[25] Vijay A. Saraswat, Radha Jagadeesan, and Vineet Gupta. Timed default concurrent constraint
programming. Journal of Symbolic Computation, 22(5/6):475–520, 1996.
[26] J. M. Spivey. The Z notation: a reference manual. Prentice-Hall, Inc., Upper Saddle River,
NJ, USA, 1989.
[27] J. B. Wordsworth. Software engineering with B. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, USA, 1996.
6