1. CAPIS REPORTES TECNICOS
MODELO DINAMICO EN ORIENTACION A OBJETOS
Maestrando: Ing. Alejandro Hossian
1. INTRODUCCIÓN
Este artículo tiene como objetivo presentar una breve introducción acerca del
modelado de los aspectos dinámicos de un sistema bajo el paradigma de la
Orientación a Objetos para el Análisis y el Diseño, proporcionando un caso
práctico a tal efecto.
Es importante destacar el papel fundamental que juega el modelo dinámico en el
desarrollo de sistemas, ya que a través del mismo podemos examinar aquellos
aspectos de comportamiento de un sistema que cambian con el tiempo.
El presente artículo, tratará de proporcionar un marco general sobre los conceptos
fundamentales que nos servirán de guía en el modelado de los aspectos
dinámicos de un sistema.
Los temas que abordaremos en éste artículo son los siguientes:
En el ítem 2 comenzaremos con una breve introducción acerca del modelo
dinámico y su relación con el modelo de objetos, que es el modelo sobre el cuál
operará el modelo dinámico.
Luego se hará una breve mención sobre las ventajas que ofrece el modelo
dinámico (ítem 2.1) para después abordar en forma general aquellos conceptos que
nos permitirán la construcción del modelo dinámico, cómo ser los sucesos y
estados (ítem 2.2), escenarios (ítem 2.3) y diagramas de estado (ítem 2.4) .
Luego en el ítem 3 trataremos de aplicar éstos conceptos para la construcción del
modelo dinámico a un caso práctico.
Comenzamos por la construcción del modelo de objetos (ítem 3.1), siguiendo con la
realización de los diagramas de escenarios (ítem 3.2) y los diagramas de estado
(ítem 3.3). Luego se refinarán aquellos diagramas de estado que se consideren
relevantes en el dominio de la aplicación, realizando los diagramas de estados
anidados correspondientes (ítem 3.4).
También haremos mención a la concurrencia y sincronización de estados dentro
de un objeto (ítem 3.5)
En el ítem 3.6, trataremos de explicar tres elementos que contribuyen al
enriquecimiento del modelo dinámico, aportando detalles adicionales a los
diagramas de estado.
En el ítem 4, presentamos las conclusiones del artículo y en el ítem 5 la
bibliografía consultada.
2. MODELO DINÁMICO Y MODELO DE OBJETOS
Algunos principios fundamentales del modelado son los siguientes:
- Un modelo constituye una abstracción de la realidad.
- Dado que los modelos omiten los detalles no esenciales, resulta más sencillo
manipularlos a ellos que a la entidad original.
- Un modelo puede expresarse a diferentes niveles de precisión.

2. CAPIS REPORTES TECNICOS
A partir de éstas consideraciones, se desprende que al Modelo Dinámico no le
resultan ajenos los requisitos expuestos, cabiéndole la importante responsabilidad
de describir aquellos aspectos de un sistema que cambian con el tiempo. Es
decir, que el Modelo Dinámico se utiliza para especificar e implementar los
aspectos del control del sistema, colaborando de ésta manera en describir las
secuencias de operaciones que se producen, sin tener en cuenta lo que hagan
éstas operaciones, aquello a lo que afecten o la forma en que las mismas estén
implementadas.
Cabe aclarar, que el modelado del aspecto dinámico de un sistema no constituye
una característica exclusiva del paradigma orientado a objetos, dado que también
puede ser abordado a través del enfoque del Análisis Estructurado.
En el caso que nos ocupa, nuestro Modelo Dinámico operará sobre el Modelo de
Objetos que resulta ser el más importante, dado que bajo el enfoque de
orientación a objetos, la construcción de nuestro sistema se hará en torno a ellos
y no a la funcionalidad del mismo.
Y será precisamente la identificación de los objetos procedentes del dominio de la
aplicación, el principal centro de atención del analista, para luego ajustarle a dichos
objetos los procedimientos.
Tales afirmaciones, están sustentadas en principios fundamentales del modelado
orientado a objetos, como ser la expresa necesidad del Modelo de Objetos para
poder describir “QUE” está cambiando o transformándose, antes de describir
“CUANDO” y “COMO” cambia. Así cómo también el mejor soporte de la evolución
de los requisitos que provee el enfoque orientado a objetos, dado que está
basado en el entorno subyacente del dominio de la aplicación en sí, más que en
los requisitos funcionales de un único problema.
El Modelo de Objetos cumple la función primordial de capturar la estructura
estática (de datos), de los objetos del sistema (identidad, atributos y operaciones),
así cómo también sus relaciones.
La metodología OMT (Técnica de Modelado de Objetos), cuyo creador es James
Rumbaugh, incorpora el llamado Modelo Funcional después de haber modelado la
estructura estática (Modelo de Objetos) y la estructura dinámica (Modelo Dinámico).
Este modelo funcional describe las transformaciones de valores de datos que
ocurren dentro del sistema es decir, que es responsable de capturar lo que hace
el sistema independientemente de cuándo se haga o de la forma en qué se haga.
OMT emplea tres clases de modelos para describir el sistema, a saber:
DESCRIBE “QUE” ESTÁ CAMBIANDO
EL MODELO DE OBJETOS
CONTIENE DIAGRAMAS DE OBJETOS
DESCRIBE “CUANDO” CAMBIA
EL MODELO DINAMICO
CONTIENE DIAGRAMAS DE ESTADO
DESCRIBE “COMO” CAMBIA
EL MODELO FUNCIONAL
CONTIENE DIAGRAMAS DE FLUJOS DE DATOS

