Otros métodos que usan diagramas de estados

VFSM es una técnica nacida en la compañía Bell que permite especificar el comportamiento de un módulo de software como una máquina de estados finitos. Esta técnica definida por sus autores en [God96] como “un paradigma de diseño en el cual el comportamiento de un módulo se especifica con un autómata; y un paradigma de implementación que consiste en una estructura de diseño que define la interfaz entre la especificación del control y el resto de la implementación”. Con la ayuda de herramientas, se afirma en [Flo97] y [Ard96] que se puede probar, generar el código y hacer documentación del sistema. La Figura 2.38 muestra un ejemplo sencillo de una VFSM tomado de [Flo97]. VFSM añade únicamente a las máquinas de estados finitos convencionales el uso de variables booleanas.

SIDLE{ NS: ICARDPRESENT > SGETPIN } SGETPIN{ C:IPINPRESENT,ICTIMEOUT; E:OPINPROMT,OSTARTCTIMER; X:OSTOPCTIMER; NS:IPINPRESENT > SCHKPIN; ICTIMEOUT > SBYEBYE } SCHKPIN{ M:PROCEED; E:OPINVALREQ;

IA: IPINNOTOK ? OBADPINREPLY NS: IPINOK > SBTRANS; IPINRETRYOK > SGETPIN; TRUE > SBYEBYE; } ICARDPRESENT IPINPRESENT ICTIMEOUT IPINRETRYOK IPINOK TRUE SCHKPIN SGETPIN SIDLE SBTRANS SBYEBYE

Figura 2.38 Ejemplo de especificación de una VFSM y diagrama de transición de estados

Los autores de VFSM han realizado estudios comparativos de su método con otras técnicas de especificación. El más exhaustivo, por el número de métodos cubiertos, es [Ard96]. En [Flo97] afirman que en comparación con SDL y los statecharts de Harel, que se usan más según ellos en la definición de la arquitectura del sistema, VFSM se usa en el diseño de bajo nivel. La otra diferencia que ponen de relieve es la capacidad expresiva de SDL y los statecharts es mucho mayor que la de las VFSM y eso tiene el peligro, según ellos, de que pueden usarse incorrectamente como un lenguaje de programación, que mezcla el diseño con la implementación y que no puede validarse ni simularse fácilmente. VFSM, en cambio, es mucho más simple y obliga a hacer una especificación menos detallada que es más fácil de entender. Pero al mismo tiempo, afirman que han podido capturar la mayoría de las aplicaciones que han encontrado.

2.4.4.2 Análisis estructurado: método de Ward y Mellor

Es una variante al análisis estructurado de De Marco, que incluye también elementos de control, y que se ha quedado ya un tanto obsoleto. Los diagramas de este método, llamados esquemas de transformación contienen nodos de datos y nodos de control. Los nodos están unidos por flechas que expresan flujo de datos en el caso de ser flechas continuas y flujo de control en el caso de las flechas discontinuas. El diagrama principal es el diagrama de contexto, que muestra las interacciones del sistema con su entorno. Los nodos (también llamados transformaciones) de control contienen una máquina de estados.

Puesto que este método usa los diagramas de estados convencionales, no tiene las ventajas adicionales que proporciona la notación de los statecharts, especialmente las jerarquías de estados, concurrencia o estados historia. Tampoco existen mecanismos para manejar componentes similares dentro de un

2.4.4.3 Structured Description Language (SDL)

SDL es un lenguaje de especificación de comportamiento para sistemas de tiempo real definido por la ITU [SDL95] y que goza de gran aceptación en el ámbito de los sistemas de telecomunicación Se puede aplicar en varias fases del ciclo de vida: especificación de requisitos, diseño detallado del sistema y descripción de casos de prueba. El comportamiento del sistema se modela con un conjunto de máquinas de estados finitos conectadas entre sí. Estas máquinas de estados tienen estados,

entradas, salidas y transiciones. Un estado en SDL no puede englobar dentro de él otros estados. Tiene una notación textual y otra notación gráfica. En SDL, el elemento básico de un modelo es el

proceso. Un proceso es una máquina de estados que a su vez puede comunicarse con otros procesos. Se pueden hacer los modelos en SDL más compactos y fáciles de entender usando paquetes como los de UML y otros mecanismos parecidos.

A continuación se muestra un ejemplo tomado de [SDL95] de la especificación de un sencillo proceso, en forma textual y en forma gráfica, que controla un juego y que puede arrancar el juego, terminarlo, guardar los puntos y comunicárselos a los usuarios.

SUBSCR JUEGOID a JUGADOR CONTADOR:=0 comienza ___ ___ CONTADOR:=

CONTADOR + A (CONTADOR) aPUNTOS

JUGADOR ACABA_JUEGO FINJUEGO RESULTADO PRUEBARES (A) service Controla_Juego;

/*Contador que guarda los puntos*/

dcl CONTADOR Integer,

A Integer; /* incremento contador */

start;

output SUBSCR;

output JUEGOID to JUGADOR;

task CONTADOR:=0;

nextstate comienza;

state comienza;

priority input PRUEBA_RESULTADO(A);

task CONTADOR:=CONTADOR+A;

nextstate -;

input RESULTADO;

output PUNTOS(CONTADOR) to JUGADOR;

nextstate -; input FINJUEGO; output ACABA_JUEGO; stop; endstate comienza; endservice Controla_Juego;

Figura 2.39 Ejemplo de un diagrama de proceso en SDL

El propio Harel en [HaPo98] admite que el poder expresivo de SDL y los statecharts es muy parecido. Ambos métodos pueden aplicarse en diseño estructurado y en diseño orientado a objetos.

[Ek95] comenta que el punto fuerte de los métodos de diseño orientado a objetos es su carácter intuitivo que facilita enormemente la fase inicial de análisis de un sistema. SDL, sin embargo, define un sistema con tanto detalle, que es muy fácil generar los casos de prueba del sistema a partir de los modelos SDL. Unos casos de prueba además, que son automatizables. La herramienta Tau Tester, de la casa Telelogic [Tel02], ofrece la posibilidad de convertir statecharts en SDL y viceversa, y, a partir de la especificación en SDL, generar casos de prueba de acuerdo a la notación TTCN (Tree and Tabular Combined Notation), estándar ISO 9646-3 o ITU X.292 [ITU92].