FORMATO
LECTURA PARA

Lectura 1. Diagramas de actividad y de secuencia

Los diagramas que se han abordado hasta este momento comparten la característica de
que sirven para documentar la estructura estática de una solución de software. Es decir,
representan el “estado” de dicha solución en un momento del tiempo, y no consideran las
variaciones que ese estado sufre a lo largo del tiempo, ni las interacciones que se llevan a
cabo entre los elemento que lo constituyen. En esta semana se presentan por primera vez
diagramas que tienen dentro de sus objetivos: el modelar cómo se comporta la solución de
software a lo largo del tiempo con los cambios, interacciones y procesos que esto implica. En
esta lectura se presentan dos diagramas: el diagrama de actividad y el diagrama de
secuencia.

DIAGRAMA DE ACTIVIDAD
El diagrama de actividad se presenta como un diagrama que sirve para representar la vista
funcional de una solución. Por cuanto puede ser utilizado para describir el comportamiento
de procesos lógicos que luego serán implementados, utilizando código. Si se quiere, podría
considerarse este diagrama como una versión mejorada y aumentada de un diagrama de
flujo. Un diagrama de actividad ofrece prácticamente todos los elementos de control de flujo
que se encuentran en los principales lenguajes de programación, de tal manera que se
presta de manera ideal para describir y modelar el comportamiento interno del software. Sin
embargo, este nivel no es el único en el que resulta de utilidad. Un diagrama de actividad
puede ser utilizado en diferentes niveles de detalle y con diferentes objetivos. Puede ser
usado para describir el flujo de trabajo de una aplicación, a nivel macro y para describir el
comportamiento interno de un caso de uso, con un nivel medio de generalidad. Incluso para
detallar el funcionamiento interno de un método en una clase, siendo este nivel el más
detallado de los tres.
En el primer y segundo nivel, se utilizan diagramas de actividad para describir el flujo general
de una aplicación, bien sea a través de un proceso que involucre varios casos de uso, un
único caso de uso o incluso un escenario dentro de un caso de uso. En cada circunstancia
es posible utilizar las herramientas y elementos ofrecidos por el diagrama para documentar el
proceso de uso de la aplicación por parte del usuario, abarcando el nivel de detalle y la
complejidad del proceso que se desee.
Por otra parte, en un nivel mucho mayor de detalle, es posible utilizar diagramas de actividad
para documentar el comportamiento y estructura interna de un método dentro de una clase.
Esto implica el modelado no solamente del flujo de dicho comportamiento, sino las
implicaciones que dicho flujo tiene sobre el conocimiento (atributos) de la clase en cuestión.
Los elementos que se pueden utilizar para construir un diagrama de actividad son:

En alianza con

 
Colombia
 

ACTIVIDADES Y TRANSICIONES
Las actividades son el elemento constitutivo central de un diagrama de actividad.
Esto resulta bastante evidente. Una actividad es un paso del proceso en el que se
realiza algún tipo de trabajo, que puede tomar la forma de manipulación de datos,
cálculo o búsqueda de información, etc. Partiendo de este hecho, podría decirse
que un diagrama de actividad es simplemente un conjunto de actividades unidas
mediante transiciones. Las transiciones determinan la manera cómo es posible pasar
de una actividad a otra. Usualmente, este tránsito se da cuando una actividad ha
sido terminada. En la siguiente figura se ilustra esta idea, y se muestran las
representaciones visuales utilizadas para cada uno de los dos elementos.

Preparar comida Comer comida

Figura 1. Elementos CONSTITUIDOS básicos de un diagrama de actividad

En la figura presentada, se aprecia un diagrama de actividad con dos actividades y

una transición que las une. El sentido de la transición indica la ruta posible entre las
dos actividades, implicando que la actividad destino (en este caso Comer comida)
sólo puede ser alcanzada luego de culminar la actividad precedente.

GUARDAS
Las guardas permiten definir condiciones que deben cumplirse para que una
transición pueda darse. Si la guarda no es cumplida (evaluada con un resultado
verdadero, si se quiere ser un poco más formal) no es posible hacer la transición, a
pesar de que la actividad anterior haya sido terminada. Modificando el diagrama de
la figura anterior para incluir una guarda resultaría en:

