Diagrama de estado UML: vi­sua­li­zar se­cue­n­cias de estados de objetos

Al de­sa­rro­llar un producto o programa in­fo­r­má­ti­co, los diagramas de estado UML pueden ayudar a vi­sua­li­zar el ciclo de vida de cada objeto de forma clara y co­m­pre­n­si­ble. Aunque este diagrama solo consta de unos pocos elementos, si se utiliza co­rre­c­ta­me­n­te, puede co­n­tri­buir no­ta­ble­me­n­te al resultado final. En los si­guie­n­tes apartados, te ex­pli­ca­mos por qué y en qué casos vale la pena elaborar un diagrama de estado UML y cómo hacerlo.

Un diagrama de estado UML (también llamado diagrama de estado, diagrama de tra­n­si­ción de estados o diagrama de máquina de estados) muestra los estados por los que pasa una máquina de estados finitos, es decir, un modelo de co­m­po­r­ta­mie­n­to que consiste en acciones y estados o tra­n­si­cio­nes a otros estados. El diagrama pro­po­r­cio­na un estado inicial y uno final, así como al menos un estado in­te­r­me­dio para cada objeto. El diagrama de estado permite, de este modo, re­pre­se­n­tar el ciclo de vida completo de cualquier sistema, su­b­si­s­te­ma o co­m­po­ne­n­tes o clases del mismo, como podrían ser una máquina de café, un lector de libros ele­c­tró­ni­cos o un co­m­po­ne­n­te te­c­no­ló­gi­co de un vehículo.

El diagrama de estado es uno de los 14 tipos de diagrama definidos en el lenguaje de modelado unificado (UML), o Unified Modeling Language, y en el lenguaje de modelo de sistemas (SysML, del inglés Systems Model Language). Se remonta a un concepto propuesto por David Harel en 1987 en su artículo Sta­te­cha­rts: A Visual Formalism for Complex Systems. Otros tipos de diagramas UML son, por ejemplo, el diagrama de casos de uso o el diagrama de co­m­po­ne­n­tes.

Como ya hemos me­n­cio­na­do, el objetivo de los diagramas de estado es describir el co­m­po­r­ta­mie­n­to de un sistema con la máxima precisión. Entre otras cosas, esta re­pre­se­n­ta­ción gráfica de los procesos debería dar respuesta a las si­guie­n­tes preguntas:

• ¿Qué sucede cuando el objeto está en un estado concreto?
• ¿En qué estado debe estar el objeto para cambiar de co­m­po­r­ta­mie­n­to?
• ¿Cuáles son los des­en­ca­de­na­n­tes?
• ¿Qué pro­pie­da­des debe tener el objeto para poder cambiar de estado?

Por lo tanto, los diagramas de estado UML se utilizan para optimizar cualquier proceso de de­sa­rro­llo donde sea útil vi­sua­li­zar los estados del objeto y las co­n­di­cio­nes para que se produzca la tra­n­si­ción de un estado a otro. Suelen emplearse, por ejemplo, en el diseño de sistemas embebidos (en inglés, embedded systems), donde las señales au­to­ma­ti­za­das y los procesos en segundo plano deben estar pe­r­fe­c­ta­me­n­te coor­di­na­dos. En este caso, el diagrama de estado ayuda a los de­sa­rro­lla­do­res a vi­sua­li­zar todas las funciones de control y re­gu­la­ción más im­po­r­ta­n­tes en un solo esquema.

La función de in­te­rru­p­ción de la toma de agua que tienen casi todas las lavadoras puede servirnos de ejemplo para imaginar un diagrama de estado UML. En este contexto, esta función se re­pre­se­n­ta­ría como un sistema in­de­pe­n­die­n­te. En este caso, el esquema mostraría en qué estado y bajo qué co­n­di­cio­nes se activa la función.

Aunque los diagramas de estado UML se basan solo en unos pocos elementos, co­m­bi­nar­los de manera in­te­li­ge­n­te nos permite re­pre­se­n­tar fá­ci­l­me­n­te se­cue­n­cias de estado complejas. ¿Cuáles son los co­m­po­ne­n­tes pri­n­ci­pa­les y cuál es la es­tru­c­tu­ra básica de un diagrama de estado?

Asimismo, en el diagrama de estado de la puerta se indicaría que siempre debe cumplirse la siguiente condición:

• El objeto siempre se encuentra en uno de los dos estados: la puerta está abierta o cerrada, pero nunca abierta y cerrada al mismo tiempo.

En los diagramas de estado más complejos, el re­c­tá­n­gu­lo puede dividirse en hasta tres zonas donde se muestran es­pe­ci­fi­ca­cio­nes de co­m­po­r­ta­mie­n­to (ver tra­n­si­ción).

Para pasar de un estado al siguiente, se debe des­en­ca­de­nar un evento que provoque una tra­n­si­ción. Esta tra­n­si­ción de estado comunica los estados entre sí y se re­pre­se­n­ta mediante una flecha. Puede haber co­n­di­cio­nes para que se des­en­ca­de­ne dicha tra­n­si­ción. En términos generales, los diagramas de estado UML re­pre­se­n­tan tra­n­si­cio­nes internas y externas. Un diagrama de estado siempre debe presentar alguna tra­n­si­ción externa, pero no es obli­ga­to­rio que incluya tra­n­si­cio­nes internas.