3. CAPIS REPORTES TECNICOS
2.1 Ventajas del Modelo Dinámico
Las relaciones dinámicas no resultan sencillas de comprender en muchas
aplicaciones, por lo que la fase de análisis dinámico es una etapa importante en
lo que se refiere a los cambios de los objetos y sus relaciones en el tiempo, en
ella se pretende describir:
- Las relaciones temporales y de eventos entre los objetos del sistema.
- Los estados de los objetos, es decir, lo que se refiere a sus cambios
internos a lo largo del desarrollo de la aplicación .
- Las acciones efectuadas por los objetos en un cierto contexto.
- Las acciones de los sistemas externos sobre los objetos del sistema en
estudio, así como las reacciones de dichos objetos .
2.2 Sucesos y Estados
Los conceptos más importantes del Modelo Dinámico son los sucesos, que
representan estímulos externos, y los estados que hacen referencia a los valores
de los objetos.
Más precisamente podemos afirmar, que un suceso es un estímulo individual
proveniente de un objeto y que llega a otro, pudiendo ser éste un objeto del
sistema o externo al mismo.
Sea cual fuera su origen, un evento puede dirigirse hacia uno o más objetos, o
incluso no poseer un destino preciso en el sistema, con lo que ciertos objetos del
sistema pueden captarlo.
La respuesta de un objeto a un suceso que le llega depende del estado del
objeto receptor, el cual reaccionará en función del contexto de la aplicación,
pudiendo ocurrir lo siguiente:
- Un cambio de estado en el objeto receptor.
- Desencadenar un mensaje (envío de otro suceso) al remitente ó a un
tercer objeto .
Un suceso se produce en un instante dado, y si bien podemos afirmar que no
tienen duración (a diferencia de los estados) , decimos que se produce muy
rápidamente en comparación con la granularidad de la escala temporal de un
abstracción determinada .
En cuánto a los estados, decimos que constituyen una abstracción de los valores
de los atributos y de los enlaces de un objeto.
Durante el transcurso del desarrollo de una aplicación y en función de las
opciones elegidas por los usuarios, un objeto puede pasar por varios estados o
mantenerse en un estado inicial.
El estado tiene duración, se corresponde con un intervalo de tiempo entre dos
sucesos recibidos por un objeto y se lo asocia con actividades continuas, como
puede ser el sonido de una alarma o con actividades que demoren un cierto
tiempo en concluir, tal como un viaje en auto entre dos lugares.
El suceso no tiene duración y decimos que representan puntos temporales, como
ser pulsar un botón para desactivar la alarma o encender el auto.
Por lo que podemos concluir que sucesos y estados son duales entre sí, es decir
que un suceso separa a dos estados y un estado separa a dos sucesos.

