Como ya he mencionado en ediciones anteriores y se lo repetimos a nuestros alumnos constantemente, no todos los proyectos requieren utilizar todos los artefactos de UML. Uno de los artefactos que no veremos en todos los proyectos, es el diagrama de estados. Sin embargo, esto no le resta importancia. En proyectos donde el comportamiento del sistema depende en gran medida del estado en que se encuentran los objetos de negocio, los diagramas de estado son indispensables. Los diagramas de estado permiten visualizar los estados de un objeto —ya sea éste un documento, producto o persona—, los eventos ante los cuales reacciona y los efectos o acciones que realiza al cambiar de estado o mientras se encuentra en un estado.
Centrado en los Objetos
Lo que convierte a estos diagramas en algo especial y que lo liga con el paradigma de orientación a objetos, es que en lugar de centrarse en un proceso completo, mostrando los diversos objetos que colaboran, este diagrama se centra únicamente en lo que afecta a un objeto específico; por ejemplo el paquete, el adeudo, el semáforo o el préstamo.
Es decir, se desarrolla un diagrama de estados por cada objeto a analizar. Claro que no todos los objetos que identificamos merecen ser analizados tan a fondo como para crearles uno de estos diagramas. Recuerda que no queremos tener proyectos llenos de artefactos que no aportan valor, así que hay que ser muy selectivos.
Estados y sus Diferentes Tipos
Podemos ubicar los estados de un objeto de acuerdo a tres posibles situaciones:
a. Estado Determinado por los Atributos. La primera situación que determina el estado de un objeto se define por los datos que en ese momento están asociados al objeto analizado. En otras palabras, a los valores de uno o más de sus atributos. Por ejemplo, una persona que tenga edad de 8 años está en el estado “niñez”, si la edad es 14, está en “adolescencia”, y así respectivamente. Como se podrán imaginar, el atributo más simple que podría definir el estado de un objeto sería un atributo llamado “estado” o “estatus”.
b. Estado Determinado por las Acciones del Objeto. La segunda situación que determina el estado del objeto analizado son las acciones realizadas por el mismo en un momento determinado. Por ejemplo, un reproductor de MP3 cuando toca la música está en estado de “tocando”; un avión que va surcando los cielos está “volando”.
c. Estado Pasivo o En Espera. El estado más simple es aquel en el que el objeto analizado simplemente espera a que algo ocurra en el entorno para pasar a un nuevo estado. Ejemplificando nuevamente con el reproductor de MP3, está en “pausa” hasta que el usuario le indique que continúe reproduciendo la música o se detenga totalmente.
Cambios de Estados: Las Transiciones
No porque el objeto pueda tener ocho posibles estados significa que puede pasar a cualquiera de ellos en cualquier momento. Uno de los valores que ofrece este diagrama es precisamente que establece las reglas para que el objeto, estando en un estado determinado, pueda pasar a otro. Por ejemplo, si el semáforo está en verde no debe de poder pasar a rojo, sino únicamente a amarillo. Estos cambios y restricciones se muestran con una flecha, que es el símbolo para las transiciones entre estados.
¿Por Qué Cambia un Objeto?
Si queremos indicar la causa por la cual se puede dar una transición de un estado a otro, lo podemos indicar con un evento, con una condición o con ambos. Un evento es algo que ocurre en el ambiente que afecta el comportamiento del objeto analizado ocasionando que cambie a un nuevo estado. Si una computadora está apagada y se oprime el botón de “Encendido”, la computadora pasa a un estado de “Arrancando”. Pulsar el botón de encendido es el evento que ocasionó este cambio. La mayoría de las veces vamos a encontrar a estos elementos como verbos, pues es algo que ocurre y que afecta el comportamiento del objeto.
Un evento es una posible causa de que un objeto pase de un estado a otro, pero otra posible causa se debe al cumplimiento de una condición que afecta al objeto analizado. Puede ser el hecho de que los atributos del objeto analizado tomen cierto valor, o que haya pasado un lapso de tiempo. Ejemplo, si el monto acumulado en la máquina dispensadora es igual al precio del producto deseado, entonces pasa a un nuevo estado donde permite seleccionar el producto a despachar. La comparación del monto acumulado en un momento en la máquina, contra el precio del producto deseado puede considerarse como una condición de guardia. Estas condiciones se muestran entre corchetes como expresiones booleanas junto a las transiciones.
Hay Causas, pero También Consecuencias de los Cambios
Así como hay situaciones que provocan el cambio de estado de un objeto, también hay situaciones que se dan como resultado de un cambio de estado. A estos efectos se les llama acciones. Aunque tanto las acciones como los eventos se muestran como verbos, las acciones son consecuencia del cambio y los eventos son causas del cambio.
Todo tiene un Principio y un Final
Todo objeto tiene un principio, pues necesariamente debe de nacer en algún estado. Dicho estado se representa con un círculo relleno. Por otro lado, un objeto puede tener de cero a N estados finales, los cuales se representan por un círculo relleno, dentro de otro círculo hueco. El estado final es el último estado en el que queda un objeto antes de desaparecer, o cuando deja de tener más comportamiento. Los objetos que se mantienen siempre activos regresan una y otra vez a estados anteriores, por eso no tienen un estado final. En cambio hay objetos que pueden terminar su vida de diferentes maneras; en diferentes estados. El diagrama 2 representa los estados y transiciones de un préstamo. Procesar, aceptar, rechazar, depositar son eventos que ocasionan cambios de estado. [monto = adeudo] es una condición de guardia. Los primeros son verbos y el segundo es una expresión booleana.
Estos son algunos ejemplos de sistemas donde los diagramas de estado son de gran utilidad.
• Seguimiento a un pedido. Necesitamos saber si el pedido ya fue autorizado, si está en producción, si fue cancelado o en qué estado se encuentra dentro del proceso.
• Rastreo de paquetes. Para las empresas de mensajería es un requisito casi indispensable ofrecer a los clientes la posibilidad de rastrear sus paquetes a través de Internet. Y en realidad el sistema de rastreo para los clientes es sólo la punta del iceberg, pues una empresa de este tipo requiere una logística complicada alrededor de los paquetes que se envían. Razón mayor para utilizar diagramas de estados al desarrollar este tipo de sistemas.
• Flujos editoriales. Alguna vez participé en un sistema de monitoreo de un periódico, y los participantes en el flujo del negocio necesitaban saber con oportunidad el estado en que se encontraba cada una de las páginas del periódico, pues la impresión del mismo no podía retrasarse. Se desarrolló un diagrama de estados para la “Página del Periódico”.
• Productos y servicios financieros. Una solicitud de préstamo también sigue un flujo donde diferentes entidades realizan acciones relacionadas con el préstamo. Alguien tiene que validarlo, otro tiene que autorizarlo, otro más lo deposita, también podrían rechazarlo. Este tipo de flujos que giran alrededor del estado de un producto o servicio son excelentes candidatos para modelarse con diagramas de estados.
• Comportamiento de aparatos y dispositivos. Los dispositivos mecánicos y electrónicos son objetos cuyo comportamiento también es conveniente modelar. Un ejemplo sería una máquina dispensadora de golosinas. La máquina espera que alguien deposite una moneda para comenzar a funcionar. Cuando depositan una moneda la máquina cambia su comportamiento y entra a un estado donde espera que seleccione el usuario algún producto o que siga agregando monedas según sea el caso. Al seleccionar el producto lo entrega si lo depositado es suficiente para cubrir el precio, y regresa cambio si excede el precio; si no es suficiente, sigue esperando más monedas.
Conclusión
Como podrán ver, los diagramas de estado son de gran utilidad. Estos diagramas tienen muchos más elementos de los que aquí se han explicado, pero aquí hemos explicado 20% de los elementos que ayudan a resolver 80% de los problemas.
Acerca del autor
Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting. Primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en UML, CMM y orientación a objetos. info@milestone.com.mx www.milestone.com.mx
- Log in to post comments