1. UML

2. Modelos y Diagramas
 Un proceso de desarrollo de software debe ofrecer un
conjunto de modelos que permitan expresar el producto
desde cada una de las perspectivas de interés
 El código fuente del sistema es el modelo más detallado
del sistema (y además es ejecutable). Sin embargo, se
requieren otros modelos ...
 Cada modelo es completo desde su punto de vista del
sistema, sin embargo, existen relaciones de trazabilidad
entre los diferentes modelos

3. Modelos y Diagramas
 Modelo: captura una vista de un sistema del mundo
real. Es una abstracción de dicho sistema,
considerando un cierto propósito.
 Diagrama: representación gráfica de una colección de
elementos de modelado, a menudo dibujada como un
grafo con vértices conectados por arcos.

4. Organización de Modelos
Vista de
Vista de Diseño Implementación
Vista de los
Casos de Uso
Vista de Vista de
Procesos Despliegue

5. Diagramas de UML
State
State
Use Case Diagrams de
Diagramas
Use Case Diagrams State
Use Case Diagrams de
Diagramas Clases State
Use Case Diagrams Diagrams de
Diagramas
Diagrams de
Diagramas Casos de Uso Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario State
Diagrams de
Diagramas Diagrams de
Diagramas
Diagrams Diagrams
Colaboración Modelo Componentes
Scenario Component
Scenario Component
Diagramas de
Diagrams
Diagrams de
Diagramas Diagrams
Diagrams Distribución
Estados Diagramas de
Actividad

6. Casos de Uso

7. Casos de Usos
 Un Caso de Uso muestra la distintas
operaciones que se esperan de una aplicación o
sistema y cómo se relaciona con su entorno
(usuario u otras aplicaciones).
 Es una herramienta esencial para la captura de
requerimientos y para la planificación y control
de un proyecto interactivo.

8. Casos de Usos
 Los Casos de Uso son qué hace el sistema
desde el punto de vista del usuario. Describen
un uso del sistema y cómo este interactúa con el
usuario.
 Escenario: Secuencia de pasos para describir una
interacción entre un usuario y un sistema.
 Casos de Uso: Conjunto de escenarios unidos por
una meta del usuario en común.
 Actor: Rol que juega el usuario con respecto a un
sistema.
 Un actor realiza varios casos de uso
 Un caso de uso puede involucrar varios actores

9. Casos de Usos
 Cada caso de uso es una operación
completa desarrollada por los actores y
por el sistema en un diálogo.
 El conjunto de casos de uso representa la
totalidad de operaciones desarrolladas por
el sistema.

10. Template de Caso de Uso
 Nombre del CU:
 Actores:
 Descripción:
 Referencias a Funciones del Sistema:
 Pre-condición
 Post-condicion
 Curso Básico
 Cursos Alternativos
 Cursos de Excepción

11. Cursos de un Casos de Uso
Un caso de uso:
•Tiene UN curso básico, que es la secuencia
exitosa de eventos.
•Puede tener variantes del curso básico que
son cursos alternativos.
•Puede tener varios cursos de excepción
para el manejo de errores.

12. Participantes de un Caso de Uso
 Actor: Es un usuario del sistema, que necesita o
usa alguno de los casos de uso.
 Un usuario puede jugar más de un rol.
 Un solo actor puede actuar en muchos casos de uso;
recíprocamente, un caso de uso puede tener varios
actores.
 Los actores no necesitan ser humanos pueden ser
sistemas externos que necesitan alguna información
del sistema actual.

13. Relaciones en los Diagramas de Casos
de Usos
 También se puede encontrar tres tipos de
relaciones, como son:
 Comunica (comunicates) Entre un actor y un
caso de uso (u otro actor), denota la
participación del actor en el caso de uso
determinado.

14. Relaciones en los Diagramas de Casos
de Usos
 Usa o Incluye (uses/includes): Relación
entre dos casos de uso, denota la inclusión
del comportamiento de un escenario en otro.
 Se utiliza cuando se repite un caso de uso en
dos o más casos de uso separados.
 Frecuentemente no hay actor asociado con el
caso de uso común.

15. Relaciones en los Diagramas de Casos de
Usos
 Extiende (extends): Relación entre dos