4. CAPIS REPORTES TECNICOS
Esto se puede observar en el diagrama de estados de FIG 1 en página 7, dónde
el suceso conexión separa los dos estados del foco del automóvil (Apagado y
Desconexión), mientras que el estado Encendido, por ejemplo, separa los dos
sucesos de Conexión y Desconexión.
2.3 Escenarios
Un escenario constituye una secuencia de sucesos ordenados en el tiempo que
simulan una ejecución particular del sistema.
Utiliza dos conceptos importantes:
- Objetos que forman parte del sistema (no necesariamente todos se van a
representar en el diagrama de escenarios) y objetos externos al sistema
y que interactúan con éste .
- Sucesos emitidos y recibidos por los objetos implicados en el escenario.
Los escenarios permiten experimentar las ejecuciones del sistema, por lo que
resultan muy útiles para las fases de pruebas y mantenimiento.
Posteriormente veremos la aplicación de los diagramas de escenarios en un caso
práctico, los cuáles están referenciados en FIG 5 y FIG.
2.4 Diagramas de Estado
Un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos
dirigidos son transiciones entre estados causadas por sucesos.
De ésta definición se desprende que una transición constituye un cambio de
estado causado por un suceso, es decir que si un objeto se encuentra en un
cierto estado y se produce un suceso cuyo nombre corresponda al de una de
sus transiciones, entonces el objeto pasa al estado que se encuentra en el
extremo de destino de la transición. Decimos que la transición se dispara.
El Modelo Dinámico consta de múltiples diagramas de estados, con un diagrama
para cada clase que tenga un comportamiento dinámico relevante dentro del
dominio de la aplicación, mostrándonos la trama de actividad de todo el sistema.
Es decir, que debemos concentrarnos en clases de objetos que tengan
interacciones importantes, de lo que se desprende que no todas las clases
necesitan un diagrama de estados, así por ejemplo, si el objeto solo posee un
estado inicial y otro final, no será de utilidad su diagrama de estados.
Los estados los representamos por un rectángulo de esquinas redondeadas con el
nombre del estado y las transiciones por medio de flechas desde el estado
receptor hasta el estado destino, dónde el rótulo de la flecha hace referencia al
nombre del suceso que da lugar a la transición, debiéndose destacar que todas
las transiciones que salgan de un estado deben de corresponder a sucesos
distintos.
Por ejemplo, éste podría ser el diagrama de estados de un foco de automóvil,
dónde el suceso conexión – desconexión es la secuencia del suceso conexión
seguido por el suceso desconexión.

5. CAPIS REPORTES TECNICOS
Conexión
Apagado Encendido
Desconexión
FIG 1
A su vez, los diagramas de estado pueden representar ciclos vitales únicos o bien
bucles continuos.
Los diagramas de un solo uso representan objetos de duración finita y poseen
estados iniciales y finales, entrándose en el estado inicial al crear el objeto y
cuándo se ingresa en el estado final se implica la destrucción del objeto.
El estado inicial se representa mediante un círculo negro, el cuál puede estar
rotulado para indicar diferentes condiciones iniciales.
El estado final se expresa por un círculo blanco con centro negro, cuyo rótulo
también indicaría distintas condiciones finales.
Cómo ejemplo de diagrama de un solo uso, podemos ver el ciclo vital simplificado
de un juego de ajedrez representado en la FIG 2.
Comienzo Jaque Mate Ganan
Piensan las las
Blancas Rey Ahogado Negras
Mueven las Mueven las
Negras Blancas Tablas
Piensan las Rey Ahogado Ganan
Negras las
Jaque Mate Blancas
FIG 2
Cabe aclarar, que los diagramas de un solo uso los podemos considerar cómo
una subrutina del diagrama de estados, a la cuál se puede hacer alusión desde
diferentes lugares en un diagrama de alto nivel.
En los diagramas que representan bucles continuos, en general se desconoce y
carece de importancia la forma en que comienza el bucle.
Por ejemplo, el diagrama de estados que describe el comportamiento de una línea
telefónica representado en FIG 3 constituye un bucle continuo que muestra la
utilización normal del teléfono.
El diagrama de FIG 3, contiene las secuencias asociadas a llamadas normales así
cómo algunas secuencias anormales, tales cómo que se agotó el tiempo mientras
se marca.