[ Haberse lavado las manos ]

Preparar comida Comer comida

Figura 2. Diagrama de actividad incluyendo una guarda

Puede verse en la figura la notación para la guarda, escrita entre llaves cuadradas, y
colocada sobre la transición a la que aplica.

DECISIONES
En los casos en que es necesario tomar una decisión dentro del flujo de un diagrama
de actividad, se utiliza una representación que es común en los diagramas de flujo: un
rombo. Por cada alternativa de acción posible, debe existir una flecha que sale del
rombo y cada una de ellas debe tener una guarda, que determine si se toma o no

En alianza con

 
Colombia
 

esa ruta. Es importante anotar que para que una decisión esté bien definida, las
guardas de todas las rutas que salgan de ella deben ser mutuamente excluyentes, de
manera que solamente sea posible tomar una. La ambigüedad en la definición de las
guardas destruiría el propósito de la decisión.

[ Tener hambre aun ]

[ Haberse lavado las manos ] [ Estar satisfecho ]

Preparar comida Comer comida Comer postre

Figura 3. Diagrama de actividad incluyendo una condición

En la figura, se aprecia la inclusión de una condición al flujo del diagrama. En caso
de estar satisfecho luego de haber terminado la actividad Comer comida, es posible
pasar a la actividad Comer postre. En caso contrario, se repite la actividad Comer
comida.

CONCURRENCIA/SINCRONIZACIÓN
En el tiempo, desde que los diagramas de flujo fueron creados, resulta
extremadamente común encontrar lenguajes en plataformas de software y hardware
que soportan el proceso concurrente de hilos de ejecución. Los diagramas de
actividad presentan convenciones para manejar este tipo de situaciones. En primer
lugar, cuando es posible ejecutar simultáneamente un conjunto de actividades es
posible incluir, en el diagrama, un elemento conocido como un fork (tenedor
literalmente) que representa la ejecución concurrente de una serie de hilos. De
manera similar, cuando un conjunto de actividades concurrentes deben mezclarse o
sincronizarse, se crea un punto de sincronización que, para todos los fines prácticos,
es un fork invertido.

Actividad 1

Actividad 0 Actividad 2 Actividad 4

Actividad 3

Figura 4. Diagrama de actividad con procesos de concurrencia y sincronización

El diagrama de la figura, ilustra un caso hipotético en este sentido. Al terminar la
actividad cero se inician de manera concurrente las actividades uno, dos y tres. Al
terminar la ejecución de dichas actividades concurrentes, se realiza una
sincronización que tiene como resultado la ejecución de la actividad cuatro.

En alianza con

 
Colombia
 

INICIO Y FINAL
Los diagramas de actividad ofrecen también elementos para modelar el comienzo y
el final del diagrama. Como anotación, es posible que exista más de un punto de
finalización para un diagrama de actividad. Las diferentes rutas y decisiones que se
presentan dentro de un diagrama de este estilo pueden generar la existencia de
diferentes formas, y por tanto puntos de finalización de la actividad. La
representación visual de cada uno de estos elementos es:

Figura 5. REpresentación del punto inicial de un diagrama de actividad

Figura 6. Representación del punto final de un diagrama de actividad

DIAGRAMA DE SECUENCIA
Los diagramas de secuencia son un tipo particular e importante de los diagramas UML de
comportamiento. El foco principal de los diagramas de comportamiento es ofrecer una
representación sencilla de las interacciones y el orden de las mismas. Sin embargo, no todas
las interacciones dentro de un sistema de software merecen o necesitan ser documentadas
utilizando un diagrama de secuencia, u otro diagrama de comportamiento. En primer lugar,
puede darse el caso de que una interacción particular sea demasiado compleja, por lo que
se represente solo una parte de la misma. El otro caso posible es que la interacción sea tan
sencilla que no sea necesario emplear tiempo ni recursos documentándola.

ELEMENTOS EN UN DIAGRAMA DE SECUENCIA