casos, denota cuando un caso de uso es
una especialización de otro.
 Se usa cuando se describe una variación
sobre el normal comportamiento.
 Agrega pasos a un caso de uso existente.

16. Ejemplo de extends
 •Nombre: Facturar Pago
 1. El caso de uso comienza cuando un cliente llega a la caja
 .........
 X. Si la fecha de pago excede la fecha actual (Factura Vencida)
 .............................
 Nombre: Facturar Vencimiento de Pago
 1. Se calcula el interés correspondiente al monto.....

17. Otro tipo de relación
 Generalización: Denota una relación de
Herencia. Un caso de uso hereda
comportamiento de otro.

18. Diagrama de Caso de Uso
Ej: Maquina expendedora
Buy a
product Self Service Machine
<<includes>>
customer Open Machine
Restock
<<extends>>
(generalized actor)
<<includes>> Close Machine
Restock according to sales
Supplier Agent <<includes>>
Open Machine
Collect
Restocker Collector
<<includes>>
Close Machine

19. Diagrama de Caso de Uso
Ejemplo: Registro Web

20. Caso de uso en forma de dialogo
Ejemplo: Comprar productos
Curso Básico
ACTOR SISTEMA
1. Selecciona de la lista de productos los
que va a comprar
2. Valida que haya stock
3. Ingresa la información de envío
4. Muestra costos de compra y de envío
5. Ingresa la información de tarjeta de
crédito
6. Confirma la compra
7. Autoriza la compra
8. Registra la compra e imprime factura

21. Caso de uso en forma de dialogo
Ejemplo: Comprar productos
Curso Alternativo
2 .1 No hay stock disponible de algún producto.
Envía mensaje al operador, que puede confirmar
la operación sin incluir el producto o cancelar
toda la operación.
7.1No se autoriza la compra. El sistema envía un
mensaje al usuario, que puede reingresar los
datos con la misma tarjeta o con otra, o cancelar
la operación.

22. Caso de uso en forma de dialogo
Ejemplo: Comprar productos
Cursos de excepción
- Se cortó la comunicación con el
servidor. No se lleva a cabo la
transacción.

23. Casos de Usos
 Técnicas comunes de modelado:
 Modelado del contexto del sistema.
 Modelado de los requisitos de un sistema.
 Modelado del proceso de test y estrés del
sistema.

24. Diagramas de Interacción

25. Introducción
Los diagramas UML de secuencia y de colaboración
(llamados diagramas de interacción o comportamiento) se
utilizan para modelar los aspectos dinámicos de un sistema.
Un diagrama de interacción consiste en un conjunto de
objetos y sus relaciones, incluyendo los mensajes que se
pueden enviar entre ellos.
Los diagramas de secuencia destacan el orden temporal de
los mensajes. Los diagramas de colaboración destacan la
organización estructural de los objetos que envían y reciben
mensajes.

26. Ejemplos
Diagrama de secuencia:
destaca el orden temporal objetoA:A objetoB:B objetoC:C
de los mensajes.
<<create>>
mensaje1( )
objetos
mensaje2( )
tiempo mensaje3( )
objetoA:A
<<destroy>>
1: <<create>>
2: mensaje1( )
3: <<destroy>>
objetoB:B objetoC:C Diagrama de colaboración:
2.1: mensaje2( )
destaca la relación estructural
2.2: mensaje3( ) entre los objetos que interactúan

27. Conceptos
Ambos diagramas (secuencia y colaboración) son semántica-
mente equivalentes.
Se puede pasar de uno a otro sin pérdida de información.

28. Diagramas de Interacción
 Los diagramas de Interacción explican gráficamente
cómo los objetos interactúan a través de mensajes
para realizar las tareas.
 Los diagramas de interacción se realizan en la etapa
de diseño de un ciclo de desarrollo.

29. Para desarrollar un diagrama de
interacción se requiere:
 Diagrama de Clases:
A partir de este modelo el diseñador podrá definir las
clases de software correspondientes.
 Los objetos de las clases participan en las interacciones
que se describen gráficamente en los diagramas.
 Casos de Uso:
A partir de ellos el diseñador recaba información sobre
las tareas que realizan los diagramas de interacción.

30. Diagramas de Interacción
 En los diagramas de Interacción es importante
