Modelado de Software con UML2.0 - Universidad Autónoma de ...

Modelado de Software con
UML2.0
Introducción
http://uml.org
Esther Guerra, Juan de Lara
{Esther.Guerra, Juan.deLara}@uam.es
Ingeniería g Informática
Universidad Autónoma de Madrid
Unified Modeling Language Language. Estándar de la OMG
(http://www.uml.org)
Notación estándar para
orientados a objetos, a
modelado más conocidos:
Booch - OOD.
Rumbaugh -OMT.
la descripción
partir de los
de sistemas
lenguajes de
Jacobson - OOSE y Objectory Objectory.
Combina las mejores propiedades de:
Conceptos de modelos de datos (ERD)
Modelos de negocios (workflow)
Modelos de Objetos j
Modelos de Componentes
1
3
Indice
Introducción.
Diagramas g de Clases y Objetos. j
Otros Diagramas.
OCL
Acción Semántica.
Perfiles.
Bibliografía
Lecturas sugeridas/ejercicios.
Introducción
LLenguaje j gráfico áfi para visualizar, i li especificar, ifi construir t i y
documentar partes de un sistema software desde
distintos puntos p de vista.
Puede utilizarse:
Con cualquier proceso de desarrollo.
A lo largo de todo el ciclo de vida.
Con distintas tecnologías de implementación
Uso también en otras áreas, , como la ingeniería g de
negocio, modelado de procesos, etc.
Adaptación/Extensión mediante perfiles.
2
4

Introducción
No es un método, método ni un proceso ni una metodología.
metodología
No establece qué modelos construir en el proceso de
desarrollo.
PPara un óptimo ó ti aprovechamiento, h i t ddebe b ser usado d en un
proceso:
guiado por casos de uso,
centrado en la arquitectura
arquitectura,
iterativo e incremental.
Vistas
Vi Vista t dde CCasos dde UUso
Funcionalidad externa del sistema
Vi Vista t Ló Lógica i
Estructura estática y conducta dinámica del sistema
Vi Vista t dde CComponentes t
Organización modular en componentes
Vi Vista t dde CConcurrencia i
Comunicaciones y sincronización
Vi Vista t dde DDespliegue li
Arquitectura física
5
7
Modelos
Familia de notaciones, útiles para describir
distintos aspectos p de un sistema:
Estático Estático. Describe los elementos del sistema y
sus relaciones.
Dinámico. Describe el comportamiento del
sistema a lo largo del tiempo tiempo.
Casos Casos de Uso Uso. Desde el punto de vista del usuario usuario.
Modelos
Tipos de
Diagramas
Modelos
UML
6
8

Tipos de Diagramas
Indice
Introducción
Introducción.
Diagramas de Clases y Objetos.
Otros Diagramas.
OCL.
Acción Semántica.
Perfiles Perfiles.
Bibliografía
Lecturas sugeridas/ejercicios.
9
11
Tipos de Diagramas
¿Cómo ¿ estamos seguros g de que q la
composición de un conjunto de diagramas es
correcta, es decir, que los modelos son
consistentes?
consistentes?.
¿Cómo podemos comprobar ciertas
propiedades de nuestro sistema global?
¿Cuál es la semántica precisa de los diagramas
y de sus combinaciones?
UML vs. Lenguajes Específicos de Dominio.
Clases y Objetos
LLos di diagramas dde Cl Clases y dde Obj Objetos t son llos principales i i l
modos de representar los aspectos estructurales en UML.
Diagramas de clases. Estructura del sistema.
Clases.
Atributos: Tipos, valores iniciales.
Operaciones: visibilidad.
Relaciones con otras clases: Asociaciones
Diagramas de objetos. Estructura del sistema en tiempo
de ejecución.
Objetos. Instancias de una Clase.
Atributos (valores actuales) actuales).
Links. Relaciones entre objetos, instancias de asociaciones.
10
12

Clases y Objetos
Diagrama de
clases l
Diagrama de
objetos
Clases
Atributos
Carbono
Notación para p atributos:
Elemento
:Hidrógeno
Hidrógeno
:Hidrógeno
:Hidrógeno :Carbono :Carbono
:Hidrógeno
:Hidrógeno :Hidrógeno
[visibilidad] [/] nombre [: tipo] [multiplicidad] [= valor] [{ propiedad }]
Visibilidad (opcional):
Pública: +
Privada: -
Protegida: #
Paquete: ~
“/” indica que el atributo es derivado.
La multiplicidad va entre [ ] y por defecto vale 1.
Propiedades válidas: {readOnly} {readOnly}, {union} {union}, {subsets },
{redefines }, {ordered}, {bag}, {seq},
{sequence}, y {composite}.
Un atributo subrayado es estático.
13
15
Clases y Objetos
Nombre
de la clase
visibilidad
Circulo
-radio: double
-centrox: t double d bl
-centroy: double
+Area(): double
+Perímetro(): double
At Atributos ib t
Operaciones
Nombre
ddel l objeto bj
unCirculo: Circulo
Clase
del objeto
radio = 3.4
centrox = 20 2.0
centroy = 2.0
Valores de
los atributos
Clases
Ejemplo atributos
ClaseA
name: String
shape: Rectangle
+ size: Integer [0..1]
/ area: Integer {readOnly}
hheight: i ht IInteger t = 5
width: Integer
# pos: Point
ClaseB
id: {redefines name}
shape: Square
14
16

Clases
Métodos
NNotación t ió para métodos: ét d
[visibilidad] [ ] nombre ( [lista-parametros] [ p ] ) : [{propiedad}]
[{p p }]
Visibilidad (opcional).
nombre del método
lista de parámetros formales, separados por coma:
direccion nombre : tipo [multiplicidad] = valor [{propiedad}]
Los métodos estáticos se subrayan.
Ejemplos:
display ()
-hide ()
+createWindow (location: Coordinates Coordinates, container: Container [0 [0..1]): 1]): Window
+toString (): String
Asociaciones: Navegación, Roles y
Cardinalidad
Las asociaciones pueden tener etiquetas:
Roles en la relación
MMultiplicidad lti li id d ( (cardinalidad) di lid d)
centro
Círculo Punto
1
Ej Ejemplos l de d cardinalidad: di lid d
1..* mínimo 1, no hay máximo
0 0..* * mínimo 0, 0 no hay máximo
0..1 mínimo 0, máximo 1
124 1,2,4 uno uno, dos o cuatro
3 exactamente tres
navegación g
N Navegación: ió
Unidireccional
Bidireccional
No especificado.
No navegable (x)
17
19
Asociaciones: Composición
Un Círculo contiene un Punto
Se representa con una Composición
Círculo Punto
Relación del tipo todo/parte
El todo es el Círculo
La parte es el Punto
Es una relación fuerte
Si el Círculo se destruye o copia, también lo es el Punto
La cardinalidad en la parte del todo es 0..1 o 1.
Asociaciones
Ejemplos de Navegación y Cardinalidad
18
20

