Uzcátegui, Elluz Ortega, Dinarle Delgado, Desirée

 Las autoras del presente articulo desempeñan sus actividades como Docentes a Dedicación Exclusiva en el Departamento de Computación de la Facultad Experimental de Ciencias y Tecnología, Universidad de Carabobo, Antiguas Instalaciones del Decanato de la Facultad de Ciencias de la Salud, Bárbula, Estado Carabobo, Venezuela. La Lic. Elluz Uzcátegui tiene el telefax 0241-8678243 y celular 0412-5121631, correos electrónicos elluz_uzcategui@yahoo.es y euzcateg@uc.edu.ve. La Dra. Dinarle Ortega, celular 0416-6411495, correos electrónicos dinarleortega@yahoo.es y dinarleortega@gmail.com. La Ing. Desirée Delgado, el telefax 0241- 8678243, celular 0416-7341562, correos electrónicos desi.delgado@gmail.com y ddelgado@uc.edu.ve.

Resumen:

Este trabajo incentiva el uso de las metodologías de desarrollo de software de Tiempo Real. Se facilita una herramienta de soporte a los desarrolladores para determinar la metodología mas adecuada de acuerdo a las necesidades del problema. Se establecen un conjunto de criterios para comparar metodologías de desarrollo de software: COMET, Octopus/UML y ROPES, y en base a estos resultados se logra seleccionar entre ellas la más apropiada a un problema en particular. Durante la investigación, expertos y desarrolladores revisan y ratifican cada uno de estos criterios. Finalmente, se identifican las ventajas de aplicar en un proceso de desarrollo de un sistema de tiempo real los conceptos de calidad de software y evaluación arquitectónica, como herramientas para garantizar características de calidad en el sistema. Se utiliza como metodología de investigación la Investigación-Acción.

Palabras clave: Tiempo Real / Metodología de Desarrollo de Software /COMET/ ROPES/ OctopusUML/ Calidad del Software / Evaluación Arquitectónica.

METHODOLOGY FOR THE DEVELOPMENT OF REAL TIME SYSTEMS. A COMPARATIVE STUDY

Abstract:

This work promotes the use of a methodology for the development of Real Time software. We offer a tool that could help to determine the most appropriate methodology, according to problem needs. A set of criteria is established to compare methodologies for the development of software, such as: COMET, Octopus/UML and ROPES. On the basis of these results the most appropriate methodology can be selected to deal with a particular problem. During the research process, experts and developers verify and ratify every one of these criteria. Finally, the advantages of applying software quality and architectural evaluation concepts to the development process of a real time system, are identified as tools to guarantee the quality characteristics of the system. Research-Action is used as a research methodology.

Keywords: Real Time / Methodology for the Development of Software / COMET / ROPES / OctopusUML / Software Quality / Architectural Evaluation.

I. INTRODUCCIÓN

En los últimos años en Venezuela, como consecuencia de las políticas de estado en lo referente al desarrollo endógeno, existe actualmente una orientación estratégica hacia el desarrollo de software de Tiempo Real, tomando en cuenta las necesidades de automatización de procesos, robótica, inteligencia artificial, entre otros.

En este sentido, es importante resaltar que el desarrollo de software en el dominio de Tiempo Real puede llegar a ser un proceso complejo, por lo tanto es fundamental aplicar metodologías y herramientas del área de la ingeniería del software adecuadas, para orientar el proceso de desarrollo. Actualmente, existen una amplia variedad de metodologías y notaciones que se han desarrollado para el análisis y diseño de sistemas de Tiempo Real, de las cuales los desarrolladores deben seleccionar la más adecuada, según el contexto del problema. El objetivo de este trabajo es, plantear una herramienta para ayudar a los involucrados en el proceso de desarrollo de software, al momento de seleccionar una metodología en el contexto de sistemas de Tiempo Real, estableciendo para ello un conjunto de criterios que permita realizar una comparación entre metodologías. Asimismo, se busca propiciar el uso de las metodologías de desarrollo de software como guía para el desarrollo sistemático de este tipo de aplicaciones, y se exponen las ventajas de aplicar conceptos de calidad de software y evaluación arquitectónica.

El presente trabajo está formado por cinco secciones: una primera sección de introducción, donde se exponen los fundamentos y objetivos de la investigación; luego se describe la metodología utilizada en la investigación. Una tercera sección con los resultados obtenidos, y una cuarta y quinta sección con las conclusiones y referencias bibliográficas.

