Diagramas de

interacción

Nehil Muñoz Casildo

Diagramas UML para Análisis
UML está compuesto por los siguientes
diagramas:
 Vista de interacción
Una vista de interacción muestra el flujo
de control requerido que se establece
entre los objetos.
 Diagramas de interacción de UML

¿Cuáles son?

UML define dos Diagramas de Interacción:

 Diagrama de Secuencia
 Diagrama de Comunicación
 Diagramas de interacción de UML

Muestran como los objetos se

comunican unos con otros para
satisfacer los requerimientos.

¿Para qué se utilizan?

 Diagramas de Interacción

Diagramas de Interacción
 Usos comunes
• Modelar los aspectos dinámicos de un sistema.
• El uso de estos diagramas es en el contexto del
sistema como un todo, un subsistema, una
operación, o una clase.
• Podemos unir diagramas de interacción para
casos de uso (para modelar un escenario) y para
colaboraciones (para modelar los aspectos
dinámicos de una sociedad de objetos).
 Diagramas de Interacción

Diagramas de Interacción
 Usos comunes
• Cuando modelamos los aspectos dinámicos de un
sistema, usamos diagramas de interacción de dos
maneras:
– Para modelar flujos de control por orden de tiempo
» Se usan diagramas de secuencia. Se hace énfasis en el
paso de mensajes, en cómo se desenvuelven sobre el
tiempo, lo cual es una manera útil para visualizar el
comportamiento dinámico en el contexto de un escenario
de un caso de uso.
– Para modelar flujos de control por organización
» Se usan diagramas de colaboración. Se hace énfasis en
las relaciones estructurales entre las instancias dentro de
la interacción y junto con los mensajes que pueden ser
pasados.
• Los diagramas de colaboración hacen un mejor
trabajo para visualizar iteraciones y bifurcaciones
complejas y para visualizar flujos de concurrencia
múltiple de control.
 Componentes
•Actores y Objetos
de las clases,

•Eventos

•Orden de los eventos

 Reglas básicas para elaborarlos

• Un diagrama por cada caso de uso

• Si el diagrama es grande, dividirlo
• Diseñe los diagramas de interacción
utilizando la descripción de casos de uso.
 ¿Cómo nombrar los eventos?

 Denominarse en el nivel de propósito y no el

medio físico de entrada o de elementos de la
interfaz.
 Comenzar con verbos en infinitivo.
 Captar el propósito de la operación y no
pronunciarse respecto a las decisiones de
diseño sobre una interfaz TerminarVenta -
PresionarEnter.
 Expresar las operaciones procurando alcanzar
el nivel más alto o la meta final.
 ¿Cómo nombrar los eventos?

IntroducirImporteOfrecido(Monto)
IntroducirPago(Monto)
EfectuarPago(Monto)

EfectuarPago(Monto)
Cada vez mejor! Importante:
Describir el
Propósito
 Mensajes

 Los eventos contienen mensajes.

 Un mensaje desencadena una acción en el
objeto destinatario.
 Un mensaje se envía si han sido enviados
los mensajes de una lista (sincronización):
A.1, B.3 / 1:Mensaje
B
A

Mensaje()
 Tipos de Mensajes

 Sincrónicos: el que envía espera por la respuesta

que retorna el que recibe.

 Asincrónicos: el que envía puede estar haciendo

otras cosas, no necesita esperar por la respuesta.

 Retorno de mensaje:

<<create>>
 Creación de un objeto: P1:Class

<<destroy>>
 Destrucción:
 Diagramas de interacción

Explica gráficamente las

interacciones existentes entre las
instancias de las clases
(habitualmente de un solo caso de uso)

Diagramas Diagramas de
de colaboración
secuencia
Diagramas de colaboracion
vs. Diagrama de secuencia
 Diagramas de colaboracion vs. Diagrama
de secuencia

(Habilidad para representar el paso del tiempo gráficamente)

(Se pierde claridad cuando hay mensajes condicionales)
 Interacción: Secuencia
