UML - Diagramas de estados

[ Home > Apuntes Tácticos > UML ]


Mapa General

UML

Resumen

Los diagramas de estados son una técnica conocida para describir el comportamiento de un sistema. Describen todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que llegan a él. En la mayor parte de las técnicas OO, los diagramas de estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida.


Arriba

Índice de Contenidos


Introducción

Los diagramas de estados son una técnica conocida para describir el comportamiento de un sistema. Describen todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que llegan a él. En la mayor parte de las técnicas OO, los diagramas de estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida.

Existen muchas formas de diagramas de estados, cada una con semántica ligeramente diferente. La más popular que se emplea en las técnicas de OO se basa en la tabla de estados de David Harel (Vol. 8). OMT fue quien la usó por primera vez para los métodos de OO y fue adoptada por Grady Booch en su segunda edición (1994).

La Figura 8-1 muestra un diagrama de estados de UML para un pedido del sistema de proceso de pedidos que presenté antes. El diagrama indica los diversos estados de un pedido.

Comenzamos en el punto de partida y mostramos una transición inicial al estado de Comprobación. Esta transición está etiquetada como "/obtener el primer artículo". La sintaxis de una etiqueta de transición tiene tres partes, las cuales son optativas: Evento {Guard Guardia} / Acción. En este caso, sólo tenemos la acción "obtiene primer artículo." Una vez realizada tal acción, entramos al estado de Comprobación. Este estado tiene una actividad asociada con él, la cual se indica mediante una etiqueta con la sintaxis hace/actividad. En este caso, la actividad se llama" comprueba artículo".

Figura 08-01(10K)

Figura 8-1:Diagrama de estados

Nótese que utilizo los términos "acción" para indicar la transición, y "actividad" para indicar el estado. Aunque ambos son procesos, implementados característicamente mediante algún método sobre Pedido, se tratan de manera diferente. Las acciones se asocian con las transiciones y se consideran como procesos que suceden con rapidez y no se pueden interrumpir. Las actividades se asocian con los estados y pueden tardar más. Una actividad puede ser interrumpida por algún evento.

Adviértase que la definición de "rápidamente" depende del tipo de sistema que se está produciendo. En un sistema de tiempo real, "Rápidamente" puede significar unas pocas instrucciones de código máquina; en los sistemas de información normales, "rápidamente" puede significar menos de unos cuantos segundos.

Cuando una transición no tiene evento alguno en su etiqueta, significa que la transición se da tan pronto como se completa cualquier actividad asociada con el estado dado. En este caso, ello significa tan pronto se termine la Comprobación. Del estado Comprobación se derivan tres transiciones. Las tres sólo tienen guardias en su etiqueta. Un guardia es una condición lógica que sólo devuelve "verdadero" o "falso." Una transición de guardia ocurre sólo si el guardia se resuelve como "verdadero".

Sólo se puede tomar una transición de un estado dado, por lo que tratamos de que los guardias sean mutuamente excluyentes para cualquier evento. En la Figura 8-1 abarcamos tres condiciones:

  1. Si no hemos comprobado todos los artículos, tomamos el siguiente artículo y regresamos al estado de Comprobación para comprobado.

  2. Si hemos comprobado todos los artículos y todos están en existencia, hacemos la transición al estado de Despachando.

  3. Si hemos comprobado todos los artículos pero no todos están en existencia, hacemos la transición al estado Espera.

Veamos, en primer lugar, el estado Espera. Como no hay actividades para este estado, el pedido se detiene en él esperando un evento. Ambas transiciones del estado Espera se etiquetan con el evento Artículo recibido. Esto significa que el pedido espera hasta que detecta este evento. Llegado ese momento, evalúa los guardias de las transiciones y hace la transición apropiada (ya sea a Despachando o de vuelta a Espera).

Dentro del estado Despachando, tenemos actividad que inicia una entrega. También hay una transición simple no guardada, disparada por el evento Entregado. Esto indica que la transición ocurrirá siempre que tenga lugar el evento. Sin embargo, nótese que la transición no sucede cuando termina la actividad; por el contrario, una vez terminada la actividad "iniciar entrega", el pedido se mantiene en el estado Despachando, hasta que ocurre el evento Entregado.

La última cuestión a considerar es la transición denominada" cancelado". Queremos tener la posibilidad de cancelar un pedido en cualquier momento, antes de que sea entregado. Podríamos hacerlo dibujando transiciones separadas desde cada uno de los estados, Comprobación, Espera y Despacho. Una alternativa útil es crear un superestado con los tres estados, y después dibujar una transición simple, a partir de él. Los subestados simplemente heredan todas las transiciones sobre el superestado.

Las Figura 8-2 y 8-3 muestran cómo estos enfoques reflejan el mismo comportamiento del sistema. La Figura 8-2 aparece más bien cargada, a pesar de que sólo tiene tres transiciones duplicadas. La Figura 8-3, en cambio, da un cuadro más claro y, si se necesitan posteriormente los cambios, será más difícil olvidar el evento cancelado.

Figura 08-02(12K)

Figura 8-2: Diagrama de estados sin superestados

En los ejemplos actuales, he mostrado una actividad dentro de un estado, indicándola con texto en la forma de hace/actividad. También se pueden indicar otras cosas en un estado.

Si un estado responde a un evento con una acción que no produzca una transición, dicha condición se puede mostrar poniendo un texto de la forma nombreEvento/nombreAcción en el cuadro de estado.