Asociaciones: Agregación
Cuando la relación todo/parte no es tan
fuerte, , se utiliza Agregación g g
susFiguras
Ventana Figura
0 0.. *
La ventana contiene figuras,
pero cada una puede existir sin la otra
Clases Asociativas
Asociación con atributos propios.
Empleado
1
casado con
1
Persona
Matrimonio
testigos 2
fecha
0 0.. *
Clase Asociativa
21
23
Asociaciones y Dependencia.
Dependencia
Existen relaciones de conocimiento entre clases que no
implican una relación todo/parte
titular
cuentas
Cliente Cuenta
1 1.. *
0 0.. *
Dependencia: relación muy débil.
MMuchas h veces no se hhace explícita. lí it
Ejemplo
Ventana
suContexto
ContextoDibujo
susFiguras
0..*
Cliente
Orden
nombre 1 0..* fecha
dirección estado
Pago
1..* 1
monto 1
calcImpuesto
calcTotal
calcPesoTotal
Figura
Draw(ContextoDibujo)
Dependencia
línea 1..*
Crédito Efectivo Cheque DetalleOrden Item
fecha
número
moneda
nombre
identifBanco
cantidad
tipoImpuesto
0 0.. * 1 peso
descripción
tipo
autorizado
calcSubtotal
precioPorCantidad
autorizado
calcPeso
obtenerPeso
22
24

Clases y Objetos j
Estilo
Los atributos no deben ser objetos (utilizar
relaciones en tal caso).
En los diagramas de clases no suelen aparecer:
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”)
Ya que son detalles de implementación y no de
diseño.
No olvidar que q el diagrama g de clases es un
modelo, y por tanto una abstracción.
Ejercicio (entrega)
Especificar un diagrama de clases que describa redes de
ordenadores.
d d
Los elementos que se pueden incluir en la red son:
Servidor, PC, Impresora.
Hub, Cable de red.
Los PCs pueden conectarse con un único Hub, los servidores con
uno o varios.
LLos SServidores id y PC PCs pueden d generar mensajes, j con una cierta i t
longitud.
Los Hubs tienen un número de puertos, algunos de los cuales
puede usarse para conectar con otros Hubs Hubs. Tienen cierta
probabilidad de “perder” mensajes.
Las impresoras pueden averiarse, con cierta probabilidad, durante
cierto tiempo tiempo.
Entrega individual el día 2 de Noviembre.
25
27
Ejercicio je c c o (c (clase) ase)
Un sistema sencillo de revisión de conferencias científicas
El sistema puede gestionar varias conferencias a la vez.
Cada conferencia tiene uno o dos chairs.
Los autores envian artículos, dentro de un plazo. Uno de los autores
es el autor “de correspondencia”.
Estos son revisados por 3 revisores, dentro de un plazo.
En base a las revisiones, los chairs deciden aceptar o rechazar los
artículos. Para ello, envían una notificación a los autores de
correspondencia d i dde cada d artículo. tí l
El autor de correspondencia de los artículos aceptados envía una
versión final, dentro de un plazo.
Los artíc artículos los están descritos por un n tít título, lo aautores, tores res resumen men y
cuerpo del artículo.
Autores, revisores y chairs están descritos por un nombre, afiliación
y correo correo.
Las revisiones están compuestas por una nota (del 0 al 5) y una
sección de comentarios.
Los revisores de una conferencia pueden enviar artículos artículos, pero no
revisar sus propios artículos. Los chairs de la conferencia no
pueden enviar artículos.
Más sobre asociaciones
Asociaciones n-arias
Asociaciones entre más de dos clases:
Año
temporada d
EEquipo i equipo
JJugador d
pichichi
29

Más sobre asociaciones
Adornos en asociaciones y fin de asociación.
AAsociaciones i i dderivadas i d ( (con un “/” ddelante l t ddel l nombre). b )
Propiedades, cerca del nombre de la asociación.
Los finales de la asociación pueden adornarse con:
Multiplicidad.
Nombre (rol). ( )
Propiedades:
{subsets }.
{redefined }
}.
{union}.
{ordered} (un conjunto ordenado).
{bag} (conjunto con repetición) repetición).
{sequence} o {seq} (bag ordenado).
Más sobre asociaciones
Asociaciones Cualificadas
Un cualificador declara una partición del conjunto de instancias asociadas con
respecto a la instancia cualificada.
Banco
NumCuenta
*
0..1
Tablero
Ajedrez
fila: Fila
col: Colum
1
1
Persona Casilla
Dado un objeto cualificado, el número de objetos al otro lado de la asociación
viene i ddado d por lla multiplicidad lti li id d ddeclarada. l d
0..1 : el valor del cualificador es único.
0..* : el conjunto de instancas asociadas se particiona en subconjuntos.
Similar a un array asociativo, asociativo map o tabla hash hash.
30
32
Más sobre asociaciones
Adornos en asociaciones y fin de asociación: Ejemplos
a b
A B
0..1 *
{ordered}
C D
d
1 0..1
{subsets b}
Para un objeto de tipo C, la colección d es un subconjunto de la colección b.
Pre Pre- yPost y Post- Condiciones Condiciones, Notas
pre-condición
body-condition
post-condición
31
33