considerar cuidadosamente la asignación de
responsabilidades y las habilidades que todo el
sistema requiere.
 En un proyecto de sistemas un porcentaje
considerable de tiempo debe destinarse a esta fase.
 Los diagramas de interacción constituyen uno de los
artefactos más importantes que se generan en el
análisis y en el diseño orientados a objetos.

31. Consideraciones en los Diagramas de
Interacción
 Se deberá elaborar un diagrama por cada operación
que realice el sistema.
 Si el diagrama se torna muy complejo (Si no cabe en
una página de papel) es mejor dividirlo en diagramas
más pequeños.
 Diseñe un sistema de objetos interactivos que realicen
las tareas definidas usando como base los escenarios
de los casos de uso y las post-condiciones de los
mismos.

32. Diagramas de interacción
 Elementos básicos de los diagramas de
interacción:
 Objetos o actores para cada entidad.
 Enlaces entre los objetos.
 Procedimientos a invocar entre los objetos.
 Mensajes entre los objetos.

33. Notación de las Clases y de las Instancias
en los Diagramas de Interacción
Oferta Clase
:Oferta Instancia
Instancia
x1:Oferta
con Nombre

34. Tipos de mensajes:
Sintaxis Nombre Semántica
Mensaje síncrono. El emisor espera hasta que el receptor
unMensaje (unParámetro) regresa de ejecutar el mensaje.
Mensaje El emisor envía el mensaje y continúa
asíncrono. ejecutando; no espera una respuesta
unMensaje (unParámetro) del receptor.
Retorno de El receptor de un mensaje anterior
mensaje. devuelve el foco del control al emisor
de ese mensaje.
Creación de objeto El emisor crea una instancia de la
<<create>> (Crea el objeto A) clase especificada por el receptor.
unMensaje() :A
:A Destrucción de El emisor destruye el receptor. Si la
<<destroy>>
objeto línea de vida tiene una línea vertical
(Destruye el discontinua, se termina con un X.
objeto A)

35. Objetos de Control
(Controller Objects)
 En la mayoría de escenarios los diagramas de casos de uso
se inicia con un actor inicial (el cual genera un evento sobre
el sistema).
 Los actores fuera del sistema necesitan además
comunicarse con otros objetos dentro del sistema.
 Es necesario escoger un objeto particular dentro del sistema
que sea el punto de contacto o la interfaz del sistema.
 Para estos casos un Objeto de Control es usualmente creado
para coordinar la interacción entre el actor con el resto del
sistema. Este se encarga de distribuir los mensajes entre los
objetos. (debido a que un objeto para enviar un mensaje a otro
objeto debe conocerlo).

36. Objetos de Control
Ejemplo: Cajero automático
 Un cliente (Actor) no puede comunicarse directamente con su
objeto cuenta. Debido a que existen millones de cuentas en
el banco a las que el cliente no debe tener acceso.
 El cliente debe proporcionar una tarjeta electrónica junto con
un código de seguridad para que el sistema pueda identificar
sus cuenta.
 En este caso es útil definir un nuevo objeto llamado Cajero
Automático que corresponde con el cajero físico que pueda
ser única e inmediatamente identificado por el actor, el
mismo que se encarga de distribuir los mensajes entre los
demás objetos del sistema.

37. Diagramas de Secuencia
Notación
 Los objetos son mostrados como cajas en la parte superior
del diagrama.
 El flujo del tiempo se muestra de arriba abajo.
 La linea de vida de un objeto es la línea discontinua
vertical, que representa la existencia de un objeto a lo
largo de un periodo de tiempo.
 Las áreas gruesas (“Fat Areas”) indican cuales objetos tiene
el control.
 El foco de control es un rectángulo delgado que
representa el periodo de tiempo durante el cual un objeto
ejecuta una acción.

38. Diagramas de Secuencia
Notación
 El actor puede representarse como un estereotipo dentro
del diagrama de secuencias (esta representación es
distinta al objeto que contiene la información del actor):
<<Actor>>
También se puede representar con:
 Cada objeto requiere una línea vertical (línea de tiempo
o lifeline) donde representar los mensajes que recibe y
las acciones que ejecuta.

39. Diagramas de Secuencia
 Eventos: son la comunicación entre los objetos o a