6. CAPIS REPORTES TECNICOS
También podemos observar, que el suceso “colgar” da lugar a una transición desde
cualquier estado hasta el estado en reposo , circunstancia ésta que se manifiesta
en el diagrama con una cuantas transiciones que llevan hasta el reposo .
Colgar Colgar
Libre
Descolgar
Tiempo Agotado Tiempo
Tono de Marcar Agotado
Dígito n
Tiempo
Agotado
Dígito n Mensaje
Marcando Número no Válido Grabado
Número Número Válido
Línea Ocupado
Ocupada Mensaje
Conectado Finalizado
Señal de Red
Ocupado Sobrecargada
Encaminando
Sonando
Responde el Teléfono Llamado
Conectado
Cuelga el Teléfono Llamado
Desconectado
FIG 3
3. CONSTRUCCIÓN DEL MODELO DINÁMICO
Para ilustrar éstos conceptos básicos acerca del Modelo Dinámico, se desarrollará
un caso práctico simple a partir del modelo de objetos y se avanzará sobre
algunos conceptos mas avanzados del Modelo Dinámico, como anidamiento de
estados, atributos, centinelas y operaciones.

7. CAPIS REPORTES TECNICOS
3.1 Modelo de Objetos
Supongamos un objeto persona que posee un nombre, una dirección y un cargo
y que puede trabajar o no para una empresa y que también podrá ser contactado
por una agencia de colocación para recibir una o mas propuestas de empleos.
Las palabras subrayadas indican las clases de objetos a modelar. Representamos
la asociación “muchos a muchos” entre la clase Persona y la clase Agencia por
un asterisco * en ambos extremos de clase, y la asociación muchos a uno entre
la clase Persona y la clase Empresa por un asterisco * en el extremo Persona y
0..1 en el extremo Empresa (que denota que una persona podrá trabajar para
ninguna o a lo sumo para una empresa).
Construyamos el modelo de objetos para ésta aplicación en FIG 4:
Persona
Contactar Para * Nombre * Trabajar Para
Dirección
Propuesta Cargo
* 0..1
Agencia Empresa
Nombre Nombre
Dirección Dirección
FIG 4
Los símbolos * y 0..1 se refieren a las cardinalidades, así es que el símbolo * lo
utilizamos para representar un conjunto de valores potencialmente infinito, es decir
0 o más.
Por ejemplo, en el diagrama de objetos de FIG 4 se indica que una persona
puede ser contactada por 0 o más agencias y que una agencia puede contactar
a 0 más personas. Así como también, que en una empresa pueden trabajar 0
más personas.
El símbolo 0..1 indica que 0 o 1 objetos de la clase a la que le corresponde la
cardinalidad pueden estar relacionados con los objetos de otra clase.
Para el diagrama de objetos en FIG 4 tenemos que una persona puede trabajar
para 0 o una empresa a lo sumo.
3.2 Diagramas de Escenarios o de Secuencia de Sucesos
Este diagrama muestra cada objeto como una línea vertical y cada suceso como
una flecha horizontal que va desde el objeto emisor hasta el objeto receptor,
efectuándose la lectura secuencial en orden descendente.
El tiempo va en aumento desde arriba hacia abajo, aunque debemos aclarar que
el espacio entre las flechas representativas de los sucesos, carece de importancia.
Es decir, que lo único que se visualizan son las secuencias de sucesos sin hacer
referencia a su temporización exacta.
Es de destacar, que los objetos que intervienen en los escenarios son instancias,
por lo que es necesario especificar su nombre y su clase, a partir de lo cual
podemos afirmar que:

8. CAPIS REPORTES TECNICOS
“Un escenario es al Modelo Dinámico lo que un diagrama de instancias
es a un Modelo de Objetos”
En el marco de la aplicación que gestiona la asignación de puestos, cuyo
diagrama de clases es el que se presenta en la FIG 4 el siguiente escenario hace
intervenir a los tres objetos del sistema , a saber : la instancia Costas de la clase
Persona , la instancia Baner de la clase Empresa y la instancia Sima de la clase
Agencia .
El suceso original de éste escenario es la búsqueda de un perfil de desarrollador
en Java efectuada por la empresa Baner a la agencia Sima. Trás la
correspondiente petición, Sima envía la propuesta al señor Costas quien establece
contacto con Baner para solicitar entrevista. Luego de la convocatoria efectuada
por la empresa al señor Costas, éste acude a la entrevista. Posteriormente, la
empresa Baner realiza un balance de dicha entrevista y decide asignar el puesto
al señor Costas, quien lo notifica a la agencia Sima.
La traza de sucesos de FIG 5 representa una asignación de puesto:
Buscar desarrollador en Java
Llegada Propuesta
Petición de Entrevista
Convocatoria
Asistencia a Entrevista
Perfil del Entrevistado
Asignación de Puesto
Notificación de Contratación
Sima (Agencia) Costas (Persona) Baner (Empresa)
FIG 5
Supongamos ahora una situación dónde una instancia del objeto Empresa rechaza
la asignación de una instancia del objeto Persona. Dicha situación sería de utilidad
ilustrarla con la implementación de otro modelo de escenario.
En éste caso, la secuencia de sucesos podría ser la siguiente: un suceso
disparador similar al caso anterior, en el cuál la Empresa Soft.SA se dirige a la
agencia Zeta para un puesto de Gerente de Sistemas.
Como respuesta, ésta agencia le envía a Soft.SA el currículum – vitae del señor
Tass.