Un diagrama de secuencia está conformado de manera principal por un conjunto de
participantes que son quienes guían las interacciones. Los participantes se ubican de manera
horizontal en el diagrama, como se muerta en la figura. Ya que el diagrama modela las
interacciones, en tiempo de ejecución, cada participante representa en realidad un objeto
de una clase particular y esto se refleja en el nombre dado a cada uno: en primer lugar, se
encuentra el nombre del objeto y separado de él, por (:) se encuentra la clase a la que
corresponde.

En alianza con

 
Colombia
 

Cada participante tiene una línea punteada que corre verticalmente desde su centro. Estas
líneas son llamadas líneas de vida e indican que un participante existe y está listo para recibir
mensajes (invocaciones de métodos) de otros participantes en la interacción.
Ya que se ha mencionado que uno de los propósitos principales de un diagrama de
secuencia es la representación del orden de las interacciones, resulta evidente que el sentido
del tiempo juega un papel importante en un diagrama de este tipo. El tiempo, en un diagrama
de secuencia, comienza en la parte superior de la página, justo debajo del participante que
se encuentra más arriba y aumenta a medida que se baja por el diagrama. El orden en que
se ubican las interacciones, en la página, indica el orden en que suceden en tiempo de
ejecución. La siguiente figura ilustra el concepto:

En un diagrama de secuencia, la duración de las interacciones no es tan importante como el

orden de las mismas. El orden es indicado por la posición de la interacción en el diagrama,
pero cuánto espacio ocupe verticalmente una interacción dada no es indicativo de la
duración de la misma.
Con el ordenamiento de las interacciones claro, se puede continuar con el próximo elemento
clave de un diagrama de secuencia: los mensajes entre participantes. Una interacción sucede
cuando un participante decide enviar a otro un mensaje.

Aquí puede verse la situación cuando el participante part1, de la clase Participante1 envía
un mensaje al participante part2, de la clase Participante2. Inspeccionando la figura, es
posible ver que aparecen nuevos elementos:

En alianza con

 
Colombia
 

• El mensaje mismo es representado por una flecha en la dirección en que es enviado,