través de la frontera del sistema.
 Los eventos se expresan a través de flechas (con el nombre
del mensaje invocado) entre las líneas de tiempo del objeto
que lo envía y del objeto que lo recibe.
 El orden en que ocurren los eventos son mostrados de arriba
hacia abajo.
 Cada mensaje puede incluir los argumentos y los tipos de
retorno similar al diagrama de colaboración.
 Es posible representar invocaciones a eventos del mismo
objeto.
 El valor de retorno es opcionalmente mostrado al terminar la
Fat Area.

40. Diagramas de Secuencia
 Regiones de Control (Fat Areas): Muestran el
periodo de tiempo cuando un objeto tiene el control
del proceso.
 Concepto similar a las llamadas anidadas de
procedimientos.
 Una Fat Area es mostrada como un rectángulo en la línea
de tiempo de un objeto. Ello indica que el objeto está
actualmente activo dentro del sistema.
 El control de las regiones anidadas puede ser mostrado
(cuando un objeto le envía un mensaje a si mismo)
sobreponiendo dos Fat Areas (una encima de otra).

41. Diagramas de Secuencia
Ejemplos de Diagrama de Secuencias:
<<Actor>> :InstanciaClaseA :InstanciaClaseB
mensajeA()
mensajeB()
tiempo
Actor Fat Area
retorno
retorno
:InstanciaClaseA :InstanciaClaseB
mensajeA()
mensajeB() mensC() tiempo
retorno
Región
Anidada

42. Diagramas de Secuencia
 Mensajes Condicionales:
 Similar a los diagramas de colaboración existen los mensajes
condicionales que indica que un mensaje sólo puede ser enviado
cuando una condición es verdadera.
 Los mensajes condicionales son útiles en casos simples pero
para casos más complejos es recomendable realizar dos o más
diagramas.
 Las condiciones se encierran en corchetes ( “[ ]” ) similar a los
diagramas de colaboración.
:InstanciaClaseA :InstanciaClaseB
mensajeA()
[condición]mensajeB()
retorno

43. Diagramas de Secuencia
 Iteraciones:
 En los diagramas de secuencia es posible mostrar las
iteraciones de un proceso.
 Permite mostrar que un mensaje es enviado varias veces a
varios objetos receptores.
 Similar a los diagramas de colaboración se utiliza el asterisco
(“*”) como símbolo para indicar una iteración.
:InstanciaClaseA :InstanciaClaseB
mensajeA()
*[condición]mensajeB()
retorno
Indica que se encuentra en una
iteración hasta que se cumpla
la condición

44. Diagramas de Secuencia
 El Retorno:
 El retorno indica el regreso del control del flujo del proceso
del objeto receptor del mensaje previo al objeto que envío
tal mensaje.
 El retorno no es un nuevo mensaje.
 Algunos autores los muestran con líneas punteadas para
diferenciarlos de los mensajes normales.
 Es opcional colocar el Retorno. Principalmente cuando
este clarifica el diagrama y no lo hace más complejo.

45. Diagramas de Secuencia
 Creación y Destrucción Instancias.
 Es posible indicar la creación y destrucción de instancias.
 La creación de una nueva instancia se coloca esta a la altura
del mensaje de creación que esta recibió de otro objeto.
 Para indicar la destrucción de una instancia se coloca sobre la
línea de tiempo del mismo una equis (“X”)
:InstanciaClaseA :InstanciaClaseB Creación de
Instancia
mensajeA()
mensajeB()
mensajeC()
:InstanciaClaseC
retorno
retorno
Destrucción X
de Instancia

46. Diagramas de Secuencia
 Comentarios en los diagramas de secuencia:
 Se puede insertar descripciones textuales de que esta
ocurriendo en el diagrama con el fin de hacerlo más legible.
 Estos comentarios son insertados del lado izquierdo del
diagrama a la altura del conjunto de mensajes que se desea
comentar.
:InstanciaClaseA :InstanciaClaseB
Inicio del mensajeA()
proceso.
mensajeB()
Creación de la mensajeC()
nueva instancia de :InstanciaClaseC
la clase C.
retorno
Destrucción de la retorno
instancia de la X
Clase C