Definición según OMG
 "Un diagrama que representa una interacción poniendo el
foco en la secuencia de los mensajes que se intercambian,
junto con sus correspondientes ocurrencias de eventos en
las líneas de vida.”

 "A diferencia de un diagrama de comunicación, un

diagrama de secuencias incluye secuencias de tiempo
pero no incluye relaciones de los objetos. Un diagrama de
secuencias puede existir en una forma genérica (describe
todos los escenarios posibles) y en una forma de instancia
(describe un escenario actual). Los diagramas de
secuencias y los diagramas de comunicación expresan
información similar, pero la muestran de diferentes
formas."
 Diagramas de secuencia

Describen las interacciones en una especie de

formato de cerca o muro

:ClaseA :ClaseB

mensaje1 ()
mensaje2 ()

mensaje3 ()

Capturan el comportamiento dinámico (orientado

al tiempo)
Diagrama de secuencia para cada caso de uso
 Iteración para grupos de mensajes

:Instancia1 :Instancia2 :Instancia3

*[i:=1..N]
 Diagramas UML 2.0

 Los diagramas de secuencia de UML 2.0 utilizan la

notación de los MSC (Message Sequence Charts).
 Notación gráfica para:
 Condiciones.
 Repeticiones.
 Alternativas.
 Partes opcionales.
 Inclusiones de diagramas.
 UML 2.0: Expresiones en línea

 Alternativa (alt).
 Composición paralela (par).
 Iteración (loop).
 Composición opcional (opt).
 Composición excepcional (exc).

Instancia1 Instancia2 Instancia3

Marco de expresión

Operador

Regiones de
una expresión
 UML 2.0: Referencias a diagramas

 Expresiones dentro de un MSC que permiten

referenciar a otro diagrama:
 Simples (referencias planas)
 Compuestas (referencias planas + operadores alt, par, loop,
Instancia1 Instancia2
etc.)

alt r

A Referencia Simple

B alt C Referencia Compuesta

 UML 2.0: ejemplo

Bibliotecario I.U O.C Socio Libro Préstamo

Nuevo Préstamo
Nuevo Préstamo
Datos Socio?

Buscar Socio

Datos Libro?

Libro(Signatura) Libro(Signatura) ComprobarEstado(Signatura)

alt
Error('Libro no existe') not ok
Error('Libro no existe')

ok

ObtenerFecha
Datos(FechaDev)
Fecha(FechaDev)

Confirmar?
Confirmar?

alt Prestar Prestar

Crear Préstamo(Signatura, Socio)

Anular Anular
 UML 2.0: ejemplo

Empleado I.U O.C Cliente Artículo Pedido

Nueva Venta

Datos Cliente?
Nueva Venta New()
Buscar Cliente

loop (1,N) Linea?

Linea(Cod, Cant) Linea(Cod, Cant)

Comprobar(cod,Cant)
ok

ObtenerDatos(Cod)

Datos(PVP, Descripción)
Datos(PVP, Descripción) addLinea(cod,can)
Forma Pago?
Pago(TipoPago) Pago(TipoPago)

alt
when TipoPago = Tarjeta

Pago con Tarjeta

when TipoPago = Contado

Pago en Efectivo
 ¿Cómo usar los objetos en los diagramas?

Una línea de vida puede representar un objeto o

su clase. Usualmente representa los objetos de
una clase.
Los objetos pueden no nombrarse, pero deben
nombrarse si usted quiere discriminar diferentes
objetos de una misma clase.
Varias líneas de vida en el mismo diagrama
pueden representar diferentes objetos de una
misma clase, pero los objetos tienen que
nombrarse de manera diferente.
Directrices en la creación del diagrama de secuencia

1. Representar los actores y la clase

interfaz del sistema que recibe las
acciones del usuario (Menú).
2. Seleccionar la clase controladora que se
encargue del mensaje de las
operaciones del sistema.
 Directrices en la creación del diagrama de secuencia

3. Aplicar el principio de separación de