II. DESARROLLO

1. Metodología

La investigación fue desarrollada utilizando la Metodología Investigación-Acción propuesta por Susman y Evered (1978) [1], dada su adaptación en el contexto de la Ingeniería de Software y Sistemas de Información. A continuación se detallan las cinco fases presentes en el proceso iterativo:

a. Fase de Diagnóstico: Corresponde a la identificación y descripción de la situación actual.

b. Fase de Planificación de la Acción: Especifica las acciones que deben ser ejecutadas para mejorar el problema.

d. Fase de Evaluación: Después de ser completadas las acciones, los investigadores evalúan las salidas, utilizando técnicas apropiadas que aporten evidencia de la calidad de las acciones emprendidas.

e. Fase de Especificación del Aprendizaje: en esta fase se reflexiona sobre los resultados de la fase de evaluación.

2. Conceptos fundamentales

En esta sección se presenta una breve revisión de los conceptos fundamentales relacionados con el desarrollo de esta investigación.

• Sistemas de Tiempo Real (STR)

Un Sistema de Tiempo Real, se define como: “Un sistema en el que el tiempo en que se produce su salida es significante.  Esto es debido a que generalmente la entrada corresponde a algún instante del mundo físico y la salida tiene relación con ese mismo instante" [2]. Entre los elementos principales de un STR, se encuentran un sistema de control, interactuando con el mundo físico a través los sensores, quienes capturan datos para ser procesados y enviar la respuesta de retorno al mundo físico a través de los actuadores.

Por otra parte, dentro de las características propias del dominio de STR se encuentran los requisitos de tiempo, de seguridad y fiabilidad, que vistos desde el modelo de calidad estándar ISO 9126-1 corresponderían con las características de calidad: Eficiencia, Funcionalidad y Fiabilidad, respectivamente.

• Metodologías de Desarrollo de Software para Aplicaciones de Tiempo Real

Una metodología puede definirse como "Una versión ampliada del ciclo de vida completo del desarrollo de sistemas, que incluyen tareas o pasos para cada fase, funciones desempeñadas en cada tarea, productos resultantes, normas de calidad y técnicas de desarrollo que se utilizan en cada tarea" [3]. En los últimos años se han desarrollado diversas metodologías de aplicación específica del diseño de STR, entre ellas se pueden encontrar ROOM/UML-RT, HRT-HOOD, OOHARTS, SiMOO-RT, ACCORD/UML COMET, Octopus/UML, ROPES [4]. Para esta investigación, se seleccionaron las tres últimas de las metodologías mencionadas, tomando en cuenta características comunes tales como, basadas en notaciones estándares como UML y enfocadas bajo el paradigma orientado a objetos, utilizan la definición arquitectura de software. A continuación, se presenta una descripción breve de cada una de ellas.

COMET [4, 5] es una metodología que emplea notación UML, y está basada en un ciclo de desarrollo iterativo, con las siguientes fases: modelado de requisitos, análisis , diseño, construcción e integración incremental del software y validación del sistema (ver Figura 1).

Los requisitos funcionales del sistema se especifican mediante actores y casos de uso. En la fase de análisis, se refinan los requerimientos para describir los objetos que intervienen y sus interacciones, a través de diagramas de clase (modelo estructural) y mediante colaboraciones y/o diagramas de estado (comportamiento dinámico). En la fase de diseño, se desarrolla la arquitectura del software. En la fase de construcción se lleva a implementación, el diseño del comportamiento estático y dinámico del sistema. Durante la fase de integración se integran los módulos de software creados. Finalmente, sobre la arquitectura de tareas obtenida en la fase de diseño, se lleva a cabo la validación temporal del sistema, a través de un análisis de planificación o un análisis de secuencias de eventos.

• Octopus/UML

Octopus/UML [4, 6] es una metodología de desarrollo orientado a objetos y utiliza UML como notación. Sin embargo, para algunos aspectos donde UML no dispone de notación específica, utiliza la notación original de Octopus. No fuerza la redefinición de objetos, ya que admite la reutilización de segmentos de software ya diseñados. Propone seguir las fases de especificación de requisitos, la definición de la arquitectura del sistema y luego el desarrollo en paralelo de cada subsistema siguiendo las habituales fases de análisis, diseño e implementación para cada uno. En la última fase se lleva a cabo la integración del hardware y el código ya disponible con los subsistemas desarrollados (ver Figura 2).