es decir, yendo del origen del mensaje (en este caso part1) hacia el receptor del
mismo (part2). Obsérvese la punta de la flecha. El tipo de punta será importante para
definir qué tipo de mensaje ha sido enviado. Se revisará esta cuestión en más detalle
más adelante.
• Sobre el mensaje va un texto que es conocido como la firma del mismo. En este texto
se especifica qué mensaje ha sido enviado. Como se dijo con anterioridad, la mayor
parte de los mensajes se traducen en la invocación de métodos pertenecientes a la
clase que los recibe, de manera que el texto del mensaje es el estereotipo del
método invocado, incluyendo los parámetros enviados para dicha invocación.
• Al principio de la firma, del mensaje, se encuentra un número. Este número identifica el
orden del mensaje dentro del diagrama de secuencia y es opcional. Resulta útil para
diagramas particularmente complicados o cuando se desea hacer observaciones
escritas acerca del diagrama a otra persona (resulta mucho más sencillo hablar del
“mensaje número siete”, que de “la decimoséptima invocación del método
CalcularPorcentaje”.
• En la línea de vida del receptor del mensaje se crea un rectángulo. Este rectángulo
indica que el receptor no solo existe, sino que se encuentra activo haciendo lo
solicitado por el mensaje recibido. Este rectángulo se conoce como una barra de
activación y es útil para identificar los periodos de actividad reales de un objeto, a lo
largo de una interacción.

Adicionalmente, y dependiendo del tipo (más detalle sobre esto abajo en el documento), un
mensaje puede generar una respuesta por parte del receptor (se puede pensar en esto en
términos del valor retornado luego de invocar un método, o simplemente el retorno de control
del punto de ejecución cuando el método es de tipo void). La respuesta a un mensaje es
representada mediante un tipo particular de flecha; una punteada y hueca representa el
retorno de un mensaje previamente enviado:

Ahora bien, las interacciones entre participantes pueden ser, y usualmente son, más complejas
que un simple envío/recepción de mensajes (uno a la vez). En la mayor parte de los casos, un
mensaje recibido por un participante causa que éste envíe a su vez mensajes a otros
participantes, o incluso, invoque mensajes sobre sí mismo (ejecutando métodos que le
pertenecen). Un ejemplo de estas situaciones es:

En alianza con

 
Colombia
 

En este caso, el envío del mensaje inicial desde part1 hacia part2, produjo que part2 enviara
dos mensajes (mensajeAnidado1 y mensajeAnidado2) hacia part3, recibiendo respuesta
para cada uno de ellos, y luego, invocara un mensaje sobre sí mismo (autoMensaje, que
representa una llamada al método del mismo nombre de la clase Participante2). Todo esto
sucede antes de que el mensaje inicial, mensaje genere una respuesta para part1. Esto resulta
evidente si se leen los números que indican el orden de las interacciones y además, se apoya
en el recurso visual mencionado al principio de la lectura, referente a que el orden de
ubicación de los mensajes en el diagrama representa el orden de su ocurrencia en el tiempo.
Todos los mensajes ubicados visualmente entre el mensaje uno y el mensaje ocho serán
ejecutados en el tiempo de manera similar, entre el envío del mensaje uno y la recepción de
la respuesta correspondiente, en el mensaje ocho.
Como anotación final al tema de los mensajes anidados, es importante mencionar que no
existe límite para el número de mensajes anidados dentro de un mensaje particular, así como
tampoco lo existe para el número de niveles de la invocación. En este caso, part3 pudo
haber enviado un mensaje a otros participantes antes de retornar las respuestas a part2.

TIPOS DE MENSAJES
Con la estructura de un diagrama de secuencia descrita, como se ha hecho hasta ahora, es
posible abordar un tema importante: el de los diferentes tipos de mensajes. Existen cinco tipos
de mensajes básicos en un diagrama de secuencia:

Mensajes sincrónicos. Los mensajes sincrónicos representan la situación en la que el

participante que envía el mensaje requiere de una respuesta, desde el receptor del
mismo, antes de poder continuar con su ejecución y el proceso de envío de mensajes.
Es el tipo más común de mensaje y, en términos de programación, equivale a la
invocación normal de un método perteneciente al objeto receptor. Se representa con
una flecha que tiene la punta rellena:

En alianza con

 
Colombia
 

Mensajes de retorno. Cuando un participante termina la ejecución de lo solicitado

por un mensaje recibido, puede retornar un valor al participante que envió el mensaje
o simplemente, puede retornar el control del flujo de ejecución al dicho participante.
En cualquier caso, este hecho es representado a través de un mensaje de retorno,
denotado visualmente utilizando una flecha punteada con la punta hueca.

En este caso, la ejecución del mensaje mensajeSincronico generó una respuesta

desde part2 que vuelve a part1 bajo la forma del valor almacenado en
valorRespuesta.
Algunas aplicaciones de diagramación UML y diseñadores de software consideran
innecesaria la inclusión de mensajes de retorno en un diagrama de secuencia. A
pesar de que según el estándar UML son, en efecto opcionales, al igual que los
números que indican el orden de los mensajes, las flechas de retorno pueden ser de
gran utilidad cuando se trata de leer un diagrama de interacción complejo. Como
ejercicio, se insta al lector a tratar de interpretar el diagrama de secuencia
presentado con anterioridad como ejemplo de los mensajes anidados, solo que esta
vez, sin contar con la inclusión de los mensajes de respuesta:

En alianza con

 
Colombia
 

Resulta evidente aquí la utilidad de las flechas que representan los mensajes de
respuesta. Sin ellas no es claro si los mensajes dos, tres y cuatro se envían luego de
que el mensaje uno ha recibido respuesta, o si se encuentran anidados dentro de
éste. Problemas de lectura de esta índole son mucho más probables y mucho más
costosos en diagramas más complicados. Además de indeseables, son muy fáciles de
evitar si se incluye de manera formal las flechas que indican los mensajes de retorno
dentro del diagrama.

Mensajes asincrónicos. Los mensajes asincrónicos sirven para representar la situación

en la que un mensaje es enviado, pero el participante que lo envía no necesita
esperar por una respuesta antes de continuar con su ejecución y el envío de nuevos
mensajes. En términos de implementación, los mensajes asincrónicos equivalen a la
creación y lanzamiento de hilos de ejecución, que se desprenden de la línea
principal de ejecución del programa y se convierten en líneas independientes que no
dependen de la principal. Un mensaje asincrónico se representa mediante una flecha
con la punta hueca:

Nótese que un mensaje asincrónico no tiene asociado un mensaje de respuesta, ni

implica la creación de una barra de activación en el participante que lo recibe. Por
cuanto, no es posible saber la duración del proceso que dispara el mensaje.

Mensajes de creación. Un participante no tiene por qué existir a lo largo de toda la

interacción. Puede ser creado solamente cuando es necesario. La creación de un

En alianza con

 
Colombia
 

participante (equivalente a la invocación del constructor de la clase

correspondiente) se representa de una manera particular:

En ocasiones, cuando el participante part1 requiere el objeto creado para su uso, es

necesario representar de manera explícita el retorno del constructor:

Nótese que el valor de retorno es el objeto creado.

Mensajes de destrucción. Así como un objeto puede crearse en algún punto de una
interacción, también puede ser destruido de ser necesario. Tal como sucede con un
mensaje de creación, un mensaje de destrucción tiene una representación particular:

Como elemento interesante, es de notar que la línea de vida del participante

destruido es cortada y una “X” es colocada al final de la misma, para indicar su
finalización.

En alianza con

 
Colombia
 

FRAGMENTOS
A estas alturas, y con los conceptos vistos, resulta evidente que modelar una interacción
relativamente compleja resulta sencillo en términos operativos, pero puede producir un
resultado difícil de leer, por cuanto el diagrama de secuencia resultante puede ser bastante
largo. Para facilitar la labor de organización, así como para permitir la inclusión de
condicionales y ciclos dentro de la realización de un diagrama de secuencia, se introduce
aquí el concepto de fragmento.
Un fragmento de un diagrama de secuencia es una “caja” que encierra un número de
mensajes e interacciones del diagrama. Un fragmento se superpone al diagrama y puede
contener tantas interacciones como sean necesarias y de hecho otros fragmentos, si el
diagrama así lo requiere. Un fragmento tiene, en la parte superior izquierda, un operador que
indica el tipo de fragmento del que se trata:

Fragmento opt.

En alianza con

 
Colombia
 

En este caso, se utilizó un fragmento de tipo opt, que indica que los mensajes contenidos
dentro del fragmento serán ejecutados de manera opcional, dependiendo del resultado de
la evaluación de la Guarda. La guarda, que es una condición de tipo booleano, determina
si se ejecutan o no las interacciones contenidas en el fragmento, de manera muy similar a
como lo hace una instrucción condicional en un programa. De hecho, si se desea asociar el
fragmento opt con una estructura de control, sería muy similar a una instrucción if y la guarda
se convertiría entonces en la condición a evaluar para determinar si se entra o no al if, para
ejecutar las instrucciones allí contenidas.

Fragmento alt.
En ocasiones, una sola condición no es suficiente para indicar el flujo de una interacción. En
esas situaciones, un fragmento de tipo alt es la solución.

Un fragmento alt tiene múltiples guardas que indican múltiples puntos de entrada a la
ejecución de las interacciones contenidas en el fragmento principal. Si se quiere establecer
una relación de similitud con alguna estructura de control, un fragmento alt correspondería a
una sentencia de tipo switch-case. Es acostumbrado incluir al final una guarda de tipo [else]
para que se ejecuten las interacciones allí contenidas, en caso de que ninguna de las
guardas previas haya sido disparada.

Fragmento loop.
Otro tipo de fragmento que resulta altamente útil es el fragmento loop. Este indica que las
interacciones en él contenidas deben ser ejecutadas tantas veces como indique la guarda
definida. Un ejemplo de un fragmento de tipo loop es:

En alianza con

 
Colombia
 

Nótese que en este ejemplo el fragmento loop está inmerso dentro de la opción else del
fragmento alt. Asimismo, la guarda definida indica que las interacciones contenidas en el
fragmento deben ejecutarse cinco veces. La notación utilizada es semejante a la usada
cuando se define una instrucción de control de tipo for. De hecho, el comportamiento
descrito por un fragmento loop es equivalente al descrito por una estructura de control for.

En alianza con

 
Colombia