Este documento presenta diferentes diagramas de comportamiento en UML, incluyendo diagramas de casos de uso, secuencias, estados y actividades. Explica qué es cada diagrama, sus componentes y cómo modelar diferentes tipos de comportamiento usando estos diagramas. También incluye ejemplos y una bibliografía al final.

1. Modelo de negocio:
Diagramas de comportamiento
Joan Sebastián Ramírez Pérez
2015

2. Agenda
 ¿Qué diagramas vamos a abordar?
 Diagrama de casos de uso
 Diagrama de secuencias
 Diagrama de estados
 Diagrama de actividades
 Bibliografía

3. Agenda
 ¿Qué diagramas vamos a abordar?
 Diagrama de casos de uso
 Diagrama de secuencias
 Diagrama de estados
 Diagrama de actividades
 Bibliografía

4. UML 2.0

5. Diagramas de comportamiento
 Casos de uso.
 Actividades.
 Estados.
 Diagramas de interacción: Secuencias, comunicaciones, vista de interacción y
tiempos.

6. Agenda
 ¿Qué diagramas vamos a abordar?
 Diagrama de casos de uso
 Diagrama de secuencias
 Diagrama de estados
 Diagrama de actividades
 Bibliografía

7. ¿Qué es un diagrama de casos de uso?
 Dana Bredemeyer: “Describe un conjunto de interacciones entre actores externos y
el sistema en consideración orientadas a satisfacer un objetivo de un actor”.
 Craig Larman: “Es una colección de escenarios de éxito y fracaso relacionados que
describe a los actores que usan un sistema para conseguir un objetivo”.
 Alistair Cockburn: “Es una colección de posibles secuencias de interacciones entre
el sistema en discusión y sus actores externos, relacionado con un objetivo
particular”.

8. ¿Qué contienen los casos de uso?
 Actores: roles que interactúan con el sistema.
 Casos de uso: funciones del sistema.
 Interacciones o vínculos entre actores y casos de uso.

9. ¿Qué son escenarios?
 Craig Larman: “Secuencia específica de acciones e interacción entre el usuario y el
Sistema Bajo Discusión”.
 Es una instancia de un caso de uso que se especifica a través de un diagrama de
secuencia(SSD) o textual.

10. Tipos de escenarios
 Escenarios de eventos principales
 Escenarios alternativos
 Escenarios excepcionales

11. Actores
 Un actor representa un conjunto coherente de roles que juegan los usuarios de los
casos de uso al interaccionar con el sistema.
 Roles jugados por personas, dispositivos, u otros sistemas.
 No forman parte del sistema (Excepto el SUD -System Under Discussion-)
 Alistair Cockburn distingue dos tipos de actores: primarios (requieren del sistema) y
secundarios o de soporte (el sistema requiere de ellos).
 Craig Larman distingue tres tipos de actores: primarios, de soporte y externos.

12. ¿Qué son las colaboraciones?
 Sociedad de clases y otros elementos que colaborarán para realizar el
comportamiento expresado en un caso de uso.
 Una colaboración tiene una parte estática (diagramas de clases) y una parte
dinámica (diagramas de secuencia).

13. Casos de uso y colaboraciones
 Con un caso de uso se describe un comportamiento esperado del sistema, pero no
se especifica cómo se implementa.

14. Plantilla para casos de uso
(Derek Coleman)

15. Plantilla para casos de uso
(A. Cockburn)

16. Plantilla para casos de uso
(Variante a dos columnas)

17. Tipos de relaciones o vínculos
 Generalización: un caso de uso hereda el comportamiento y significado de otro.
 Inclusión: un caso de uso base incorpora explícitamente el comportamiento de otro
en algún lugar de su secuencia. (Flujo Obligatorio)
 Extensión: un caso de uso base incorpora el comportamiento de otro, en el lugar
especificado por este otro. (Flujo Alternativo)

18. Tipos de relaciones o vínculos

19. Relación de inclusión
 Permite factorizar un comportamiento en un caso de uso aparte y evitar repetir un
mismo flujo en diferentes casos de uso.
 Ejemplo del caso de uso “Hacer Pedido”:
– Obtener y verificar el número de pedido.
– Incluir “Validar usuario”. <<Include>>
– Examinar el estado de cada parte del pedido.
– Preparar un informe para el usuario”.

20. Relación de extensión
 El caso de uso base incluye una serie de puntos de extensión.
 Sirve para modelar la parte opcional del sistema, un subflujo que sólo se ejecuta
bajo ciertas condiciones o varios flujos que se pueden insertar en un punto
 Ejemplo: el caso de uso “Hacer Pedido” tiene un flujo excepcional:
- Si se establece una prioridad.
- Se necesita “Hacer un Pedido Urgente” <<extend>>

21. Listas de chequeo

22. Casos de uso
 ¿Está relacionado con, al menos, un actor u otro caso de uso?
 ¿Está escrito en voz activa?
 ¿Describe qué ocurre y no cómo?
 ¿Resulta demasiado largo para ser legible o demasiado corto para tener entidad