En Octopus/UML, la especificación de requisitos se hace mediante casos de uso, escenarios y el diagrama de contexto. Para el análisis de cada subsistema se propone la generación de los modelos estructural, funcional y dinámico. Cada fase tiene definidos los artefactos con los que se alimentan las fases subsiguientes y favorece la combinación entre el modelo de desarrollo de software espiral y evolutivo.

ROPES [4, 7] emplea como notación UML se basa en un proceso de desarrollo iterativo (o en espiral). Está compuesto de diversas tendencias de la ingeniería del software, tales como, análisis de riesgo y calidad de software. Se organiza en cuatro grandes fases: análisis, diseño, traducción y pruebas, siendo los artefactos resultantes de cada fase, modelos o diagramas UML que se refinan o corrigen en las siguientes (ver Figura 3).

En la actividad de análisis se llevan a cabo tres tipos de análisis. Un análisis de requisitos, en el que se especifican los requisitos funcionales y no funcionales del sistema. En segundo lugar el análisis de sistema, se realiza la división de responsabilidades entre el hardware y el software, la arquitectura de alto nivel del sistema y los algoritmos de control necesarios. Y por último el análisis de objetos, el cual comprende dos grandes tareas, en una, se determinan los modelos estructurales de los objetos que han de componer el sistema y en la otra, se modela su comportamiento mediante colaboraciones o diagramas de secuencias. En la fase de diseño se llevan a cabo los diseños de la arquitectura, mecanismos y el detallado. La fase de traducción comprende la generación de código ejecutable a partir del diseño del sistema. En la fase de pruebas se verifica la conformidad de la aplicación, sea para encontrar defectos o para observar un cierto nivel funcional. Incluye pruebas de integración y de validación. Como herramienta de soporte para la elaboración y gestión de los artefactos, su autor propone Raphsody de I-Logix, en parte debido a que con ella se automatiza la generación del código. ROPES sin embargo no alcanza a proponer una estrategia que permita integrar el análisis de planificación en el proceso de desarrollo.

• Calidad del Software

En la sección correspondiente se mencionaron algunas de las principales características de calidad inherentes a los STR. En este sentido, se hace necesario que las metodologías de desarrollo en el contexto de los STR manejen de alguna manera este aspecto. En el área de Ingeniería de Software, existen dos conceptos fundamentales en relación a este aspecto y son la calidad del software y los modelos de calidad. La calidad de software se define como, la totalidad de rasgos y atributos de un producto de software que lo apoyan en su capacidad de satisfacer sus necesidades explícitas o implícitas (según ISO/IEC 9126, 1998). Relacionado con el concepto de calidad de software se pueden encontrar los modelos de calidad de software, que representan un conjunto de características y de las relaciones entre ellas, que proporcionan la base para especificar los requisitos de la calidad y evaluar dicha calidad (según ISO14598). Éstos permiten la especificación y evaluación de la calidad del producto de software desde diferentes perspectivas (adquisición, desarrollo, uso, evaluación, mantenimiento). Uno de los principales modelos de calidad es el estándar internacional ISO 9126.

• Evaluación Arquitectónica del Software

En el mejor de los casos, durante el diseño de sistemas de software se generan varias opciones arquitectónicas. En una evaluación arquitectónica se evalúan dichas opciones para determinar cuál es la más apropiada sobre la base de los objetivos y restricciones del problema a resolver. Una Arquitectura de Software ejerce influencia notable sobre la calidad del sistema que se implementa, y a través de ella se puede validar si el sistema cumple con los requerimientos de calidad exigidos. Existen diferentes métodos de evaluación arquitectónica, por ejemplo el método de Jan Bosch, ATAM(Attribute Tradeoff Analysis Method) , MACA, entre otros.

En esta sección se presentan los resultados que se obtuvieron al aplicar cada una de las fases de la metodología descrita en la sección anterior.

3.1 Fase de Diagnóstico

Durante esta fase se identificó el contexto que enmarca al problema y se realizó la revisión bibliográfica de los principales conceptos relacionadas a esta investigación.

Descripción del problema