9. CAPIS REPORTES TECNICOS
Entonces la empresa convoca al postulante para una entrevista, tras la cuál Soft
.SA , luego de efectuar un balance de la misma , decide no asignar el puesto al
señor Tass y le comunica su decisión .
Asimismo, la empresa Soft.SA le notifica a la agencia Zeta el rechazo de
asignación.
La traza de sucesos de FIG 6 representa un rechazo de asignación de puesto:
Buscar Gerente de Sistemas
Enviar Curriculum vitae del señor Tass para éste puesto
Convocatoria
Asistencia a Entrevista
Perfil del Entrevistado
Rechazo de Asignación
de Puesto
Notificación de Rechazo de Asignación
Zeta (Agencia) Tass (Persona) Soft .SA (Empresa)
FIG 6
Basados en un formalismo claro e intuitivo, los escenarios facilitan la comprensión
del funcionamiento del sistema, y en particular son útiles en la descripción de
los casos de error y casos límite de uso del sistema.
3.3 Diagramas de Estado
Siempre dentro del contexto del modelo de objetos de nuestro ejemplo, nos
interesaremos más acerca de los estados del objeto Persona.
Identificamos tres estados diferentes, dependiendo por una parte del valor del
atributo Cargo y por otra de los enlaces de éste objeto Persona con un objeto
Empresa y con uno o más objetos Agencia.
- Estado CONTRATADO: el objeto persona pasa a éste estado cuándo: el atributo
Cargo tiene un valor distinto de “Sin Cargo” , cómo por ejemplo “administrativo” ,
“gerencial” , “informático” , etc ; y por otra parte cuándo el objeto Persona posee un
enlace Trabajar Para con un objeto Empresa. Además de éstas dos características,
el objeto Persona en el estado Contratado puede poseer un enlace Contactar
Para con uno o más objetos Agencia.
- Estado BUSQUEDA: el objeto Persona pasa a éste estado cuándo: el valor del
atributo Cargo es “sin Cargo” y además el objeto Persona, no tiene ningún enlace
Trabajar Para con un objeto Empresa ni tampoco Contactar Para con uno o más
objetos Agencia.
- Estado SELECCIÓN: el objeto Persona pasa a éste estado cuándo: el valor del
atributo Cargo es “sin Cargo” y no tiene un enlace Trabajar Para con un objeto
Empresa, pero tiene un enlace con uno o más objetos Agencia.

