lunes, 20 de enero de 2014

Diagramas de estados - Parte 3 de 3





Estados históricos

Cuando se activa su protector de pantallas y mueve su ratón para regresar al estado Operación ¿qué ocurre? ¿Acaso su pantalla retoma el estado inicial, como si apenas se hubiera encendido? ¿O lucirá tal como la dejó antes de que se activara el protector de pantallas? 

Es obvio, si el protector de pantallas provocara que la pantalla regresara a su estado inicial de operación, la idea del protector de pantallas sería contraproducente. Los usuarios podrían perder su trabajo y tendrían que reiniciar una sesión nuevamente. 

El diagrama de estados históricos captura esta idea. El UML proporciona un símbolo que muestra que un estado compuesto recuerda su subestado activo cuando el objeto trasciende fuera del estado compuesto. El símbolo es la letra “H” encerrada en un círculo que se conecta por una línea continua al subestado por recordar, con una punta de flecha que apunta a tal subestado. La siguiente figura  muestra este símbolo en el estado Operación.

El estado histórico, simbolizado con la “H" dentro del círculo, le muestra que un estado compuesto recuerda su subestado activo cuando el objeto trasciende fuera de tal estado compuesto.

En el diagrama de estados no he tratado con las ventanas que están abiertas por otras ventanas (es decir, con subestados anidados en otros). Cuando un estado histórico recuerda los subestados en todos los niveles de anidación (como el estado Operación de Windows lo hace), el estado histórico es profundo. Si sólo recuerda el subestado principal, el estado histórico será superficial. Un estado histórico profundo representa agregando un asterisco (*) a la “H” en el círculo (H*).

El estado histórico y el estado inicial (representados por el círculo relleno) son conocidos como pseudoestados.
No tienen variables de estados ni actividades, por lo que no son estados completos".


Mensajes y señales

En el ejemplo, el suceso desencadenado que provocó la transición de Protector de pantalla a Operación es la opresión de una tecla, un movimiento del ratón o una opresión de uno de sus botones. Cualquiera de estos sucesos es, en efecto, un mensaje del usuario a la GUI. Esto es un concepto importante dado que los objetos se comunican mediante el envío de mensajes entre sí. En este caso, el suceso desencadenado es un mensaje de un objeto (el usuario) a otro (la GUI).

Un mensaje que desencadena una transición en el diagrama de estados del objeto receptor se conoce como señal. En el mundo de la orientación a objetos, el envío de una señal es lo mismo que crear un objeto Señal y transmitirlo al objeto receptor. El objeto Señal cuenta con propiedades que se representan como atributos.
Dado que una señal es un objeto, es posible crear jerarquías de herencia de señales.


Por qué son importantes los diagramas de estados

El diagrama de estados del UML proporciona una gran variedad de símbolos y abarca varias ideas (todas para modelar los cambios por los que pasa un objeto). Este tipo de diagrama tiene el potencial de convertirse en algo complejo con pasmosa rapidez. ¿En verdad es necesario‘?

De hecho, así es. Es necesario contar con diagramas de estados dado que permiten a los analistas, diseñadores y desarrolladores comprender el comportamiento de los objetos de un sistema. Un diagrama de clases y el diagrama de objetos correspondiente sólo muestra los aspectos estáticos de un sistema. Muestran las jerarquías y asociaciones, y le indican qué son las operaciones. Pero no le muestran los detalles dinámicos de las operaciones. 

Los desarrolladores, en particular, deben saber la forma en que los objetos se supone que se comportarán, ya que son ellos quienes tendrán que establecer tales comportamientos en el software. No es suficiente con implementar un objeto: los desarrolladores deben hacer que tal objeto haga algo. Los diagramas de estados se aseguran que no tendrán que adivinar lo que se supone que harán los objetos. Con una clara representación del comportamiento del objeto, aumenta la probabilidad de que el equipo de desarrollo produzca un sistema que cumpla con los requerimientos.


Adiciones al panorama

Ahora puede agregar los “Elementos de comportamiento” al panorama del UML. La siguiente figura le muestra la imagen con el diagrama de estados incluido.

El panorama del UML ahora incluye un elemento de comportamiento: eldiagrama de estados. La organización del UML, en ténninos de los elementos que ha utilizado hasta ahora.


Resumen

Los objetos en los sistemas modifican sus estados como respuestas a sucesos y al tiempo.
El diagrama de estados de UML captura estos cambios de estado. Un diagrama de estados se enfoca en los cambios de estado en un solo objeto. Un rectángulo de vértices redondeados representa a un estado, y una linea continua con una punta de flecha representa una transición de un estado a otro.