modelo-vista.
No compete a los objetos del dominio
comunicarse con los objetos de la
interfaz, lo hacen las controladoras.
4. Revisar las postcondiciones que se
describieron para ese caso de uso, de manera
que se garanticen.
 Diagrama de secuencia
Ejemplo

Jefe de obra Económico

Aprobar/rechazar proyecto
Evaluar un proyecto
económicamente
Evaluar un proyecto
técnicamente
 Diagrama de secuencia

Ejemplo: CUS Aprobar/Rechazar proyecto

 : Maestro de
: Jefe de obra: CI-Menú : CC-Aceptar/Rechazar : CI-Aceptar/Rechazar : Proyecto
proyectos
proyecto
Aceptar/Rechazar un proyecto( )
Aceptar/Rechazar proyecto( ) Proyectos:=Obtener todos los proyectos evaluados técnica y económicamente( )

Proyecto:=Obtener datos del proyecto( )

Técnicamente:=Verificar si está evaluado técnicamente( )

Solo se devuelven
Económicamente:=Verificar si está evaluado económicamen
los datos si el tiene
ambas evaluaciones

Mostrar todos los proyectos(Proyectos )

Indica resultados de análisis de un proyecto( )

Registrar Aceptación/Rechazo( Proyecto,Aceptación/Rechazo)

Si no es el
Registrar Aceptación/Rechazo( Proyecto,Aceptación/Rechazo) proyecto, no se
cambia el estado
Cambiar estado( Proyecto,Aceptación/Rechazo)

Verificar si es proyecto(Proyecto )

Cambiar estado( Aceptado)

Cambiar estado( Rechazado)

Se ejecuta uno u
otro método
 Diagrama de clases antes de construir el
Diagrama de interacción

Jefe de obra CI-Menú CC-Aceptar/Rechazar CI-Aceptar/Rechazar

proyecto

Maestro de
proyectos
0..n
Proyecto
Diagrama de clases después de construir el Diagrama de interacción
Diagramas de
Colaboracion
 Diagrama de Colaboracion

 Son útiles en la fase exploratoria para identificar

objetos.
 Representa la forma en que los objetos interactúan y
las conexiones necesarias para soportar esta
interacción.

2:mensaje2 ()
1:mensaje1 ()
3:mensaje3 ()
:ClaseA :ClaseB

Capturan el comportamiento dinámico (orientado a

los mensajes)
 Diagrama de Colaboracion

 La distribución de los objetos en el diagrama permite

observar adecuadamente la interacción de un objeto
con respecto de los demás.
 La estructura estática viene dada por los enlaces; la
dinámica por el envío de mensajes por los enlaces.

2:mensaje2 ()
1:mensaje1 ()
3:mensaje3 ()
:ClaseA :ClaseB

Capturan el comportamiento dinámico (orientado a

los mensajes)
 Diagrama de Colaboracion

primer mensaje primer mensaje interno

parámetros

mensaje1(parametros) 1: mensaje1(parametros)
:InstClaseA :InstClaseB

línea enlace instancia 1.1: mensaje1(parametros)

mensaje anidado
dirección mensaje :InstClaseC
 Diagramas de colaboración:
Notación

msg()

:Instancia 1 :Instancia 2
1: msg()
2: msg()

Enlace
Orden del
Dirección
mensaje
 Diagramas de colaboración
 Los enlaces muestran el intercambio de mensajes entre
objetos:
 Los mensajes se pueden intercambiar en los dos sentidos.
 Varios mensajes se pueden intercambiar en la misma
dirección.
 Notación para mensajes:
 valor:= mensaje(parámetro:tipo):tiporetorno
 Diagramas de colaboración

 La información de tipos puede ser excluida si es obvia o

no es importante.
 Descripción:= GetDescrProducto(id)
 Descripción:= GetDescrProducto(id:ItemID)
 Descripción:= GetDescrProducto(id:ItemID):DescrProducto
 Diagramas de colaboración
 La flecha indica la dirección del mensaje
 La secuencia de números describe el orden
 1, 2.1, 3.4.1
 Los mensajes puede dirigirse también a la instancia
