Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
.

Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Aliados del PMI® México

LiderDeProyecto.com es aliado estratégico del PMI® Capítulo México.
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
UML

La Vida de un Objeto - El Diagrama de Estados
Por Sergio Orozco

Como ya he mencionado en ediciones anteriores y se lo repetimos a nuestros alumnos constantemente en nuestros cursos para evitarles la burocracia en su trabajo, no todos los proyectos requieren utilizar todos los artefactos de UML. Uno de estos artefactos que no veremos en cualquier proyecto es el diagrama de estados. Aunque, en ciertos proyectos no es opcional, sino indispensable utilizarlos.

Proyectos en los que hay que monitorear la situación en que se encuentra un documento, producto o persona son buenos candidatos para explotar este artefacto. Un ejemplo sería el caso del 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

Otro caso ocurre con las empresas de mensajería. Este tipo de empresas cada vez puede competir menos en el mercado si no le ofrece a sus clientes un servicio de rastreo de sus paquetes utilizando internet. Este tipo de sistemas resulta muy complicado de analizar y desarollar si no se elabora algún artefacto como el diagrama de estados. Con un diagrama así resulta mucho más fácil comprender cuáles son las etapas por las cuales pasa un paquete del cliente.

Y en realidad el sistema de rastreo que utilizan los clientes de estas empresas es sólo la punta del iceberg, pues una empresa así requiere una logística complicada alrededor de los paquetes que se envían. Razón mayor para utilizar diagramas de estados para el desarrollo de este tipo de sistemas.

Adeudos, Periódicos, Semáforos y Préstamos

Otros sistemas donde aplicarían bien los diagramas de estados serían los que permiten saber cómo se encuentran nuestros adeudos. El adeudo puede estar vencido, pagado, renegociado, etc.

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. En este se desarrolló un diagrama de estados para la “Página del Periódico”.

Un simple semáforo tiene un flujo en su cambio de estados que puede modelarse perfectamente con estos diagramas. El diagrama nos mostraría que del Alto sólo puede pasar al Siga, y del Siga tiene que pasar por un momento a Preventiva y de ahí al Alto nuevamente, pero nunca del Siga al Alto directamente.


Estados de un semáforo

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 de un producto en particular también es muy útil elaborarlos con los diagramas de estados. Incluso hay ambientes de desarrollo donde el diseño de los sistemas se centra mucho en elaborar flujos de trabajo que giran alrededor de algún producto o documento. Para estas herramientas resulta muy útil aprovechar los diagramas de estados.

Comportamiento de Aparatos y Dispositivos

Los dispositivos mecánicos y electrónicos son objetos cuyo comportamiento también es conveniente modelar con este artefacto. 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.

Elementos Básicos

Como podemos darnos cuenta, este tipo de diagrama permite visualizar los estados de un objeto, los eventos ante los cuales reacciona y los efectos o acciones que realiza al cambiar de estado o mientras está 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 objeto a analizar. Claro que no todos los ojetos que identificamos merecen ser analizados tan a fondo como para crearles uno de estos diagramas. Recuerda que no queremos tener proyectos de software burocráticos llenos de artefactos que no aportan valor, es por eso que hay que ser muy selectivos.

Entonces ¿Qué es un Estado?

Podemos ubicar los estados de un objeto de acuerdo a tres posibles situaciones. Los estados de un diagrama para un objeto analizado pueden ser de cualquiera de estos tres tipos:

  1. 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 alguno o algunos de sus atributos Por ejemplo, una persona que tenga edad de 8 años está en el estado “niñez”, si edad es 14 está en “adolescencia” y así respectivamente. El atributo más simple que podría definir el estado de un objeto ¿adivinen cuál es? En efecto, un atributo llamado simplemente “Estado” o “Estatus”
  2. 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”.

  3. 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, este 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 consiste precisamente en que establece las reglas para que el objeto, estando en un estado determinado, pueda pasar a otro de los estados. Aclarando las razones por las cuales podría pasar a algún otro estado. 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”. El 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 un 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 buleanas junto a las transiciones.

Hay Causas, pero También Consecuencias de los Cambios

Así como hay situaciones que son las que provocan el cambio de estado de un objeto, como son los eventos y las condiciones de guardia, también hay efectos ocasionados ya sea por un cambio de estado, durante una transición o debido a que el objeto está en un estado determinado. A estos efectos generados como consecuencia de un cambio 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.


D. de Estados con un estado inicial, con condiciones de guardia
y acciones asociadas a las transiciones

Todo tiene un Principio y un Final

Todo objeto tiene un principio, pues debe de nacer necesariamente en algún estado. Aunque por otra parte puede o no tener un final, por lo menos al modelarlo con un diagrama de estados. Un punto grande en el diagrama apuntando con una transición a un estado lo que indica es el estado en el que nace el objeto, es decir, el estado inicial. Y al modelar los estados de un objeto nos podemos encontrar con que puede tener desde cero hasta N estados finales diferentes.

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 símbolo de estado final se muestra con un círulo relleno con un aro a su alrededor.


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 buleana.

Y como todo tiene un final, este artículo también llegó hoy a su fin. No sin antes volver a aclarar que este artefacto tiene muchos más elementos, pero utilizando el 20-80, el 20% de los elementos de este diagrama son los que te van a ayudar a resolver el 80% de tus sistemas. Es ese 20% el que en este artículo se menciona.

Publicado en la revista Software Gurú.
Reproducido con permiso del autor.


Temas relacionados:
Curso de análisis y diseño orientado a objetos con UML


indice del manual





Gestión y actualización de los riesgos del proyecto
(Julio Matus)
+
.
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. PMI®, PMBOK® Guide, OPM3®, CAPM® y PMP® son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.