10. CAPIS REPORTES TECNICOS
Los sucesos asociados con los cambios de estado son los siguientes:
- El “Despido” efectuado por una Empresa sobre un objeto Persona.
- La llegada de una “Propuesta de Trabajo” desde una agencia (externo).
- La “Asignación de un Puesto” a una Persona por una Empresa.
- El “Rechazo de Asignación” de un puesto por parte de una Empresa.
- La “Dimisión” de una Persona en una Empresa.
La trama de sucesos, estados y transiciones de éstos estados para el objeto
Persona , se representa en el diagrama de estados de FIG 7 :
Llegada Propuesta
CONTRATADO
Dimisión Asignación
Despido Puesto
Llegada Propuesta
BUSQUEDA Rechazo Asignación SELECCION
FIG 7
3.4 Diagramas de Estados Anidados
A los diagramas de estado como los de FIG 7 en página 13, se los llama
diagramas de estados planos o no estructurados.
Dichos diagramas aportan información general sobre los estados por los que
atraviesa un objeto y puede que dicha información sea suficiente en algunos
casos.
Pero en determinadas circunstancias, puede ser necesario asociarle a un
determinado estado de un objeto diversos subestados, a efectos de poder precisar
con mayor detalle dicho estado. Esta necesidad de obtener mayor información
acerca de un estado, se tratará de satisfacer asociándole diferentes subestados a
cada estado que el analista considere que le corresponden niveles de
granularidad distintos. Lo que se conoce como anidamiento de diagramas de
estados.
Así es que al estado SELECCIÓN del objeto Persona lo podemos precisar por
los trés subestados : Candidato a Entrevista, Entrevistado y Evaluado .
Los subestados de un objeto se relacionan entre sí en un diagrama dinámico, de
igual manera que los estados que precisan o especializan.
El anidamiento unos en otros de los diagramas de estado, facilita una lectura más
profunda acerca del comportamiento dinámico de los objetos.
El diagrama de estado anidado del estado SELECCIÓN lo podemos observar en
FIG 8 en página 14:

11. CAPIS REPORTES TECNICOS
Llegada
Propuesta
Convocatoria
Candidato a Entrevista Entrevistado
Nueva Propuesta Perfil del
Entrevistado
Asignación Puesto
Evaluado
Rechazo Asignación
FIG 8
El estado inicial que se representa en éste diagrama por un disco negro lleno,
indica el punto de entrada en el estado SELECCIÓN. Observando el diagrama de
estado de FIG 7 para el objeto Persona, se ve que el punto de entrada es la
transición Llegada Propuesta del estado BUSQUEDA al estado SELECCIÓN. Y
siguiendo el mismo hilo de razonamiento, se deduce que los estados finales
representados en el diagrama por un disco negro rodeado por un círculo
corresponden a las transiciones Rechazo Asignación y Asignación Puesto, las cuáles
desencadenan los cambios desde el estado SELECCIÓN a los estados BUSQUEDA
y CONTRATADO respectivamente.
En éste último diagrama de FIG 8 en página 14, se puede observar que el
postulante podrá ser citado nuevamente a otra entrevista si la empresa así lo
considera, después que dicho postulante haya asistido a la entrevista y la empresa
haya realizado el correspondiente balance de la misma. Esta circunstancia se
vislumbra en el diagrama a través del suceso Nueva Propuesta, el cuál
desencadena la transición desde el estado Evaluado al estado Candidato a
Entrevista.
Cabe destacar que previamente, el postulante pasó al estado Evaluado desde el
estado Entrevistado a causa del suceso Perfil del Entrevistado, que es el que
desencadena dicha transición.
3.5 Concurrencia y Sincronización de Estados
Nos referiremos a la concurrencia dentro de un objeto, esto se debe a que en
ciertas situaciones de modelado es preciso especificar subestados concurrentes, los
cuáles a su vez, permiten especificar dos o más estados que se ejecutan en
paralelo en el contexto del objeto que las contiene y en un mismo estado.
Si los subdiagramas están en concurrencia, el primer subdiagrama que permite que
se efectúe la transición del estado englobante hacia otro estado, interrumpe los
demás subdiagramas causando la salida del estado englobante.
Cuándo el objeto Persona está en el estado BUSQUEDA, podemos imaginarla
realizando diversas operaciones en paralelo, cómo ser las gestiones pertinentes en
la Agencia de colocación (supongamos que la persona deba inscribirse en la
agencia y de ser aceptada su inscripción deberá proceder a realizar un curso de
capacitación) y las gestiones individuales que dicha persona realiza en el marco
de su búsqueda de empleo (cómo la búsqueda en periódicos etc).
La FIG 9 nos muestra la concurrencia para el estado BUSQUEDA:

12. CAPIS REPORTES TECNICOS
BUSQUEDA
Inscripción en Inscripción Realizar Llegada Propuesta
Agencia Aceptada Curso por Agencia
----------------------------------- Ó SELECCION
Búsqueda en Periódicos
Llegada Propuesta
por Periódico
FIG 9
Los subestados Inscripción en Agencia y Realizar Curso son secuenciales, es decir
que en el marco de las gestiones que el postulante realiza en la Agencia, su
estado es de Inscripción ó de Realizar Curso. Ambos estados, a su vez, están en
concurrencia con el subestado Búsqueda en Periódicos, ya que dos tipos de
eventos independientes pueden encontrarse en el origen de la transición hacia el
estado SELECCIÓN: una Llegada de Propuesta por Agencia Ó una Llegada de
Propuesta por Periódico.
Cualquiera de las dos transiciones que se dé primero, hará que concluyan los
subdiagramas concurrentes, ya que ambos forman parte de un mismo estado
compuesto BUSQUEDA y solamente se encuentran activados cuándo el diagrama
de estados de más alto nivel está en ese estado.
Los diagramas de estados concurrentes son útiles si un objeto dado tiene conjuntos
de comportamientos independientes.
Si los subdiagramas están sincronizados, la transición del estado englobante hacia
otro estado solo se efectúa cuándo todos los subdiagramas lo permiten, sin poder
interrumpir ningún subdiagrama.
Llevado a nuestro caso práctico, podemos precisar el estado CONTRATADO del
objeto Persona por dos subestados: Trabajando y Licencia, siendo Trabajando el
estado englobante que contiene dos subdiagramas que están sincronizados: Pedir
Licencia y Ejercer Función.
Es decir, que cuándo un objeto Persona se halla en el subestado Trabajando del
estado CONTRATADO, pueden desarrollarse dos diagramas de estado simples en
paralelo, cómo ser el que gestiona el Pedido de Licencia (Pedir Licencia) y el que
describe sus actividades profesionales (Ejercer Función).
Asumimos como requisito impuesto por la empresa para que una persona entre
en estado de licencia, que se manifiesten dos eventos : el Pedido de Licencia debe
ser aceptado Y además que ciertas funciones que le competen a esa persona,
deben estar concluidas (por ejemplo, si la persona es la encargada de liquidar
sueldos, dicha tarea debe estar terminada antes de que la persona entre en
licencia) .
El orden en que éstos sucesos se manifiesten carece de relevancia, es decir que
los pasos internos de las actividades no están sincronizados, pero dichas
actividades deben estar finalizadas antes de que el objeto pueda avanzar hacia
el estado siguiente.

13. CAPIS REPORTES TECNICOS
La FIG 10 nos muestra la sincronización para el subestado Trabajando :
Trabajando
Aceptación
Pedir Licencia de Licencia
--------------------------- Y Licencia
Ejercer Función Tareas
Terminadas
FIG 10
3.6 Atributos Centinelas y Operaciones
Estos tres elementos enriquecen el modelo dinámico, aportando detalles adicionales
a los diagramas de estado.
Los atributos y centinelas (condiciones) permiten precisar una transición.
Así es que los atributos son los valores de datos aportados por un suceso al
igual que los valores de datos que contienen los objetos. Es decir, que constituyen
la información llevada por los eventos y se representan entre paréntesis después
del nombre de la clase de suceso.
Los centinelas o condiciones son funciones booleanas lógicas que devuelven
verdadero o falso y vendrían a ser cómo protecciones de las transiciones también
llamadas guardias, de tal manera que una transición con protección se dispara
cuándo se produce su suceso y si el guardia se resuelve como “verdadero” . Esta
guardia o protección va entre corchetes después de la lista de atributos del
suceso.
El suceso se podría representar: suceso (atributos)[centinela], por ejemplo en el
subdiagrama del estado CONTRATADO, el suceso Entrada en Licencia puede tener
los atributos número de licencia (que indica la cantidad de licencias que tomó el
empleado en un período determinado) y cantidad de días solicitada y para que la
transición al estado Licencia se dispare, debe cumplirse que éste número esté por
debajo de un cierto valor (4 por ejemplo) y que además, la cantidad de días
solicitada no sea mayor de una cierta cantidad (10 por ejemplo), así es que
podemos tener más de un centinela.
El suceso quedaría: Entrada en Licencia (Nº Licencia, Cantidad de días) [Nº Licencia< 4
&& Cantidad días < 10].
Las operaciones describen la respuesta de un objeto ante un suceso, así es que
las operaciones asociadas a estados o transiciones se efectúan en respuesta a
los correspondientes estados o sucesos.
Las operaciones asociadas a estados son las actividades, que requieren un cierto
tiempo. Podemos citar las operaciones continuas, cómo la actividad “Ejercer
Función” del objeto Persona en el subestado Trabajando del estado
CONTRATADO. Se inscribe dentro del rectángulo del estado, precedido por la
notación “do” .
También están las actividades secuenciales, que terminan por sí mismas después
de un cierto intervalo de tiempo, cómo el cierre de una válvula.