Interfaces
Clase
Objetos
MiInterfaz
métodos
e2 : Empleado
e1 : Empleado
-nombre=“María”
- nombre=“Pedro”
- edad=25 edad 25
- edad=23 edad 23
- sueldo_bruto=36000
- sueldo_bruto=30000
subordinados empleados empleados
Clase
Clase
d1 : Directivo
-nombre=“Luis”
-edad=35 d d 35
- sueldo_bruto=36000
empleados
Empresa
- nombre=“HGJ”
-categoria=“C1”
clientes
c1 : Cliente
-nombre=“Luis”
- edad=35
- nombre_empresa=“Macroware”
- telefono_de_contacto=91555666
MiInterfaz
MiInterfaz
Persona
-nombre
-edad
+ mostrar()
Empleado Cliente
subordinados
-sueldo_bruto -nombre_empresa
+ mostrar ()
- telefono_de_contacto
+ calcular_salario_neto()
l l l i t ()
+mostrar()
empleados clientes
Directivo
-categoria
+ mostrar ()
34
Empresa
-nombre
36
Plantillas
Indice
Farray Point>
Introducción.
Diagramas de Clases y Objetos.
Una clase anónima ligada:
T -> Point
K -> 10
Otros Otros Diagramas
Diagramas.
Diagramas Estructurales.
Casos de Uso Uso.
Diagramas de Comportamiento.
OCL.
Acción Semántica.
PPerfiles. fil
Bibliografía
Lecturas sugeridas/ejercicios
sugeridas/ejercicios.
35
37

Diagramas Estructurales
Clases y Objetos (ya vistos) vistos).
Componentes.
Módulos con interfaces.
EEstructuras t t CCompuestas. t
Clases con estructura interna.
Paquetes.
Estructura de la aplicación.
Despliegue.
Vista física.
Componentes
Interfaces
que ofrece
Interfaces
que requiere
40
Componentes
CComponente=“Unidad t “U id d MModular d l con iinterfaces t f
bien definidos que es reemplazable en su
entorno” entorno .
ÉÉnfasis f i enreutilización tili ió y encapsulamiento. l i t
Servicios que provee y requiere (interfaces).
Componentes lógicos (componentes de negocio,
de proceso) y físicos (EJB, CORBA, COM+, .NET,
…)
Componentes
Vi Vista t dde caja j bl blanca
39
41

