Introducción a UML

Ing. Israel Rosales T.

1
Mitos sobre UML
 Aprender UML es aprender el paradigma de
objetos.
 UML es una metodología de desarrollo.
 UML es solo para modelos de objetos.

2
Entonces ¿qué es UML?
 UML es un lenguaje “unificado” de modelado
para:
 Visualizar Representar y Comunicar Ideas
 Especificar Modelos precisos, no ambiguos, completos
 Construir Trasladar en forma directa a un leng. prog.
 Documentar Los artefactos construidos durante un proyecto
 los artefactos de un sistema de software.

3
¿Qué significa lenguaje
“unificado”?
 Lenguaje = sintaxis + semántica
 Unificado a través de:
 Métodos y notaciones históricas
 Etapas del ciclo de desarrollo (requerimientos a
implementación)
 Dominios de aplicación
 Lenguajes y plataformas de implementación
 Procesos de desarrollo

4
Evolución histórica
Nov ‘97 UML promulgado por la OMG

5
Influencias

6
Participantes en UML 1.0
 Rational Software  MCI Systemhouse
(Grady Booch, Jim Rumbaugh y
Ivar Jacobson)
 Microsoft
 Digital Equipment  ObjecTime
 Hewlett-Packard  Oracle Corp.
 i-Logix (David Harel)  Platinium Technology
 IBM  Sterling Software
 ICON Computing  Taskon
(Desmond D’Souza)  Texas Instruments
 Intellicorp and James  Unisys
Martin & co. (James Odell)

7
Modelos

E = M * C2
8
¿Qué es un modelo?
 Una representación en algún medio que captura los aspectos
importantes del sistema modelado desde un determinado punto de
vista.

 Un modelo de un sistema software es realizado en un lenguaje de

modelado.

9
Propósito de los modelos
 Capturar y precisar requerimientos de un dominio de conocimiento, que sea
comprensible por todos los stakeholders del proyecto.

 Pensar sobre un diseño de un sistema.

 Capturar decisiones de diseño de un sistema.

 Explorar posibles soluciones a un problema económicamente.

 Generar productos de trabajo útiles.

 Documentar.

10
UML - Conceptos

11
UML - Vistas
 Una vista es un subconjunto de construcciones de modelado
que se enfocan en un aspecto particular del sistema.

 Las vistas pueden dividirse en tres áreas:

 Estructural
 Comportamiento dinámico
 Gestión del modelo

12
Vistas – Clasificación estructural
 Describe los elementos del sistema (clasificadores) y sus
relaciones.
 Clasificadores más comunes:
 Clases
 Casos de Uso
 Componentes
 Nodos
 Vistas:
 Vista Estática – Diagrama de clases
 Vista de Casos de uso – Diagrama de casos de uso
 Vista de Implementación – Diagrama de Componentes /
despliegue

13
Vistas – Comportamiento dinámico
 Describe el comportamiento del sistema a través del tiempo.
 Vista de Interacción: modela como interactúan los objetos
para realizar una funcionalidad del sistema
 Diagrama de Colaboración
 Diagrama de Secuencia
 Vista de Máquina de estados: modela el ciclo de vida de una
instancia de una clase en estados y transiciones.
 Diagrama de Estados
 Vista de Actividades: modela flujos de trabajo (workflows)
 Diagrama de Actividades

14
Vistas – Gestión del modelo
 Describe la organización de los modelos en unidades
jerárquicas.

 Permite manejar la complejidad.

 Permite organizar el sistema en paquetes, subsistemas, y

modelos.

15
Relación Áreas - Vistas

16
Mecanismos de extensión de UML
 Permiten adaptar los elementos de modelado asignándole una
semántica particular.
 Estereotipos
 Valores etiquetados
 Restricciones (OCL)

17
La Vista Estática

18
La Vista Estática
 Propósito:
 Captura la estructura de los objetos.
 Es la base sobre la que se construyen las otras