El símbolo del estado contiene el nombre del mismo y puede tener variables y actividades del estado. Una transición puede suceder como respuesta a un suceso desencadenado, e implicar una respuesta o acción. Una transición también puede ocurrir por la actividad en un estado: una transición que ocurre de esta fonna se conoce como transición no desencadenada. Finalmente, una transición puede ocurrir cuando se cumple una condición particular, o condición de seguridad.

En ocasiones, un estado consta de subestados. Los subestados pueden ser secuenciales (ocurrir uno después del otro) o concurrentes (ocurrir al mismo tiempo). Un estado que consta de subestados se conoce como estado compuesto. Un estado histórico indica que un estado compuesto recordará su subestado cuando el objeto trascienda de este estado compuesto. Un estado histórico puede ser superficial o profundo. Tales términos son propios de los subestados anidados. Un estado histórico superficial recuerda sólo el subestado principal. Un estado histórico profundo recuerda todos los niveles de los subestados. 

Cuando un objeto envía un mensaje que desencadena una transición en el diagrama de estados de otro objeto, tal mensaje es una señal. Una señal es, por sí misma, un objeto, y podrá crear una jerarquía de herencia de las señales.

Es necesario contar con los diagramas de estados porque facilitan la comprensión de los objetos de un sistema a los analistas, diseñadores y desarrolladores. Los desarrolladores, en particular, deben saber cómo se supone que se comportarán los objetos, dado que serán quienes tengan que establecer estos comportamientos en el software. No es suficiente implementar un objeto: los desarrolladores tienen que hacer que tal objeto haga algo.


Preguntas y respuestas

P: ¿Cuál es la mejor manera de empezar a crear un diagrama de estados?

R: Es muy parecido a crear un diagrama de clases o un modelo de caso de uso. En el diagrama de clases, listará todas las clases y luego realizará las asociaciones entre ellas. En el diagrama de estados, primero listará los estados del objeto, y luego se enfocará en las transiciones. Conforme avance en cada transición, deberá prever si un suceso desencadenado lo activará y si se realizará alguna acción.

P: ¿Cada diagrama de estados debe tener un estado final (el que se representa por la diana)?

R: No. Un objeto que nunca queda inactivo jamás tendrá un estado final.

P: ¿Alguna sugerencia para diseñar un diagrama de estados?

R: Intente arreglar los estados y transiciones para minimizar el cruzamiento de líneas. Uno de los objetivos de este diagrama (y de cualquier otro) se centra en la claridad. Si las personas no pueden comprender los modelos que cree, nadie los usará y sus esfuerzos (no importa qué tan minuciosos hayan sido) habrán sido infructuosos.


Taller

El cuestionario y los ejercicios le harán trascender al estado “Aprendizaje de diagramas de estados”. Como siempre, encontrará las respuestas en el Apéndice A. "Respuestas a los cuestionarios".

Cuestionarios

l. ¿De qué forma difiere un diagrama de estados de uno de clases, de objetos o de caso de uso?
2. Defina los siguientes términos: transición. suceso y acción.
3. ¿Qué es una transición no desencadenada?
4. ¿Cuál es la diferencia entre los subestados secuenciales y los concurrentes?

Ejercicios

1. Suponga que diseñará un tostador. Cree el diagrama de estados que controle los estados del pan en el tostador. Incluya los sucesos desencadenados. acciones y condiciones de seguridad necesarios.
2 Cada vez que un objeto envíe una señal, se creará un objeto Señal y será transmitido. En Windows, hay varias señales posibles a partir de la GUI. Suponga que la señal (el tipo de señal que envíe a Windows) sea una clase. (¿Qué tipo de Clase es Cree un diagrama de clases de las posibles señales y muestre toda la herencia inherente.
3 La siguiente figura le muestra los subestados concurrentes dentro del estado Operación de la GUI. Dibuje un diagrama del estado Protector de pantalla que incluya los subestados concurrentes.



Espero haber ayudado en algo. Hasta la próxima oportunidad!





2 comentarios:

  1. hola quiciera saber si sabes como se resuelve el 2do ejercicio gracias

    ResponderEliminar
    Respuestas
    1. Hola Anónimo, gracias por la visita y el aporte de tu comentario!!
      Los ejercicios no han sido resueltos por mi persona, no obstante han sido compartidos para que los interesados puedan resolverlos.

      Los mejores deseos!! Hasta cualquier momento!

      Eliminar

       
free counters

Páginas vistas en total según Google