XLIRA

Proyecto financiado por la Xunta de Galicia (2001-2003)

El rápido progreso de la tecnología hardware ha permitido concebir sistemas de información de mediano y gran tamaño, y con ello han aflorado los problemas que dieron lugar a la llamada crisis del software: Los proyectos eran entregados fuera de plazo, desbordaban el presupuesto inicial, eran difíciles de mantener, poco fiables e ineficientes. Existe un amplio con- senso en considerar que las principales razones de estas disfunciones son: El escaso esfuerzo invertido en las primeras fases del proceso de desarrollo (análisis y especificación de requisitos, y diseño), y la aplicación de metodologías de desarrollo inadecuadas, cuyas principales deficiencias surgen de la imposibilidad de realizar tareas de verificación y prueba hasta que el sistema está implementado.

Cada vez en mayor medida, los sistemas informáticos forman parte de la actividad cotidiana de múltiples sectores de nuestra sociedad, y el software conforma la identidad de estos sistemas, proporcionando a su funcionalidad las características exclusivas que posee. Por esta razón, los problemas relacionados con el software son los más importantes en el desarrollo y evolución de un sistema informático, por ser los que pueden causar mayores perjuicios en su entorno. Este hecho, que se acentúa cada vez más, provoca que el coste de un sistema informático dependa principalmente del coste de desarrollo del software.

Por otra parte, un sistema informático está en un proceso de cambio continuo, lo que supone que su proceso de desarrollo no finaliza cuando el sistema se pone en funcionamiento (en contra de lo que presuponen los modelos de ciclo de vida clásicos), sino que debe seguir para permitir que el sistema se pueda adaptar a los cambios de su entorno y continuar siendo útil. El coste de mantenimiento (entendido el mantenimiento como la modificación de un sistema informático en uso) sobrepasa con creces el coste de desarrollo inicial (dependiendo del dominio de aplicación puede ser de dos a cien veces superior). Entre las razones que justifican este mayor coste cabe citar: La poca atención y mala imagen que ha tenido desde siempre el mantenimiento de sistemas informáticos, por realizarse casi siempre a nivel de código fuente, y la dificultad en el mantenimiento de sistemas software de cierta antigüedad, que fueron desarrollados sin el empleo de técnicas modernas. Además, si se realiza el mantenimiento sólo a nivel de código fuente, la estructuración del sistema tiende a degradarse y se debilitan o desaparecen los vínculos entre el sistema real y su documentación (documentos de requisitos, de diseño, etc.). Por todo ello, resulta rentable realizar esfuerzos en la concepción de un nuevo proceso de desarrollo que simplifique las futuras tareas de mantenimiento.

En este proyecto se propone la definición de un proceso incremental de desarrollo de software cuya principal característica será la consideración de las tareas de evolución y mantenimiento de un sistema como tareas de diseño y desarrollo propiamente dichas. Para la formalización del modelo, que posibilitará la verificación y prueba (validación) del sistema en cualquier fase de su proceso de diseño, se combinará el uso de técnicas formales no constructivas (especialmente indicadas en la fase de análisis y especificación de requisitos) con técnicas formales constructivas (especialmente indicadas para las fases de diseño).

En la actualidad, el empleo de técnicas formales ha tenido una amplia aceptación en la industria del hardware, pero en la industria del software su penetración ha sido escasa, a pesar de las importantes ventajas potenciales que su uso conlleva. Las principales razones que justifican esta situación son: La dificultad de los usuarios para entender los métodos formales, la deficiente integración de los métodos formales en el proceso de desarrollo y la inexistencia de herramientas estables que den soporte al proceso.

El principal resultado de este proyecto será la construcción de una herramienta software de soporte a todo el proceso de desarrollo propuesto (la formalización del modelo constituye la base para la automatización), que incluye desde la fase de análisis y especificación de requisitos hasta las tareas de evolución y mantenimiento. El trabajo del proyecto se centrará en la fase de captura y análisis de requisitos (primera fase del modelo de desarrollo propuesto) cuyo objetivo es la obtención de la arquitectura inicial del sistema. La arquitectura inicial del sistema, que se expresará en E-LOTOS, sufrirá un conjunto de refinamientos cuyo objetivo es añadir el nivel de detalle suficiente para que la especificación E-LOTOS pueda ser traducida a un lenguaje de implementación. La herramienta LIRA propocionará el soporte adecuado para esta fase de refinamiento. De esta forma, la funcionalidad de LIRA quedará integrada en la nueva herramienta que se propone desarrollar en este proyecto.

Objetivos

El objetivo principal de este proyecto es la construcción de una herramienta software que dé soporte al proceso incremental de desarrollo software propuesto (ver figura 1), cuya principal característica sea la consideración de las operaciones de evolución y mantenimiento (cada vez más importantes y frecuentes) como tareas de desarrollo, y se propone una formalización de todo el proceso software (ver figura 2) combinando técnicas formales constructivas (E-LOTOS) con técnicas formales orientadas a propiedades (lógica temporal multivalor SCTL), consiguiendo así explotar las características complementarias de ambos tipos de técnicas.

Para las etapas de adquisición y análisis de requisitos funcionales, en la metodología propuesta se define la lógica temporal SCTL (Simple Causal Temporal Logic). Los objetivos fundamentales que guiaron el diseño de SCTL fueron: Simplicidad (contiene únicamente tres operadores temporales) y sencillez de uso (para acercarse en lo posible al lenguaje natural se opta por un formalismo causal en el que una premisa provoca una consecuencia).

Como paso intermedio entre SCTL y E-LOTOS se ha definido el formalismo MUS (Model of Unspecified States). MUS es una técnica formal cuya inclusión en la metodología aporta, además, las siguientes ventajas: Proporciona una base matemática sólida para SCTL que permite combinar las dos técnicas de verificación más usadas (model checking en el dominio MUS-SCTL y demostradores de teoremas en el dominio SCTL); 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.

Para la etapa de diseño, cuyo punto de partida es la especificación resultante de la fase anterior, es necesario un lenguaje capaz de expresar la estructura del sistema, sus componentes y la interfaz entre ellos. Para este propósito se ha elegido el lenguaje E-LOTOS, con el fin de aprovechar la experiencia del equipo de investigación, así como los esfuerzos dedicados al desarrollo de la herramienta LIRA (LOTOS Interactive Reasoning Aid).

La experiencia muestra que las tareas de evolución y mantenimiento de sistemas software, cuya importancia es cada vez mayor, suelen llevar consigo tareas de adquisición y análisis de requisitos, diseño, etc., razón por la que en el modelo propuesto no se distinguen de las tareas de desarrollo propiamente dichas.

Asimismo, otro objetivo importante de este proyecto es el estudio de las ventajas que un mecanismo de reutilización aportaría al proceso de desarrollo. En concreto, dentro del grupo de investigación se está trabajando en una generalización de los requisitos funcionales que permita su reutilización (el punto de partida para el diseño de un nuevo sistema puede ser un sistema previamente diseñado o una generalización del mismo), así como la reutilización de su información de verificación (esta reutilización permitirá ahorrarse numerosas ejecuciones del algoritmo de verificación, de uso muy frecuente en la metodología propuesta). En este ámbito, se está trabajando también en la definición de una distancia funcional que permita decidir cuándo es ventajoso reutilizar y cuándo la reutilización no aporta ninguna ventaja por estar la funcionalidad de los sistemas disponibles muy alejada del sistema que se pretende diseñar.