vistas.
 Es un modelo incremental.

 Diagrama de Clases

19
Clasificación
 Clasificador: es un concepto discreto en el modelo que tiene identidad,
estado, comportamiento, y relaciones.

 Tipos de Clasificadores
 Elementos del Sistema:
 Clase
 Interfaz
 Tipos de datos

 Conceptos de Comportamiento:
 Caso de Uso

 Cosas del entorno:

 Actor

 Estructuras de implementación:
 Componente
 Nodo
 Subsistema

20
Clases & Objetos
 Objeto = estructura + operaciones + estado interno +
identidad.
 Un objeto es una instancia de una clase.

 Clase: Conjunto de objetos con estructura,

comportamiento, relaciones, y semántica común.

 Ejemplos
 algo físico → Avión
 algo del negocio → Pedido
 un concepto lógico → Horario
 algo de la aplicación → Window, Botón, Menú
 algo del comportamiento → Tarea, Proceso

21
Clases: Notación Gráfica
 Cada clase se representa en un rectángulo con
tres compartimientos:
 nombre de la clase
 atributos de la clase
 operaciones de la clase

22
Clases: Niveles de visibilidad
 Determina el nivel de encapsulamiento de los elementos de una
clase.

 (-) Privado : Los atributos/operaciones son visibles solo desde