Actualmente existe una gran demanda por el desarrollo de sistemas de Tiempo Real. El uso de herramientas del área de la ingeniería del software es fundamental para el desarrollo de este tipo de sistemas. Sin embargo, aunque existe una gran variedad de metodologías de desarrollo en este contexto, los desarrolladores son los responsables de seleccionar aquella que considere adecuada al problema, lo que en algunas ocasiones puede resultar una tarea difícil. A su vez, se debe tomar en cuenta que, muchos de los desarrolladores en este dominio, son profesionales de otras áreas afines a las de Computación. En este sentido, se hace necesario determinar aquel conjunto de aspectos principales que orienten a los involucrados en el proceso de desarrollo de software en el momento de seleccionar una metodología en el contexto de sistemas de Tiempo Real.

3.2 Fase de Planificación e Implementación de la acción

En esta fase se describe el conjunto de actividades que se llevaron a cabo para cumplir con el objetivo planteado.

3.2.1 Identificación de criterios de comparación.

Tomando en cuenta la experiencia de los autores en el uso de metodologías de desarrollo, se definen dos conjuntos de criterios para llevar a cabo la comparación de metodologías. Estos dos criterios se definen como:

 Facilidad de uso: define el esfuerzo realizado por las personas involucradas en el desarrollo del software, para seguir la metodología hasta lograr obtener el producto esperado.

 Flexibilidad: capacidad para adaptar la metodología al problema, tomando sólo aquello que se considere necesario.

 Claridad de los diagramas: define la facilidad para la elaboración de los diagramas de parte de los involucrados en el desarrollo.

 Usa Herramientas automatizadas de Soporte: indica el uso de herramientas automatizadas para asistir a los involucrados en la generación de los artefactos.

 Documentación de Soporte: disponibilidad de manuales, guías y cualquier tipo de documento para la orientación acerca del uso de la metodología.

 Cantidad de artefactos: evalúa la cantidad de artefactos y documentos generados durante el proceso de desarrollo.

 Propicia Características de Calidad: indica las características de calidad que propicia la metodología.

 Contempla Diseño Arquitectónico: indica si la metodología dentro de sus fases, concuerda con el desarrollo de la arquitectura del sistema.

 Contempla Evaluación Arquitectónica: indica si la metodología hace uso de algún método de validación de los requisitos no funcionales (características de calidad) en etapas tempranas del desarrollo.

 Concurrencia: identifica la documentación (diagramas, modelos) generada por la metodología, para describir la gestión de varios procesos dentro del sistema.

 Comunicación de Mensajes: identifica la documentación generada para describir los mecanismos para dar soporte al intercambio de mensajes entre procesos.

 Manejo de eventos: se identifican los documentos que describe el conjunto de pasos seguidos por el sistema con la llegada de ciertos eventos.

 Validación temporal del sistema: se identifican los documentos que describe la planificación de los eventos en el tiempo.

3.2.2 Validación de los criterios

El conjunto de criterios establecido en la sección anterior, se evalúa con un grupo de 8 profesores expertos en el uso de metodologías de desarrollo de software, para determinar si reúnen la mayor cantidad de características que deban considerarse de una metodología, y el grado de relevancia de estos en una comparación entre metodologías. En el instrumento aplicado, los encuestados seleccionan con un SI o NO para cada criterio. Los resultados de dicha evaluación indica (ver Tabla I) que la mayoría de los encuestados valoraron con un alto porcentaje la mayoría de los criterios establecidos. Sin embargo se debe destacar el criterio de flexibilidad que no fue considerado como aspecto importante en el momento de seleccionar una metodología. De esta manera, sólo 8 del un grupo de 9 subcriterios sujetos a la evaluación, formarán parte del estudio comparativo a realizar con las metodologías seleccionadas en este trabajo. En cuanto a los criterios de Conceptos de Tiempo Real, todos los criterios fueron calificados como esenciales para la evaluación de la metodología (ver Tabla II).

3.2.3 Comparación de Metodologías

Sobre la base de la revisión y análisis bibliográfico de las metodologías COMET, Octopus/UML y ROPES, se ha llevado a cabo la comparación de estas metodologías según los criterios establecidos en la sección anterior. Para esto, se ha definido una escala de valores para cada uno de los criterios: alto, medio y bajo. El valor de la escala indica el grado en que la metodología cumple con el criterio. En otros casos, sólo se indica "No" para señalar que no cumple con el criterio, y en caso contrario, se especifican las herramientas utilizadas para implementarlo.

