Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas Título: Técnicas Formales en procesos de desarrollo de Software Libre.
Autoras: Kirenia Bravo Fernández Daniar Babastro Rodríguez
Tutores: Ing. Susel Cañete Pollán MSc. Daymy Tamayo Ávila MSc. David Leyva Leyva
“Ciudad de la Habana, Junio 2008”
„‟Año 50 de la Revolución‟‟
El único autógrafo digno de un hombre es el que deja escrito con sus obras...
José Martí
Informáticas a hacer uso del mismo en su beneficio.
Para que así conste firmo la presente a los __4__ días del mes de _Julio__ del año _2008____.
_____________________________ __________________________
Kirenia Bravo Fernández MSc. David Leyva Leyva
____________________________ __________________________
Daniar Babastro Rodríguez Ing. Susel Cañete Pollán _____________________________
MSc. Daymy Tamayo Ávila
I
Agradecimientos
Agradecemos profundamente a todos los que de una forma u otra formaron parte de esta obra que se ha convertido en el fruto de cinco años de esfuerzo y dedicación.
De una forma muy especial a nuestro líder y Comandante en jefe Fidel Castro Ruz que nos dio la oportunidad de forjarnos como ingenieros informáticos y escribir nuestra historia en medio de la batalla de ideas del pueblo cubano. Gracias Comandante por haber sido la luz que nos conectó al futuro, con tus ideas, tu valor y la confianza que depositaste en cada uno de nosotros.
Nos sentimos eternamente agradecidos con las personas a quienes acudimos para obtener información y que desinteresadamente nos brindaron un poco de su fe y su ayuda.
Agradecemos a nuestros padres por darnos una razón de seguir adelante cada día y ayudarnos en todas las cosas que nos han pasado en estos 5 años de la carrera, a nuestros tutores especialmente a David, por poner su empeño para que las cosas salieran como deben ser, también a los compañeros de clases y amigos que de alguna forma aportaron ideas en nuestra investigación.
Muchas Gracias!!!
II
Dedico la realización de mi trabajo de diploma:
A toda mi familia que me han apoyado desde pequeña, en especial a mis abuelos maternos que han sabido llevarme siempre por el mejor camino, que han estado en mis momentos buenos y malos y hoy celebran conmigo el fruto de largos años de estudio y sacrificio.
A mi abuela y siempre amiga que nunca me deja fallar y con sus lecciones me enseñó a mirar al futuro y me vio siempre en el lugar de una estudiante graduada de la universidad.
A mi madre por desvelarse por mis problemas, por sus consejos de no dejarme caer por los nervios y estar siempre a mi lado. A mi hermano Jorge Carlos, por ser unas de las razones de inspiración, y estar orgulloso de mí.
A mi gran amor, Adonis por estar siempre a mi lado cuando más lo necesitaba para darme su apoyo, por darme un pedacito de su vida, ánimo para seguir y luchar por ver realizado el sueño que finalmente se cumple con la culminación de esta Tesis.
A mis amistades Mailis, Yuni, Juana, Yadira, Daniar por confiar siempre en mí y a todas aquellas personas que de una forma u otra estuvieron conmigo y aportaron su granito de arena en esta investigación.
A todos ellos, que también forman las ideas que dejé plasmadas aquí, gracias por ser parte de mí.
Kirenia
III
Dedico mi trabajo de diploma:
A toda mi familia que han sabido apoyarme en todos desde que era una bebita, pero sobre todas las cosas a mi mamita y a mi hermanito que más que eso son mis mejores amigos, que con su ayuda y su apoyo he llegado hasta aquí, a mi abuelito que aunque ya no este a mi lado siento que día a día me dice que siga a delante.
A mis amigos y compañeros los cuales no son perfectos pero todos estos años me han dando lo mejor de ellos, a Annies, a Lisandra, a Yaritza, a Yanisvel, a Eva, en especial a Kirenia que supo darme toda su ayuda cuando más la necesité y más que eso confió en mi, para ella un beso.
A Ornolis mi amor, que hizo que yo creyera en mí y que me dio su pecho justo en el momento preciso.
Gracias amor por todo aquello que me has dado, tu compañía, tus caricias, tu verdad, y por haberme regalado un pedacito de tu vida.
Daniar
IV Resumen
En la actualidad las técnicas formales se emplean en el proceso de desarrollo del software para eliminar los errores a tiempo y para la verificación y pruebas del sistema. Sin embargo, es insuficiente su integración en la industria del software. Con este trabajo “Técnicas Formales en procesos de desarrollo de Software Libre”, se pretende contribuir al empleo de las técnicas formales en la producción de software de la Universidad de las Ciencias Informáticas.
Se estudiaron las técnicas formales que se utilizan actualmente en el proceso de desarrollo de software libre, así como las herramientas orientadas al trabajo con ellas, para garantizar la correcta utilización de estas técnicas y obtener lo mejor de cada una de ellas en las fases de la evolución del sistema.
Finalmente se hace una propuesta de técnicas formales y herramientas orientadas a estas, vinculadas al proceso de desarrollo de software, que combinadas pueden tener buenos resultados.
PALABRAS CLAVE
Técnicas formales, herramientas basadas en técnicas formales, desarrollo de software libre.
V ÍNDICE
INTRODUCCIÓN ... 1
CAPÍTULO 1. FUNDAMENTACIÓN DEL TEMA ... 5
1.1INTRODUCCIÓN ... 5
1.2TÉCNICAS TRADICIONALES ... 5
1.3TÉCNICAS FORMALES ... 5
1.3.1 Breve reseña histórica de los métodos formales ... 6
1.4 CONCEPTOS BÁSICOS ... 6
1.5CALIDAD DEL SOFTWARE... 13
1.6 PROBLEMÁTICA ACTUAL DE LOS MÉTODOS FORMALES ... 15
1.7OPINIONES EN CONTRA Y A FAVOR DE LOS MÉTODOS FORMALES. ... 16
1.8CLASIFICACIÓN DE LOS MÉTODOS FORMALES ... 18
1.9 TÉCNICAS DE DESCRIPCIÓN FORMAL ... 19
1.10 VERIFICACIÓN FORMAL. ... 20
1.11MANDAMIENTOS DE LOS MÉTODOS FORMALES. ... 23
1.12MÉTODOS FORMALES ORIENTADOS A OBJETOS ... 25
1.12.1 Definición de métodos formales orientados a objetos ... 25
1.13LA INTEGRACIÓN DE LOS MÉTODOS FORMALES EN EL PROCESO DE DESARROLLO DE SOFTWARE. ... 27
1.14FORMACIÓN Y TRANSFERENCIA TECNOLÓGICA ... 28
1.15HERRAMIENTAS PARA EL DESARROLLO DE SOFTWARE ... 28
1.16CONCLUSIONES PARCIALES ... 33
CAPÍTULO 2. INTEGRACIÓN DE LOS MÉTODOS FORMALES EN EL PROCESO DE DESARROLLO DEL SOFTWARE LIBRE ... 34
2.1INTRODUCCIÓN ... 34
2.2PROCESO DE DESARROLLO DE SOFTWARE ... 34
2.2.1 Modelo de desarrollo del software... 35
2.2.2 Metodologías que se utilizan en los proyectos productivos en la UCI ... 39
2.2.3 Etapas del proceso de desarrollo del software ... 40
2.3PROCESO DE DESARROLLO DE SOFTWARE LIBRE ... 42
2.3.1 Captura de requisitos ... 42
2.3.2 Análisis ... 43
2.3.3 Diseño ... 43
2.3.4 Implementación... 43
2.3.5 Pruebas ... 43
2.3.6 Mantenimiento ... 44
2.4 TÉCNICAS FORMALES EMPLEADAS EN EL PROCESO DE DESARROLLO DE SOFTWARE LIBRE ... 44
2.4.1Técnicas Formales para la especificación de requisitos. ... 44
VI
2.4.2 Captura de Requisitos... 45
2.4.2.1 Definición de Requisitos ... 45
2.4.3 Validación de Requisitos ... 46
2.4.4 Técnicas Formales para la modelación del sistema. ... 47
2.4.5 Técnicas Formales para la construcción del sistema. ... 48
2.4.6 Técnicas formales para pruebas. ... 49
2.5HERRAMIENTAS ORIENTADAS A TÉCNICAS FORMALES ... 50
2.6CONCLUSIONES PARCIALES ... 52
CAPÍTULO 3: PROPUESTAS DE TÉCNICAS FORMALES Y HERRAMIENTAS ... 53
3.1INTRODUCCIÓN ... 53
3.3RESULTADOS DE LAS ENTREVISTAS ... 54
3.3 PROPUESTAS ... 54
3.4CONCLUSIONES PARCIALES... 56
CONCLUSIONES GENERALES... 57
RECOMENDACIONES ... 58
BIBLIOGRAFÍA: ... 59
GLOSARIO DE TÉRMINOS ... 63
ANEXOS……….78
1 Introducción
Con el nacimiento de la informática como una rama que estudia el tratamiento de la información mediante el uso de máquinas automáticas, las nuevas tecnologías de la información y las comunicaciones (TIC) desempeñan un papel central en las tareas cotidianas de la sociedad y ha estimulado el progresivo avance en el intercambio de información y el desarrollo de nuevas técnicas, herramientas, nuevos descubrimientos científicos para el desarrollo de software.
Se abre paso una nueva área de investigación conocida como Ingeniería de Software, que no es más que una tecnología multicapa en la que según [PRESSMAN 2005] se pueden identificar: los métodos, el proceso y las herramientas, que tiene como objetivo el establecimiento de métricas, estándares, procedimientos para lograr un software robusto, eficaz y sobre todo, con calidad.
El software debe presentar calidad en su funcionamiento, debido a que la calidad es la “concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente [PRESSMAN 2005]. La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software.[LOVELLE 1999]
En los últimos años, cobra cada vez más fuerza la idea de que una formalización matemática del software es el enfoque más apropiado para conseguir mejorar su calidad. Ello ha dado un fuerte impulso a la definición y empleo de lo que se han denominado métodos o técnicas formales en el proceso de desarrollo del software. [SOLLA 1999]
Los métodos formales son cualquier técnica basada en el uso de las matemáticas, aplicable al desarrollo de sistemas software.[DUQUE 2000]
Los mismos tienen como denominador común el empleo de las matemáticas (fundamentalmente la teoría de conjuntos, la lógica y el álgebra) para la modelación del sistema que se quiere construir. Esto permite desde el primer momento, razonar acerca de los errores que se puedan cometer, sin tener que llegar a la fase de codificación, donde los defectos de diseño están tan estables que su corrección implica un alto coste económico. Esto trae consigo como objetivo permitir la verificación y prueba del sistema, a lo largo de todo el ciclo de vida de un software, facilitando el desarrollo de especificaciones
2
claras, concisas y no ambiguas. Permite el análisis funcional de la especificación y posibilita el desarrollo de implementaciones correctas con respecto a la especificación. Además facilita la eliminación de errores, siendo así más barato y fácil de corregir.
Los métodos formales han aparecido 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. Las técnicas formales permiten validar el sistema en todo el proceso de desarrollo, evitando que los errores existentes se dispersen por todo el desarrollo del software. [PRESSMAN 2005]
Sin embargo, aún existen muchos inconvenientes para la correcta implantación de los métodos formales ya que a pesar de las ventajas potenciales de estos, es insuficiente su integración en la industria del software. Los principales argumentos para no usar técnicas formales son:
Es difícil demostrar, a priori, que el esfuerzo invertido en el desarrollo de especificaciones fo rmales se verá recompensado en las otras fases del proceso de desarrollo software. Los gestores de proyectos software prefieren adoptar posturas conservativas y no emplear nuevas técnicas hasta que sus beneficios no sean más claros.
Gran parte de los ingenieros software, especialmente los que cuentan con mayor experiencia, no han sido entrenados en el uso de estas técnicas que requieren conocer conceptos de matemática discreta y de lógica.
Los clientes no suelen conocer las técnicas de descripción formal, por lo que, en principio, son renuentes a invertir en técnicas que desconocen.[DUQUE 2000]
La aplicación práctica de los métodos formales en la industria del software encuentra gran resistencia, debido fundamentalmente a dos deficiencias: la falta de herramientas que demuestren sus ventajas en la teoría y en la práctica; y la necesidad de un nuevo proceso de adaptación en los usuarios y trabajadores involucrados en el proceso de desarrollo de software y también en el proceso de desarrollo de software libre, que no están acostumbrados a la utilización de este tipo de técnicas. En cualquier caso, existen argumentos en los dos sentidos, a favor y en contra, y sólo la aplicación real de dichas técnicas dentro de la industria podría clarificar su realidad.
Consecuentemente con esto, la escasa o no aplicación de técnicas formales y herramientas para procesos de desarrollo en software libre, se ha convertido en una necesidad en la industria del software. Además como resultado del poco conocimiento de estas técnicas y herramientas en la
3
Universidad de las Ciencias Informáticas (UCI), se hace necesario profundizar en este tema y utilizarlas para el buen desarrollo en los procesos productivos.
Para el proceso de desarrollo de software existe un trabajo de diploma, el cual trata el contenido de técnicas formales para el análisis y predicción del comportamiento fiable del software, pero este trabajo se refiere a las técnicas formales en procesos de desarrollo de software libre.
Por todo lo anteriormente expuesto se plantea como problema científico: ¿Cómo favorecer los procesos de desarrollo de software libre aplicando técnicas formales?
El objeto de estudio se enmarca en las técnicas formales y herramientas usadas en el desarrollo del software, teniendo como campo de acción, métodos formales y herramientas para el desarrollo de software libre.
Las preguntas científicas son:
¿Qué métodos formales pudieran utilizarse para el desarrollo de software libre en los proyectos productivos de la Facultad 10 y la UCI en general?
¿Cómo integrar los métodos formales en el proceso de desarrollo de software libre?
¿Cuáles herramientas libres basadas en técnicas formales pueden ser utilizadas en el proceso de desarrollo de software libre?
El objetivo general de este trabajo es proponer técnicas formales y herramientas basadas en estas técnicas para el desarrollo de software, que puedan emplearse en el desarrollo software libre.
Se definen las siguientes tareas de investigación:
1. Realizar un estudio de temas relacionados con las técnicas formales.
2. Identificar las técnicas formales que se pudieran aplicar en el proceso de desarrollo de software libre.
3. Analizar las técnicas formales que se pudieran aplicar en el proceso de desarrollo de software libre.
4. Realizar búsqueda de herramientas más usadas orientadas a técnicas formales para garantizar el desarrollo de software libre.
5. Hacer una propuesta de técnicas formales y herramientas basadas en estas técnicas para el desarrollo de software libre.
4
Para la realización de este trabajo se utilizan diferentes métodos científicos. El método analítico – sintético servirá de apoyo para extraer los elementos más significativos relacionados con métodos formales y herramientas libres para el desarrollo de software. Se utilizará el método inductivo – deductivo para la investigación de los temas de técnicas formales y herramientas libres, pues permite arribar a conclusiones generales a partir del estudio del tema. Además se empleará el método análisis histórico – lógico para estudiar la evolución histórica de las técnicas formales, y así poder plasmar el marco teórico de la investigación.
Por otra parte se utilizarán métodos empíricos como las entrevistas, mediante las cuales se podrá analizar el conocimiento existente en los desarrolladores de software y analistas de sistemas acerca de los métodos formales.
El contenido de esta investigación está desglosado en introducción, tres capítulos, conclusiones generales, referencias bibliográficas y bibliografía utilizada, glosario de términos y anexos.
El Capítulo I. Fundamentación Teórica: se presentan términos y conceptos asociados a las técnicas formales, su vinculación al proceso de desarrollo de software, en particular al software libre. También se analizan herramientas basadas en estas técnicas.
El Capítulo II. Integración de los métodos formales en el proceso de desarrollo de software libre: Está enmarcado en los métodos formales en procesos de desarrollo de software libre y herramientas libres.
En el Capítulo III. Propuestas de técnicas formales y herramientas: Se dan propuestas de técnicas formales y herramientas libres para el proceso de desarrollo del software libre. También se evalúan los resultados de los métodos de investigación que utilizados en el desarrollo de la investigación.
5 Capítulo 1. Fundamentación del tema
1.1 Introducción
Durante el desarrollo del presente capítulo se exponen los principales aspectos relacionados con las técnicas formales, también serán analizados otros que están estrechamente relacionados. Además se hace mención a elementos de las técnicas formales que intervienen en el proceso de desarrollo del software. Se tratarán de forma general conceptos referidos a las principales técnicas tradicionales y formales que se utilizan actualmente en el proceso de software.
1.2 Técnicas Tradicionales
Se denominan técnicas tradicionales a las más antiguas, las que tradicionalmente el ingeniero utiliza para desarrollar un producto, ejemplo de ellas son: las encuestas, entrevistas, cuestionarios y análisis de documentación existente. Las técnicas tradicionales extraen requerimientos de las personas individuales y de los documentos. Además las pueden emplear personas con un entrenamiento previo, sin embargo, otras técnicas como las cognitivas puede ser cuantificadas en términos de:
Disponibilidad de los involucrados: cantidad de personas y el tiempo de disponibilidad.
Trabajo de preparación de las sesiones.
Entrenamiento de los ingenieros de requerimiento. [NÚÑEZ CAMALLEA 2005]
1.3 Técnicas Formales
En otras ingenierías, las matemáticas constituyen una herramienta fundamental de estudio y análisis.
Pero, a pesar de las ventajas potenciales que ofrece la aplicación de técnicas formales en la ingeniería de software, están escasamente implantadas a nivel industrial, constituyendo, actualmente, una de las líneas de investigación más importantes dentro de la ingeniería de software.
6 1.3.1 Breve reseña histórica de los métodos formales
Las técnicas o métodos formales, llegan al mundo después de la aparición de la ingeniería de software, como parte de ella. En 1968 durante la conferencia de la OTAN en Garmish (Alemania), se trataron varios temas, específicamente sobre la construcción del software. [GARCÍA?]
En este congreso se habló de lo difícil que era y el trabajo que se pasaba cuando se iba a construir un software completamente nuevo, seguro y de calidad. En los años 70 aparecen los primeros indicios de los métodos formales, cuando aún no existían modelos de calidad como CMM. La técnica Z fue una de las primeras, y sirvió de base para lo que sería después B [B 2007] . Estas surgieron precisamente para tratar de resolver los problemas que se venían sucediendo con el software, muchos errores que sin poderlos detectar a tiempo se convertían en serios problemas tanto para los ingenieros como para los usuarios finales.
Se planteó la meta de desarrollar sistemas que pudieran ser verificados, corregidos, cuantas veces fuera necesario y en cualquier momento. Para ello establecieron métodos que, matemáticamente o mediante reglas lógicas, definían un sistema y podían comprobarlo disminuyendo así los índices de errores que tenía [GARCÍA?] .
Poco a poco fueron desarrollando nuevos métodos que se dedicaban a ciertas ramas específicas de la industria, ganándose así la confianza de grandes productores. A pesar de las ventajas que representaban para la confiabilidad del software, muchos ingenieros no se atrevían a asumirlos por sus bases matemáticas, alegando que para trabajar con ellos hay que tener conocimientos muy profundos de esa ciencia. Otros, que antes se veían intimidados, tuvieron que aventurarse por problemas de seguridad o pérdidas muy grandes en sus empresas. [GARCÍA?]
Actualmente se conoce que los métodos formales sirven de gran ayuda para los sistemas de comunicaciones, compiladores, aplicaciones de transporte, etc. Aún así, no se utilizan en todos los países, ni en todas las industrias. Para trabajar con ellos es necesario tener un sólido conocimiento matemático, pero su uso puede ser beneficioso y evitar pérdidas por no emplearlos.
1.4 Conceptos Básicos
Los métodos formales son 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ólido fundamento matemático. [AVENDAÑO 2006]
7
Un método es formal si posee una base matemática estable y dicha base, a su vez, está dada por un lenguaje de especificación. Esta base proporciona una forma de definir de manera precisa nociones tales como la consistencia y completitud, y aún más relevante la especificación, la implementación y la corrección [PRESSMAN 2005]. Los métodos formales permiten a los ingenieros de software especificar, desarrollar y verificar un sistema basado en computadora aplicando una notación rigurosa. Además, crear una especificación sin imprecisiones que sea más completa y constante que las que se utilizan en otros métodos.
El lenguaje de especificación Z está acompañado de una herramienta automatizada que almacena axiomas, reglas de inferencias y teoremas orientados a la aplicación que dan lugar a pruebas de corrección matemáticas de la especificación.
Las especificaciones en Z se estructuran como un conjunto de esquemas, son estructuras parecidas a cuadros que presentan variables y que especifican la relación existente entre las variables. Un esquema es en esencia una especificación formal análoga a la subrutina o el procedimiento de un lenguaje de programación. Del mismo modo que los procedimientos y las subrutinas se utilizan para la estructura de un sistema, los esquemas se utilizan para estructurar una especificación formal.
La notación Z está basada en la teoría de conjuntos con tipos, y en la lógica de primer orden. Z proporciona una estructura denominada esquema, para describir el estado y las operaciones de una especificación.
Los esquemas agrupan las declaraciones de variables con una lista de predicados que limitan los posibles valores de las variables. [PRESSMAN 2005]
A continuación, se destacan dos sistemas reales en los que se empleó Z:
CICS (Customer Information Control System) es un proyecto desarrollado por IBM en colaboración con el Laboratorio de Computación de la Universidad de Oxford. En 1992 se utilizó Z para la nueva versión del sistema de procesamiento de transacciones de la versión CICS/ESA V3.1.
En CIDS se utilizó Z como especificación formal de parte del software del Airbus A330/340.
[DUQUE 2000]
B: En [DUQUE 2000] podemos ver más información sobre esta técnica. Es también una técnica formal derivada de Z, y ha sido desarrollada igualmente por Jean Raymond Abrial, con el objetivo de especificar y verificar tanto sistemas hardware como software. Es un conjunto de técnicas
8
matemáticas apropiadas para el diseño e implementación de componentes software. Incluye un grupo de herramientas como B-Toolkit y Atelier-B que han sido aplicadas en varias ramas de la industria.
Varios trabajos prácticos pueden encontrarse en [B 2007] como muestra de la Séptima Conferencia del Método B que tuvo lugar del 17 al 19 de junio del año pasado en Francia.
VDM (Vienna Development Method) [DUQUE 2000] es una colección de técnicas para la especificación formal y el desarrollo de sistemas software. Tiene su origen en un laboratorio de Viena de IBM entre 1960 y 1970. El modelo del sistema se describe mediante un conjunto de tipos de datos y una serie de operaciones sobre los mismos que se representan mediante funciones. A cada función se le asocia una pre-condición y una post-condición.
Utiliza un lenguaje de especificación denominado VDM-SL. El lenguaje permite definir tipos complejos como conjuntos, registros, secuencias, etc., sobre los que se pueden especificar restricciones mediante invariantes. A diferencia de Z, en VDM-SL se diferencian dos tipos de componentes: estados (sobre los que se pueden especificar invariantes); y operaciones (con pre y post-condiciones).
Dos de los proyectos más relevantes en los que se ha utilizado VDM son:[DUQUE 2000]
CDIS. Parte del mecanismo de representación de información del sistema de control de tráfico aéreo de Londres fue verificado utilizando VDM. Este proyecto fue llevado a cabo en 1992 por la empresa Praxis.
ACS. En este caso, VDM se utilizó para especificar requisitos de seguridad de un sistema de almacenamiento de explosivos del ejército británico.
Cuando se aplican técnicas formales se produce una especificación representada en un lenguaje formal como Z y VDM.
LOTOS (Language Of Temporal Ordering Specification) [DUQUE 2000]: Es una técnica de descripción formal. Fue introducida por ISO en el año 1989. Su principal objetivo es expresar formalmente normas de servicios y protocolos OSI de una manera clara, no ambigua, precisa, completa, e independiente de la implementación.
Proporciona un modelo basado en álgebra de procesos para expresar el comportamiento e interacción entre procesos. Según sus funcionalidades LOTOS expresa el comportamiento e interacciones entre procesos concurrentes, debido a que está basado fundamentalmente en CSP y CCS. Otra visión de analizar dicha técnica es la especificación de datos abstractos.
9
En la actualidad, LOTOS se encuentra en proceso de revisión. Los trabajos de revisión, que se encuentran en una fase avanzada, darían lugar a una nueva versión de LOTOS denominada E- LOTOS (Enhanced-LOTOS).
LOLA, ISLA y CADP son tres de las herramientas más destacadas que han sido desarrolladas para LOTOS.
Lenguajes Formales: Las técnicas que se han convertido en alternativa para el lenguaje natural son los lenguajes formales que cumplen con el propósito de describir los requisitos de un sistema. Las especificaciones algebraicas como ejemplo de técnicas de descripción formal, han sido aplicadas en el mundo de la ingeniería de requisitos desde hace años.
Las características que tienen estos lenguajes pueden encontrarse en:[PAREDES HERNÁNDEZ 2000]
Componente semántico mínimo.
Posibilidad de incrementar el componente semántico de acuerdo con la teoría a formalizar.
La sintaxis produce oraciones no ambiguas.
La importancia del rol de los números.
Completa formalización y por esto, el potencial de la construcción computacional.
El mayor inconveniente es que no favorecen la comunicación entre cliente y analista. Por otro lado, es la representación menos ambigua de los requisitos y la que más se presta a técnicas de verificación automatizadas.
Ejemplos de estos lenguajes se puede mencionar a:
RAISE: Rigorous Approach to Industrial Software o en español Riguroso Enfoque Industrial a la Ingeniería de Software [PEDERSEN. 2004], es un lenguaje de especificación formal y consiste en el método de plantear el desarrollo. Se ha utilizado en la LaCoS, proyecto que fue financiado en el marco del programa ESPRIT II, así como a otros industriales y proyectos de investigación.
TRIO (Tempo Reale Implicito) [FURIA 2005]: es un lenguaje formal y un método para la especificación, análisis y verificación de las críticas, sistemas de tiempo real. Se basa en una extensión de métricas de primer orden, lógica temporal y apoya a la gestión de grandes y complejas funciones, y a mantener las especificaciones. Una colección de prototipos de herramientas de apoyo a la edición de especificaciones TRIO, para su análisis formal, y la
10
derivación de casos de prueba de ella está disponible de forma gratuita. TRIO se ha utilizado con éxito en varios proyectos industriales y continúa siendo objeto de la actividad de investigación en curso.
Existen ejemplos de lenguajes de especificación formal orientados a objetos como: OBLOG y TROLL.
Estos son utilizados en [VICENTE PELECHANO 1996] junto con OASIS en una forma de integración con algunos métodos de modelado conceptual para conseguir reducir el esfuerzo y la complejidad inherente a la utilización de estas técnicas, obteniendo el beneficio de su utilización, y eliminando el esfuerzo adicional.
Más información de los métodos formales orientados a objetos se verá en otro epígrafe.
Otra técnica formal es Larch: Es un proyecto de investigación, que según manifiesta [DUQUE 2000]
persigue explorar métodos, lenguajes y herramientas para facilitar el uso de las especificaciones formales. El proyecto se inició como alternativa del Instituto de Tecnología de Massachusetts (MIT por sus siglas en inglés), en el Grupo de Desarrollo de Programas Sistemáticos y en el Centro de Investigación de Sistemas Digital en Palo Alto, California.
Son métodos algebraicos basados en propiedades que utilizan axiomas ecuacionales. Una característica que los distingue es que cada especificación tiene componentes escritos en dos lenguajes: BISL (Lenguaje de Interfaz Larch, o en inglés, Behavioral Interface Specification Language) y LSL (Larch Shared Language). El primero se utiliza principalmente para describir las interfaces entre los componentes del programa a través de tipos abstractos de datos. El segundo es usado para describir el vocabulario matemático usado en especificaciones de pre y pos condiciones, sin importar el lenguaje.
CSP: Communicating Sequential Processes. En [DUQUE 2000] se hace referencia a un artículo de 1978 por C.A.R. Hoare, cuyo refinamiento dio origen a una notación más flexible en 1985. CSP es un lenguaje formal para describir patrones de interacción en sistemas concurrentes, el cual es soportado por una teoría matemática bastante fuerte, un conjunto de herramientas de prueba y literatura extensiva. Como se ha dicho anteriormente, esta técnica entra en la clasificación de las constructivas algebraicas. Ha sido aplicado en la industria del software extranjera para verificar y especificar aspectos concurrentes en varios sistemas. [POLLÁN 2007]
OBJ: Es una familia de lenguajes algebraicos de programación y de especificación de amplio espectro, basados en lógica de orden ecuacional, acompañado de otras como lógica ecuacional oculta o de primer orden, además proveen un poderoso sistema de módulos de programación parametrizada.
11
[GOGUEN 2005]. Todos los lenguajes OBJ están basados fundamentalmente en sistemas lógicos. Las últimas versiones de OBJ para el año 2005, usaban álgebra de orden clasificada.
Una de las aplicaciones de esta técnica ha sido al proyecto Tatami, el cual soporta diseño corporativo distribuido, especificación y validación de hardware y/o software, especialmente si son sistemas concurrentes distribuidos.
Estelle: De esta técnica de descripción formal no se conoce mucho, pero pueden encontrarse algunos datos interesantes en [TENNEY 2000]. Fue desarrollado para la especificación de servicios y protocolos del modelo de referencia OSI de ISO. No obstante, es útil para la especificación de sistemas distribuidos en general. Se distribuyen un conjunto de herramientas de Estelle, que se nombran en inglés Estelle Development Toolset (EDT), que incluyen un compilador, simulador y un depurador, un generador de pruebas y otro generador de tablas de estado/evento.
Ha sido aplicado a sistemas tanto Unix como Windows, por esto puede utilizarse en la esfera del software libre. Algunos recursos propios de esta técnica que han tenido repercusión en la industria del software por su valor operacional son el eXperimental Estelle Compiler (XEC), que es un compilador desarrollado por la Universidad de Kaiserslautern en Alemania. Lleva implícito el nombre experimental porque se concibió sólo para experimentos de puesta en práctica de métodos formales. Este producto fue desarrollado para construir una plataforma de prueba, evaluación del funcionamiento y la optimización de la implementación de los métodos para Estelle. Otros ejemplos del uso de esta técnica pueden ser encontrados en [TENNEY 2000].
También existen herramientas para su aplicación, pueden ser Pet Dingo, la cual fue desarrollada por NIST, que puede encontrarse una versión en [TENNEY 2000].
Petri Nets: Esta técnica toma el nombre en honor a su creador Karl Adam Petri, quien en 1962 creó lo que se conocen en español como Redes de Petri (RP). [GONZALES URMACHEA?]. En varios artículos visitados se hablaba que es una herramienta para el modelado de sistema, pero no es así, pues está demostrado que son métodos que contribuyen a modelar el comportamiento y la estructura de sistemas basados en la teoría de autómatas y llevar el modelo a condiciones límite, que en un sistema real son difíciles de lograr o muy costosas. Su característica más relevante es que pueden ser analizadas de manera formal y obtener información del comportamiento dinámico del sistema modelado.
12
Es aplicable a modelos de redes abstractas, procesamiento paralelo y distribuido, teoría de grafos, problemas de transporte, problemas de decisión y reconocimiento de patrones, entre otras [POLLÁN
2007].
Cuentan con un conjunto de herramientas disponibles que favorecen el trabajo de los desarrolladores debido a las ventajas que poseen, por lo que son muy conocidas y aplicadas.
Podemos ver aplicaciones practicas de las RP en [SÁNCHEZ PALMA 2000], donde se definen las bases teóricas y prácticas necesarias para la validación automática de especificaciones del lenguaje OASIS, como parte de un proyecto de Comisión Interministerial de Ciencia y Tecnología (CICYT).
Se puede decir que la notación de los métodos formales es utilizada para especificar (en vez de diseñar o implementar) el sistema requerido. Dos características que los identifican son abstracción y precisión. [MACCOLL 1999]
La teoría de conjuntos y las notaciones lógicas se utilizan para crear una sentencia clara de requisitos.
Esta especificación matemática se puede analizar para comprobar que sea correcta y constante. Como esta especificación se crea utilizando notaciones matemáticas, relativamente es menos confusa que los nodos informales de presentación.
Las técnicas formales tienen gran importancia ya que son capaces de reducir drásticamente los errores de especificación y consecuentemente son la base del software que tiene pocos errores una vez que el usuario comienza a utilizarlo. También los métodos formales proporcionan marcos de referencia en el seno de los cuales las personas pueden especificar, desarrollar y verificar los sistemas de manera sistemática.
Estas técnicas tienen la ventaja de facilitar una mejor comprensión de los requisitos del sistema reduciendo errores y omisiones. Además proporcionan la base para un diseño elegante incluyendo la definición de pruebas y el proceso con herramientas software.[PAZOS ARIAS 2000]. También se comprende mejor el sistema, la comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario, el sistema se describe de manera más precisa, y se asegura matemáticamente que es correcto según las especificaciones, mayor productividad y calidad de software respecto al cumplimiento de las especificaciones. [BOTON 2008]
Los métodos formales, también tienen sus propias desventajas, por ejemplo a la hora de hacer uso de ellos, en muchos casos, no se dispone de herramientas adecuadas. Por otro lado, el uso que se le da a estos métodos es poco, debido al desconocimiento que tienen los ingenieros informáticos en el momento de aplicarlos, es por eso que los clientes sienten ciertas limitaciones cuando tienen que
13
invertir en esta actividad ya que ellos casi nunca saben lo que realmente quieren y dejan en manos de los desarrolladores la forma de hacer el software. [PAZOS ARIAS 2000]
En la aplicación de las técnicas formales, se definen varios pasos como: el invariante de datos, el estado y las operaciones para el buen funcionamiento de un sistema.
El invariante de datos es una condición que se verifica mediante la ejecución de una función que contiene un conjunto de datos.
Los datos almacenados forman el estado en donde una función puede acceder y alterar las operaciones, y estas son las acciones que tienen lugar en un sistema a medida que lee o escribe datos en un estado. Una operación se asocia a las condiciones: una precondición y una postcondición.
La notación y la heurística asociados con los conjuntos y especificaciones constructivas, operadores de conjuntos, operadores lógicos y sucesiones forman la base de los métodos formales. [PRESSMAN
2005]
1.5 Calidad del software
El concepto de calidad proviene del latín Qualitas y está asociado al atributo o propiedad que distingue a las personas, bienes o servicios. [MIRANDA 2006]
La gestión de la calidad es el conjunto de acciones, planificadas y sistemáticas, necesarias para dar la confianza adecuada de que un producto o servicio va a satisfacer los requisitos de calidad.
[POLLÁN 2007]
Existen normas para llevar a cabo un plan para la calidad del software. Estas son precisamente las normas internacionales las que contribuyen a que esto sea posible. Por lo general dirigen la línea organizativa de las compañías y la estandarización de calidad de los productos.
Ejemplos de estas normas se tienen:
ISO es la Organización Internacional de Estandarización (en algunos casos Organización Internacional de Normalización) y fue creada para medir y asegurar la calidad en la producción
CMM (Software Capability Maturity Model o en español, Modelo de Madurez de La Capacidad de Desarrollo del Software)
14
CMMI (CMM Integrated, o Modelo de Madurez de Capacidad Integrado)
Se siguen 8 principios básicos fundamentales de la gestión de calidad o excelencia. Los cuales son:
1. Organización enfocada a los clientes 2. Liderazgo
3. Compromiso de todo el personal 4. Enfoque a procesos
5. Enfoque del sistema hacia la gestión 6. La mejora continua
7. Enfoque objetivo hacia la toma de decisiones
8. Relaciones mutuamente beneficiosas con los proveedores
Una vez tratado los temas anteriores de calidad pasamos a ver que es la calidad del software.
La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.
La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.
Existen varios tipos de calidad, como por ejemplo:
1. Calidad de diseño
2. Calidad de conformación 3. Calidad de servicio resultante
Más información de la calidad del software se puede ver en [POLLÁN 2007]
15 1.6 Problemática actual de los métodos formales
La falta de madurez en la práctica de los métodos formales es la causa de la imposibilidad de utilizarlos a nivel industrial al igual como se utilizan otros métodos de la Ingeniería del Software.
Algunas de estas causas son las siguientes:
El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios.
Los investigadores por lo general no conocen la realidad industrial.
Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado indiscutible.
Se considera que la aplicación de métodos formales aprueba los productos y ralentiza su desarrollo.
El gran auge que a nivel académico han tenido los métodos formales en los últimos años ha sup uesto la aparición de muchos y muy distintos métodos, técnicas, notaciones, etc. En general, no hay ningún tipo de consenso en qué método o técnica es mejor, aunque si en la importancia de la adecuación de las características del método a la fase de desarrollo en la que se aplica. Por ejemplo:[SOLLA 1999]
En la fase de captura de requisitos es más importante la especificación flexible de un sistema en función de sus propiedades más importantes. La descripción resultante de esta fase constituye la arquitectura inicial del sistema.
En la fase de arquitectura es necesario poder describir los componentes del sistema, su interfaz y cómo interactúan entre ellos. Es, por tanto, necesario poder expresar la estructura.
Esto, a menudo, no es posible en la práctica, ya que los requisitos de usuario pueden imponer ciertas restricciones a la implementación (conformidad con estándares, compatibilidad con otro software o hardware, exigencias de rendimiento, etc.)
En la fase de implementación, los componentes tienen que poder describirse de forma que su comportamiento pueda ser generado por máquinas. El proceso de traducción de un lenguaje de especificación a un lenguaje de implementación se puede automatizar en gran medida. Por ello, esta fase se suele decir que es semiautomática. Por la misma razón, resulta preferible realizar las tareas de mantenimiento a nivel de lenguaje de especificación. Sin embargo, pese a todas las ventajas que sus
16
defensores afirman, los métodos formales han tenido hasta el momento poca penetración en la industria, limitándose su uso a proyectos de pequeña-mediana escala , generalmente cofinanciados por organismos de apoyo a la investigación u obligados por directivas gubernamentales. Los motivos, justificados o no, son muy variados y han provocado la publicación de interesantes artículos a medio camino entre la aclaración, la desmitificación y la autoreflexión.
1.7 Opiniones en contra y a favor de los métodos formales.
Según [PRESSMAN 2005] en 1990, un investigador llamado Hall argumenta en contra de las principales razones dadas para no usar los métodos formales, formulando siete mitos de los métodos formales:
1. El uso de métodos formales produce software perfecto. Una especificación formal es un modelo del mundo real y puede contener errores, malas interpretaciones y omisiones. Su traducción a un programa ejecutable está limitada por el hardware del ordenador, el sistema operativo y los compiladores utilizados. Sin embargo, una especificación formal permite que los errores sean más fáciles de detectar, y proporciona una base no ambigua para el diseño.
2. Los métodos formales sirven para verificación. La verificación es sólo una de las ventajas que proporcionan los métodos formales.
3. El uso de métodos formales es caro por lo que solo se justifica para sistemas con fuertes restricciones de seguridad. Hall argumenta que el empleo de métodos formales puede suponer reducción de costes de desarrollo para cualquier tipo de sistemas.
4. El empleo de métodos formales requiere una fuerte base matemática. Sólo son necesarios conocimientos básicos de matemáticas.
5. Los métodos formales incrementan los costes de desarrollo. El reparto de costes entre las distintas fases del proceso de desarrollo software se ve modificado, dedicando mayores esfuerzos a las primeras fases, pero sin que lleve consigo un aumento del presupuesto global del proyecto.
6. Los clientes no entienden las especificaciones formales. Una especificación formal, con comentarios en lenguaje natural y con técnicas de animación, permite entender mejor los requisitos de un sistema.
7. Los métodos formales sólo se han usado en el desarrollo de sistemas de escasa complejidad.
17
Más recientemente, [BOWEN 1996] formula otros siete argumentos a favor del empleo de métodos formales en la ingeniería del software:
1. Los métodos formales retrasan el proceso de desarrollo. Uno de los principales problemas de la ingeniería de software, que constituye una de las principales preocupaciones de los equipos de desarrollo, es la estimación de costes del proceso software.
El modelo de estimación de costes más usado es el COCOMO, propuesto por Bowen está basado en la ponderación de varios factores (nivel de experiencia, conocimiento del dominio de aplicación, etc.) medidos a partir de la experiencia previa en el desarrollo de otros sistemas software.
Todavía no se dispone de esta experiencia cuando el desarrollo se acomete con técnicas de descripción formal, lo que complica todavía más la estimación de costes. No obstante, en la literatura se pueden encontrar numerosas experiencias de desarrollo de grandes sistemas software en los que el empleo de técnicas de descripción formal ha supuesto una reducción del tiempo estimado de desarrollo y, por tanto, de los costes previstos.
2. No se dispone de herramientas de soporte adecuadas. Muchas de las técnicas de descripción formal actuales tienen distintos tipos de herramientas de soporte asociadas, algunas de ellas de libre distribución.
Sin embargo, muchas de estas herramientas no han alcanzado un estado estable, ya que no están suficientemente probadas.
3. Los métodos formales suponen el abandono de los métodos tradicionales de la ingeniería de diseño.
Una de las principales críticas que se le hacen a los métodos formales es que no son en realidad métodos formales sino más bien lenguajes formales, es decir, proporcionan un lenguaje de especificación formal y un sistema de verificación, pero no está claro su papel dentro de los métodos estructurados de desarrollo software.
Los métodos formales no sustituyen a los métodos estructurados de diseño, sino que ofrecen características complementarias a los mismos. No obstante, muchos autores reconocen la necesidad de seguir investigando en la integración de métodos estructurados de diseño y métodos formales.
4. Los métodos formales sólo se aplican al software. Los métodos formales pueden aplicarse tanto al desarrollo software como al diseño hardware. En la literatura se pueden encontrar numerosas referencias a la aplicación con éxito de demostradores de teoremas (HOL, Nuprl, etc.) y técnicas de model checking al diseño hardware.
18
Una línea de trabajo más reciente en el desarrollo hardware es la llamada compilación hardware. Este procedimiento permite compilar un programa de alto nivel en una lista de componentes hardware simple junto con sus interconexiones. La tecnología de FPGAs (Field Programable Gate Arrays) permite que este proceso sea por completo equiparable a un proceso de desarrollo software.
Asimismo, esta tecnología posibilita la aplicación de métodos formales al diseño de sistemas hardware-software.
5. Los métodos formales no son necesarios. El uso de métodos formales es recomendable en cualquier sistema donde sea importante garantizar su corrección.
6. Los métodos formales no tienen un soporte lo suficientemente amplio. En la actualidad, existen notaciones formales con distintos tipos de expresividad y nivel de abstracción, así como libros, simposios y foros de debate sobre los métodos formales. Además, los métodos formales más populares están normalizados por organismos de normalización internacionales.
7. Las personas especializadas en métodos formales los usan incluso en situaciones donde no son necesarios. Como ya se comentó los métodos formales no son una panacea, y hay sistemas interfaces de usuario, en los que su aplicación no se aconseja.
Las conclusiones que se pueden extraer de la discusión anterior son, que el empleo de los métodos formales es más adecuado para el desarrollo de ciertos tipos de sistemas software, y que un uso más generalizado de estos métodos exige definir claramente su papel dentro del ciclo de vida del software, así como desarrollar herramientas de soporte adecuadas.
1.8 Clasificación de los métodos formales
Existen varias clasificaciones de los métodos formales, pero la más común se realiza en base al modelo matemático, en cada método, [BOTON 2008] de esta manera se clasifican en:
1. Especificaciones basadas en lógica de primer orden y teoría de conjuntos: permiten especificar el sistema mediante un concepto formal de estados y operaciones sobre estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lógica de primer orden. La semántica de los lenguajes está basada en la teoría de conjuntos. Los métodos de este tipo más conocidos son: Z, VDM y B.
2. Especificaciones algebraicas: proponen una descripción de estructuras de datos estableciendo tipos y operaciones sobre esos tipos. Como ejemplo de este tipo de técnica está el CSP.
19
Métodos basados en modelos matemáticos. En estos métodos se suele describir el sistema mediante la modelación de su espacio de estados. Esta descripción se realiza, principalmente, a través de teoría de conjuntos y lógica de primer orden. Los métodos más conocidos de este tipo son los métodos Z y B.
3. Especificación de comportamiento:
Métodos basados en álgebra de procesos: Modelan la interacción entre procesos concurrentes. Esto ha potenciado su difusión en la especificación de sistemas de comunicación (protocolos y servicios de telecomunicaciones) y de sistemas distribuidos y concurrentes. Los más conocidos son: CCS, CSP y LOTOS.
Métodos basados en Redes de Petri: Una red de petri es un formalismo basado en autómatas, es decir, un modelo formal basado en flujos de información. Permiten expresar eventos concurrentes. Los formalismos basados en redes de petri establecen la noción de estado de un sistema mediante lugares que pueden contener marcas. Un conjunto de transiciones (con pre y post condiciones) describe la evolución del sistema entendida como la producción y consumo de marcas en varios puntos de la red.
Métodos basados en lógica temporal: Se usan para especificar sistemas concurrentes y reactivos. Los sistemas reactivos son aquellos que mantienen una continua interacción con su entorno respondiendo a los estímulos externos y produciendo salidas en respuestas a los mismos, por lo tanto el orden de los eventos en el sistema no es predecible y su ejecución no tiene por qué terminar.
1.9 Técnicas de Descripción Formal
Varios autores resaltan la aparente contradicción de una disciplina que, denominándose ingeniería, presta tan poca atención a los métodos y modelos matemáticos para lograr su objetivo.
En este ambiente, suele denominarse técnicas de especificación formal a los lenguajes cuyo vocabulario, sintaxis y semántica están formalmente definidos. Por tanto, una técnica de especificación formal es un método formal especialmente adecuado para escribir especificaciones de sistemas.
Aunque el término de técnicas de descripción formal se acuñó para denominar los métodos y lenguajes normalizados, actualmente se utiliza para nombrar cualquier técnica o método que permite
20
definir completamente el comportamiento de un sistema (hardware o software) mediante un lenguaje con sintaxis y semántica formales.
Las principales mejoras que se persiguen con el empleo de estas técnicas son: corrección del sistema construido respecto a una especificación formal; mejora de la calidad del sistema (entendiendo calidad como el grado de cumplimiento de los requisitos y expectativas planteadas); y aumento de la productividad.
Dos propiedades fundamentales de un lenguaje de este tipo son:[DUQUE 2000]
Expresividad. Debe ser lo suficientemente expresivo para poder describir, de forma clara, el comportamiento de los sistemas que pretende modelar. Ello depende, fundamentalmente, del conjunto de constructores y operadores matemáticos de que se compone su sintaxis.
Abstracción. Debe ser lo suficientemente abstracto para poder describir qué hace un sistema sin poner restricciones a cómo lo hace.
Estas dos propiedades permiten lograr una característica deseable en el proceso de desarrollo: hacer independiente la especificación de un sistema de su posterior implementación. Esta característica suele hacer muy apropiada a las técnicas de descripción formal para la especificación de normas y estándares. Las técnicas de descripción formal proporcionan un marco apropiado para reducir el riesgo esencial a la fase de captura y especificación de requisitos del sistema. No obstante, es importante ser consciente de que una especificación de un sistema escrita en una notación formal puede contener también errores.
1.10 Verificación Formal.
Para aumentar la confianza del diseñador en la corrección del método es preciso realizar operaciones de verificación sobre la especificación. Muchas veces esta verificación se realiza de manera informal a través de inspecciones y reuniones de revisión. Sin embargo, la base matemática de los métodos de especificación formal posibilita la verificación formal en dos aspectos: verificación formal de propiedades formuladas sobre la especificación, y verificación formal de que la implementación satisface la especificación. [DUQUE 2000]
Una de las motivaciones más importantes que estimuló el desarrollo de las técnicas de descripción formal, fue la posibilidad de realizar una verificación formal del sistema obtenido. La verificación formal de grandes especificaciones es, en muchos casos, inviable por el alto coste de recursos que es
21
necesario invertir, por lo que es necesario limitar o concentrar las verificaciones a partes del sistema que por su naturaleza se consideren más críticas.
A pesar de los numerosos trabajos de investigación realizados, hasta la fecha sólo se ha demostrado su aplicación en sistemas de tamaño pequeño o medio, lo que motiva su escasa utilización en la industria y que su uso esté prácticamente restringido a entornos académicos o de investigación.
Un método alternativo a la verificación formal de que la implementación satisface la especificación, lo constituye un proceso de refinamiento iterativo donde la especificación formal de un sistema se obtiene tras la aplicación sucesiva de un conjunto de simples refinamientos o transformaciones aplicadas a una especificación inicial del sistema con un elevado nivel de abstracción. Cada una de las fases de este proceso toma como entrada la especificación resultante del refinamiento anterior y produce como salida otra especificación con mayor cantidad de detalles de implementación. Este proceso continúa hasta que se dispone de una especificación con el nivel de detalle suficiente como para poder traducirla a un lenguaje de programación convencional. Las especificaciones de entrada y salida de un refinamiento se pueden relacionar mediante relaciones de equivalencia o de orden. Las ventajas de este método es que las verificaciones que se hacen son mucho más simples.
En la actualidad existen dos grandes técnicas para la realización de la verificación formal: [DUQUE
2000]
- Model Checking: es una técnica basada en la definición de un modelo de estados finito del sistema y la demostración de que una propiedad dada se satisface en dicho modelo.
Básicamente, la demostración se realiza mediante una búsqueda exhaustiva en el espacio de estados, por lo que para que termine este espacio de estados debería ser necesariamente finito.
Desde un punto de vista técnico, los trabajos de investigación en model checking se dirigen a la búsqueda de algoritmos y estructuras de datos más eficientes que permitan el manejo de un espacio de estados más grande.
Las principales ventajas del model checking son: la posibilidad de automatizar totalmente las demostraciones; su rapidez; su capacidad para trabajar con especificaciones parciales; y su capacidad para proporcionar información útil aun cuando el sistema no se encuentre totalmente especificado. Estas dos últimas características hacen que el model checking sea una técnica especialmente útil en las primeras fases del desarrollo software, ya que, por una parte el sistema no está totalmente especificado; y por otra, el espacio de estados será más reducido que en las fases posteriores.
22
Por contra, su principal desventaja es el problema de la explosión de estados.
Demostradores de teoremas: Según [DUQUE 2000] y [MUÑOZ 1998] se basan en expresar tanto el sistema como sus propiedades deseadas en alguna lógica matemática o mecanismos lógicos de derivación. También es conocida como (theorem proving) en inglés, que significa probadores de teoremas. Un ejemplo es ACL2, cuyas siglas en inglés significan: “A Computational Logic for Applicative Common Lisp”, en español: “Una Lógica Computacional para Common Lisp Aplicativo”
desarrollado por Matt Kaufmann y Moore.[DYKSTRA 2002]
La técnica que emplean los demostradores de teoremas se basa en expresar tanto el sistema como sus propiedades deseadas en alguna lógica matemática. Esta lógica es un sistema formal que define un conjunto de axiomas y de reglas de inferencia.
La demostración de una propiedad se realiza a través de la aplicación sucesiva de los axiomas, propiedades y reglas definidas en la lógica utilizada. El proceso finaliza cuando se obtiene una relación, que suele ser de equivalencia o de orden, entre la especificación y la propiedad formulada.
Al contrario que la técnica de model checking, los demostradores de teoremas pueden manejar espacios de estados infinitos. Su principal desventaja reside en la dificultad de automatizar la aplicación de las reglas de inferencia para obtener un resultado sin entrar en procesos de reescritura sin fin.
A continuación, se describen brevemente los demostradores de teoremas más representativos clasificándolos según el grado de automatización que proporcionan:
Herramientas de deducción automáticas guiadas por el usuario: Tienen como característica común que su operación se guía por una secuencia de lemas y definiciones, si bien cada teorema se demuestra automáticamente mediante heurísticos y la aplicación de inducción, lemas, reescritura y simplificación.
Demostradores propiamente dichos: Han sido usados para formalizar y verificar problemas complejos de matemáticas, así como para la verificación tanto hardware como software. Los ejemplo más ilustrativos de este tipo de demostradores de teoremas son:
HOL. Es un sistema demostrador de teoremas basado en lógica de orden superior, en [MUÑOZ 1998] se puede encontrar una descripción detallada del sistema HOL. Diseñado para construir especificaciones y verificaciones formales de sistemas. Ha sido aplicado
23
en entornos académicos e industriales para el desarrollo de hardware, sistemas de tiempo real, verificación de compiladores, etc.
Isabelle: Es un demostrador de teoremas genérico. Posibilita la introducción de nuevas lógicas especificando su sintaxis y reglas de inferencia. Proporciona un alto grado de automatización. En [DUQUE 2000] se puede encontrar una descripción detallada de la funcionalidad de esta técnica.
Sistemas híbridos: Su característica principal es que combinan varias técnicas de verificación.
Entre los más representativos cabe citar:
Analytica: Combina la demostración de teoremas con el sistema de álgebra simbólica Matemática.
PVS y STeP combinan potentes procedimientos de decisión con model checking para realizar demostraciones interactivas. PVS ha sido usado con éxito para verificar diseños hardware, así como sistemas reactivos, de tiempo real y tolerantes a fallos. [MUÑOZ
1998]
LCF es uno de los primeros demostradores de teoremas. Ha sido empleado para la verificación de propiedades y la comprobación de corrección de algún algoritmo de unificación. [SOLLA 1999]
MUS (Model of Unspecified States). Es una técnica formal cuya inclusión en la metodología aporta las siguientes ventajas: Proporciona una base matemática sólida para SCTL(Simple Causal Temporal Logic) que permite combinar las dos técnicas de verificación más usadas (model checking y demostradores de teoremas); la inclusión de la subespecificación permite trabajar con especificaciones parciales de sistemas, dando así soporte al desarrollo incremental; y proporciona una representación gráfica de SCTL, permitiendo así realizar labores de prototipado y de ejecución simbólica del comportamiento del sistema en cualquier fase de su proceso de desarrollo. [DUQUE 2000]
1.11 Mandamientos de los Métodos Formales.
Según [PRESSMAN 2005] se expresa de la siguiente manera.
1- Seleccionarás la notación adecuada. Con objeto de seleccionar eficientemente dentro de la amplia gama de lenguajes de especificación formal existente, el ingeniero del software deberá
24
considerar el vocabulario del lenguaje, el tipo de aplicación que haya que especificar y el grado de utilización del lenguaje.
2- Formalizarás pero no de más. En general, resulta necesario aplicar los métodos formales a todos los aspectos de los sistemas de cierta envergadura. Aquellos componentes que sean críticos para la seguridad serán nuestras primeras opciones, e irán seguidos por aquellos componentes cuyo fallo no se pueda admitir (por razones de negocios).
3- Estimarás los costes. Los métodos formales tienen unos costes de arranque considerables. El entrenamiento del personal, la adquisición de herramientas de apoyo y la utilización de asesores bajo contrato dan lugar a unos costes elevados en la primera ocasión. Estos costes deben tenerse en cuenta cuando se está considerando el beneficio obtenido frente a esa inversión asociada a los métodos formales.
4- Poseerás un experto en métodos formales a tu disposición. El entrenamiento de expertos y la asesoría continua son esenciales para el éxito cuando se utilizan los métodos formales por primera vez.
5- No abandonarás tus métodos formales de desarrollo. Es posible, y en muchos casos resulta deseable, integrar los métodos formales con los métodos convencionales y/o con métodos orientados a objetos. Cada uno de estos métodos posee sus ventajas y sus inconvenientes. Una combinación de ambos, aplicada de forma adecuada, puede producir excelentes resultados.
6- Documentarás suficiente. Los métodos formales proporcionan un método conciso, sin ambigüedades y consistentes para documentar los requisitos del sistema. Sin embargo se recomienda que se adjunte un comentario en lenguaje natural a la especificación formal, que sirva de mecanismo para reforzar la comprensión del sistema por parte de los lectores.
7- No comprometerás los estándares de calidad. Los métodos formales no tiene nada de mágico, y, por esta razón las demás actividades de SQA deben de seguir aplicándose cuando se desarrollen sistemas.
8- No serás dogmático. El ingeniero de software debe conocer que los métodos formales no son una garantía de corrección. Es posible (como algunos probablemente dirían) que el sistema final, aun cuando se haya desarrollado empleando métodos formales, siga conteniendo pequeñas omisiones, errores de menor importancia y otros atributos que no satisfagan nuestras expectativas.