14. CAPIS REPORTES TECNICOS
Las acciones son operaciones “instantáneas” y pueden estar asociadas a una
transición o también al estado de un objeto, pudiendo intervenir en la entrada del
estado (prefijo entry/), en la salida del estado (prefijo exit/), en respuesta a un evento
desencadenante (prefijo nombre evento/), o bien en el transcurso de una transición (la
acción figura tras la lista de centinelas precedida por el signo / ).
Supongamos nuestro objeto Persona cuándo ingresa en el estado CONTRATADO,
la misma efectúa su primera acción que es firmar su contrato de trabajo, contrato
éste que se rompe cuándo la persona sale del estado CONTRATADO. Por otra
parte, durante el tiempo de su contrato la persona se encarga de realizar una
actividad consistente en ejercer su función para la que fue contratado.
Además, mientras la persona permanece en éste estado pueden producirse varios
eventos de distinta naturaleza, cómo ser la llegada de una propuesta proveniente
de una agencia de empleo (debiendo responder la persona a ésa solicitud) ó la
notificación de un cambio (la persona cambia de asignación).
Para nuestro caso, tendríamos para el estado CONTRATADO el siguiente diagrama
completo representado en FIG 11 en página 18 :
CONTRATADO
entry / firmar contrato de trabajo
do : ejercer función
llegada propuesta /responder a la propuesta
cambio / cambiar de asignación
exit / romper contrato de trabajo
FIG 11
Y de una forma más general tendríamos la siguiente situación, que representamos
en la FIG 12
ESTADO 1
entry / acción al entrar en estado
do : actividad durante el estado
evento 1 / acción 1
evento 2 / acción 2
....
exit / acción al salir del estado
suceso (atributos) [centinelas] /acción
ESTADO 2
FIG 12

15. CAPIS REPORTES TECNICOS
4. Conclusiones
El modelo dinámico describe los aspectos de comportamiento de un sistema que
cambia con el tiempo y es de utilidad para implementar los aspectos de control,
es decir aquella parte del sistema que describe las secuencias de operaciones que
se producen en respuesta a estímulos externos.
La importancia del modelo dinámico dependerá de la naturaleza de la aplicación,
así por ejemplo, dicho modelo no será preponderante para un depósito de datos
puramente estático cómo una base datos, adquiriendo mayor importancia para
sistemas interactivos.
Los sucesos que representamos en los diagramas de estado correspondiente a un
objeto, suelen implementarse como operaciones para ése objeto en el modelo de
objetos. Según algunos autores, como James Rumbaugh, los sucesos son más
expresivos que las operaciones, ya que el efecto de un suceso depende tanto de
la clase del objeto cómo de su estado.
El modelo dinámico constituye un soporte muy útil para el paso a la fase de
diseño, ya que permite describir los encadenamientos de los métodos.
5. Bibliografía
Martin Fowler con Kendall Scott - “UML GOTA A GOTA” - Ed Eyrolles
Gestión 2000. 1997
López Nathalie, Migueis Jorge, Pichon Emmanuel - “Integrar UML en los proyectos” -
Ed Eyrolles Gestión 2000 . 1998
Rossi Bibiana, Britos Paola, García Martínez - “Modelado de Objetos”
Revista del Instituto Tecnológico de Buenos Aires Nº 21. 1998
Rumbaugh James , Blaha Michael, Premerlani William , Eddy Frederick , Lorensen
William - “Modelado y diseño orientados a objetos”
Ed Prentice - Hall . 1991
Muller Pierre Alain - “Modelado de objetos con UML” - Ed Eyrolles
Gestión 2000. 1997
Grady Booch, James Rumbaugh, Ivar Jacobson - “El Lenguaje Unificado de
Modelado” - Ed Addison Wesley. 1999
Piattini Mario G , Calvo - Manzano José A , Cervera Joaquín , Fernández Sanz
Luis - “Análisis y diseño detallado de Aplicaciones Informáticas de Gestión” - Ed
Rama. 1996