la propia clase.

 (#) Los atributos/operaciones protegidos están visibles para la

propia clase y para las clases derivadas de la original

 (+) Los atributos/operaciones públicos son visibles a otras

clases (cuando se trata de atributos se está transgrediendo el
principio de encapsulación)

23
Clases: Niveles de visibilidad
 Ejemplo
Reglas de visibilidad

+ Atributo público : int

# Atributo protegido : int
- Atributo privado : int

+ "Operación pública"
# "Operación protegida"
- "Operación privada"

24
Clases: Estereotipos
 Objetos Entidad Empleado

UIEmplead
 Objetos Interfaz

 Objetos de Control Control

25
Clases y Objetos
 Diagrama de Clases y Diagramas de Objetos
pertenecen a dos vistas complementarias del modelo.

 Un Diagrama de Clases muestra la abstracción de una

parte del dominio.

 Un Diagrama de Objetos representa una situación

concreta del dominio.

26
Diagrama de Objetos
Diagrama de Clase

Banco Cliente Cuenta

1 * 1 *

Diagrama de Objetos
cta0101 : Cuenta
cliente01 : Cliente

unBanco : Banco
cta0201 : Cuenta

cliente02 : Cliente
cta0202 : Cuenta

27
Interfaces
 Describen un protocolo de comportamiento sin
especificar su implementación.
 Contienen operaciones pero no atributos.
 Una interfaz puede ser implementada por varias clases.

28
Relaciones
 Las relaciones entre clasificadores son:
 Asociación (conocimiento)
 Agregación / Composición
 Generalización
 Dependencias

29
Asociación
 Asociación:
 Conexión semántica entre instancias de clases.
 proporciona una “conexión” entre los objetos para el
envio de mensajes.

 Enlace:
 Instancia de una asociación.
 Lista ordenada de referencias a objetos.

30
Asociación: representación gráfica
marido

casado-con 0.. 1
0.. 1 trabaja-para *
Persona
* Compañía
mujer
emplea-a
nombre nombre
jefe
s. s. dirección
0.. 1
Administra
*
empleado

31
Asociación: multiplicidad
 Especificación de multiplicidad (mínima...máxima)
1 Uno y sólo uno
0..1 Cero o uno
M..N Desde M hasta N (enteros naturales)
* Cero o muchos
0..* Cero o muchos
1..* Uno o muchos (al menos uno)

 La multiplicidad mínima >= 1 establece una restricción

de existencia

32
Asociación: casos especiales
Presentacion
-Fecha
 Asociación como clase -Hora
* *
Teatro Obra

Presentacion Num_Butaca Entrada

 Asociación calificada
1 1..*

Presentacion Diapositiva

 Asociación ordenada 1 1..*

{ordered}

* * Persona

Cuenta
or
 Restricción
* Empresa
1 33
Agregación y composición
 Representa una relación todo-partes entre objetos.
 Son una variación de la asociación con mayor fuerza semántica.
 Una composición es una forma de asociación más fuerte en la cual el
compuesto es responsable de gestionar sus partes, por ejemplo
asignación y desasignación. La composición implica tres cosas
 Dependencia existencial. El elemento dependiente desaparece al
destruirse el que lo contiene y, si es de cardinalidad 1, es creado al
mismo tiempo.
 Hay una pertenencia fuerte. Se puede decir que el objeto contenido es
parte constitutiva y vital del que lo contiene
 Los objetos contenidos no son compartidos, esto es, no hacen parte del
estado de otro objeto.

34
Representación gráfica

 Agregación Coleccion Obra

* *

Computadora

 Composición
1 1 1
1 1 *

ALU RAM Disk

35
Generalización
 Relación taxonómica entre una descripción general y
otra más específica que la extiende.

 Relación “es un tipo de”.

 Herencia: mecanismo a través del cual los atributos,

operaciones, y restricciones definidas para una clase,
denominada superclase, pueden ser heredados
(reutilizados) por otras clase denominadas subclases.

36
Representación Gráfica
Cuenta

Vehículo

CajaDeAhorro CuentaCte

Veihículo Terrestre Vehículo Aéreo

Coche Camión Avión Helicóptero

37
Herencia Múltiple
Bípedo Cuadrúpedo

nro patas nro patas

Con Pelos Herbívoro

cubertura comida

Animal
Con Plumas cobertura
comida
cobertura Carnívoro

Con Escamas

Conejo

38
Dependencias

 Indica una relación semántica entre dos o más

elementos del modelo en la cual un cambio al
elemento proveedor puede requerir un cambio o
indicar un cambio en el significado del elemento
cliente en la dependencia.

39
Dependencias
Modelo del Modelo de
 De traza Analisis Diseño

Cliente
(diseño)
 De refinamiento
Cliente (analisis)

 De uso

 De importación

 …

40
Diagrama de clases: ejemplo

41
La Vista de Casos de Uso

42
La Vista de Casos de Uso
 Capturan los requerimientos funcionales del sistema
 Describen la forma de usar el sistema tal como se la ve
desde el exterior.
 Visión de “caja negra” del sistema.
 No es un modelo orientado a objetos.
 Particiona la funcionalidad del sistema en unidades
discretas: los casos de uso.
 Concepto introducido por I.Jacobson en OOSE.
 Diagramas de Casos de Uso: Actores + Caso de uso

43
Actor
 Representa algo que interactúa con el sistema.
 Puede ser humano u otro sistema.
 Reside fuera del sistema. Describe el entorno.
 Describe un “rol” que asume un usuario.
 La misma persona física puede asumir distintos roles.
 Ejemplos:
 Cliente del Banco
 Cajero
 Sistema Link

Cliente del Banco

44
Caso de Uso
 Secuencia de transacciones realizadas por el sistema que brinda un
resultado de valor a un actor.
 Describe una “forma” de utilizar el sistema.
 Funciones:
 Capturan requerimientos funcionales del sistema.
 Estructuran los modelos de objetos en vistas manejables.

 Un caso de uso puede tener varios caminos de acción o “escenarios”.

 Los casos de uso sirven como hilo conductor del proceso de
desarrollo.

45
Diagrama de Caso de Uso
Cajero Automático

Extracción
(from Extraccion)

Transferencia
Cliente
Sistema Central
(f rom Actors) (f rom Actors)

Depósito

Administración
Operador
(f rom Actors)

46
Descripción textual
CU Extracción – Camino Estandard
1 Un mensaje de bienvenida está en espera en la pantalla del CA.
2 El cliente inserta su tarjeta en el CA.
3 El CA lee el codigo de la banda magnética y verifica que sea aceptable.
4 Si la tarjeta es aceptable, el CA solicita al cliente su código PIN.
5 El cliente ingresa su código PIN.
6 Si el código PIN es correcto, el CA solicita al cliente el tipo de transacción a realizar.
7 El cliente selecciona <extracción> y el CA envía el código PIN al Sistema bancario solicitando
los datos de la cuenta del cliente.
8 Los datos de la cuenta recibidos se despliegan en la pantalla.
9 El cliente selecciona una cuenta y el monto a extraer.
10 El CA envia al sistema bancario el requerimiento de extracción.
11 El CA preparan los billetes a ser dispensados.
12 El CA imprime el comprobante del movimiento.
13 Los billetes son dispensados al cliente.

47
 RF- <id del requisito> <nombre del requisito funcional>
Versión <numero de versión y fecha>

Descripción
Autores <autor>
Fuentes <fuente de la versión actual>
Objetivos asociados <nombre del objetivo>
Descripción El sistema deberá comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de

textual Precondición
activación> , abstracto durante la realización de los
casos de uso <lista de casos de uso>}
<precondición del caso de uso>
Secuencia Paso Acción
Normal 1 {El <actor> , El sistema} <acción realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción
realizada por el actor o sistema>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
n
Postcondición <postcondición del caso de uso>
Excepciones Paso Acción
1 Si <condición de excepción>,{el <actor> , el
sistema} }<acción realizada por el actor o
sistema>>, se realiza el caso de uso
< caso de uso RF-x>, a continuación este caso
de uso {continua, aborta}
2
3
Rendimiento Paso Cota de tiempo
1 n segundos
2 n segundos
Frecuencia esperada <nº de veces> veces / <unidad de tiempo>
Importancia {sin importancia, importante, vital}
Urgencia {puede esperar, hay presión, inmediatamente}
Comentarios <comentarios adicionales>