actual (self,this).

:Instancia 1

1.2: limpiar()
 Diagramas de colaboración:
numeración de mensajes

 El primer mensaje no se numera

 Representa una acción/evento que dispara la colaboración
 Si se recibe un mensaje m con número x.y.z, entonces
los mensajes que se envían durante el procesado de m
se numeran con: x.y.z.1, x.y.z.2, etc.
 Diagramas de colaboración:
numeración de mensajes

Msg1()
1:Msg2()
:Instancia 1 :Instancia 2

1.1:Msg3()

2.1:Msg5()
2:Msg4()
:Instancia 3

2.2:Msg6()

:Instancia 4
 Diagramas de colaboración

 La creación de instancias se indica mediante create().

 Puede contener parámetros: create(DNI)
 La notación para las condiciones en el envío de
mensajes y para las iteraciones es similar a la utilizada
en los diagramas de secuencia.
 Cómo preparar diagramas de colaboración

1. Elabore un diagrama por cada operación del sistema durante

el ciclo actual de desarrollo.

r En cada mensaje del sistema, dibuje un

diagrama incluyéndolo como mensaje inicial.

2. Si el diagrama se torna complejo (por ejemplo, si no

cabe holgadamente en una hoja de papel 8.5x11),
dividalo en diagramas más pequeños.
 Diagrama de Secuencia, Caso de Uso
SurtirOrden
Se dibuja 1 diagrama de secuencia para cada
escenario.
Primero identificar todos los objetos
participantes, y se colocan hasta arriba del
diagrama. No importa el orden pero puede ser
que se vayan moviendo para mejorar la
comprensión del diagrama.
Este caso incluye: el dependiente que surte las
órdenes, el sistema en sí mismo, la base de dato
de las órdenes, la orden principal y la backorder
y el inventario.
 Diagrama de secuencia: objetos y líneas de
tiempo

:Dependiente :System :OrdersDB 12345:Order 23456:Order :Inventario

 El primer diagrama de Secuencia modela el escenario 1.
Este escenario es el camino exitoso, el más
comprensible. Los otros escenarios se van derivando
del camino principal.
 Cada paso del diagrama de flujo se convierte en un
mensaje o en un return en el diagrama de Secuencia.
 El primer paso es: El sistema pide número de orden, en
