UML

1
 Referencias
• Eriksson, Hans-Erik: UML 2 Toolkit, ed. Wiley Publishing, 2004.
– Es una referencia completa para UML 2.0.
• Fowleer, M.: UML Distilled: A Brief Guide to the Standard Object Modeling Language,
Third Edition by Martin Fowler, 2003
– Es UML 2.0. Bastante completo.
• Pilone, D.: UML 2.0 in a Nutshell, 2005
– Es UML 2.0. Bastante completo.
• Bennett, S.: Análisis y diseño orientado a objetos de sistemas usando UML 3ª ed, 2006.
– Es UML 2.0. Incluye patrones de diseño y proceso unificado.
• Rumbaugh, J.; Jacobson, J.; Booch, G.: Unified Modeling Language Reference Manual,
The Second Edition, 2004.
– Es una referencia clásica.
• Booch, G.; Rumbaugh, J.; Jacobson, I.: Unified Modeling Language User Guide,
Addison-Wesley, 1998. (versión en español: "El Lenguaje Unificado de Modelado",
Addison-Wesley, Madrid, 1999).
– Es una referencia clásica.
• Tutorial de Borland (http://bdn.borland.com/article/0,1410,31863,00.html)
– Referencia resumida y rápida en la web (es UML 1.x)

2
 Introducción, I
• Similitud:
– Arquitectos, edificios, planos
– Ing. Inf., programas, diagramas
• UML
– Unified Modeling Language. Versión 2.0 (finales 2004)
– Diagramas (ing. inf.)
• Usados como esquemas y menos con información rigurosa (“planos de arquitectos”)
• Dos modos:
– Ingeniería inversa: a partir de código hacer diagramas
– Ingeniería directa: hacer diagramas y luego implementar
• Dominio
– Mundo en el que hay definido un problema
• Modelo:
– Abstracción de un problema
– Formado por objetos

3
 Introducción, II
• Objetos:
– Interaccionan entre sí enviándose mensajes
– Cosas que saben (atributos) y cosas que pueden hacer
(operaciones)
– Los valores de sus atributos determinan sus estados
• Clases:
– Un “diagrama” para un objeto
– Objetos son instancias de clases

4
 Diagramas de casos de uso
• Válidos támbién en contextos no Orientados a Objetos (OO)
• Lo que hace el sistema (no cómo lo hace)
• Pueden describirse en lenguaje natural
• Escenario:
– Una secuencia de operaciones (lo que ocurre al interaccionar con el sistema)
• Caso de uso (un óvalo):
– Resumen de escenarios para un caso particular
• Un actor (persona u objeto) establece una comunicación con un caso de uso,
que es una línea recta (si es dirigida, es decir con una flecha, indica quién
inicia la interacción)
• Diagrama de casos de uso:
– Una colección de actores, casos de uso y sus comunicaciones
– Puede contener fronteras de separación (rectángulos)
• Permiten:
– Planificar acciones de debugging
– Hacer análisis de requisitos (las acciones completas de los usuarios)
• Pueden contener precondiciones y postcondiciones
• Un caso de uso suele consistir en una tarea completa
– Por ejemplo, es más conveniente 2) que 1) para considerarse como un caso de uso:
1. Añadir un artículo al carro de la compra
2. Comprar un artículo 5
Ejemplo, I

6
Ejemplo, II

7
 Ejemplo, III (a)

realizar llamada telefonica

Emisor Receptor

8
 Ejemplo, III (b)
Un escenario para el caso de uso
“realizar una llamada telefónica”:
• Origen levanta receptor
• Suena alarma
• Suena tono de llamada destino
• Origen marca cifra (9) • Suena señal origen
• Para tono de llamada • Destino responde
• Origen marca cifra (1) • Para alarma destino
• Origen marca cifra (3) • Para señal origen
• Origen marca cifra (9) • Conexión
• Origen marca cifra (7) • Destino cuelga
• Origen marca cifra (4) • Origen cuelga
• Origen marca cifra (4)
• Origen marca cifra (6)
• Origen marca cifra (7)

9
 Relaciones