47. Ejemplo
Modelar una llamada a través de una central telefónica.
Para esto se tienen cuatro objetos involucrados:
• dos interlocutores (s y r)
• una central
• una conversación.
La secuencia empieza cuando un interlocutor envía un
mensaje a la central al descolgar el auricular.
La central da el tono de llamada, y el interlocutor marca el
número al que desea llamar.
El tiempo de marcado debe ser menor que 30 segundos.

48. Ejemplo
s:Interlocutor :Central r:Interlocutor
descolgarAuricular( )
darTonoDeLlamada( )
*marcarDigito( ) [marcando.tiempoEjecucion < 30 segs] enrutarLlamadas(s,n)
marcando
<<create>>
c:Conversación
llamar( )
descolgarAuricular( )
conectar(r,s)
conectar(r) conectar(s)
Los interlocutopres r y s pueden
intercambiar información después
de conectarse.

49. Diagramas de colaboración
Notación
Los diagramas de colaboración explican gráficamente
las interacciones entre las instancias del modelo (objetos).
Por ejemplo:

50. Diagramas de colaboración
Notación
Un objeto se puede enviar
un mensaje a sí mismo:
Es posible representar iteraciones:
msg1() {
for i := 1 to 10 {
miB.mens2();
miC.mens3();
}
}

51. Diagramas de colaboración
Notación
Secuencia de los mensajes en un diagrama de colaboración:

52. Diagramas de colaboración
Notación
Es posible definir mensajes condicionales:

53. Diagramas de colaboración
Notación
Es posible definir trayectorias mutuamente excluyentes:

54. Diagramas de colaboración
Notación
Un multiobjeto, por ejemplo un arreglo, se representa como
una pila de objetos:
Se pueden enviar mensajes a multiobjetos:

55. Diagramas de colaboración
Notación
Ejemplo de crear un objeto y agregarlo a un multiobjeto:

56. Ejemplo
Matricular un nuevo estudiante en la universidad
Hay cuatro objetos involucrados:
• un encargado de matrícula
• un estudiante
• un curso
• la universidad
La acción comienza cuando el encargado de matrícula crea
un objeto estudiante, lo añade a la universidad, y le pide al
objeto estudiante que se matricule.
El objeto estudiante obtiene (de sí mismo) su plan de
estudio, e identifica los cursos que quiere matricular.

57. Ejemplo
2: agregarEstudiante(s)
r:EncargadoMatricula :Universidad
1: <<create>> 3.1: obtenerPlanEstudios( )
3: matricular( )
s:Estudiante s:Estudiante
matriculado = False matriculado = True
3.4: <<become>>
3.2: agregar(s) 3.3: agregar(s)
c1:Curso c2:Curso
{asociación} {asociación}

58. COMPARACIÓN ENTRE DIAGRAMA DE
SECUENCIA Y DE COLABORACIÓN
Tipo Puntos fuertes Puntos débiles
Secuencia Muestra claramente la Fuerza a extender por
secuencia u ordenación en el la derecha cuando se
tiempo de los mensajes. añaden nuevos objetos;
Notación simple. consume espacio
horizontal.
Colaboración Economiza espacio, Difícil ver la secuencia
(Comunicación) flexibilidad al añadir nuevos de mensajes.
objetos porque crece en dos Notación más compleja
dimensiones.
Es mejor para ilustrar
bifurcaciones complejas,
iteraciones y comportamiento
concurrente.

59. MODELO DE IMPLEMENTACIÓN

60. Diagrama de Componentes

61. Diagrama de componentes
 Los diagramas de componentes describen
los elementos físicos reemplazables del
sistema y sus relaciones
 Muestran las opciones de realización
incluyendo código fuente, binario y
ejecutable

62. En UML se representa:
 Un componente posee características similares
a una clase: tiene nombre, realiza interfaces,
puede participar de relaciones, puede tener
instancias, puede participar en interacciones.
 Porqué se diferencian?
 Un componente representa un elemento físico (bits).
 Una clase es una abstracción lógica.
 El componente se puede representar en nodos
físicos, la clase no.
 Las operaciones de un componente solo se alcanzan
a través de interfaces. Las de una clase podrían ser
accesibles directamente.

63. Diagrama de componentes
 Los componentes representan todos los tipos de