el diagrama de secuencia aparece como un
procedimiento llamado paso 1 y la respuesta del
dependiente del número de orden es el paso 2.
 El formato de un mensaje es:
 Un número de secuencia (opcional)
 Dos puntos
 Condición (opcional), entre corchetes cuadrados [ ].
 Identificación de la operación: Visibilidad (+pública, -privada,
#protegida). Nombre de la operación. Argumentos, se ponen
entre paréntesis (). Dos puntos. Tipo de dato de retorno.
 Pasos 1 y 2;
obtener el número de orden

:Dependiente :System :OrdersDB 12345:Order 23456:Order :Inventario

1:getOrderNbr():int

2:return 12345
El siguiente paso es la consulta a la base de
datos, en el Caso de Uso corresponde a “¿Se
encontró la orden?, en el diagrama de
secuencias se detalla el mensaje y la respuesta,
que en la siguiente figura corresponden a los
pasos 3 y 4.
El valor de regreso es simplemente él número
de orden. El diagrama de secuencias modela
un caso de prueba, por lo que el return debe ser
un valor. Si se está modelando una regla, el
retorno será el tipo de dato más que un valor.
 Pasos 3 y 4;
obtener la orden usando el número de orden

:Dependiente :System :OrdersDB 12345:Order 23456:Order :Inventario

1:getOrderNbr():int

2:return 12345

3:getOrder(ordernbr:int):Order

4:return Order 12345

 El siguiente paso es “Desplegar Orden”, (mostrar la
orden correspondiente). Ya que este mensaje no
requiere respuesta, la figura muestra el uso de una
comunicación asíncrona usando una flecha con punta
tipo
 En este caso no hay flecha de retorno correspondiente.
No hay valor de retorno y por lo tanto el tipo de retorno
es “void”.
 Poner un mensaje asíncrono

:Dependiente :System :OrdersDB 12345:Order 23456:Order :Inventario

1:getOrderNbr():int

2:return 12345

3:getOrder(ordernbr:int):Order

4:return Order 12345

5:displayOrder(Order):void
 Una vez que se desplegó la orden en el paso 5, el
sistema le pide al usuario que seleccione el primer ítem
para buscarlo, es el paso 6: getItem( ):int.
 El sistema espera obtener un entero que represente el
número de ítem en la Orden para buscarlo, obtiene la
respuesta en el paso 7: item #1.
 El sistema en el paso 8 busca el item en el inventario:
 8:[item found] getProduct(itemnbr:int):boolean
 En el paso 9 responde true, significa que si lo encontró,
recordemos que estamos en el camino más sencillo.
 En el paso 10 el sistema pide la cantidad de producto y
el dependiente se la da en el paso 11.
 En los pasos 12 y 13 se actualiza el inventario y
responde que se llevó a cabo la operación, (return
verdadero)
 Continuación…

:Dependiente :System :OrdersDB 12345:Order 23456:Order :Inventario

[para c/ítem]:Finalizar()
6:getItem():int
7:return item#1

8:[item found] getProduct(itemnbr:int):boolean

9:return true

10:getQty( 9:int

11: return 25kg

12:reduceinv(prod:Product):boolean

13:return true
 Observaciones

En la figura se pueden ver las activaciones de

los objetos: los rectángulos verticales angostos
en las líneas de tiempo. Las activaciones
indican cuando está ocupado cada objeto. La
activación inicia cuando un mensaje toca la línea
de tiempo y termina cuando la respuesta es
enviada de regreso.
En el caso del objeto system, su activación está
en todo el diagrama mostrando que el sistema
está vigilando todo el juego de interacciones.
También se conoce como el foco.
 Escenario 2

 Se repiten los pasos 1, 2 y 3 del escenario 1.

 El siguiente paso debe desplegar el mensaje de que la
orden no se encontró.
 Escenario 2

:Dependiente :System :OrdersDB 12345:Order 2345:Order :Inventario

Repetir pasos 1 al 3 del escenario 1 y después:

1:displayMsg(chars):void
 Escenario 3

 Son los mismos primeros 7 pasos del escenario 1.

 Si el ítem no se encuentra, hay que crear una backorder.
 Escenario 3

:Dependiente :System :OrdersDB 12345:Order 23456:Order :Inventario

Repetir pasos 1 al 7 del escenario 1 y entonces:

Si [item not found] crear una backorder

1:[items no
surtidos>0]backorder(item:int):Order

2: return Order 23456

 Escenario 4
Repetir todos los pasos del 1 pero incluir el ciclo para repetir para todos los
items
:Dependiente :System :OrdersDB 12345:Order 23456:Order :Inventario
[para c/ítem]:Finalizar()
6:getItem():int
7:return item#1

8:[item found] getProduct(itemnbr:int):boolean

9:return true

10:getQty( 9:int

11: return 25kg

12:reduceinv(prod:Product):boolean

13:return true
 Objetivo Diagrama de Secuencias

 Descubrir las interfases requeridas para cada objeto y

validar que cada interfase se usa realmente.
 El diagrama de Secuencias modela interacciones entre
objetos. Ya que estas interacciones pueden ser muy
complejas, se modelan un pequeño juego de
interacciones como un solo escenario.
 Resumen: para construir el diagrama

Identificar a los objetos participantes

Dibujar una línea vertical bajo cada objeto, que
representa la línea de tiempo
Cada mensaje se convierte en una línea
horizontal del objeto que manda al que recibe.
Para un mensaje síncrono o procedimiento de
llamada se requiere una respuesta.
Los asíncronos no necesitan respuesta.