En relación a los aspectos generales (ver Tabla III), la metodología COMET es fácil de usar, y posee diagramas sencillos de elaborar. Las tres metodologías poseen herramientas que soportan la generación automática de artefactos; para ROPES, su autor propone utilizar una herramienta en particular (Raphsody de I- Logix) y en los casos de Octopus/UML y COMET, se asocian directamente las herramientas que se utilizan para UML. La Documentación de soporte de Octopus/UML es amplia, de fácil acceso a los usuarios. En la Tabla IV también se observa que Octopus/UML se caracteriza por ser una metodología pesada, ya que es la que genera mayor cantidad de artefactos. En cuanto al manejo de características de calidad, ROPES plantea dentro de sus fases, actividades orientadas a garantizar características muy importantes de los sistemas de Tiempo Real como lo son la seguridad y la fiabilidad.

La reutilización es un aspecto que propicia tanto ROPES como Octopus/UML. En el caso de COMET, la documentación no especifica actividades en las que se consideren el análisis y tratamiento de requerimientos adicionales a las funciones del sistema. Las tres metodologías llevan a cabo el desarrollo de la arquitectura de software. Sin embargo, ninguna de ellas aplica métodos de evaluación arquitectónica, restringiendo de esta manera la posibilidad de validar durante las etapas tempranas del desarrollo del software, el cumplimiento de los requisitos de calidad especificados durante la etapa de levantamiento de requerimiento.

Por otra parte, todas las metodologías ofrecen herramientas para describir los conceptos propios del dominio de tiempo real (ver Tabla IV) como la concurrencia, comunicación de mensaje, manejo de eventos y validación temporal del sistema. En cuanto a éste último, ROPES y Octopus/UML no ofrecen ningún modelo al respecto.

En esta fase, se utilizan los resultados de la comparación de las metodologías, y se selecciona una de ellas, para aplicarla en el desarrollo de un sistema de tiempo real. Esta selección se valida con los desarrolladores del sistema.

A. Descripción del Problema.

Se requiere implementar un módulo de navegación para un Vehículo Autónomo Submarino (VAS), en dos fases. En la primera (septiembre 2006- diciembre 2007), se desarrollará el software bajo un ambiente simulado que deberá ser capaz de detectar y evadir obstáculos encontrados en la ruta especificada, utilizando como mecanismo de reconocimiento una cámara fotográfica. En la segunda fase se tiene previsto rediseñar el módulo, con el objeto de permitir la visualización de obstáculos que puedan presentar riesgos o peligros para la integridad y movilidad del VAS, bajo ambientes de poca fuente de luz. La diferencia principal respecto al desarrollo anterior, es que el sistema llevará a cabo la búsqueda de objetos con determinadas características, basadas en las respuestas a las ondas emitida por un sonar (digital), a diferencia de hacerlo con una cámara.

B. Selección de la metodología

Sobre la base de los criterios establecidos en la sección 3.2 y tomando en cuenta el dominio del problema planteado, se identifican las características prioritarias a ser tomadas en cuenta en el momento de la escogencia de la metodología de desarrollo de software:

• Generación de artefactos. Tomando en cuenta la complejidad del problema, resultaría beneficioso contar con una metodología que genere gran cantidad de artefactos, para documentar completamente el módulo a desarrollar.

• Buena documentación de soporte. De ésta depende la comprensión y el uso adecuado de la metodología de desarrollo de software, por parte de los desarrolladores.

• Propicia la reutilización de código, dado que se tiene previsto realizar modificaciones al módulo a desarrollar. • Diseño de la arquitectura. Este aspecto permite a los involucrados en el desarrollo tener una visión clara del sistema y sus componentes.

• Usa herramientas automatizada de soporte. se considera importante que la metodología proporcione herramientas que permita la generación automática de todos o algunos de los artefactos.

C. Validación de la metodología seleccionada.

Se entrevistó a los 6 desarrolladores implicados en las dos fases del desarrollo del módulo para el VAS, con el objeto de evaluar su experiencia con el uso de la metodología Octopus/UML. (Tabla V)

Los resultados señalados en la Tabla V ponen de manifiesto el grado de satisfacción de parte de los desarrolladores, con el uso de la metodología recomendada, validando de esta manera que aplicando los criterios establecidos en este trabajo puede ayudar a tomar una decisión en cuanto a seleccionar la metodología más adecuada según el contexto del problema.