elementos software que entran en la fabricación
de aplicaciones informáticas. Pueden ser simples
archivos, librerías, bibliotecas cargadas
dinámicamente, etc.
 Las relaciones de dependencia se utilizan en los
diagramas de componentes para indicar que un
componente utiliza los servicios ofrecidos por otro
componente

64. Componentes e interfaces
 Una interfaz contiene una colección de
operaciones y se utiliza para especificar
los servicios de una clase o de un
componente.
 Una interfaz se conecta al componente
que la implementa a través de una
relación de realización, y al componente
que utiliza sus servicios con una
dependencia.

65. Gráficamente

66. Tipos de componentes
 Componentes de despliegue: necesarios y
suficientes para formar un sistema ejecutable. Por
ejemplo: bibliotecas dinámicas (dll), ejecutables
(exe).
 Componentes productos de trabajo: surgen durante
el proceso de desarrollo y quedan al final del
mismo. Por ejemplo: una base de datos.
 Componentes de ejecución: se crean como
consecuencia de un sistema en ejecución. Por
ejemplo: objetos que se instancian a partir de una
dll.

67. Estereotipos estandar de
componentes
 executable: especifica un componente ejecutable
en un nodo.
 library: especifica una biblioteca de objetos.
 table: especifica una tabla de una BD.
 file: especifica un componente que contiene un
documento con código fuente o datos.
 document: especifica un componente que
representa un documento.

68. Diagrama de componentes
 Modela los aspectos físicos de un sistema.
 Modela la vista de implementación estática de un
sistema.
 Modela los elementos físicos que residen en un
nodo, tales como ejecutables, tablas, librerías,
archivos y documentos.
 Un Diagrama de Componentes muestra un
conjunto de componentes y sus relaciones.
 Los elementos que lo componen son:
 Componentes
 Interfaces
 Relaciones de dependencia, generalización, asociación,
realización.

69. Diagrama de componentes

70. Diagrama de componentes
 Técnicas de modelado:
 Modelado de ejecutables y bibliotecas.
 Modelado de tablas, archivos y documentos.
 Modelado y diseño de un API.
 Modelado del código fuente.
 Planificación de versiones ejecutables para su
implementación con Nant.

71. Diagrama de Deployment

72. Diagrama de
deployment/distribucion
 Los diagramas de despliegue muestran la
disposición física de los distintos nodos que
componen un sistema y el reparto de los
componentes sobre dichos nodos

73. Nodo
 Es un elemento físico que existe en tiempo de
ejecución y representa un recurso computacional,
que generalmente tiene alguna memoria y
capacidad de procesamiento.
 Posee un nombre simple.
 Ejemplo: Ventas o un nombre extendido indicando el
paquete que lo contiene;
 Ej: servidor::Ventas.

74. Nodo
 En los Nodos se ejecutan los Componentes.
 La relación entre un nodo y un componente se puede
modelar con una relación de dependencia.
 Los nodos se pueden organizar agrupándolos en paquetes.
También a través de relaciones de dependencia,
generalización, asociación, agregación.
 Generalmente se conectan con una asociación.

75. Diagrama de despliegue
 La vista de despliegue representa la disposición de las
instancias de componentes de ejecución en instancias
de nodos conectados por enlaces de comunicación.
 Un nodo es un recurso de ejecución tal como
 Dispositivos
 Procesadores
 Memoria
 Los nodos se interconectan mediante soportes
bidireccionales que pueden a su vez estereotiparse.
 Esta vista permite determinar las consecuencias de la
distribución y la asignación de recursos.

76. Diagrama de despliegue
Primer Ejemplo

77. Diagrama de despliegue
Segundo Ejemplo

78. Tercer Ejemplo
 Modela aspectos físicos de un sistema.
 Modela la vista de despliegue estática de un sistema.
 Modela una configuración de nodos y los componentes
que residen en ellos.
 Modela la topología del hardware donde se ejecuta el
sistema.
 Los elementos que lo componen son:
 Nodos
 Relaciones de dependencia, generalización, asociación y
realización.
 Pueden contener los componentes que residen en los nodos.

79. Cuarto Ejemplo

80. Otro ejemplo

81. Diagrama de despliegue
 Técnicas de modelado:
 Modelado de procesadores y dispositivos.
 Modelado de distribución de componentes.