48
Caso de Uso: Relaciones

 Inclusión:
 Secuencias comunes a varios casos de uso.

Procesar Tarjeta

<<include>>
<<include>>

<<include>>

Extracción Transferencia Depósito

49
Caso de Uso: Relaciones

 Extensión:
 Partes opcionales de un caso de uso.

Extracción

<<extend>> <<extend>>

Estadística Monitoreo
Extracción Extracción

50
Caso de Uso: Relaciones

 Generalización:
 Distintas variantes de un caso de uso. (“es un tipo de”)

Extracción

Extracción Pesos Extracción Dólares

51
Caso de Uso: Relaciones

 Ejemplo
Silicitar
Hacer Pedido
Catálogo

«»
«»

«»
«»
<<extend>>
<<include>> <<include>>
<<include>>

Sum inistro de
datos de Pedir Producto Pagar
«»
«»

«»
«»

«»
«»
clientes

Pagar al Acordar
contado Crédito
«»
«»

«»
«»
52
La Vista de Interacción

53
La Vista de Interacción
 Representa como interactúan cooperativamente los objetos para
implementar el comportamiento definido por los casos de uso.

 Colaboración:
 Interacción entre un conjunto de objetos para implementar un
comportamiento del sistema.
 Una colaboración <<realiza>> la funcionalidad definida en un casos de
uso.

 Interacción:
 Una interacción es un conjunto de mensajes que se intercambian
dentro del contexto de una colaboración por instancias de clases
(objetos) a través de enlaces (instancias de asociación).

54
Diagramas de Secuencia
 Énfasis en la secuencia cronológica de los mensajes.

:WInPréstamos :Socio :Video :Préstamo

: Encargado

prestar(video, socio)
verificar situación socio

verificar situación video

registrar préstamo

entregar recibo