Estructuras Compuestas
CComposición i ió dde elementos l t ( (clasificadores l ifi d o
colaboraciones)
Instancias en tiempo de ejecución que colaboran
a través de
comunes.
enlaces para alcanzar objetivos
Colaboraciones: a través de roles.
Se añade a las clases estructura internas y
puertos.
Estructuras Compuestas p
Colaboración.
Et Estructura t it interna dde una colaboración. lb ió
42
44
Estructuras Compuestas
Paquetes
Estructura interna de una clase. clase
Estructura interna de una clase. Multiplicidades.
Un paquete es un contenedor que agrupa elementos
relacionados.
Los diagramas de paquetes muestran la estructura de alto
nivel de la aplicación. aplicación
43
45

Paquetes
Un paquete puede extender aotrouniendosus
contenidos.
El contenido del paquete “target” se une con el
contenido del paquete “source” por medio de
especialización y redefinición donde sea
aplicable ( (elementos del mismo nombre). )
Paquetes Paquetes. Plantillas Plantillas.
46
48
Paquetes. q Unión (merge). ( g )
Despliegue
DDefinen fi lla arquitectura it t dde ejecución j ió dde un sistema. i t
Representa la asignación de artefactos software a nodos nodos.
Nodos = elementos hardware, o entornos
de ejecución software.
Artefactos = elementos concretos (p.e.:
ficheros) que son el resultado del proceso
de desarrollo.
47
49

Despliegue p g
Relaciones entre artefactos.
Casos de Uso
“Manifestación” de
elementos a través de
artefactos
AActor t = Al Algo con comportamiento t i t ( (persona, otro t
programa, organización...), que interactua con el
sistema sistema.
EEscenario i (i (instancia t i dde caso d de uso) ) =
Secuencia de acciones e interacciones entre los
actores y el sistema sistema.
CCaso dde UUso = CColección l ió dde escenarios i (é (éxito it y
fracaso) que describen actores que usan el
sistema para conseguir un objetivo objetivo.
50
52
Casos de Uso
DDescriben ib quéé hhace ell sistema it ddesde d ell punto t
de vista de un observador externo.
Ponen énfasis en qué hace el sistema, no en
cómo ó llo hhace.
Un escenario es una instancia particular de un
diagrama de casos de uso.
Ejemplo de lo que ocurre cuando alguien interactúa con
ell sistema i t
Casos de Uso: Ejemplo
Cajero Terminal
Punto de Venta
(TPV)
51
53

Casos de Uso: Ejemplo
CASO DE USO 1: Procesar venta
Actor Primario:
CCajero. j
Interesados y objetivos:
Cajero: Quiere anotaciones precisas y rápidas de precios, sin errores.
Cli Cliente: t QQuiere i que ell pago sea rápido á id conell mínimo í i esfuerzo. f QQuiere i
una prueba de compra para justificar devoluciones.
Compañía: Quieren almacenar las transacciones y satisfacer los
intereses de los clientes.
Comercial: Quiere que se le actualicen sus comisiones por venta.
Agencias de impuestos gubernamentales: Quieren recolectar impuestos
de cada venta. Puede que haya varias agencias (nacionales, regionales,
etc.) t )
Servicios de Autorización de Pagos (por tarjetas de crédito): Quiere
recibir peticiones digitales de autorizaciones en el formato y protocolo
correcto.
Precondiciones:
54
El cajero se ha identificado y autentificado.
Casos de Uso: Ejemplo
Extensiones (Flujos alternativos):
a*. En cualquier momento, el sistema falla.
3a. Identificador inválido.
1. El sistema señala un error y rechaza la entrada.
7a. Pago en efectivo.
...
7b 7b. Pago con tarjeta tarjeta.
...
Requisitos especiales:
Pantalla táctil en panel grande y plano. El texto debe ser visible desde un metro.
Respuesta de autorización de crédito en menos de 30 secs, el 90% de las veces.
Recuperación robusta cuando el acceso a sistemas externos (tales como el inventario,
impuestos, etc.) falla.
Posibilidades de internazionalización de texto.
Reglas de negocio insertables en los pasos 3 y 7.
...
56
Casos de Uso: Ejemplo
Garantía de éxito (Postcondiciones):
Se registra la compra en el sistema. Se calcula el impuesto aplicable. Se actualizan los sistemas de
inventario y de contabilidad. Se registran las comisiones. Se genera un recibo. Se registran las
aprobaciones de pago por tarjeta.
Escenario principal de Exito:
1. Llega un clienta al TPV con bienes o servicios que comprar.
2. El cajero comienza una nueva compra.
3. El cajero introduce un identificador de producto.
44. El sistema it registra i t ell elemento l t ypresenta t unadescripción d i ió ddel l mismo, i su precio i y
total actual. Se calcula el precio de una lista de reglas.
El cajero j repite p los pasos p 3-4 hasta que q no hayy más elementos.
5. El sistema presenta el total con los impuestos calculados.
6. El cajero le dice el total al cliente, y le pide que pague.
77. El cliente paga y el sistema procesa el pago pago.
8. El sistema registra la venta completada y manda la información a los sistemas
externos de inventario y contabilidad.
9. El sistema genera el recibo.
10. El cliente se va.
Casos de Uso: Ejemplo
Lista de variaciones de tecnología y datos:
3a. Se introduce el identificador del elemento mediante escáner de código de barras o
mediante el teclado.
3b. Distintos esquemas de identificadores: UPC, EAN, JAN o SKU.
7a. La información sobre el pago con tarjeta se puede introducir mediante el teclado o
lector.
7b. Se pide firma en papel. En dos años, creemos que muchos clientes van a querer
captura de firma digital.
Frecuencia de ocurrencia:
Puede ser casi continua.
Temas abiertos:
¿Cuáles son las posibles variaciones en las leyes sobre impuestos?
Explorar el tema de recuperación en caso de fallo de sistemas externos.
¿Qué modificaciones se necesitan para negocios distintos?
¿Debe el cajero extraer el cajón con la recaudación al terminar?
¿Puede el cliente usar directamente el lector de tarjetas o es el cajero el que lo hace?
55
57

Casos de Uso: Ejemplo
cajero
TPV
Procesar
Venta
Procesar
Devoluciones
Servicio
de Autorización
de Pagos
«actor»
Analizar
«actor»
Analizador de
Atiiddd Actividad de
Ventas
Actividad
Calculador de
Impuestos p
...
«actor»
Administrador
del sistema
Gestionar
Seguridad
Gestionar
Usuarios
Casos de Uso: Ejemplo
SSon útil útiles en ttres ááreas:
Especificación de requisitos
Sistema de
contabilidad
Comunicación con los clientes
Su simplicidad los convierte en excelentes medios de
comunicación
Generación de casos de prueba
A partir de los escenarios de un Caso de Uso
58
60
Casos de Uso: Ejemplo
Cancel Appointment
Make Appointment
Patient Request Medication
PPay Bill
Extensions Points
More Treatment
Check Patient Record
Defer Payment
Bill Insurance
Shdl Scheduler
Doctor
Diagramas de Comportamiento
Comportamiento.
Diagramas Di dde IInteracción. t ió
Comunicación.
Secuencia.
Visión de conjunto j de la interacción.
Tiempo.
Diagrama de Estados (Statecharts).
Diagrama de Actividad.
Clerk
59

Diagramas de Interacción
Diagrama de Comunicación
Muestra un contexto y una interacción interacción.
Di Diagrama dde SSecuencia i
Representación explícita de la secuencia de
comunicaciones, eje temporal.
Es más apropiado para aplicaciones con
interacciones complicadas
Diagramas de Comunicación
Llamadas anidadas:
realizarPago(cantidad) 1: realizarPago(cantidad)
:Registro :Venta
Iteraciones:
1.1: crear(cantidad)
:Pago
Ejectuar() 1*[i:=1..N]: num:= nextInt()
:Simulador :Random
62
64
Diagramas de Interacción
EEstructura t t dde llos participantes ti i t
Diagramas de Comunicación
Patrones de comunicación
Diagramas de Comunicación
Diagramas de Secuencia
Temporización p de la comunicación.
Diagramas de Secuencia
Diagramas de Tiempo.
Estructuración de las interacciones
Diagrama g de visión de conjunto j de la
interacción.
Diagramas g de Comunicación
Ejemplo.
redisplay()
1.1*[i:=1..n]: drawSegment(i)
>
:Controller :Window
wire:Wire
i-1 i
1:displayPositions(window) 1.1.3.1:add(self)
wire
111 1.1.1a: r0:= 0 position() ii () 111b 1.1.1b: r1:= 1 position() ii ()
left:Bead right:Bead g
> line
1.1.2: create(r0,r1)
1.1.3: display(window)
:Line Li {new} { }
63
contents {new}
65

Diagramas de Secuencia
RRepresenta t conjunto j t de d mensajes j entre t roles l
(o instancias) en una interacción
Dos dimensiones:
Tiempo Tiempo (generalmente vertical); puede ser una escala si
el sistema es de tiempo real
Dif Diferentes t instancias i t i (generalmente ( l t horizontal); h i t l) el l
orden relativo no tiene importancia
Se muestra la existencia y duración de las
instancias, pero no sus relaciones
Diagramas de Secuencia
:caller :exchange :receiver
a: lift receiver
b: dial tone
Objetos
c: di dial l digit di it
...
Focos de
d: route
Control
ringing tone phone rings
Mensajes
answer phone
stop tone stop ringing
66
68
Diagramas de Secuencia
Traza:secuencia de ocurrencias de eventos La semántica de una interacción es un par de conjuntos
de trazas (válidas e inválidas) [P, I].
PPueden d existir i ti ttrazas no iincluidas l id en llos ddos conjuntos j t
anteriores.
Equivalencia de interacciones, si sus conjuntos de trazas
son iguales.
Una interacción se puede especializar: se añaden más
trazas al conjunto. j
Diagramas de Secuencia
67
Gate (formal),
con nombre
out out_Unlock
Unlock
69

Diagramas g de Secuencia
Operadores sobre interacciones.
Fragmentos combinados combinados, operadores (i):
Alternativa (alt).
Elección (mediante una guarda) de una interacción interacción.
Aserción (assert).
Laa secuencia secue c a especificada espec cada por po el e operador ope ado es laa única ú ca válida. áda
Opción (opt).
Equivalente a un operador alt con un solo fragmento.
Ruptura (break).
El operando se ejecuta en lugar del resto de la interacción englobada en el
fragmento “padre”. padre .
Paralelo (par).
Mezcla de las trazas de los operandos (cualquier entrelazado es válido
mientras preserve el orden de los eventos de cada operando) operando).
Diagramas g de Secuencia
Operadores sobre interacciones. Alternativa.
70
72
Diagramas g de Secuencia
Operadores sobre interacciones.
Secuenciación débil (seq) (seq).
Define un conjunto de trazas que cumple:
1. Se mantiene el orden de eventos de los operandos
2. Eventos de otras líneas de vida de otros operandos pueden venir en cualquier
orden.
3. Eventos de la misma línea de vida de otros operandos se ordenan de tal
manera que cualquier evento del primer operando va antes que el del
segundo.
Secuenciación estricta (strict).
Secuenciación estricta en el orden de los eventos de los operandos.
Negativa (neg).
Define trazas inválidas.
Región crítica (critical).
Los eventos del operando no pueden mezclarse con ningún otro.
Diagramas g de Secuencia
Operadores sobre interacciones. Opción.
71
73

Diagramas g de Secuencia
Operadores sobre interacciones. Región Crítica.
Diagramas g de Secuencia
Loop.
74
76
Diagramas g de Secuencia
Negative.
Diagramas g de Secuencia
Tiempo
Restricciones temporales (duración)
Duración de mensajes y señales (duration)
Intervalos de tiempo ({t..t+3}) y restricciones temporales.
Observaciones temporales (tiempo actual, now)
77
Asignación de instantes a variables (t=now), restricciones sobre estas.
75

Visión de Conjunto de la Interacción
DDefine fi las l interacciones i t i a ttravés é dde
una
variante de los diagramas de actividad.
Visión general del flujo de control.
Usa elementos de los diagramas de actividad
para especificar:
Alternativas entre interacciones.
Paralelismo de interacciones.
Bucles de interacciones.
Tiempo
Muestran M t iinteracciones t i ddonde d es
importante razonar sobre el tiempo.
Representa Representa condiciones que cambian en
una o varias líneas de vida, en un eje
lineal de tiempo tiempo.
Cambios en el estado de un objeto con el
tiempo en respuesta a eventos.
78
80
Visión de Conjunto de la Interacción
Tiempo
Diagrama temporal
correspondiente p
a la interacción
79
81

Tiempo
Máquinas de Estados
“St “Statecharts” t h t ”[H [Harel] l]
Representan el comportamiento de entidades ( pe p.e.
instancias de clases).
Especifican reacción ante eventos
Describen posibles secuencias de estados y acciones
por las que pueden pasar las entidades.
De comportamiento vs. de protocolo.
82
84
Tiempo
Máquinas de Estados
Comienzo Estados
Fin
digit(n)
start Partial Dial
Transiciones
digit(n)
83
85

Máquinas de Estados
Un estado tiene:
Nombre
Transiciones internas: lista de acciones ejecutadas en ese
estado (entry/exit/do)
( y )
Ejemplo: j p
Typing Password
entry/set t / t echo h invisible i i ibl
exit/set echo normal
character/handle character
help/display help
Máquinas de Estados
Componentes Ortogonales:
Incomplete
lab done
Lab1 Lab2
Nombre
Transiciones
internas
Term
Project
project done
Passed
Final
Test
fail
pass
Failed
86
88
Máquinas de Estados
Start
entry/start dial tone
exit/stop dial tone
digit(n)
Partial Dial
entry/number.append(n)
Estado compuesto:
Dialing
Start
entry/start y dial tone
exit/stop dial tone
digit(n)
Máquinas de Estados
PPseudo d - estados: t d
Fork / Join.
Initial.
Deep History / Shallow History. H* H
Junction.
Choice.
Entry / Exit point.
Terminate.
digit(n)
Partial Dial [number.isValid()]
entry/number.append(n)
y pp ( )
A1 A2
digit(n)
Setup Cleanup
B1 B2
Fork Join
87
89

Máquinas q de Estados
Estado Histórico
I
t1: ev0
t4: ev2
B12
t3: ev1
H
t4
B1 B2
B11
Máquinas q de Estados
Estado Histórico. Ejercicio.
t2
Modelar el comportamiento de una
cadena de música. Esta puede p estar
encendida (ON) o apagada (Standby). La
cadena tiene reproductor de CD CD, Radio y
Cinta. Se cambia de uno a otro con el
botón “mode” mode . Cuando se enciende la
cadena se recuerda el último estado en el
que estuvo.
B
B21
t3
90
92
Máquinas q de Estados
Estado Histórico (ii)
I
t1: ev0
t4: ev2
B12
t3: ev1
H* H
t4
B1 B2
B11
Máquinas de Estados
Pseudo - estados: Junction.
Pseudo - estados: Choice.
t2
B
B21
t3
91
95

Máquinas de Estados
UUn ttransición i ió puede d ttener:
[not driver.
detectarAbierto()]
C
[drriver.detectarrAbierto()]
eject e ()/
driver.abrir d () (
Evento.
Eventos Eventos temporales: tm(n)
Acción.
pre-condiciones (guardas) y post- condiciones.
[guard] evt/action [post-]
A1 A2
Símbolos especiales para el envío y recepción de
señales (normalmente usados en diagramas de
actividad). )
Ejemplo. Diagrama de estados para la
clase ReproductorCD
p
Cerrado
eject ()/
driver.cerrarr
()
Abierto
[(info=driver.detectarDisco())!=NULL]/
disco=buscaDisco(info)
NumActual = 1;
actual = disco.obtenerCancion(ordenActual)
( )
eject ()/
driver.stop();
driver.abrir()
Play()/
Stop driver.play(actual, 0) Play
stop()/
driver.stop();
NumActual=1
NumActual 1
actual=
disco.obtenerCancion(NumActual)
Play()/
driver.pllay(actual,
Tppausa)
apagar ()/
driver.stop();
driver.apagar()
endOfSong()/
NumActual+=1
Pause() )/
Tpausa = driver.stopp()
Pause
C
96
[NumActual

Ejercicio
Interface provisto por el controlador:
getTime() : Devuelve la hora actual.
refreshTimeDisplay() : Repinta la hora en el visor con la hora interna actual. El
visor no necesita limpiarse antes de llamar a esta función. Por ejemplo, si se está
visualizando el crono, se borrará antes de pintar la hora.
refreshChronoDisplay() :verrefreshTimeDisplay(). resetChrono() : Resetea el crono interno a 00:00:00.
increaseTime() : Incrementa la hora en un segundo. Los minutos y horas se
modificarán adecuademente, (por ejemplo, si se llama a increaseTime () a las
11:59:59, la nueva hora será 12:00:00).
increaseChrono () : Incrementa el crono en 1/100 segundos.
setLight() : Enciende la luz del visor.
unsetLight() : Apaga la luz del visor visor.
Eventos de botones recibidos:
topRightPressed.
topRightReleased.
p g
topLeftPressed.
topLeftReleased.
bottomRightPressed.
bottomRightReleased
bottomRightReleased.
bottomLeftPressed.
100
bottomRightReleased.
Máquinas q de Estados
Ejemplo. Herramienta de Dibujo (ii)
Shapes Canvas
Modes
103
Máquinas de Estados
Ejemplo. Herramienta de Dibujo (i)
wmQuit
/setup widgets
setup t bi bindings di
Active
exitButton
Máquinas q de Estados
Ejemplo. Herramienta de Dibujo (iii)
Shapes
shapeSelected(Triangle)
shapeSelected(Rectangle)
Triangle
shapeSelected(Circle)
shapeSelected(Triangle)
p ( g )
Rectangle
shapeSelected(Circle)
h S l t d(Ci l )
shapeSelected(Rectangle)
Circle
102
104

Máquinas q de Estados
Ejemplo. Herramienta de Dibujo (iv)
Modes
modeSelect(Insert)/
Canvas.Insert
modeSelect(Move)/
Canvas.Move
Insert
modeSelect(Delete)/
Canvas.Delete
modeSelect(Insert)/
Canvas.Insert
Move
modeSelect(Delete)/ ( )/
Canvas.Delete
Delete
modeSelect(Move)/
CCanvas.Move M
Diagramas de Actividad
Refinamiento de los diagramas de estados estados.
Los estados representan p la ejecución j de acciones o
subactividades
Las transiciones son disparadas p cuando se completan p estas
acciones o subactividades
Semántica basada en tokens.
Flujos dirigidos por procesamiento interno (en los
diagramas de estados normales son dirigidos por eventos
externos).
Semántica basada en Redes de Petri. No obstante no se
107
da una transformación a Redes de Petri.
105
Canvas
onDrawingMouse1Press(x,y)
Idle
move
insert
Máquinas de Estados
Ejemplo Ejemplo. Herramienta de Dibujo (v)
Idle
[Shapes in Circle]/
Insertingg
ddrawCircle(x,y) Ci l ( )
[Shapes in Rectangle]/
drawRectangle(x,y)
[Shapes in Triangle]/
drawTriangle(x,y)
C
Moving
delete
insert
Idle
Deleting
onDrawingMouse1Press(x,y)/
movingObject=find_closest(x,y)
i Obj t fi d l t( ) onDrawingMouse1Click(x,y)/
D i M 1Cli k( )/
find_closest(x,y).del()
onDrawingMouse1Release(x,y)
Moving
onDrawingMouse1Motion(x,y)/
oldCoords=coords(movingObject)
move(movingObject, distance(oldCoords, (x,y)))
Diagramas g de Actividad
Ejemplo
[found
coffee]
Find
Beverage g
Put Coffee
Put Filter
in Filter in Machine
Add Water
to Reservoir
move
Turn on
Machine
Brew
coffee
delete
106
/ coffeePot.turnOn
[no coffee]
Get
Cups
light goes out
Pour
Coffee
[found cola] Get cans
of cola
[no cola]
Drink
108

Diagramas de Actividad
Swimlanes
Indice
Introducción.
Diagramas de Clases y Objetos.
Otros Diagramas. g
OCL.
Acción Semántica Semántica.
Perfiles.
Bibliografía g
Lecturas sugeridas/ejercicios.
109
111
Diagramas de Actividad
Flujos de Objetos: Objectflows
OCL: Object Constraint Language
Lenguaje de restricciones para expresar condiciones
adicionales que no podemos expresar con diagramas y
cardinalidades.
Combinar diagramas y especificaciones textuales.
Lenguaje preciso, no ambiguo, declarativo, tipado, basado
en matemáticas
conjuntos) conjuntos).
(lógica de predicados y teoría de
Útil en DSDM: modelos precisos p (no ( anotaciones en
lenguaje natural).
Se utiliza fundamentalmente junto a los diagramas de
clases.
112
110

Ejemplos
Flight
Flightnr: Integer
availableSeats(): Integer
0 0.. *
flights
1
plane
Airplane
numberOfSeats: Integer
flights 0 0.. *
passengers
0..*
PPerson
name: String
También es un lenguaje de consultas (mismo
poder expresivo que SQL).
Context Flight::availableSeats(): Integer
body: plane.numberOfSeats – passengers->size()
¿Cómo se expresa el hecho de que en ningún vuelo puede haber
más pasajeros p j que q asientos tiene el avión?
Restricción OCL:
Context Flight
Inv: passengers->size() isUnique(numSegSoc)
Context Persona::contratarHipoteca(sum: Dinero, aval: Casa)
pre: self.hipotecas.mensual->sum()+sum = aval.hipotecas.principal->sum()
113
115
Ejemplos
Casa
Persona
valor: Dinero
0 0.. *
casas
1 numSegSoc: S S Identificador
Id ifi d
propietario sueldo: Dinero
aval 1
Hipoteca
principal: Dinero
contratarHipoteca(sum: Dinero,
aval: Casa) )
1 contratante
0..* mensual: Dinero 0..*
hipotecas fechaInicio: Fecha
fechaFinal: Fecha
hipotecas
Reglas adicionales:
1. Una persona puede tener una hipoteca sobre una casa sólo si es el
propietario.
22. La fecha de inicio de cada hipoteca ha de ser menor que la de final final.
3. El número de la seguridad social de cada persona ha de ser único.
4. Sólo es posible contratar una nueva hipoteca si el salario de la persona
es suficiente.
5. Sólo es posible contratar una nueva hipoteca si el valor de la casa aval
es suficiente.
Ejemplos
“Los PCs pueden conectarse con un único Hub, los servidores con uno o varios”
Context PC
Inv: cable_equipo->size() = 1
Context Servidor
Inv: cable_equipo->size() >= 1
114
116

Ejercicio
“Un Hub no puede conectarse consigo mismo a través de
un puerto”
Context Cable_Hubs
Inv: Puerto_Hub.hub->asSet()->size() = 2
Ejemplos
EEspecificación ifi ió ddel l valor l iinicial i i l y dderivado i d dde atributos/association t ib t / i ti ends: d
context Person::income : Integer
init: parents.income->sum() * 1% -- pocket allowance
dderived:if i d if self.age lf < 18
then parents.income->sum() * 1% -- pocket allowance
else job.salary -- income from regular job
endif
Subexpresiones (let):
context Person inv:
let income : Integer = self.job.salary->sum() in
if isUnemployed then
income < 100
else
income >= 100
endif
117
119
Ejemplos
parents
0..*
children 0..*
Ejemplos Ejemplos. Colecciones.
Colecciones
Tipos: Set, OrderedSet, Bag, Sequence.
Operaciones de bucle con colecciones:
select(expr): selecciona los elementos que cumplan una condición.
coleccion->select( expresion-logica )
coleccion->select( l i l t( v | expresion-logica-con-v)
i l i )
coleccion->select( v : Type | expresion-logica-con-v)
context t t CCompany iinv:
self.employee->select(age < 25)->notEmpty()
context Company inv:
self.employee->select(gender=female)->notEmpty()
118
120

Ejemplos Ejemplos. Colecciones.
Colecciones
collect(expr): devuelve la colección que resulta de evaluar expr
para cada elemento de la colección fuente.
self self.employee->collect( employee >collect( birthDate ) )->asSet() >asSet()
forAll(expr): devuelve verdadero si expr es verdadero en cada
elemento de la colección.
coleccion->forAll( expresion-logica )
coleccion->forAll( v | expresion-logica-con-v )
coleccion->forAll( v : Type | expresion-logica-con-v )
context Company
inv: self.employee->forAll( isUnemployed = False )
inv: self.employee->forAll( p | p.isUnemployed = False )
iinv: self.employee->forAll( lf l >f All( p : Person P | p.isUnemployed i U l d = FFalse l )
Colecciones Colecciones. Otras Operaciones
Operaciones.
Otras operaciones p de bucle:
source->any(iterator|body)
source->select(iterator|body)->asSequence()->first()
source->collectNested(iterators|body)
source collectNested(iterators|body)
Bag de elementos que resultan de aplicar body a cada elemento de
source.
source->isUnique(iterators|body)
( | y)
True si body se evalua a un valor diferente para cada elemento de
source.
source->one(expr)
Devuelve true si existe exactamente un elemento de source que cumple
la condición.
source->reject(expr)
Devuelve una colección con los elementos de source que no cumplen la
condición.
source->sortedBy(expr)
Ordena source, source resulta en un OrderedSet
121
123
Ejemplos Ejemplos. Colecciones.
Colecciones
exists(expr): devuelve true si al menos hay un elemento en la
colección para el que expr es verdadera verdadera.
coleccion->exists( expresion-logica )
coleccion->exists( v | expresion-logica-con-v )
coleccion->exists( v : Type | expresion-logica-con-v )
context Company
inv: self.employee->exists( age > 50 )
inv: self.employee->exists( p | p.age > 50 )
inv: self.employee->exists( p : Person | p.age > 50 )
iterate(…): itera sobre todos los elementos de una colección.
coleccion->iterate( elem : Type; acc : Type = | expresion-logica-
con-elem-y-acc l )
collection->collect(x : T | x.property)
collection->iterate(x ( : T; ; acc : T2 = Bag{} g{} | acc->including(x.property))
g( p p y))
Indice
Introducción.
Diagramas de Clases y Objetos.
Otros Diagramas. g
OCL.
Acción Acción Semántica.
Perfiles.
Bibliografía g
Lecturas sugeridas/ejercicios.
añade un elemento a una colección
122
124

Acción Semántica
Una parte del meta meta-modelo modelo de UML contiene la
especificación de un lenguaje para la manipulación de
modelos (i.e. sólo la sintaxis abstracta).
Modelos similares a los de flujo de datos.
Permite describir el contenido de métodos, y acciones
ejecutables en un lenguaje abstracto, antes de la
iimplementación. l ió
Se persigue un modo estándar estándar, independiente de la
plataforma y de la implementación de especificar
comportamientos detallados.
125
¿Primer paso hacia la “ejecutabilidad” de modelos UML?
Acción Semántica
Actividades. Ejemplo.
Sintaxis abstracta
(parcial)
127
(De C. Bock)
Acción Semántica
AAcciones i y Actividades.
A ti id d
Acción: Unidad fundamental de comportamiento.
p
Convierte un conjunto de entradas en un conjunto de
salidas salidas.
Las entradas pueden ser salidas de otras acciones
(dataflow).
LLas acciones i están tá contenidas t id en actividades, ti id d que lles
proporcionan un contexto, así como restricciones de
secuencialidad y control, y mecanismos de estructuración
anidada. id d
Lenguaje de acción semántica: acciones
primitivas+mecanismos de estructuración de 126 las
actividades.
Acción Semántica
Actividades. Ejemplo.
Sintaxis abstracta
(parcial)
128

Indice
Introducción.
Diagramas de Clases y Objetos.
Otros Diagramas. g
OCL.
Acción Semántica.
Perfiles.
Bibliografía g
Lecturas sugeridas/ejercicios.
Perfiles
En UML1.x: estereotipos y etiquetas
UML::Class
Desventajas:
Las etiquetas no tienen tipo, son Strings.
No es posible declarar nuevas asociaciones.
MiComponente
{ transactional}
Formalmente la extensión se realiza en el nivel M1. “Semanticamente”
en el M2. 2
M0
M3 MOF Meta-modelo de MOF
M2 UML Meta-modelo de UML
M1
MModelos d l UML
Datos/Tiempo ejecución
129
131
Perfiles
MMecanismos i dde extensión t ió (i (i.e. no modificación) difi ió ) para
declarar nuevas construcciones dentro de UML,
adaptadas p a un dominio específico. p
Útiles para: p
Dar una terminología adaptada a un dominio específico (p.ej.:
EJBs, CORBA, Servicios web, etc).
Dar una sintaxis para elementos que no tienen notación (p (p.ej.: ej :
acciones).
Dar una notación distinta para un símbolo existente.
Añadir “semántica” que no se especifica en el meta meta-modelo. modelo
Añadir restricciones adicionales.
Añadir información adicional útil para transformaciones.
Ejemplo j p
Un perfil sencillo para EJB
130
132

Ejemplo j p
Definiendo un perfil
Sintaxis concreta de un stereotype
Sintaxis abstracta de un stereotype
Ejemplo
Perfil para servicios web
http://www.ibm.com/developerworks/rational/library/05/419_
133
135
Ejemplo j p
Aplicación de perfiles
Clases como
tipos de las
propiedades del
stereotype
Perfiles en UML2 UML2.0 0
FFormalmente l t seguimos i realizando li d lla extensión t ió
en el nivel M1.
Mejor soporte de propiedades y asociaciones
que en la versión 1.x.
¿Cuándo realizar un profile y cuándo crear un
meta-modelo basado en MOF?.
Este mecanismo no sería necesario con
herramientas más potentes de meta-modelado
(que permitan acceder al meta meta-modelo modelo de UML) UML).
136
134

Perfiles
Multitud de perfiles “no estándar”.
Perfiles promovidos por la OMG:
CORBA.
CORBA Component Model (CCM).
Enterprise Application Integration (EAI). (EAI)
Enterprise Distributed Object Computing (EDOC) (UML 1.4):
Enterprise Collaboration Architecture (ECA).
Metamodel and UML Profile for Java and EJB.
Fl Flow Composition C iti MModel d l (FCM)
UML Profile for Patterns
UML Profile for ECA
UML Profile for Meta Object Facility
UML Profile P fil for f Relationships
R l ti hi
Real-Time Embedded Systems (MARTES).
QoS and Fault Tolerance Characteristics and Mechanisms
Schedulability, y Performance and Time
System on a Chip (SoC).
Software Radio.
Voice.
Systems Engineering (SysML). (SysML)
Testing.
Otros: SPEM.
Bibliografía: UML
Web de la OMG sobre UML: http://www.uml.org
UML 2.0 in a Nutshellby Dan Pilone; Neil Pitman. O'Reilly. June 2005
Perdita Stevens, Rob Pooley. “Utilización de UML en Ingeniería del
Software con Objetos y Componentes” Componentes . Addison Wesley Wesley, 2002 2002.
Grady Booch, James Rumbaugh, Ivar Jacobson. “The Unified Modeling
Language User Guide”. Addison-Wesley, 1999.
UML 2 Toolkit. Eriksson, H. E., Penker, M., Lyons, B., Fado, D. OMG
Press, Wiley. 2004.
Craig Larman Larman. “Applying Applying UML and Patterns Patterns” . Prentice Hall Hall. 2002 2002.
137
139
Indice
Introducción.
Diagramas de Clases y Objetos.
Otros Diagramas. g
OCL.
Acción Semántica.
Perfiles.
Bibliografía. g
Lecturas sugeridas/ejercicios.
Bibliografía
UML:
Infraestructura y Superestructura:
http://www.omg.org/technology/documents/formal/uml.htm
Atiidd Actividades y AAcciones: i
Conrad Bock: “UML 2 Activity and Action Models”, in Journal of
Object Technology, vol. 2, no. 4, July-August 2003, pp. 43-53.
http://www.jot.fm/issues/issue_2003_07/column3
Conrad Bock: “UML 2 Activity and Action Models Part 2:
Actions”, Actions , in inJournal Journal of Object Technology, vol. 2, no. 5, pp. 41 41-
56. http://www.jot.fm/issues/issue_2003_09/column4
“UML 2 Activity and Action Models Part 3: Control Nodes”, in
Journal of Object Technology, Technology vol vol. 22, no no. 66, pp pp. 7-23 7-23.
http://www.jot.fm/issues/issue_2003_11/column1
Conrad Bock: “UML 2 Activity and Action Models Part 4: Object
NNodes”, d ” iin JJournal lof fObj Object tT Technology, h l vol. l 33, no. 11, pp. 27 27-
41. http://www.jot.fm/issues/issue_2004_01/column3
138
140

Bibliografía: Statecharts
Harel D D. “On Visual Formalisms” Formalisms”. Communications of the
ACM. Vol 31, No. 5. Pp.: 514-530. Mayo 1988.
Harel D., Naamad A. “The STATEMATE Semantics of
Statecharts”. ACM Transactions on Software
Engineering and Methodology Methodology, Vol Vol. 55, No No. 44, Oct Oct. 1996 1996,
pp.: 293-233.
DDavid id HHarel l andd EEran GGery. EExecutable bl object bj
modeling with statecharts. IEEE Computer, pages 31-42,
1997.
Bibliografía
Perfiles UML.
Lista de perfiles p estándar:
http://www.omg.org/technology/documents/profile_catalog.htm#UML_for_EDOC
141
143
Bibliografía
OCL
The Object Constraint Language 2nd Edition. Getting your
Models Ready for MDA. MDA Warmer, Warmer Kleppe Kleppe. Addison Addison-Wesley. Wesley
2003.
Especificación de OCL 2.0: http://www.omg.org/docs/ptc/03-
10-14.pdf
Lecturas Recomendadas
D. D Th Thomas. “UML – UUnified ifi d or UUniversal i l
Modeling Language?”. Journal of Object
Oi Oriented t d TTechnology. h l VVoll 2 (1) (1), JJanuary-
February 2003.
S. S. Anonsen. “Experiences Experiences in Modeling for a
Domain Specific Language”. UML’04
Satelite Activities, LNCS 3297, pp.: 187- 187
197, Springer (2005).
142
144