 |
Novática
es la revista de ATI (Asociación de Técnicos de
Informática). Nota importante: Se permite la reproducción de este artículo, excepto si está marcado con © o Copyright, debiéndose en todo caso citar su procedencia Important notice:This article can be reprinted except if marked with © or Copyright. If reprinted full mention of the source is mandatory |
Prototipado en Métrica 2: ejecución de especificaciones basadas en DFDs
A pesar de las reestructuraciones laborales vividas en el sector informático, no son una sorpresa los resultados del estudio. El desarrollo de software tiene futuro según este informe, en cuanto se acomoda a los nuevos retos. Los ingenieros que sacian la sed de software se han convertido en un bien muy preciado. Sus ventas en EEUU han crecido una media del 27 por 100 anual desde 1982. El año pasado se ingresaron 35.600 millones de dólares por software comercial y se prevé que esa cantidad se duplique con creces de aquí al año 2000.
A medida que los computadores y las redes se hacen más complejos, ocurre lo mismo con las expectativas de los consumidores; por ello, el desarrollo de software (como verdadera solución informática frente a otras) debe modernizarse continuamente para ser mejor, más eficiente y conseguir unos niveles de calidad que permitan el resultado que el usuario final demanda. La Universidad Carnegie Mellon afirma que la contratación de sus estudiantes de ingeniería del software ha crecido más de un 20 por 100 este año.
Toda la continua modernización de hoy día en ingeniería del software y la posibilidad de dar respuesta a la mayoría de las necesidades de desarrollo de software contrastan con la realidad de un pasado próximo. Cuando asumí la coordinación de esta monografía sobre ingeniería del software, me vino el recuerdo de los que en los años setenta y principios de los ochenta afrontábamos proyectos de desarrollo de software en la industria o la administración. Ante los escasos medios de desarrollo de que se disponía, frecuentemente aparecía la referencia a autores que pugnaban por realizar en el campo del software lo que ya se conseguía en otros ámbitos. Los componentes CI (circuitos integrados) tienen un número de pieza, una función determinada, una interfaz bien definida y un conjunto estándar de criterios de integración. En definitiva actuan como verdaderas 'pastillas'.
" Porqué no hay 'pastillas de software' ?" volvemos a oír, planteada por nuestros alumnos, 'la' pregunta de entonces; cúando será posible que funcione con efectividad la reusabilidad del fruto de nuestro trabajo, conseguido con tanto tiempo y desvelo...? Evidentemente, el uso cada vez más extendido de la programación orientada a los objetos ha dado como resultado la creación de auténticas pastillas de software. Lejos queda ya el hecho histórico de la ciudad de Garmisch, donde en 1968 se acuñó el término de ingeniería del software.
"Debido a los cambios rápidos e inexorables que se están produciendo en la tecnología de la información y a las consecuencias irreversibles de quedarse atrás, las empresas se ven obligadas a asimilar la tecnología o morir...Esta situación se parece a una rueda de molino tecnológica. Las empresas tendrán que trabajar cada vez más para estar actualizadas". Esto decía Max Hopper en 1990 en su trabajo titulado Rattling SABRE, News Ways to Compete on Information, de la Harvard Business Review (mayo-junio)..
Como hemos podido comprobar toda nueva aportación sufre un proceso, y como afirma Michael Horner de Digital Equipment Corporation, todo nuevo concepto suele requerir unos 15 años para pasar de idea inicial a producto de masas: de forma que en los 5 primeros años se formula una idea nueva que se plasma en un prototipo utilizado para demostrar los conceptos básicos; en los 5 años siguientes los científicos proceden a refinar el prototipo y también se procede a lanzar los primeros productos; y por último se introduce el producto en el mercado comercialmente en los 5 años siguientes, completando así el 'ciclo' de 15 años expresado por Horner. Aplicando este ciclo completo desde la simple idea a un producto de masas, recordemos que las tecnologías orientadas a los objetos se iniciaron en los años ochenta ... podríamos decir que estamos en el último tramo de la regla del ciclo de 15 años?
Como es de todos conocido, se celebran dentro del campo de la Ingeniería del Software, en sus diferentes vertientes, importantes eventos con distinta periodicidad y lamentablemente no con la frecuencia y abundancia que los interesados en estos temas quisiéramos. Dada la historia que arrastra y por lo acontecido en él, merece especial mención el ESEC'95. Se desarrolló en Sitges del 25 al 28 de septiembre. En ella ATI actuaba como anfitriona y su contribución se ha realizado dentro del marco de CEPIS, el Comité Europeo de Sociedades de Profesionales de Informática. ATI ha sostenido a la organización del Congreso Europeo, buscando siempre la divulgación de las Tecnologías de la Información, en este caso en el campo de la ingeniería del software.
Tenemos la enorme satisfacción de iniciar este número con una aportación de primera mano, la del Executive Chairman del ESEC`95, Profesor Pere Botella, Decano de la Facultad de Informática de Barcelona. Además de sus apreciadas opiniones, su aportación refleja la encuesta realizada a los asistentes por la organización del ESEC'95. ATI mostró su apoyo a la Conferencia y el siguiente apartado de la monografía recoge las palabras del Presidente de ATI pronunciadas en la inauguración de ESEC`95. No puede extrañar que ATI siga con su tradicional y aquí especial apoyo a los acontecimientos que permiten la formación y actualización de conocimientos de los profesionales de la Informática.
Para ofrecer una opinión del desarrollo de ESEC'95, cabe destacar desde el primer día una notable asistencia a los tutoriales. Rubén Prieto-Diaz de Reuse Inc. nos deleitó con su análisis del dominio de la reusabilidad, dando una vertiente eminentemente práctica a su exposición. Fue muy animado el coloquio final que permitió ampliar determinados aspectos de interés. Hans-Martin Hoercher nos dió su particular visión del papel de la especificación formal en el testeo del software. Interesante fue la presentación del tutorial de Philippe Kruchten de la Rational Western Canada, que hizo un amplio recorrido por la problemática de los procesos iterativos de desarrollo y de la arquitectura del software. Fue seguido con gran interés el desarrollo del tutorial de Mehdi Jazayeri de la Technische Universitae de Viena que hizo una exposición de la problemática del diseño del software y la implementación en C++. Richard Kemmerer de la Universidad de California sorprendió con su ilustración de los aspectos de la seguridad en los sistemas informáticos a los pocos asistentes, que tuvieron la oportunidad de hacer un recorrido ameno por la seguridad en redes.
Para entrar de lleno en el contenido de los debates, no puede evitarse la tradicional pregunta estamos en una etapa de transición en la ingeniería del software? En esa etapa de 'transición' en que, en opinión de algunos, se encuentra la ingeniería del software, creemos que ESEC`95 ha marcado al menos nuevas pautas con las conferencias invitadas. La primera sobre la visión de la demanda industrial de ingenieros de software no revistió especial relevancia aclaratoria. Pero en las siguientes conferencias volvieron a aparecer las 'pastillas de software'. Hay que destacar el enfrentamiento entre Bertran Meyer y François Bancilhon con su distinta visión de la justificación a la necesidad de utilización de bases de datos orientadas a objetos. Fue uno de los momentos estrella del Congreso, junto con la conferencia de Watts Humphrey, que nos deleitó a todos con su visión de la calidad del software, y que puso un merecido broche de oro, tras el animado coloquio que resaltó el interés de los asistentes por la calidad del sofware (las encuestas reflejaron la máxima puntuación). Más
controversia hubo en el panel sobre plataformas abiertas y distribuidas, que fue de interés para muchos por los distintos aspectos afrontados.
En las diez sesiones del Congreso, las 29 ponencias presentadas y retenidas cubrieron con un nivel de calidad alto las distintas parcelas de la ingeniería del software. Los asistententes siguieron con gran interés las sesiones, dando lugar a animados coloquios al final de cada exposición. Sería muy dificil destacar una sesión. Interés para los asistentes tuvo la sesión del Technical Council on Software Engineering de IEEE, las exposiciones de productos y el Industrial Track. Especial asistencia y seguimiento tuvo el Workshop del proyecto Nature, pese a la cantidad de sesiones y ponentes. Fue muy participativo el coloquio final de cada sesión y hay que destacar la abundancia de documentación presentada por los organizadores (Nature es un proyecto ESPRIT centrado en ingeniería de requisitos pero que afronta gran cantidad de vertientes recogidas en el alto número de informes presentados). Se prodría hablar de sobresaliente el interés despertado.
ESEC'95 también tuvo sus detalles de organización. Nota de interés lógico para muchos fue la posibilidad de usar Internet en una de las salas del Congreso, muy valorada y agradecida por los asistentes. La climatología contraria no fue un obstáculo para la gran capacidad de los organizadores que supieron afrontar perfectamente los retos que se presentaban. El grupo Ars-Animae nos dejó gratamente impresionados a muchos.
Volviendo a la organización concreta de esta monografía y después de planear distintas estructuraciones para ordenar los artículos, se pensó que todas ellas darían lugar a polémica ante las distintas visiones en un sector tan polifacético. Así que se ha optado por una alternancia entre las aportaciones del ámbito de la industria y las del universitario. El resultado intenta reflejar, tanto por la disposición como por el número de aportaciones, el profundo equilibrio entre los dos ámbitos que juntos han hecho y continuarán haciendo mucho por la ingeniería del software. Por poner otro ejemplo reciente, en las Jornadas Técnicas centradas en ingeniería del software y organizadas por ATI en la E.T.S.de Ingeniería Informática de Granada durante octubre y noviembre, también se puso de manifiesto el interés mostrado por asistentes de la industria, la administración, de profesores y de alumnos, transformadas en altas a ATI procedentes de todos los colectivos citados.
Repasando el contenido de artículos de la monografía, tras la crónica de ESEC`95 por Pere Botella y el saludo a la Conferencia de pedro Gómez Grau,la aportación de Jose Luis Iparraguirre, del European Software Institute, expone los métodos de evaluación y mejora de los procesos de producción del software. Una autoridad en este campo, un grupo de autores que incluye al Profesor Isidro Ramos Salavert presenta un importante trabajo sobre una arquitectura orientada a agentes utilizando un nuevo lenguaje como soporte lingüístico que ofrece la visión del sistema de información como una colección de agentes. Juan Peña y Jesus Macías aportan una experiencia práctica de utilización y uso metodológico. Ambrosio Toval y otros autores realizan un prototipado, ejecución de especificaciones basadas en diagramas de flujo de datos. Josep Ramón Freixanet y otros autores presentan su trabajo de gran interés para obtener una herramienta parametrizable. Alberto Valderruten, Nuria Castell y Javier Tuya fueron ponentes en ESEC`95 y aportan un importante trabajo de su linea de investigación. Jose Luis Esteban y Mario Piattini, dos compañeros de AENOR 71/SC7, transmiten una aportación en normalización internacional. Es de destacar la experiencia práctica en 'calidad en el mantenimiento de un sistema' que presentan I. García y J.A. Mellado. Dentro del ámbito de calidad del software, se presenta un original estudio en Eurométodo. Fernando Aldea presenta aportaciones sobre software en el sector espacial. Dentro de las posibilidades emergentes nos encontramos con el trabajo del entorno DELPHOS. La aportación de las técnicas de la información nos da una visión bastante interesante de la situación en España y las perspectivas futuras. De las posibilidades de utización de las técnicas formales y su impacto en la calidad, encontramos un interesante trabajo de G. Huecas. Tras dos artículos sobre Reutilización de Código e Inspecciones de calidad escritos por F. Aldea y otros autores,cierra la monografía un último artículo global sobre análisis y perspectivas de A. Bajja.
Es muy dificil indicar tendencias futuras en un campo cada vez más dinámico que evoluciona por el influjo de avances tecnológicos internos y la presión de un entorno que exige continuas soluciones a sus nuevas necesidades. Parece confirmarse una preocupación creciente por la calidad de un software que satisfaga al usuario y permita la eficiencia en las prestaciones y la facilidad en el mantenimiento.
Las tecnologías orientadas a los objetos podrían formar un puente entre los enfoques de inteligencia artificial (inherentemente orientada a los objetos), las aplicaciones convencionales y la tecnología de las bases de datos. El diseño orientado a los objetos proporciona un método para romper las barreras entre los datos y el procesamiento, con la consiguiente mejora de la calidad del software. A medida que los enfoques orientados a los objetos tomen más relevancia, los paradigmas evolutivos para la ingeniería del software se irán modificando para integrar la reusabilidad de componentes de programas. La reusabilidad es una característica importante para un componente de software de alta calidad. La calidad, como campo de investigación, nunca perderá su importancia.
Después de todo lo expuesto y mirando al horizonte del siglo veintiuno, sería interesante prestar atención retrospectiva a Rich y Waterls. En su libro The Programmer's Apprentice (Addison-Wesley, 1990) ya hacía de una forma bastante razonable el recorrido de lo que ya ocurre actualmente y lo que puede suceder en el futuro próximo respecto al desarrollo del software y los proyectos informáticos será posible la 'pastilla de software' llevada a sus últimas consecuencias...?
Resumen: la deseada implantación de las metodologías de desarrollo de Sistemas de Información (SI) se encontraría seriamente limitada sin herramientas que ayuden a los productores de software a completar las guías propuestas. Este artículo presenta una aportación original para generar y ejecutar prototipos a partir de especificaciones estructura-das de acuerdo con los criterios de la metodología oficial MÉTRICA 2: utilización de técnicas estructuradas formales/rigurosas y utilización de prototipos durante la especificación funcional del sistema. Presentamos un lenguaje formal, a la vez que simple, denominado MSL (Mini-Specifications Language), para escribir las miniespecifica-ciones (ME) de los procesos reflejados en los sucesivos Diagramas de Flujo de Datos (DFD) del sistema. El proyecto se aborda íntegramente desde una perspectiva rigurosa que incluye una formalización de técnicas estruc-turadas de MÉTRICA 2 en una lógica de primer orden. La ejecución visual usando los mismos DFD posibilita que estos aspectos formales no sean visibles a los usuarios. Existe ya una prime-ra versión experimental de esta herramienta en entornos PC.
Palabras clave: MÉTRICA 2, Especificaciones Formales, Prototipado, Técnicas Estructuradas, Ingeniería de Requisitos, Programación Lógica.
La Metodología de Desarrollo de Sistemas en la Administración Española (MÉTRICA 2) [MAP 95] se ha implantado con el fin de solucionar la problemática que resulta de la escasa documentación de los sistemas y de la falta de comunicación con los usuarios durante el proceso de desarrollo, lo que genera productos que no responden totalmente a las necesidades de los usuarios. En este sentido, define un conjunto de métodos, procedimientos, técnicas y herramientas que facilitan la construcción de SI. El marco de trabajo de MÉTRICA 2 se estructura en fases que a su vez se dividen en módulos. Nuestro trabajo realiza su contribución básicamente en la fase de `Análisis de Sistemas'. Por un lado, formalizando determinadas técnicas estructuradas utilizadas en MÉTRICA 2; y por otro lado, aportando una herramienta conversacional y visual para el prototipado funcional que es posible utilizar en los módulos 'ARS. Análisis de Requisitos del Sistema' y 'EFS. Especificación Funcional del Sistema', con el fin de generar y ejecutar prototipos a partir de las especificaciones, y validar/verificar los requisitos del sistema junto a los usuarios. También, en otras fases de MÉTRICA 2 es útil esta contribución en la medida en que se deban mantener, validar y/o verificar requisitos con los usuarios.
Autores reconocidos como [Harel 92] [Fuchs 92] [Goguen 94] defienden la idea de que para tener éxito en el desarrollo de software es necesaria una adecuada planificación y ejecución de las fases de especificación y diseño que incluya la utilización de prototipos. Pero desgraciadamente, no existen herramientas que permitan generar y ejecutar prototipos funcionales. Por ejemplo, MÉTRICA 2 consciente de que la participación activa del usuario es una condición imprescindible para el éxito en el desarrollo de SI, propone técnicas interactivas, entre ellas el uso de prototipos, pero no menciona en ningún momento una herramienta o método para la construcción de prototipos funcionales (sólo se refiere a prototipos de interfaz: pantallas, diálogos, formularios e informes).
El trabajo realizado se podría trasladar , sin grandes cambios, a otros métodos que también utilicen técnicas estructuradas, como p. ej. las metodologías oficiales SSADM (Inglaterra), MERISE (Francia) que han supuesto un verdadero cambio sociotécnico en el desarrollo de SI en sus respectivos países. Aún más, algunas de las metodologías y herramientas CASE Orientadas a Objetos (OO) también utilizan estas técnicas, por ejemplo OMT (Object Modelling Technique) [Rumbaugh 91].
MÉTRICA 2 recomienda, al menos en su versión actual, el uso de técnicas estructuradas, entre ellas los DFD. Estas técnicas resultan muy adecuadas para describir requisitos funcionales de sistemas complejos: su facilidad de aprendizaje y uso las convierte en un buen método de comunicación entre los usuarios y los productores de software. Sin embargo, carecen de un fondo teórico sólido, lo que dificulta los procedimientos de validación y verificación automática. Otra importante desventaja es la distancia ('gap' semántico) que existe entre la última especificación (`DTS. Diseño Técnico del Sistema' en MÉTRICA 2) y la fase de construcción de sistemas, lo que dificulta la obtención de prototipos funcionales a partir de las especificaciones. Los métodos formales (Z, VDM, especifi-caciones algebraicas [Ehrig et al 92]) ofrecen una alternativa válida al proceso de desarrollo del software; en realidad, constituyen una de las tendencias que más acerca a la Ingeniería del Software a una verdadera disciplina científica. Aun así, nosotros estamos convencidos que métodos informales como los estructurados todavía desempeñan, y desempeñarán en los próximos años, un papel muy importante. Dada la dificultad que están encontrando los métodos formales para ser aceptados por la comunidad de desarrollo de SI, resulta interesante intentar formalizar metodologías intuitivas y ampliamente consolidadas, como es el caso del Análisis y Diseño Estructurado, combinando una aproximación rigurosa al proceso de desarrollo con metodologías no formales. En esta línea, han aparecido recientemente diversas formalizaciones de algunos de los conceptos de las técnicas estructuradas, bien desde un punto de vista algebraico [Tse 91][Tao et al. 91][France et al. 89], bien desde un punto de vista lógico [Tse et al 94], o mediante VDM [Larsen et al 94]; en [Fuggeta et al 93] se emplea un diagrama similar a una red de Petri junto con un lenguaje estructurado. Los trabajos citados ponen el énfasis en la traducción de las especificaciones [Tse 91], en la combinación de DFD y diagramas de EntidadRelación [Fuggeta et al 93] y en los diagramas de estructura [Tse et al. 94], etc... Nosotros nos centramos en la formalización de los DFD, en la descripción formal de la lógica de los procesos utilizando un lenguaje a la vez fácil y expresivo, denominado MSL, y en la generación automática de prototipos ejecutables. Nuestro grupo de investigación adopta una estrategia similar en la formalización del proceso de especificación de requisitos desde un punto de vista OO [Toval et al 94][OOAP 95].
Este trabajo se sitúa en la fase de Ingeniería de Requisitos, en particular, hace posible la ejecución de los DFD. Incluye un lenguaje de miniespecificaciones (MSL) para escribir los requisitos lógicos de los procesos. Incorpora el rigor de los métodos formales (concretamente lógica de primer orden) lo que supone una contribución a la obtención de software de calidad, con requisitos validados y verificados, no sólo de pantallas o formularios sino, lo que es más importante, sobre el comportamiento y la funcionalidad del sistema [Fuchs 92].
La posibilidad de escribir ME y, a partir de ellas y los DFD, de generar prototipos, produce un efecto sinérgico que incrementa la productividad, ya que se permite en la fase de análisis la validación por parte de los usuarios de los productos obtenidos, tal como se recomienda en MÉTRICA 2.
Es importante resaltar que la herramienta que proponemos es integrable en un entorno CASE estructurado, lo que conlleva una serie de ventajas relativas al uso de un vocabulario común consolidado como son los DFD, de los cuales mantenemos la notación original.
En el resto de esta sección se describe el proceso de prototipado y su aplicación en MÉTRICA 2. En la sección 2 se describen las funciones del entorno de prototipado. La sección 3 se dedica a pormenorizar el lenguaje de miniespecificaciones MSL. En la sección 4 se describe, desde un punto de vista más tecnológico, el proceso automático de obtención de prototipos a partir de las especificaciones. Finalmente, en la sección 5 se resumen las conclusiones y las líneas de investigación abiertas. La sección 4 puede obviarse por los lectores que sólo sean usuarios de la metodología MÉTRICA 2.
Tanto en MÉTRICA 2 como en la gran de la mayoría de las herramientas CASE que integran metodologías estructuradas, las funciones de prototipado sólo consisten en la generación automática de pantallas y en herramientas que simulan el aspecto visual de los informes o formularios. MÉTRICA 2 menciona la importancia de los prototipos funcionales pero sólo incluye en las guías metodológicas el uso de prototipos de interfaz. Aunque este tipo de prototipos ayudan a la hora de validar los requisitos del usuario, no se pueden considerar suficientes pues no cubren la parte esencial de los requisitos de un SI: los requisitos funcionales y de comportamiento.
En la figura 2 se muestra una visión general de la metodología MÉTRICA 2 donde aparecen sombreadas las actividades que consideramos que más pueden aprovechar las ventajas de la utilización de prototipos funcionales. El prototipado funcional se centra en la fase de análisis, cuyo fin es capturar los requisitos del sistema (módulo ARS) e identificar la arquitectura lógica del nuevo sistema (módulo EFS).
En concreto, consideramos que la técnica del prototipado funcional se puede incluir en las actividades:
ARS.3. Diseñar el Modelo Lógico Actual. La ejecución de los DFD que se generan en esta actividad es útil para que analistas y usuarios comprueben propiedades del Modelo aprehendido.
ARS.4. Estudiar alternativas de construcción. Las distintas alternativas se representan mediante un modelo lógico de procesos que describe sus rasgos más distintivos. En la elección de una de las alternativas puede desempeñar un papel clave la utilización de prototipos que permitan identificar las ventajas e inconvenientes de cada opción.
EFS.1. Construir el Modelo de Procesos del Nuevo Sistema. Al igual que en ARS.3 los prototipos funcionales son muy útiles como herramienta conversacional en el diálogo de los analistas con los usuarios para conocer sus necesidades y para la descripción en detalle de las especificaciones funcionales del sistema mediante especificaciones formales ejecutables para obtener la validación/verificación de los requisitos.
EFS.3. Realizar el Análisis detallado del Nuevo Sistema. En esta actividad que es un refinamiento de la EFS.1 son válidos los mismos criterios.
EFS.4. Definir Interfaces de Usuario. MÉTRICA 2 sólo incluye en esta actividad el uso de prototipos de interfaz y, aunque resalta una vez más la importancia de los prototipos funcionales, no los incorpora a las guías metodológicas. El uso de prototipos que simulen el comportamiento del sistema con datos específicos es posible con la herramienta propuesta y es un complemento ideal a los prototipos de interfaz.
Nuestra aportación intenta llenar el vacío de herramientas de prototipado funcional y va más allá. Al utilizar la interfaz gráfica de los DFD para su ejecución, evita de esta manera que el usuario no experto interactúe directamente con el formalismo subyacente (en nuestro caso lógica de primer orden) y permite la definición de ME en un lenguaje muy próximo al lenguaje estructurado tradicional.
[Molina et al. 92] y [Fugetta et al 93] contienen dos propuestas para la ejecución de los DFD. En [Molina et al. 92] se describe SAPE, que sería la primera versión de un entorno de prototipado que integra MSL. En [Fugetta et al 93] se intenta solucionar la ambigüedad que presentan los DFD, introduciendo un lenguaje formal al que se incorporan características típicas de los lenguajes estructurados, como PASCAL, y una nueva notación para los DFD, que incluye información del diagrama de E-R. En nuestra opinión, esta propuesta se aleja de la notación original de los DFD ampliamente aceptada, lo que creemos un claro inconveniente al apartarse del estándar; además, el lenguaje que se utiliza es demasiado parecido a un lenguaje de programación con detalles de implementación.
Nosotros adoptamos una postura 'ecléctica' que nos sitúa entre la flexibilidad del Lenguaje Estructurado y el rigor de PROLOG. Proponemos un lenguaje estructurado imperativo, MSL, con algunas restricciones que lo convierten en un lenguaje formal, lo que permite la manipulación automática de las miniespecificaciones escritas en MSL. Nuestra filosofía apunta en tres direcciones que se pueden representar como las tres hojas de un trébol (figura 3). La hoja superior representa un CASE típico que proporcione soporte a técnicas estructuradas y que incluya un administrador de proyectos, un editor visual para editar (y posteriormente ejecutar) las especificaciones en términos de DFD, un editor de miniespecificaciones MSL y un Sistema de Soporte a la Ejecución (en nuestro caso y de forma transparente al usuario, un intérprete PROLOG).
La figura 4 proporciona, mediante un DFD, una descripción simplificada de las funciones del entorno de prototipado. A partir de la información de los DFD y el Diccionario de Datos (DD) es posible conocer, para cada uno de los procesos, los flujos de entrada/salida, los almacenes de datos que utiliza, etc. En primer lugar, se convierte la representación gráfica de un DFD a 'hechos' PROLOG (es decir, a una representación formal en lógica de primer orden); a continuación, se genera de forma automática, para cada uno de los procesos, una plantilla de código MSL validado que incluye la descripción de los flujos de datos, los almacenes de datos e información relativa a los procesos, lo que supone ya una ayuda automática a la posterior especificación detallada de la funcionalidad de los procesos (el analista utiliza el lenguaje MSL para completar esta plantilla con los requisitos lógicos del programa). Finalmente, se realiza automáticamente un análisis de consistencia y se genera, internamente, un programa PROLOG equivalente a un prototipo funcional de la especificación.
La formalización en lógica de primer orden de los DFD y del código MSL permite la demostración formal de propiedades de la especificación. Algunas de estas propiedades son meramente sintácticas, otras se refieren a la coherencia entre la especificación MSL completa y los DFD (p. ej., comprobar si todos los componentes de los DFD están correctamente descritos en la especificación MSL, si todos los flujos de entrada/salida aparecen en la lista de argumentos,...); otras propiedades hacen referencia a la corrección semántica de los DFD (p.ej., comprobar que desde cada uno de los procesos es posible acceder a una fuente y a un sumidero de datos, comprobar si un proceso explota, si los archivos se heredan de un nivel a otro,...).
Otra propiedad que es posible comprobar es la completitud de las miniespecificaciones MSL, p. ej. para detectar partes indefinidas. Además, esta formalización facilita posteriores traducciones del modelo, generación de código, etc. Productores de software y usuarios pueden utilizar el prototipo generado para verificar los requisitos funcionales del sistema de información en desarrollo utilizando la herramienta de forma conversacional. A partir de ese momento, es posible refinar la especificación (DFD, MSL), combinar prototipos funcionales con otro tipo de prototipos, 'simular' la ejecución de los procesos con datos de entrada proporcionados por los usuarios, etc.
Usando el prototipo equivalente a un ejemplo de gestión de pedidos (figura 5), se puede preguntar el valor de los flujos de datos, de los almacenes, de los procesos de entrada de datos o en general los resultados de la ejecución de cualquiera de los procesos descritos. Las respuestas permiten 'capturar' el com-portamiento funcional del sistema en desarrollo. Si se desea conocer p.ej. todos los pedidos tasados y aceptados, sólo hay que picar con el ratón en el flujo etiquetado como 'pedido tasa-do aceptado': aparece un panel de diálogo, en el que se deben de rellenar (o dejar en blanco como variables libres) los parámetros del flujo de datos, entre ellos el nombre del cliente. A continuación, el sistema de soporte a la ejecución entra en acción (debe ejecutar el proceso 'verif. cliente', para lo cual es necesario instanciar sus flujos de datos de entrada, recuperar registros de un almacén, etc., así hasta alcanzar los flujos de datos que salen de la entidad externa 'cliente'); por último, se visualiza una lista con los resultados solicitados (variables instanciadas). Actualmente, existe una versión de este entorno disponible en PC con Arity PROLOG, que cubre la definición de requisitos, la generación automática de prototipos y la ejecución de prototipos.
- definición de los componentes del sistema (entidades externas, procesos, almacenes de datos y flujos de datos);
- conjunto de miniespecificaciones de procesos.
La primera parte se genera de forma automática a partir de la especificación de los DFD previamente traducida a hechos PROLOG. En ella se incluyen todas las entradas del DD y consta de cuatro secciones:
- 'entidades externas',- 'procesos',
- 'almacenes'- 'flujos de datos'.
En las dos primeras se enumeran los identificadores de las entidades externas y los procesos según aparecen en los DFD. En las dos últimas se describen los campos componentes de los almacenes y flujos de datos según informaciones procedentes del DFD y del DD. La figura 6 muestra parcialmente esta parte de la especificación para el DFD de la figura 5, el ejemplo de gestión de pedidos.
La segunda parte está compuesta de un conjunto de descripciones (miniespecificaciones) de las primitivas funcionales. Cada primitiva funcional tiene asociado un identificador, al que sigue una lista entre paréntesis de los flujos de datos de entrada/salida del proceso. Esta cabecera se genera de forma automática. La especificación completa de un proceso consiste en dos secciones: 'proceso' y 'generacion flujos', con la siguiente sintaxis:
PROCESO <identificador> (e1,...,en s1,...,sm)
<descripción proceso>
GENERACION FLUJOS
<decisión>
FINPROCESO
dondeei/si: flujos y almacenes de datos de entrada / salida;
<descripción proceso>: sentencias estructuradas que describen las tareas del proceso.
<decisión>: precondición, opcional, asociada a cada uno de los flujos de datos generados.
Se consideraría así p.ej. flujos de datos mutuamente exclusivos. Esta característica permite, en cierto modo, usar un mecanismo de pre y pos-condiciones como recomienda [Yourdon 89], potenciando la capacidad expresiva de las ME de los procesos.
MSL utiliza una notación imperativa similar a la de los lenguajes estructurados Por qué usamos una semántica imperativa en vez de declarativa (como en PROLOG o SQL)? La razón radica en nuestro interés por utilizar un vocabulario común a todos los usuarios de MÉTRICA 2 y mantenernos dentro de un estándar aunque por ello se pierda capacidad expresiva y declarativa. Las sentencias se dividen en dos grupos:
Sentencias que caracterizan a los lenguajes estructurados imperativos: ES (asignación), SI..ENTONCES..SINO..FINSI (decisión), SEGUN..SELECCIONAR..FINSEGUN (alternativa), PARA CADA..EJECUTAR..FINPARA (repetición), LEER y ESCRIBIR (entrada/salida). En la sentencia de asignación ES, el lado izquierdo debe ser un identificador o un componente de un flujo de datos. La sentencia SEGUN..SELECCIONAR se muestra útil cuando la lógica de un proceso es compleja. Las sentencias LEER y ESCRIBIR permiten a los usuarios introducir datos mediante el teclado o visualizar resultados en pantalla.
Sentencias relacionadas con características propias de los DFD, como son la gestión de almacenes y flujos de datos: RECUPERAR DE <almacén> recupera un registro del almacén; BORRAR DE <almacén> elimina un registro del almacén y ALMACENAR EN <almacén> añade un registro a un almacén; INDEFINIDO <lista flujo de datos de salida> permite dejar incompletamente definida una especificación, o sea no se dice cómo se van a generar los flujos de datos de la lista y será en tiempo de ejecución cuando se solicite al usuario que introduzca manualmente valores para los elementos de los flujos indefinidos (esta sentencia es útil cuando no es factible realizar un prototipo completo del sistema y sólo se pretende prototipar las partes de mayor interés, dejando el resto indefinidas y permitiendo al usuario aportar interactivamente un comportamiento por defecto, similar a las clases abstractas de la tecnología Orientada a Objetos). La sentencia OBTENER <lista flujo de datos entrada> (en el caso de que los flujos de datos tengan su origen en otro proceso) permite deshacer una parte importante de la ambigüedad de los DFD al hacer explícita la obtención de los valores de los flujos de datos. En el ejemplo
se fija el control interno del proceso y se detalla en qué casos se hará uso de la información que contiene un determinado flujo de datos. En la sección GENERACION FLUJOS de un proceso es posible especificar condiciones para la generación de los flujos y determinar en qué casos se generarán los flujos de salida D y E. La utilización de la sentencia OBTENER en combinación con la sección de GENERACION FLUJOS y sentencias de control permiten definir sin ambigüedades la lógica de control interna de un proceso lo que permite la ejecución de los DFD.
MSL también permite el uso de operadores matemáticos básicos con el fin de escribir expresiones de cálculo pero evitando, por el número y naturaleza de los operadores que incluye, que éstas sean complejas, tal como recomienda MÉTRICA 2. La figura 7 proporciona las especificación de dos de los procesos del ejemplo de la figura 5.
Es importante reseñar que se permite el uso de la notación punto para indicar de forma inequívoca el objeto al que se refiere una sentencia. P. ej. si un proceso tiene dos flujos de entrada que proceden de otro proceso (flujoA) y de un almacén (flujoB) y los dos flujos incluyen un campo con idéntico nombre (campoX), será preciso usar la notación punto para indicar cuando se trata del campo del flujo A (flujoA.campoX) o cuando se trata del campo del flujo B (flujoB.campoX), lo que preserva la propiedad de identificador único.
En [Goble 89] se propone una técnica manual para convertir los DFD y las ME en programas PROLOG. Nosotros utilizamos estas ideas asociando una regla PROLOG a cada flujo de datos de salida de un proceso, cuyo nombre coincide con el del identificador del flujo de datos en la especificación MSL y cuyo número de argumentos es igual al número de elementos del flujo de datos. La ejecución de la regla asignará un valor a cada uno de los elementos del flujo de datos. Suponemos que los flujos de datos que entran a un almacén o salen de él poseen idéntico nombre que el almacén. Asociamos a cada primitiva funcional P (proceso) una regla cuya cabecera es el predicado que corresponde al nombre del proceso y donde los argumentos del predicado son todos los flujos de datos de entrada y salida al proceso; el cuerpo de la regla representa las acciones del a-partado <descripción del proceso> de su especificación MSL.
Un flujo de datos de salida de un proceso P tiene la siguiente regla asociada: su cabecera es el predicado asociado al flujo de datos con sus correspondientes argumentos (es decir, flujoDatosSalida1(ListArgSalida)); su cuerpo consta de:
- el predicado correspondiente al proceso P (procesoP(List
ArgProcesoP)), que a su vez contiene en su cuerpo llamadas a los predicados correspondientes a los flujos de datos de entrada al proceso P; y
- los predicados correspondientes a las condiciones reflejadas en la sección GENERACION FLUJOS de P para el flujo de datos (generacionFlujosProcesoP).
flujoDatosSalida1(ListArg):-
procesoP(ListArgProcesoP),
generacionFlujosProcesoP.
donde generacionFlujosProcesoP no aparece cuando la generación es incondicional. En el caso de una generación de flujos condicional se pueden presentar dos opciones:
- Si flujoDatosSalida1 aparece en una sentencia SI..ENTONCES..SINO..FINSI, generacionFlujosProcesoP equivale a la condición o a la negación de la condición, dependiendo de si el flujo se asocia con las cláusula 'ENTONCES' o 'SINO', respectivamente.
- Si flujoDatosSalida1 aparece asociado a un valor v en una sentencia SEGUN..SELECCIONAR..FINSEGUN con etiqueta i, generacionFlujosProcesoP equivale a la igualdad i=v.
Si en el cuerpo de una regla correspondiente a un proceso existe un predicado relativo a un flujo de datos generado por otro proceso, existirá otra regla en el prototipo para calcular tal flujo de datos. Otra posibilidad es que en el cuerpo de una regla se haga referencia a un flujo de datos que tiene su origen en una entidad externa o en un almacén. En el primer caso, es preciso incluir en la base de datos 'hechos' PROLOG con información acerca del flujo de datos, o bien introducir por teclado la información necesaria, en el momento de la ejecución de la regla. En el caso en el que el flujo de datos tiene su origen en un almacén, es necesario que en la base de datos haya un hecho para cada uno de los registros del almacén, de la forma: nombre_almacen(Valor1, Valor2, ....).
Usando MSL se obtienen ME que son a la vez formales y simples: al ser formales es posible validar automáticamente la información de los DFD y del DD, generar prototipos y, además, corregir errores cometidos por los productores de software en la fase de análisis; al ser simples, permiten a los usuarios o a los programadores entender fácilmente las ME escritas por los productores de software debido, en gran parte, a las propiedades de un Lenguaje Estructurado [Vessey 86].
Nuestro interés actual se centra en la investigación de los fundamentos formales de los conceptos de AE para intentar unificar en un solo modelo las diferentes técnicas de AE a través de una teoría matemática única. Con esto se pretende mejorar la calidad de las herramientas software y de las técnicas de generación de prototipos relacionadas con AE, al permitir una validación y verificación continua de los diferentes modelos del sistema.
En relación con el lenguaje MSL, estamos trabajando en la conveniencia de distinguir entre funciones primitivas y no primitivas (jerarquías) con el propósito de permitir prototipos de alto o bajo nivel de abstracción aún cuando los procesos no estén especificados completamente: algo así como 'mini-especificaciones abstractas' en clara analogía con las clases abstractas del paradigma OO; lo que se ha revelado muy útil durante el análisis.
[Ehrig et al 92] H. Ehrig; B. Mahr; I. Classen; F. Orejas; Introduction to Algebraic Specification. Part 1; Formal Methods for Software Development. The Computer Journal, vol. 35, n
[France et al. 89] Robert B. France y Thomas W.G. Docker; Formal Specification using structured systems analysis. Lecture Notes in Computer Science. ESES'89. C. Ghezzi et al. (eds.) Springer-Verlag n
[Fuchs 92] Norbert E. Fuchs; Specifications Are (Preferably) Executable. Software Engineering Journal, septiembre 1992.
[Fuggeta et al 93] Alfonso Fuggeta, C. Ghezzi, D. Mandrioli y A. Morzenti; Executable Specifications with Data-flow Diagrams. Software-Practice and Experience, Vol. 23 (6), 629-653, junio 1993.
[Goble 89] T. Goble; Structured Systems Analysis through Prolog. Prentice-Hall 1989.
[Goguen 94] Joseph A. Goguen; Requirements Engineering as the Reconciliation of Technical and Social Issues. En Requirements Engineering: Social and Technical Issues editado con Marina Jirotka, Academic, 1994, pp. 165-199.
[Harel 92] D. Harel; Biting the Silver Bullet. Computer, vol. 25, n
[Larsen et al 94] Larsen P.G., Nico Plat y Hans Toeenel; A Formal Semantics of Data Flow Diagrams. Formal Aspects of Computing, diciembre 1994.
[Luqi 89] Luqi. Naval Postgraduate School; Software Evolution Through Rapid Prototyping. IEEE COMPUTER vol.22, n.5, mayo 1989 pp.13-25.
[MAP 95] Metodología de Planificación y Desarrollo de Sistemas de Información. MÉTRICA V.2.1. MAP: Ministerio de la Administración Pública, Sub. Gen. de Coordinación Informática. TECNOS, Madrid, 1995.
[Molina et al 92] J. García Molina, A. Toval Álvarez; M. González Rodríguez; SAPE: A structured analysis prototyping environment. 12Th World Computer Congress. IFIP Congress 92, Madrid 1992.
[OOAP 95] Object-Oriented Assistant Prototyper. Proyecto PASO (Plan de Acción SOftware) subvencionado por CEE (DG. XIII) y M Industria. DIS (Univ. de Murcia) y DSIC (UPV Valencia), junio 1995.
[Rumbaugh 91] Rumbaugh, J. et al.; ObjectOriented Mode-ling And Design. PrenticeHall, Englewood Cliffs, NJ, 1991.
[Steer 88] K. Steer; Testing Data Flow Diagrams with PARLOG. 1988. En Logic Programming. Actas de la V Conference and International Symposium. MIT Press, 1988.
[Tanik et al. 89] M.M. Tanik; R.T. Yeh; Rapid Prototyping in Software Development. IEEE Computer vol.22, n
[Tao et al. 91] Yonglei Tao y Chenho Kung; Formal Definition and Verification of Data Flow Diagrams. Journal of Systems Software. 1991.
[Toval et al. 94] Prototyping Object Oriented Specifications in an Algebraic Environment. A.Toval, I.Ramos, O.Pastor. En Database and Expert Systems Applications (D.Karagianis, Ed.). LNCS n
[Tse 91] T.H. Tse; A unifying Framework for Structured Analysis and Design Models: An Approach using Initial Algebra Semantics and category Theory. Cambridge University Press 1991.
[Tse et al. 94 ] T.H. Tse, T.Y. Chen, C.S. Kwok; The use of Prolog in the modeling and evaluation of structure charts. Information and Software Technology 1994, Vol. 36 n
[Vessey 86] Iris Vessey and Ron Weber; Structured Tools and Conditional Logic: An Empirical Investigation. Comm. de ACM, junio 1986, vol.29, n
[Williams 86] M.H. Williams, G.Chen; Translating Pascal for execution on a Prolog-based System. The Computer Journal, vol.29, n
[Yourdon 89] Edward Yourdon; Modern Structured Analysis. YOURDON Press 1989.