55
Diagrama de Colaboración
 Énfasis en la distribución física y relaciones de los objetos.

:Socio

:Video

2: verificar situación socio

1: prestar(video, socio) 3: verificar situación video

:WInPréstamos

5: entregar recibo
: Encargado 4: registrar préstamo

:Préstamo

56
La Vista de Máquina de Estados

57
La Vista de Máquina de Estados
 Describe el comportamiento dinámico de los objetos,
modelando su ciclo de vida.
 Autómatas finitos con estados y transiciones.
 Cada objeto se trata en forma aislada, el que se
comunica con el resto del mundo detectando eventos y
respondiendo a ellos.
 Es útil modelar solo para objetos con comportamiento
estado-dependiente.
 Uso de Diagramas de Estado.

58
Diagramas de Estado
 Cada objeto está en un estado en cierto instante.
 El estado describe un período de tiempo caracterizado
por:
 Conjunto de valores de atributos y relaciones del objeto.
 Período de tiempo durante el que se espera que ocurra un evento
 Período de tiempo durante el cual el objeto realiza una actividad
 El estado en el que se encuentra un objeto determina su
comportamiento.
 Cada objeto sigue el comportamiento descrito en el D. de
Estados asociado a su clase.
 La transición entre estados es instantánea y se debe a la
ocurrencia de un evento.

59
Diagramas de Estado
 Estados y Transiciones

Evento [condición] / Acción

A B

El evento se considera instantáneo

60
Diagramas de Estado
 Ejemplo: Pila pop
error
crear pila

borrar pila
Pila
Vacía

push pop (size = 1)

pop (size > 1)

borrar pila
Pila no vacía
ni llena
push (size+1 <> full)

push (size+1 = full) pop

evento (cond)
acción
borrar pila
Pila
llena
push
error

61
Eventos
 Acontecimiento significativo que tiene localización en tiempo y espacio.
 No tiene duración. Instantáneo
 Tipo de eventos
 Señal: comunicación asíncrona entre objetos.
 Llamada: invocación sincrónica de método del objeto que recibe el evento.
 Cambio: satisfacción de una condición lógica que depende de valores de un atributo.
 Tiempo: instante absoluto, o lapso transcurrido.
 Pueden modelarse con clases y jerarquías

62
Acciones
 Una acción es un cómputo atómico y breve
 una sentencia de asignación
 una operación aritmética
 el envío de una señal a otro objeto
 la invocación de una operación propia
 asignación de valores de retorno
 creación o destrucción de objetos
 una secuencia de acciones simples
 Acciones específicas de entrada, salida, durante, un estado o por un evento

estado A
entry: acción por entrar
exit: acción por salir
do: acción mientras en estado
on evento: acción
63
Estados compuestos

64
La Vista de Actividades

65
La Vista de Actividades
 Variante de la máquina de estados para modelar flujos
de trabajo.

 Utilización de diagramas de actividad. Caso particular de

los diagramas de estado.

 Los estados representan estados de actividad no de un

objeto.

66
Diagrama de Actividades

67
Calles y flujo de objetos

68
Vistas Físicas

69
Vista de Implementación
 Modela el empaquetado físico del sistema en unidades
reutilizables llamadas “componentes”.
 Un componente es una unidad física de implementación
con interfaces definidas pensada para ser utilizada como
parte reemplazable del sistema.
 Cada componente implementa una o más clases del
diseño.
 Incluyen código fuente, binario, o ejecutable.
 Los componentes se vinculan por relaciones de
dependencia.

70
Diagrama de Componentes

71
Vista de Despliegue
 Modela la disposición física de los recursos de ejecución
computacional (computadores, unidades de com., etc.)
 Nodo: es un objeto físico de ejecución que representa
un recurso computacional. Pueden tener estereotipos
(UCP, memorias, disk, etc.)
 Las asociaciones entre nodos representan líneas de
