2.4 Modelos de prueba
2.4.2 Statecharts o Diagramas de Estados Jerárquicos
Una mejora de las máquinas de estados finitos convencionales son los statecharts. Fueron introducidos por Harel [Har87] y su uso se ha extendido mucho en el análisis y diseño de software: están soportados por multitud de herramientas y forman parte del estándar UML. Los statecharts son apropiados para especificar el comportamiento de sistemas reactivos, sistemas que se encuentran siempre en un estado y cuyo número de estados posibles es finito. Cuando sucede un evento, el sistema reacciona realizando unas determinadas acciones y/o cambiando de un estado a otro.
B P A H C init [else] E/X N>0 W D
Figura 2.16 Statechart ejemplo
La Figura 2.16 muestra un statechart sencillo. Los estados son los rectángulos de bordes redondeados y están identificados por su nombre. Las flechas que unen los estados son las transiciones. El estado inicial por defecto aparece marcado con una flecha con un círculo al principio. E/X es un par
evento/acción. Esto significa que, en el estado A, cuando se produce el evento E, inmediatamente se ejecuta X y se cambia al estado B. La C rodeada por un círculo simboliza una condición: si N>0, el sistema cambia de B a H, y si no, cambia de B a P. Análogamente, existen los conectores de “switch”, que se representan con una S rodeada por un círculo, que sirven para hacer lo mismo con eventos en vez de con condiciones.
Activo Confirmado Esperando_ACK Visto NoVisto Activo Confirmado Esperando_ACK Visto NoVisto evVisto evAck
Figura 2.17 Anidamiento de estados
Otra propiedad importante de los statecharts es el anidamiento de estados. En la Figura 2.17 se ve que el estado Esperando_ACK incluye los subestados Visto y NoVisto (estado por defecto). El evento evAck provoca una transición desde el estado Visto al estado Confirmado, pero se ignora en el estado NoVisto. Si la flecha partiera del estado Esperando_ACK, el evento evAck provocaría la misma transición en ambos subestados. La ventaja de esta notación es que aumenta la claridad del modelo, pues se reduce el número de elementos que aparecen.
Un problema de los diagramas de estados convencionales es el de la explosión del número de estados posibles en cuanto el sistema se complica. Por ejemplo, si tenemos un semáforo al que añadimos un timbre y queremos usar para las dos cosas la misma máquina de estados, el número total de estados posibles es el producto de ambos. Para estos casos, los statecharts disponen de los estados AND, que descomponen la máquina de estados en varias máquinas independientes que funcionan paralelamente. La Figura 2.18 es más sencilla que la Figura 2.19, representando ambas lo mismo.
estado_2 estado_5 estado_4 estado_3 estado_0 estado_1 V W Z E X
Figura 2.18 Estados AND
estado_04 estado_03 estado_13 estado_14 estado_15 estado_05 E E E X X X Z Z W W V V
Figura 2.19 Diagrama equivalente sin usar estados AND
Otro elemento importante de los statecharts son los conectores históricos, que se representan con una H rodeada por un círculo. En la figura puede verse un ejemplo. Si se vuelve al estado on se pasa al último subestado visitado, y si no se hubiera visitado ningún subestado, se pasa a inactivo.
on inactivo activo off
H
arranca ON OFFFigura 2.20 Estados Historia
Otros elementos menos usados son las transiciones compuestas, que necesitan de la combinación de varios eventos para dispararse. En la Figura 2.21 el cambio del estado A2 puede estar disparado por el evento v o el evento k. También se ve un conector de unión de dos transiciones y una transición que se desdobla en dos del estado A a los subestados AND A1 y A2. La T es el símbolo de un estado
A A1 A2
T
init e f a v or k vFigura 2.21 Ejemplo de conectores y de estado terminal
Aparte de los elementos gráficos, en la notación de Harel hay elementos textuales, que se describen brevemente a continuación en la Tabla 2.6. Lo expuesto hasta ahora sirve para dar una idea de lo completo y detallado que es el lenguaje de los statecharts para modelar el comportamiento de un sistema.
Expresiones para eventos,
condiciones y datos Expresiones para nombrar (equivalentes a un Son abreviaturas para dar mayor claridad o para ocultar detalles todavía no define en C) definidos.
Acciones Básicas: alteran el valor de los elementos (eventos, condiciones y datos): mandar un evento, hacer que la condición se cumpla o no.
Condicionales o iterativas: iguales que en cualquier lenguaje de programación.
Expresiones relacionadas
con el tiempo Timeouts Acciones planificadas para un cierto momento
Reacciones estáticas Se llama así a las actividades de entrada y a las actividades de salida de un estado. En el diccionario de datos del modelo aparecen como asociadas al estado. Son tareas que se realizan siempre al entrar o salir del estado. A diferencia de las acciones, que son instantáneas (no pueden interrumpirse) las actividades tienen una cierta duración.
Tabla 2.6 El Lenguaje de Expresión Textual de los Modelos de Harel
2.4.2.1 La Semántica de los statecharts
Harel ha defendido siempre los modelos ejecutables, esto es, que tienen el suficiente nivel de detalle como para poder ser depurados con la ayuda de una herramienta (STATEMATE, Rhapsody, etc.). Véase [HaGe96], [HaGe97] o [HaPo98]. Ahora bien, esa ejecución del modelo necesita una cierta semántica. Por ejemplo, en un sistema real no hay nada instantáneo. Si ele sistema es monoprocesador tampoco hay una concurrencia pura en los estados AND. Hay que saber cómo entiende el sistema la información del statechart. En [HaPo98] y en [HaNa96] con más detalle, Harel expone su visión sobre esta cuestión, que coincide con la estrategia seguida por la herramienta STATEMATE.
[vdB94] recoge diferentes variantes de los statecharts que han aparecido en la literatura. Hay para todos los gustos, pero se pueden dividir entre los que, en función de sus necesidades, simplifican la notación de Harel, como [MLS97], donde se usan los statecharts en combinación con un entorno de verificación automática, [MLSH98] y [Scho97] y los que le añaden nuevos elementos que necesitan por las características del dominio donde aplican la técnica como [Sow98] y [PMF99]. Especialmente interesante es el trabajo de [BGK98], que ordena las transiciones y estados del statechart en función de como afecten a la seguridad del sistema. [Sel93] explica las simplificaciones que hace la metodología
ROOM a los statecharts, que son el origen de los ROOMcharts, para conseguir una ejecución más eficiente.
2.4.2.2 Jerarquías de statecharts
Si un statechart es muy complejo, es posible dividirlo en diferentes partes. Esto tiene las siguientes ventajas:
• Fácil comprensión
• Los usuarios pueden seleccionar las partes que sean relevantes para ellos y desentenderse del resto.
• Puede haber diferentes niveles de detalle.
• Cada parte puede tener su gestión de configuración por separado.
• Cada parte puede diseñarse con una estrategia de diseño propia, la que resulte más adecuada en cada caso (top-down, bottom-up, etc.).
• Modificaciones más fáciles.
La manera de dividir el statechart en varias hojas depende de cada caso. No es bueno tener muchas divisiones fuertemente relacionadas entre sí, porque ello haría perder visibilidad más que ganarla.
A A1
A2
A11 A12
A21 A22
Figura 2.22 Dividiendo un diagrama en hojas
Lógicamente, los flujos salientes y entrantes en cada hoja deben de ser consistentes con los de las hojas restantes. Además, la notación de Harel ofrece los elementos conectores que permiten enlazar statecharts: el conector hace referencia a la parte del statechart que no vemos. Los flujos compuestos pueden usarse también para simplificar la representación y sirven para conectar diagramas de actividad y de módulos. Dos diagramas comunes no pueden tener el mismo nombre. Esto sólo esta permitido para los diagramas genéricos, que se explican más adelante.
2.4.2.3 Statecharts Genéricos
Son componentes reutilizables que pueden tener varias instancias dentro del modelo. Las posibles diferencias entre las instancias, tanto en las interfaces externas como en la estructura interna se definen modificando los parámetros en el diagrama genérico. Puede haber diagramas genéricos de actividades, de módulos y de estados. La Figura 2.23 muestra un ejemplo sencillo de definición e
SENSOR
PROCESA_SEÑAL Diagrama de actividad PROCESA_SEÑAL
SEÑAL MUESTRA
PS1<PROCESA_
SEÑAL PS2<PROCESA_SEÑAL PS3<PROCESA_SEÑAL PS4<PROCESA_SEÑAL
SENSOR1 SENSOR2 SENSOR3 SENSOR4
SEÑAL1 SEÑAL2 SEÑAL3 SEÑAL4
COMPARAR
MUESTRAS
Figura 2.23 Diagrama genérico y sus instancias
ACTIVIDADES_XYZ (ac) CONTROL (sc) SISTEMA (mc) 4< PROCESAR_SEÑAL (ac) SET_UP (sc) ACTIVIDADES_QWE(ac) < PROCESAR_SEÑAL (ac) CALCULAR (ac)
Figura 2.24 Jerarquía de diagramas con charts genéricos
La “caja” de la instancia no puede contener otras “subcajas”, ni tampoco otra información de comportamiento que no sea la que hereda. En la Figura 2.24 puede verse cómo se representa un diagrama genérico en la jerarquía de diagramas del modelo.
Cada statechart genérico tiene un conjunto de parámetros formales. Estos son puertos (canales por los que la información fluye hacia dentro o hacia fuera del componente) o constantes (valores para caracterizar una determinada instancia). Cada parámetro formal se describe en el diccionario de datos. Los puertos pueden ser de cualquier tipo de datos o de estructura, también colas.
En el caso de los statecharts genéricos, los parámetros formales del tipo puerto, pueden ser actividades. Esto significa que las instancias de un statechart genérico pueden mandar señales de control a diferentes actividades o comprobar su estado.
En esta línea de buscar máquinas de estados generalizables están los trabajos de [KTW98] y [Wei97], que han desarrollado herramientas que extraen del código en C y C++ máquinas de estados que reemplazan por componentes genéricos, hechos conformes a un patrón de diseño que denomina “autómata de Harel genérico”.
2.4.2.4 Los statecharts en UML 2
La versión actual de UML [OMG03], la 2.0, ha introducido los siguientes cambios significativos en la notación de los statecharts:
• Las interfaces pueden tener asociado un statechart de protocolo, que se diferencia de los statecharts normales en que los estados no tienen actividades asociadas.
• Se introducen elementos nuevos en la notación, como los puntos de entrada, los puntos de salida y los terminadores. Los puntos de entrada y de salida se usan si tenemos diagramas de estados anidados dentro de otros diagramas, para mayor claridad (ver Figura 2.25). Los terminadores son una mejora respecto de lo que era el estado final o terminal, pues si se llega al terminador, significa que la entidad asociada al diagrama de estados (se le llama “clasificador” en terminología UML 2 y puede ser una clase, un objeto, etc.) deja de existir en el sistema.
A B
C D
A B
C D
Figura 2.25 Uso de punto de entrada para mayor claridad en el diagrama
• Existe una notación específica para representar statecharts genéricos, representados con una línea discontinua alrededor (ver la figura). Los statecharts derivados de un statechart genérico tienen todo lo que tiene el statechart “padre” y le pueden añadir nuevos estados, nuevas transiciones o nuevos estados “AND”. Si algún elemento del statechart “padre” está etiquetado con la palabra clave {final} no puede ser ni extendido ni reemplazado.
B (extended) C G D j h i A B CC d D a f {final} E e A B C G C G D f {final} E e d h i j a EXTENSION ORIGINAL RESULTADO