En el diagrama de estado de un ascensor, por ejemplo, se podría es­pe­ci­fi­car la siguiente condición para la acción “cerrar la puerta del ascensor”: que el ascensor haya estado abierto al menos cinco segundos antes de que el estado cambie de “abierto” a “cerrado”.

Una tra­n­si­ción interna no des­en­ca­de­na un cambio de estado, sino una actividad.

Ejemplo: algunos sistemas de co­n­ta­bi­li­dad vuelven a enviar las facturas sin pagar au­to­má­ti­ca­me­n­te al cliente (tra­n­si­ción externa). Si lo que envían es un re­co­r­da­to­rio de que la factura está pendiente de abonar, este re­pre­se­n­ta una tra­n­si­ción interna: es decir, aunque hay una actividad (“enviar el re­co­r­da­to­rio”), la factura permanece en el mismo estado (“no pagada”) hasta nuevo aviso.

En los diagramas de estado UML, si algún elemento de control influye en el fu­n­cio­na­mie­n­to de una máquina de estados, pero no tiene asignado ningún valor, se denomina pseu­doe­s­ta­do. En UML 2, la versión actual del lenguaje de modelado unificado, se definen los si­guie­n­tes diez pseu­doe­s­ta­dos:

• Estado inicial (en inglés, initial): sin tra­n­si­ción entrante y con una tra­n­si­ción saliente que revela cuál es el estado al principio de la secuencia.
• Estado final (en inglés, final): sin tra­n­si­ción saliente; fin de la secuencia de co­m­po­r­ta­mie­n­to.
• Bi­fu­r­ca­ción (en inglés, fork): división en varios estados paralelos.
• Si­n­cro­ni­za­ción (en inglés, join): si­n­cro­ni­za­ción de varios estados paralelos.
• Unión (en inglés, junction): nodo de unión de varias tra­n­si­cio­nes en serie.
• Elección (en inglés, choice): nodo desde el cual pueden iniciarse diversas tra­n­si­cio­nes sobre la base de una decisión previa.
• Punto de entrada (en inglés, entry point): síntesis de tra­n­si­cio­nes similares que entran en un estado compuesto.
• Punto de salida (en inglés, exit point): síntesis de tra­n­si­cio­nes similares que se originan en un estado compuesto.
• Historial su­pe­r­fi­cial (en inglés, shallow history): al­ma­ce­na­mie­n­to del último subestado activo de un estado compuesto.
• Historial profundo (en inglés, deep history): al­ma­ce­na­mie­n­to del último subestado activo de todos los niveles je­rá­r­qui­cos de un estado compuesto.

De­pe­n­die­n­do de la co­m­ple­ji­dad del proceso, es posible incluir su­be­s­ta­dos en el esquema que muestran una imagen detallada de cada estado del objeto y de su posible co­m­po­r­ta­mie­n­to. Esta versión más compleja de los diagramas de estado UML suele ser la más habitual, es­pe­cia­l­me­n­te en el ámbito técnico.

• Estado compuesto: esta es­tru­c­tu­ra permite definir un estado en pro­fu­n­di­dad.

Ejemplo: una puerta puede estar en dos estados: “abierta” o “cerrada”. Los su­be­s­ta­dos del estado “cerrada” podrían ser “bloqueada” y “de­s­blo­quea­da”.

• Estado de su­b­má­qui­na: el estado incluye un diagrama de estado su­bo­r­di­na­do. Un subestado que consista en varios su­be­s­ta­dos se denomina un estado complejo. Los diversos su­be­s­ta­dos pueden tanto eje­cu­tar­se in­de­pe­n­die­n­te­me­n­te el uno del otro como estar re­la­cio­na­dos entre sí.

Ejemplo: la función de de­s­pe­r­ta­dor de un sma­r­t­pho­ne es una de las muchas funciones que puede estar re­la­cio­na­da con otros estados. Si se programan distintas alarmas para di­fe­re­n­tes horas y días de la semana, el proceso completo co­n­si­s­ti­rá en su­be­s­ta­dos que se ejecutan de forma in­de­pe­n­die­n­te.

En el punto de partida, la factura se encuentra en el pseu­doe­s­ta­do “escrita” (written). En el mejor de los casos, se producirá la tra­n­si­ción hacia el estado “pagada” (paid). Esta tra­n­si­ción podría de­s­cri­bi­r­se con más detalle indicando el evento “enviar”.

Una vez que se ha pagado, la factura se encuentra en el estado “pagada”. Antes de llegar a este estado, puede ser necesario enviar un “re­co­r­da­to­rio” (reminder). En este caso, como la factura no cambia de estado, aunque se ocasione una actividad, se trata de una tra­n­si­ción interna. Si no se paga la factura, se enviarán hasta tres re­co­r­da­to­rios.