comunicación.
 Se representan por diagramas de despliegue.

72
Diagrama de Despliegue

73
Diagrama de Despliegue

DB Server

*
*

APP
Server * Servlets
*
* JSP
*
* JDBC
Cliente

* Web Browser

74
La Vista de Gestión

75
La Vista de Gestión
 La Vista de Gestión del modelo está compuesta por
paquetes y relaciones de dependencia entre paquetes.
 Paquete: es una unidad de organización del modelo.
 Los paquetes ofrecen un mecanismo general para la
organización de los modelos / subsistemas agrupando
elementos de modelado.
 Los paquetes contienen elementos del modelo como
clases, diagramas de casos de uso, interacciones, etc.
 Todos los elementos del modelo deben pertenecer a un
paquete.
 Los paquetes tambien pueden contener otros paquetes.

76
La Vista de Gestión

 Los paquetes pueden organizarse según el criterio del

diseñador:
 Por la vista (estática, casos de uso, etc.)
 Por subsistema
 Por etapa del ciclo de desarrollo.

 Una buena organización refleja la arquitectura de alto

nivel del sistema.

77
4 + 1 vistas de Kruchten

Vista de
Vista Lógica
Realización
Vista de los
Casos de Uso

Vista de Vista de
Procesos Distribución

78
Dependencias de acceso / importación
 Todas las clases no son
necesariamente visibles
desde el exterior del
paquete, es decir, un
paquete encapsula a la
vez que agrupa

 El operador “::” permite

designar una clase
definida en un contexto
distinto del actual

79
Dependencias de acceso / importación
 La dependencia de
acceso no modifica el
espacio de nombres del
cliente. Solo concede
permiso para establecer
referencias.

 La dependencia de
importación se utiliza
para agregar nombres al
espacio de nombres del
paquete del cliente como
sinónimos de los
caminos completos.

80
Modelo y Subsistema
 Un modelo es un paquete que abarca una descripción
completa de una vista particular de un sistema.
Proporciona una descripción cerrada de un sistema a
partir de un punto de vista.

 Un subsistema es un paquete que tiene piezas

separadas de especificación y de realización.
Representa una partición del sistema.

81
Proceso de Desarrollo

82
Proceso de Desarrollo
 UML no prescribe ningún proceso de desarrollo.

 Sin embargo se recomienda un proceso:

 Dirigido por Casos de Uso

 Centrado en la Arquitectura

 Iterativo e Incremental

 Ejemplo: Proceso Unificado (RUP)

83
Ciclo de Vida

84
Ciclo de Vida

85
Ciclo de Vida

86
Ciclo de Vida

87
Herramientas CASE

88
Herramientas CASE
 UML no es un leguaje de programación visual, pero sus
modelos pueden conectarse directamente con una
variedad de lenguajes.

 Forward & reverse engineering.

 Ingeniería de ida y vuelta.

89
Herramientas CASE
 Rational Rose (www.rational.com)

 Rational XDE (www.rational.com)

 Borland Together (www.borland.com/together/)

 Embarcadero Describe (www.embarcadero.com/)

90
Herramientas CASE - Libres
 Argo UML (argouml.tigris.org)
 Poseidon (www.gentleware.com)
 Dome (www.htc.honeywell.com/dome )

 Comparativa:
 http://www.diatel.upm.es/malvarez/UML/Comparativa.html

91
 Bibliografía
Título Autor ISBN
El Lenguaje Unificado de Modelado James Rumbaugh 8478290370
Manual de Referencia
El Lenguaje Unificado de Modelado Grady Booch 8478290281
Guía del Usuario
UML Gota a gota Martin Fowler 9684443641
UML y Patrones Craig Larman 8420534382

92
Recursos en la Web
 UML Resource Center (www.rational.com/uml/index.jsp)

 The Rational Edge (www.therationaledge.com/)

93
¿ preguntas ?

94