• Relaciones entre dos casos de uso
– Generalización
• “Es un caso particular de …”
• Herencia de clases en POO (overriding)
• También se puede tener esta relación entre dos actores
– Inclusión (include)
• “Implica hacer también …”
– Extensión (extends)
• “Se insertará en …” un determinado punto (llamado “punto de
extensión”) dependiendo de una condición
• Si un caso de uso depende de varios casos de uso mediante
“extends” tendrá un punto de extensión para cada uno

10
Ejemplo (I)

11
Ejemplo (II)

Representación
alternativa para el actor
“Backup System”

12
 Diagramas de clases, I
• Clases y sus relaciones en un contexto OO
• Diagramas estáticos
– Muestran lo que interacciona pero no lo que ocurre al interaccionar
• Clase:
– Rectángulo
– Nombre de clase (en cursiva si es clase abstracta)
– Atributos y métodos
– Visibilidad (vis) para atributos y métodos
• público (+); por omisión para métodos
• privado (-); por omisión para atributos
• protegido (#)
– Atributos
• [vis]atributo[[multiplicidad orden] : tipo [= valor-inicial]]
– Tipos: Boolean, Integer, Real, String
– Orden: ordered, unordered
• Atributos de clase subrayados
– Operaciones (métodos)
• [vis]metodo[([params]) [:tipo]]
• Métodos de clase subrayados
– Implícitamente, se asume que algunos atributos son “claves primarias”

13
 Diagramas de clases, II, (a)
• Relaciones entre clases:
– Asociación (binaria) (n-aria también posible)
– Agregación (“es parte de …”)
– Generalización (herencia); “es un caso particular de …”.

• En una asociación o agregación:

– Nombre de asociación (verbo) dirigido; Rol (nombre) en un
extremo. Ejemplo: Trabajador, UnidadTrabajo, trabajaEn, suTrabajo
rol verbo

• Navegabilidad (petición de información) en una asociación

– Unidireccional
– Bidireccional

14
 Diagramas de clases, II, (b)
• Agregación
– Se puede considerar un caso particular de
“asociación” en el que la relación tiene el
nombre “contiene”
• Verbos:
– En nombres de asociaciones, “presente”
– En nombres de métodos, “imperativo”

15
 Diagramas de clases, III
• Multiplicidad en una asociación o
agregación:
– 0..1; n..m; 0..*; *; 1, 1..*
• Ejemplo de agregación con multiplicidad
(relación ternaria):
m

16
 Diagramas de clases, IV
• Dependencia.
– Otro tipo de relación (“depende de …”)
– Un cambio en la especificación (interfaz pública) de la 2ª puede forzar
cambios en la primera clase
• Observación:
– Los atributos no deben ser objetos (utilizar asociaciones en tal caso).
– En los diagramas de clases no suelen aparecen (son detalles de
implementación y no de diseño):
• Constructores
• Métodos de acceso (“get/set”)
• Métodos de gestión de elementos de una asociación o agregación (por
ejemplo, “add/remove”)
– Algunas asociaciones con multiplicidad 1 hacia algunas clases pueden ser
claves externas (“foreign keys”) implícitas
• En UML, a diferencia del modelo relacional de BD, no está previsto el uso de
“keys” y se recomienda usar OID (“object ids”): números únicos generados
automáticamente para cada objeto. A pesar de eso, siempre existe para cada
clase un conjunto implícito de “primary and foreign keys”, que permiten
hablar de multiplicidades de asociaciones con otras clases. 17
 Diagramas de clases, V
• Tipos de asociación:
– Asociación con condiciones
{condiciones}
Clase Clase

– Asociación cualificada por un atributo

cualificador

– Asociación cualificada por una clase

Clase Clase

Clase
18
 Diagramas de clases, VI
• Tipos de asociación (ejemplos):
– Asociación con condiciones. Por ejemplo, la asociación “contiene” de tipo
“1 a muchos” entre las clases “CD” y “Canción:
{ordenado}
– Asociación cualificada por un atributo:
• A cada par de la asociación se le asigna un valor (tipo primitivo)
• En una asociación “0..1----*”, el cualificador se coloca desplazado a
la izquierda (ya que cada objeto de la clase de la derecha tendría
asociado uno o ningún valores del cualificador). Ejemplo:
“PartidoPolitico”, “Ciudadano”, “códigoDeAfiliado”
– Asociación cualificada por una clase:
• Es otra asociación entre los pares de una asociación y una clase.
• Ejemplo: Clase “Alumno”, “Clase Asignatura”, relación
“matriculado-en” de tipo “muchos-a-muchos”; clase
“Nota(numero,calificacion)” y asociación “obtiene” de tipo
“muchos-a-uno” entre la asociación y “Nota”.
– No equivalente a tener las clases “Alumno”, “Asignatura” y
“Nota” y 2 asociaciones (“Alumno-Nota” y “Asignatura-Nota”).
Ver siguiente transparencia.
• En una asociación “0..1-------*”, la clase asociación se coloca
desplazada a la izquierda.
19
 Asociación cualificada por una clase
Nota
1
obtiene

Alumno * * * Asignatura
matriculado-en

El diagrama de arriba implica el de abajo pero no lo contrario.

No son equivalentes.
* Nota *

* *
Alumno Asignatura
20
 Diagramas de clases, VII
• Agregación compuesta
– Agregación fuerte pues al desaparecer el todo,
también lo hace la parte
Universidad Facultad
1 1..*
• Interfaz (en cursiva)
– Conjunto de métodos sin definir
<<interface>>
Clase MiInterfaz
métodos
Clase
MiInterfaz 21
 Diagramas de clases, VIII
• La relación también se aplica
para clases abstractas
• Son diferentess:

dependencia
herencia

22
 Diagramas de clases, IX
Clases plantilla:

Array
Array<Coche>

<<bind>><Persona>

ConjuntoPersonas

23
Ejemplo

24
 Diagramas de paquetes
• Un paquete puede tener una o varias clases
y uno o varios subpaquetes.
• Se puede usar relación de dependencia entre
paquetes y/o clases

25
 Ejemplo
A

B C

26
 Diagramas de objetos
• Instancias en lugar de clases
– Notación  [objeto]:Clase
– Los denominados “enlaces” entre objetos provienen de las
“asociaciones” entre clases. Se pueden etiquetar con el mismo
nombre que para el diagrama de clases, aunque se subrayan.

• Diag. clases:

27
Diagramas de objetos, II

subdepartment

subdepartment

subdepartment subdepartment

28
 Diagramas de secuencia, I
• Diagramas de clases son estáticos. Diagramas de objetos son
dinámicos.
• Diagramas de secuencia y de colaboración son dinámicos
• Diagrama de secuencia:
– Un diagrama que describe los mensajes (MÉTODOS) enviados en función
del tiempo en un contexto que puede ser un caso de uso o un escenario
– El tiempo crece verticalmente hacia abajo (objetos/tiempo)
– Notación  [objeto]:Clase
• Se puede utilizar una flecha discontinua (al revés) para indicar el valor
que devuelve una llamada a un método
• Dos tipos:
– Genéricos (pueden tener bucles, condicionales). Corresponden a un caso
de uso.
– Particulares. Corresponden a un escenario. Por ejemplo, si hay una
iteración con 5 vueltas, se visualizan 5 mensajes.
• Un diagrama de secuencia es relativo a un conjunto determinado de
objetos y métodos en una interacción, aunque esa interacción involucre
a más objetos y métodos 29
 Diagramas de secuencia, II
• Mensaje:
– [guard] *[iteration] sequence_number : return_variable :=
operation_name (argument_list)
• El único no opcional: operation_name
• sequence_number :  orden temporal del mensaje
• Barra de activación: rectángulo simbolizando la duración
de ejecución de un método
– Si un diagrama de secuencia sólo tiene mensajes pero no barras de
activación, el “sequence_number” simboliza los mensajes que son
generados por otros mensajes, aclarando cuál es el flujo de
mensajes.
• Se pueden usar los mensajes especiales “create” y
“destroy” para, por simplicidad de notación, poner todos
los objetos alineados en la parte superior de un diagrama
de secuencia. 30
Ejemplo, I

31
 Ejemplo, II, (a)
Bucles y condiciones

32
 Ejemplo, II, (a)
Bucles y condiciones
• En lugar de “loop” también es válido, por
ejemplo:
– *[For each worker] (un “for” de C++)
– *[No more workers] (un “while” de C++)
• Condiciones:

33
 Ejemplo, III
:Receptor :Linea :Receptor
Origen levanta receptor

Suena tono de llamada

Orig. marca 9 cifras (91...)

Para tono de llamada

Suena alarma destino

Suena señal origen

Destino responde

. . . 34
 Diagramas de colaboración
• Llamados de comunicación en UML 2.0
• Combinación de uno de objetos y uno de secuencia
– Sin considerar la línea del tiempo
– Grafo dirigido
– Cada mensaje tiene un número (número de secuencia)
• Jerárquicos, según temporalidad de ejecución
• Si son alternativos (uso de “alt”) o concurrentes (usando el operador
“par” de interacción), se utiliza una notación del estilo: “3a”, “3b”,
“3c”, etc
• Dos tipos: genéricos o particulares
• Expresa las colaboraciones que tiene cada objeto con el
resto de objetos

35
 Ejemplo, I

1: Origen levanta receptor

2: Origen marca 9 cifras 2.2: Suena alarma destino

:Receptor :Línea :Receptor

1.1: Suena tono llamada 3: Destino responde

2.1: Para tono llamada
2.3: Suena señal origen

36
Ejemplo, II

37
Otros ejemplos (UML 2.0), I

38
 Otros ejemplos (UML 2.0), II

1
1.1

1.2
1.3

1.4a

1.5a

1.6a

1.4b

1.5b

1.6b

1.7

con números de secuencia 39

 Operadores de interacción
• “Loop” y “Alt” son ejemplos de operadores
de interacción.
• Otros operadores:
– “Par”
• Hilos o tareas concurrentes
– “Ref”
• Referencia a otro diagrama de secuencia
– Más ejemplos: “Break”, “Opt”, “Critical”, ...
40
Mensajes síncronos y asíncronos

• Dos tipos:
– Mensajes síncronos
• El envío de un mensaje supone esperar al valor de
retorno

– Mensajes asíncronos
• A la vez que se procesa el mensaje, se pueden
procesar otros mensajes distintos. Por defecto,
“create” se considera asíncrono

41
Ejemplos

42
 Diagramas de estado (a)
• Un diagrama de estado:
– También tienen sentido en un contexto no OO
– Para un contexto OO:
• Tiene sentido para estados de un objeto de una determinada clase
• Interesa hacerlo sólo para algunas clases, como las que tienen un
comportamiento más complejo: interfaces de usuario, …
• Transiciones entre estados de acuerdo a EVENTOS
– Transición: “evento/actividad”. La “actividad” es opcional y se
ejecutaría tras emitirse el evento.
– En un diagrama de estados los conceptos de “actividad” y “acción”
son equivalentes (¡serán conceptos distintos en un diagrama de
actividades!).
– Los conceptos de “evento” y de “mensaje” (método) son distintos

43
 Diagramas de estado (b)
• Un nodo para estado inicial y varios posibles
nodos finales
• Los estados suelen corresponder a expresiones en
“gerundio” (“procesando”, “comprobando”, etc)
• Debe contemplar TODOS los casos de uso
posibles
• Eventos:
– nombre_evento (lista_argumentos) [condicion]
• Sólo es obligatorio el “nombre_evento” (sin lista de
argumentos si no los tiene)
• Tienen lista de argumentos como cualquier objeto de una clase
44
 Diagramas de estado (c)
• En un contexto OO, las actividades se
pueden definir mediante:
– variable_retorno:=
objeto.actividad(lista_argumentos)
• “objeto.” se puede omitir si la actividad se realiza en
el mismo objeto
• “variable_retorno” es opcional

45
 Diagramas de estado (d)
• Diseño de diagramas de estado:
– Clasificar los estados de un sistema y reconocer los posibles cambios en dichos
estados así como cómo se producen (a causa de los eventos)
• Tipos de eventos
– Evento de cambio (EC)
• Emitido cuando una condición se verifica.
• Se representa mediante “[condicion]”
– Evento temporal (ET)
• Emitido cuando ha transcurrido un cierto tiempo
– Envío de un mensaje (EM), o equivalentemente la ejecución de un método en un
contexto OO, es decir la ejecución de una determinada operación
• Puede provenir de un evento externo (como en una interacción con un usuario)
• Implementación de un diagrama de estado
– “State Pattern” (Gang of Four)
• Una clase por cada estado. Una clase controlador que tiene un método por cada tipo de
evento. Al final del curso, detalles.

46
 Diagramas de estado (e)
• Actividades internas de un estado:
– Como si correspondieran a eventos internos: entry, exit, help, …
– Sintaxis similar en estos eventos a las transiciones entre estados
– Eventos “entry” y “exit” lanzados después de entrar o salir de un
estado
– Evento “help” al entrar en modo de ayuda
– El poner una “actividad” en “entry” es equivalente a ponerlo en el
evento que creó la transición entre estados
– Evento especial “do” (actividad ejecutada todo el tiempo de
permanencia en el estado)
• Un ejemplo de evento de cambio muy común es el producido a la
finalización de la actividad “do”
• Un evento externo de mensaje puede finalizar la acción del “do”,
saliendo del estado

47
Diagramas de estado (f)

Nombre del estado

entry / actividad
exit / actividad
do / actividad
help / actividad (actividades internas; opcional)

diag. estados interno (subdiagramas de estados; opcional)

48
 Ejemplo, I, a

Press tab OR move cursor to

PIN field/Cursor to PIN

Press shift tab OR

move cursor to
SSN field/Cursor to
SSN

Banco Internet (validación);

49
 Ejemplo, I, b
ET

EM EM

EM

EM Press tab OR move cursor to

PIN field/Cursor to PIN
EC EM
EM
Press shift tab OR
move cursor to
SSN field/Cursor to
EC SSN
EM

EM

Banco Internet (validación);

50
 Ejemplo, II, a
• Suena la alarma del reloj para indicar que ha llegado la
hora predeterminada (hora objetivo)
• Se puede poner la alarma (con una hora objetivo)
• Se puede quitar la alarma
• La alarma del reloj suena cuando se cumple:
alarm=on && objetivo<=hora actual <= objetivo+20s
• Si la alarma está sonando, deja de sonar la alarma del reloj
y se quita la alarma si se cumple alguna de las siguientes
condiciones;
– Se pulsa cualquier botón
– hora actual>=objetivo+20

51
 Ejemplo II, b 2 eventos de cambio y
3 eventos de mensaje

Alarma activada
[llega-hora-objetivo] / sonar alarma

entry/reloj-muestra-alarma-activada Alarma sonando

do/alarma-sigue-sonando
quitar alarma
poner alarma
[20 segundos sonando] / desactivar alarma

Alarma desactivada
tocar cualquier tecla

52
 Ejemplo III, a
• Mientras exploran un castillo, A y B descubren lo que parece ser la
entrada de un corredor secreto. Mientras A examina la puerta, B retira
una vela del candelabro. En ese momento, la puerta gira 180º,
llevándose a A consigo.
• B vuelve a colocar la vela en el candelabro. La puerta gira 360º y A
vuelve a quedar separado de B.
• B saca de nuevo la vela. La puerta gira 360º, pero esta vez A le impide
cerrarse con su cuerpo. B pasa la vela a A. Los dos amigos fuerzan
(empujando cada uno en un extremo) a la puerta a retroceder 180º y de
nuevo quedan separados, pero ahora B está dentro y A junto al
candelabro.
• A pone la vela en el candelabro.
• Cuando la puerta empieza a girar, A saca la vela. La puerta se detiene
tras girar 90º.
• A y B penetran en el corredor para explorarlo

53
 Ejemplo III, b
• Sacar y meter la vela del candelabro es un
interruptor
• Puerta:
– Posición inicial con ángulo 180º
– Gira en sentido de las agujas del reloj (ángulo
creciente)
– Con la puerta parada, si se toca el interruptor empieza a
moverse
– Con la puerta en movimiento: ¿se toca el interruptor?
• No: la puerta gira hasta la posición 0º
• Sí: la puerta gira hasta la posición más cercana múltiplo de 90º

54
 Ejemplo III, c
Para cada estado “x-y”:
Puerta 0
- Existe un “do/mueve-puerta”
forzar
- Eventos de cambio: [puerta-en-y]
inter
inter

0-90 inter
inter

Puerta 270 270-360 90-180 Puerta 90

inter

inter
180-270

inter inter
Puerta 180
55
Estados compuestos, I

56
Estados compuestos, II

¡Son hilos !. Se dice que son “ortogonales”

57
Estados compuestos, III

58
Diagramas de estado de protocolo, I
• Describen estados y eventos de una comunicación basada
en un protocolo.
• Los eventos son siempre del tipo “eventos de mensaje” en
los que únicamente se pueden definir precondiciones y
postcondiciones (detrás de “/”), pero no actividades.
• A diferencia de un diagrama de estados normal:
– Los estados no tienen una estructura interna
• Por tanto, no se permiten actividades “exit” o “entry”
– Al poder poner postcondiciones en los eventos, se pueden
establecer invariantes en los estados, que pueden ser expresables
por ejemplo en OCL

59
Diagramas de estado de protocolo, II
Cuenta corriente

reintegro(cant)
[cant <= balance + saldo]

Close()
Abierto Cerrado

deposito(cant)

60
Diagramas de estado de protocolo, III

Una puerta con cierre automático

61
 Diagramas de actividad (a)
• Diagramas aplicables también en contextos no OO
– Son diagramas de flujo (los “organigramas” clásicos en programación)
• Actividad: rectángulo con bordes redondeados
• Actividad: una sucesión de acciones y subactividades
– Acción: actividad atómica
• Es común crear diagramas de actividad para casos de uso
• Nodo de acción:
– Se sale de ellos al finalizar la acción, de modo similar a como se sale de
un estado en un diagrama de estados al finalizar la actividad de “do”
– En un contexto OO:
• Un estado de acción puede afectar a varias clases, pero un estado dentro de
diagrama de estados está siempre asociado a una sola clase
• Una actividad puede tener parámetros o valores de retorno:
– Se representan como rectángulos adosados al borde (“pins”)
• Las actividades pueden tener “precondiciones” y “postcondiciones”
(expresables mediante “[condicion]” en las líneas de transición entre
actividades)

62
 Diagramas de actividad (b)
• Pueden existir bifurcaciones salientes (forks, branches) y
entrantes (joins, merges) para hilos y condicionales,
respectivamente.
– Observación: en diagramas de estados también se pueden utilizar
estos “pseudoestados”
• Se pueden crear agrupaciones de actividades (particiones)
según el “contexto” en los que se realizan. Si cada
actividad pertenece a un solo “contexto”, se tienen “calles”
(“swinlanes”).
• Haciendo una similitud para los diagramas de estado:
– Los diagramas de actividad serían una especie de diagramas de
estados compuestos y relativos a varias clases

63
swinlanes

Ejemplo

EJEMPLO, I

64
Ejemplo, II (a)

¡diagrama de secuencia! 65
 Ejemplo, II (b)
Selección Selección inicio [libre() and inicio++
hotel días fin inicio!=fin]
[mas=si]

mas mensaje [!libre()]

[mas=no] [libre() and

inicio=fin]
Aviso
banco

Aviso
cliente

¡diagrama de actividad! 66
 Relación entre diagramas de
actividades y de estados
• Un diagrama de estados se puede representar como un
diagrama de actividad, considerando los eventos de
mensaje como condiciones entre nodos del diagrama de
actividad
– Pero no al revés, ya que un diagrama de actividades puede
involucrar a varias clases
– Los estados ortogonales corresponderían a “forks” en los
diagramas de actividad
• Ejemplo:
– Representación como diagrama de actividades del diagrama de
estados de la interfaz de usuario “Geting SSN, Geting PIN,
Validating, ...”
• Actividades “Get SSN, Get PIN, Validate” y psedoestados “branch”
para las posibles acciones y resultados de operaciones

67
 Otro ejemplo
Muestra
[Pulsó mensaje
Cancelar]
Pide
contraseña
[Contraseña Comprueba
escrita] contraseña

... [Contraseña correcta] [No coincide]

Muestra
mensaje

Es un diagrama de actividad, que puede ser reformulado

como un diagrama de estados (evento de mensaje: cancelar;
eventos de cambio: contraseña correcta o incorrecta) 68
 Entrada y salida de actividades
Ejemplos (incluyen manejo de errores o excepciones):

69
Subactividades

70
 Diagrama de despliegue
• Distribución física de trozos de hardware y software
• Diagrama aplicable a un contexto no OO
• Contiene nodos:
– Un nodo es algo que contiene un software. Puede ser:
• Hardware (un ordenador o algún hardware conectado al sistema)
• Entorno de ejecución (un software que puede contener otras partes de
software; ejemplo: un sistema operativo o un proceso contenedor)
– Los nodos contienen “artifacts” (manifestación física de software,
que son normalmente ficheros)
– Los nodos pueden ser compuestos
– Un nodo o un “artifact” pueden contener un conjunto de
propiedades (“tagged-values”)
– Algunos nodos se comunican entre ellos (“communication paths”)

71
Ejemplo

72
 Diagrama de componentes, I
• Aplicables a contextos OO. Componentes:
• Partes independientes (y por lo tanto actualizables)
de un sistema, desde el punto de vista de un usuario
final
– Una componente también puede ser un conjunto de clases
de un diagrama de clases

• Notación:

73
 Diagrama de componentes, II
• Una componente puede estar compuesta por otras
componentes
• Una componente se puede conectar con otras componentes
mediante interfaces.
– Se puede utilizar la notación UML del diagrama de
clases (dependencia + implementación-interfaz).
Ejemplo:

74
Ejemplo

75
Ejemplo (diag. componentes)

La componente “Sales Server” tiene

2 puertos (un tipo especial de
subcomponente) para comunicar
con el exterior 76
 Ejemplo
Un diag. de despliegue. Aparecen
también componentes. UML 1.x

77
 Un ejemplo completo para
todos los diagramas

Un sistema de gestión de cursos impartidos para un conjunto

de clientes. Algunos de esos clientes pueden pertenecer a
empresas.

78
79
80
81
0
1
1.1
2
2.1
3
3.1 3.1.1

3.2
3.2.1

82
83
84
85
86
87
OCL (Object Constraint Language)

88
89
90
91
@pre=previous
92
 Anotación de restricciones
• Opciones:
– Mediante anotaciones directas, utilizando la
nomenclatura descrita
– Mediante anotaciones separadas

Persona
nombre
{self.edad > 0}
edad
…

93
Ejemplo

94
 Herramientas, I
• Permiten el dibujo de diagramas además de dar:
– Soporte a la correctitud de los diagramas en base a su
semántica
– Apoyo para simplificar la comprensión de los
diagramas
• Además, incluyen:
– Comprobación de inconsistencias
– Detección de trabajo a realizar y mejoras
– Generación de informes
– Soporte a la reutilización

95
 Herramientas, II
• Soporte a la navegación
– Vistas compuestas
– Elaboración de conexiones entre información
relacionada
– Búsqueda
– Visión con diferentes niveles de granularidad
(expansión y contracción de partes de la vista)
– Filtros
– Operaciones sobre componentes de la vista

96
 Herramientas, III
• Soporte al trabajo multiusuario
– Bloqueo de información
– Trabajo colaborativo
• Generación de código
– Esqueletos con información estática (clases)
– Integración con lenguajes especiales (SQL, …)
• Ingeniería inversa
– Construcción de un modelo de diseño a partir de código
• Más complejo que la ingeniería directa

97
 Herramientas, IV
• Integración con otras herramientas
– Entorno de desarrollo (tendencia a confluir)
– Configuración del sistema y control de versiones
– Herramientas de documentación
– Herramientas de prueba de software
– Herramientas de construcción de interfaces de usuario
– Herramientas de especificación de requerimientos
– Herramientas de gestión de proyectos y soporte al
proceso de diseño y desarrollo

98
 Herramientas, V
• Distintos niveles de abstracción
• Intercambio de información
– Especificación OMG de representación de
modelos UML en XMI (XML Metadata
Interchange)

99