propia?
 ¿Su nombre está orientado al punto de vista del actor y no del sistema?

23. Actores
 ¿Son entidades (humanas, organizaciones, dispositivos o sistemas) externos al
sistema?
 ¿Son abstracciones de roles, no una persona particular?

24. Diagramas
 ¿Define claramente los límites del sistema?
 ¿Representa un conjunto cohesivo de casos de uso?
 ¿Tienen un tamaño apropiado o sería conveniente dividirlo en paquetes?

25. Relaciones
 La clausula «extends» ¿se usa para describir alternativas o extensiones opcionales
del caso de uso?
 La clausula «includes» ¿se usa para describir un conjunto común de pasos a varios
casos de uso?
 La excepción ¿se usa para expresar una situación excepcional?

26. Paquetes en casos de uso

27. Agenda
 ¿Qué diagramas vamos a abordar?
 Diagrama de casos de uso
 Diagrama de secuencias
 Diagrama de estados
 Diagrama de actividades
 Bibliografía

28. Diagrama de secuencia
 Muestran el intercambio de mensajes (es decir la forma en que se invocan) en un
momento dado.
 Interacción entre clases en el tiempo.
 Los objetos están representados por líneas intermitentes verticales, con el nombre del
objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia
abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas
con los nombres de la operación y los parámetros.
 Los mensajes pueden ser síncronos, el tipo normal de llamada del mensaje donde se
pasa el control a objeto llamado hasta que el método finalice; o asíncronos donde se
devuelve el control directamente al objeto que realiza la llamada. Los mensajes
síncronos tienen una caja vertical en un lateral del objeto invocador que muestra el flujo
del control del programa.

29. Ejemplo

30. Diagrama de secuencias caso de uso hacer
pedido.

31. Agenda
 ¿Qué diagramas vamos a abordar?
 Diagrama de casos de uso
 Diagrama de secuencias
 Diagrama de estados
 Diagrama de actividades
 Bibliografía

32. ¿Qué representa un estado?
 Una condición durante la vida de un objeto durante la cual este satisface algunas
condiciones o espera por algún evento.

33. Diagrama de estados
 Es una máquina de estados que modela el comportamiento cambiante de las
clases reactivas.
 Un diagrama por cada clase reactiva.
 Los diagramas de estado muestran los varios estados por los cuales un objeto
pasa, así como los eventos que causan una transición de un estado a otro

34. Ejemplo de clases reactivas
 Ordenes de compra.
 Solicitud de vacaciones.
 Artículo de revista.
 Transacciones.
 Solicitud de crédito.

35. ¿Qué contiene un diagrama de estados?
 Estados.
 Inicio y Final.
 Transiciones.
 Entry, do, y exit.

36. Ejemplo
New Order
do/ add line items
Customer
Order
Completed Request
entry/ authorize payment
Confirmed
entry/ notify customer
Shipped
entry/ notify customer
Canceled
entry/ record cancellation
create new
line item added
add customer information
payment information added
payment received
shipped to customer
after 15 min.
payment rejected

37. Agenda
 ¿Qué diagramas vamos a abordar?
 Diagrama de casos de uso
 Diagrama de secuencias
 Diagrama de estados
 Diagrama de actividades
 Bibliografía

38. Diagrama de actividades
 Describen la secuencia de las actividades en un sistema.
 Siempre están asociados a una clase, a una operación o a un caso de uso.
 Requieren de al menos un inicio y un final.

40. Ejemplo

41. Agenda
 ¿Qué diagramas vamos a abordar?
 Diagrama de casos de uso
 Diagrama de secuencias
 Diagrama de estados
 Diagrama de actividades
 Bibliografía

42. Bibliografía
 Larman,C.:UmlyPatrones:Introducciónalanálisisydiseñoorientadoaobjetos,2ed.PrenticeHa
ll.2005.627p.
 Ambler,S.TheObjectPrimer.SecondEdition.CambridgeUniversityPress.2001.
 Buschmann,Franketal.:PatternOrientedSoftwareArchitecture,Volume1:ASystemofPatterns
,Willey&Sons,1996.
 GammaE.,Helm,R.,Johnson,R.,VlissidesJ.:DesignPatterns:ElementsofReusableObjectOrient
edSoftware,AddisonWesley,1995.
 Martin,J.YOdell,J.Analisisydiseñoorientadoaobjetos.PrenticeHall.1992.
 Eckel,Bruce.ThinkinginJava.PrenticeHall.1998.
 Cockburn, Alistair. Writing effective uses case. Addison-Wesley, 2000.
 Fowler,M.PatternsofEnterpriseApplicationArchitecture.Addison-Wesley.2003.
 Gamma,Helm,JohnsonyVlissides.DesignPatterns.Addison-Wesley.1995.

44. Gracias