3.2.5 Fase de Especificación del aprendizaje

En el desarrollo del módulo para el VAS, el uso de una metodología de desarrollo, facilitó la modificación del sistema, y permitió a los dos grupos de desarrolladores comprender y tener una visión clara del sistema a desarrollar y modificar. Sin el uso de las metodologías de desarrollo, la tarea de mantenimiento puede resultar un trabajo arduo y costoso, incluso puede darse el caso de tener que iniciar desde el principio todo el proyecto por falta de documentación. Efectivamente tomando en cuenta los criterios establecidos, se pudo identificar la metodología que mejor se adaptaba al problema. Dado que el problema estaba originalmente dividido en dos fases bien identificadas, permitió ratificar en dos momentos diferentes la experiencia de cada uno de los grupos con el uso de la metodología recomendada, quienes a nivel general catalogaron como satisfactoria la experiencia. Se puede decir que aun y cuando todas las metodologías tratadas en este trabajo son perfectamente aptas para aplicarlas en el desarrollo de sistemas de tiempo real, de problemas de cualquier magnitud, es posible establecer aspectos de comparación que permitan la escogencia de una de ellas.

III. CONCLUSIONES

1. Los resultados sugieren que tomando como base el conjunto de criterios establecidos, se puede determinar la metodología que mejor se adapta a las necesidades del problema planteado.

3. Se detectó que ninguna de las metodologías estudiadas contempla actividades orientadas a la identificación de requisitos de calidad en etapas tempranas del desarrollo.

4. Los modelos de calidad de software ayudan a especificar las características de calidad en etapas tempranas del proceso de desarrollo, donde el costo (en tiempo y recursos económicos) es menor para realizar cambios.

5. Aplicar un método de evaluación de arquitectura dentro del proceso de desarrollo permite validar la arquitectura en relación con los propósitos del sistema.

6. Se resalta la importancia de aplicar una metodología en el desarrollo de Sistemas de Tiempo Real y los beneficios que ésta puede aportar al producto final (el sistema), si se combina con otros conceptos de la ingeniería del software.

7. Se sugiere aplicar los criterios establecidos en este trabajo, en diversos problemas para validar la utilidad de la herramienta en otros contextos y así ampliar el uso de la misma.

IV REFERENCIAS

1. Susman, G. I. & Evered, R. D.. An Assessment of the Scientific Merits of Action Research. Administrative Science Quarterly, (23), 1978, pp. 582-603.         [ Links ]

2. Burns, A.; Wellings, A. Real-time systems and programming languages.3ª ed., London Addison Wesley. 1997. pp16-21.         [ Links ]

3. Whitten, J. ; Bentley, L. ; Barlow, V. Análisis y Diseño de Sistemas de Información. 3ª ed., Madrid. McGraw-Hill. 2003. pp146-160.         [ Links ]

4. Medina, J. Metodología y Herramientas UML para el Modelado y Análisis de Sistemas de Tiempo Real Orientados a Objetos. http://www.tesisenred.net/TDR-0209106-103344 . Revisado en marzo del 2008         [ Links ]

5. Gomaa , H. Designing Real-Time Applications with the COMET/UML Method . George Mason University. http://www.dedicatedsystems.com/magazine/01q1/2001q1_p044.pdf          [ Links ]

6. Domiczi, E, ; Farfarakis R. ; Ziegler J. Release of Octopus/UML. Nokia Research Center.

http://www.nrc.nokia.com/octopus/supplement/index.html  . Revisado en febrero 2008.

7. Bruce, D. ROPES: Rapid Object-Oriented Process for Embedded Systems. http://www.cs.ru.nl/~hooman/ots/Ropes.pdf%20.%20 . Revisado en febrero 2008.         [ Links ]

8. Ghezzi, C. ; Jazayeri, M. ; Mandrioli, D. Fundamentals of Software Engineering. Washington. Prentice Hall. 1991. pp37-39.         [ Links ]

9. Sommereville, I . Ingeniería del Software. 7ª ed., Madrid. Pearson Addison Wesley. 2005. pp 309-323         [ Links ]

10. Spiteri, A. A Comparison of Software Analysis and Design Methods for Real Time Systems. Proceedings of Wrld Academy of Science, Engineering and Technology. Vol 21. May 2007. pp55-59        [ Links ]