Figura 08-03(13K)

Figura 8-3: Diagrama de estados con superestados

Existen también dos eventos especiales, entrada y salida. Cualquier acción que esté marcada como vinculada al evento entrada se ejecuta siempre que se entre al estado dado a través de una transición. La acción asociada con el evento salida se ejecuta siempre que se sale del estado por medio de una transición. Si se tiene una transición que vuelve al mismo estado (a esto se le llama autotransición ) por medio de una acción, se ejecuta primero la acción de salida, luego la acción de transición y, por último, la acción de entrada. Si el estado tiene también una actividad asociada, ésta se ejecuta tras la acción de entrada.


Arriba

Diagramas de estados concurrentes

Además de los estados de un pedido que se basan en la disponibilidad de los artículos, también existen estados que se basan en la autorización de pagos. Si vemos estos estados, podríamos ver un diagrama de estados como el de la figura 8-4.

Figura 08-04(5K)

Figura 8-4: Autorización de pagos

Aquí comenzamos efectuando una autorización. La actividad de "comprobación de pago" termina señalando que el pago fue aprobado. Si el pago está bien, el pedido espera en el estado Autorizado hasta que sucede el evento de "entrega". De otro modo, el pedido entra al estado de Rechazado.

El objeto Orden presenta una combinación de los comportamientos que se muestran en las Figura 8-1 y 8-2. Los estados asociados y el estado Cancelado mencionados anteriormente pueden combinarse en un diagrama de estados concurrentes

(Véase la Figura 8-5).

Nótese que en la figura 8-5 he dejado fuera los detalles de los estados internos.

Las secciones concurrentes del diagrama de estados son lugares en los que, en cualquier punto, el pedido está en dos estados diferentes, uno por cada diagrama. Cuando el pedido deja los estados concurrentes, se encuentra en un solo estado. Se puede ver que un pedido se inicia tanto en el estado Comprobando como en el estado Autorizando. Si la actividad de "comprobación de pago" del estado Autorizando se completa inicialmente de modo exitoso, entonces el pedido estará en los estados Comprobando y Autorizado. Si sucede el evento" cancelar", entonces el pedido sólo estará en el estado Cancelado.

Figura 08-05(7K)

Figura 8-5:Diagrama de estados concurrentes

Los diagramas de estados concurrentes son útiles cuando un objeto dado tiene conjuntos de comportamientos independientes. Nótese, sin embargo, que no se debe permitir que sucedan demasiados conjuntos de comportamientos concurrentes en un solo objeto. Si se tienen varios diagramas de estados concurrentes complicados para un solo objeto, se deberá considerar la división del objeto en varios.


Arriba

Cuándo utilizar los diagramas de estados

Los diagramas de estados son buenos para describir el comportamiento de un objeto a través de varios casos de uso. No son tan buenos para describir un comportamiento que involucra cierto número de objetos que colaboran entre ellos. Así pues, es útil combinar los diagramas de estados con otras técnicas. Por ejemplo, los diagramas de interacción (véase el capítulo 6) son buenos para la descripción del comportamiento de varios objetos en un mismo caso de uso. Por su parte, los diagramas de actividades (véase el capítulo 9) son buenos para mostrar la secuencia general de las acciones de varios objetos y casos de uso.

Hay quienes consideran que los diagramas de estado son naturales, pero muchos no los consideran así. Preste atención al modo en que los emplean quienes trabajan con ellos; podría ocurrir que su equipo no considere útiles los diagramas de estados, debido a su modo de trabajar. Esto no sería un gran problema; como siempre, deben combinarse las técnicas que sean de utilidad.

Si decide utilizar diagramas de estados, no trate de dibujar uno por cada clase del sistema. Aunque éste es el enfoque que emplean los detallistas ceremoniosos, casi siempre es un esfuerzo inútil. Utilice los diagramas de estados sólo para aquellas clases que presenten un comportamiento interesante, cuando la construcción de tales diagramas le ayude a comprender lo que sucede. Muchos consideran que los objetos de interfaz de usuario (IU) y de control tienen el tipo de comportamiento que es útil describir mediante diagramas de estados.


Arriba

Para mayor información

Tanto Grady Booch (1994) como Jim Rumbaugh (1991) tienen material sobre los diagramas de estados, aunque no contiene mucha mayor información de la que hemos mencionado en este capítulo. Cook y Daniels (1994) son quienes han abordado con mayor detalle los diagramas de estados; yo recomiendo ampliamente su libro, si usted emplea con frecuencia los diagramas de estados. La semántica que definen es mucho más detallada que la de cualquier otro libro. Aunque tal semántica no corresponda enteramente con la del UML, los autores tratan de forma exhaustiva cuestiones que usted debe tener en cuenta, si va usar diagramas de estados.


Arriba

Índice


Arriba

Referencia Bibliográfica

Fowler, Martín
UML, gota a gota
Addison Wesley Longman de México,SA de CV
México 1.999
ISBN: 968-44-364-1
Formato 17x23
Paginas 224


Atrás arriba Adelante

© 2.003 - La Güeb de Joaquín - Apuntes Tácticos - UML
[Arriba] [Home] [Apuntes] [UML] [Correo]
La documentación es como el sexo: cuando es bueno, es muy,
muy bueno; y cuando es malo, es mejor que nada.
Fecha de la última actualización.:  17 / Septiembre / 2003
Esta página es española