Sei sulla pagina 1di 206

UML

UML:
Lenguaje Unificado de
Modelado http://uml.org

Tema 4

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

zDiagramas de Casos de Uso.


zDiagramas de Estructura.
Estructura
zDiagramas de Comportamiento.
zOCL.
zH
zHerramientas.
i t
zEjemplos.
j p
zBibliografía.
3
Casos de Uso
z Describen
D ib qué éhhace ell sistema
i t d
desde
d ell punto
t
de vista de un observador externo.

z Ponen énfasis en qué hace el sistema, no en


cómo lo hace.

z Un escenario es una instancia particular de un


diagrama de casos de uso.

{Ejemplo de lo que ocurre cuando alguien interactúa


con el sistema

4
Casos de Uso
z Actor
A t = Algo
Al con comportamiento
t i t (persona,
( otro
t
programa, organización...), que interactua con el
sistema.

z Escenario (instancia de caso de uso) =


Secuencia de acciones e interacciones entre los
actores y el sistema.

z Caso de Uso = Colección de escenarios (éxito y


fracaso) que describen actores que usan el
sistema para conseguir un objetivo.

5
Casos de Uso
zP
zPasos:

{ Identificar los límites del sistema.

{ Identificar los actores principales.

{ Para cada uno, identificar sus objetivos.

{ Definir casos de uso que satisfagan sus


objetivos.
6
Ejemplo
Aplicación para una Galería de Arte
Te encargan realizar una aplicación para la compra-venta de cuadros. En cuanto a la compra de cuadros, una vez
que el agente introduce unos datos básicos sobre el cuadro,
cuadro el sistema debe proporcionar el precio recomendado
que el agente de la galería debería pagar. Si el vendedor del cuadro acepta la oferta, entonces el agente de la
galería introduce más detalles (sobre el vendedor del cuadro y la venta).

y el nombre y apellidos
Los datos básicos incluyen p del artista,, el título y fecha de la obra,, sus dimensiones,, la técnica
(óleo, acuarela u otras técnicas), el tema (retrato, naturaleza muerta, paisaje, otro) y la clasificación (obra maestra,
obra representativa, otro tipo). Si es obra maestra, el precio recomendado se calcula comparando el cuadro
introducido con los que hay en el registro de cuadros, tomando el más parecido y aplicando un algoritmo que tiene
en cuenta la coincidencia de tema, la técnica y las dimensiones del cuadro. El sistema debe utilizar información de
subasta de todo el mundo que ahora la galería recibe en un CD de manera mensual. Para una obra representativa,
el precio recomendado se calcula como si fuera una obra maestra y luego se aplica una corrección. Para una obra
de otro tipo, se calcula utilizando el área del cuadro y un coeficiente de moda para el artista. Si no hay coeficiente de
moda para un artista, el agente tiene por norma no comprar el cuadro. El coeficiente de moda varia de mes a mes.

Si el cuadro finalmente se compra, se introducen datos adicionales.

En cuanto a la venta de cuadros por parte de la galería, el sistema simplemente registra la fecha de venta, el nombre
y dirección del comprador
p y el p
precio de venta real.

El sistema también deberá detectar nuevas tendencias en el mercado de arte tan pronto como sea posible. La idea
es detectar secuencias de compras por valores mayores que los esperados por la obra de un artista determinado, de
tal manera que tu cliente pueda comprar cuadros de ese artista antes de que otros detecten la tendencia. Con el
objetivo de detectar cuándo el precio de venta es mayor que el precio esperado cuando tu cliente compró el cuadro,
se debe mantener un registro de todas las compras y todas las ventas.
7

Se quieren generar tres informes: compras y ventas realizadas durante un año, y artistas de moda.…
Ejemplo Comprar
p una
Obra maestra

Comprar una
O
Obra representativa
Vendedor
Comprar una
Obra de Otro Tipo

Vender un
cuadro

Producir Informe Comprador


compras
Agente
Galería Producir Informe
ventas

Producir Informe
tendencias

Actualizar
8
Coeficiente de moda
Ejemplo
Caso de uso: comprar una obra maestra
Actores primarios:
Agente Galería, vendedor
Interesados y Objetivos:
• Agente: quiere obtener una recomendación lo más acertada posible del precio
máximo
á i recomendado
d d d de manera rápida.
á id
• Vendedor: quiere vender el cuadro a un precio razonable de manera rápida.
Precondiciones:
El agente ha entrado en la aplicación.
Garantía de éxito (post-condiciones):
Se registra la venta.
Escenario Principal de Éxito:
1 El agente
1. t iintroduce
t d lla d
descripción
i ió d dell cuadro.
d
2. El sistema busca el cuadro más parecido del mismo autor.
3. El sistema presenta el precio recomendado.
4. El age
agentee hace
ace u
una
ap propuesta
opues a popor debajo de
del pprecio
ec o recomendado,
eco e dado, y e el vendedor
e dedo
acepta la oferta.
5. El agente introduce información de la venta.
Extensiones:
2 N
2a. No hhay ningún
i ú cuadrod parecido id ddell mismo
i autor,
t asíí que ell sistema
i t no presenta
t una
recomendación. 9
4a. El vendedor no acepta la oferta y la venta no se produce.
Ejemplo
Terminal Punto de Venta

TPV
Procesar
Venta
Servicio
cajero de Autorización
Procesar de Pagos
Devoluciones

«actor»
«actor» Analizar
Analizador de Actividad Calculador de
A ti id d de
Actividad d Impuestos
p
Ventas
...
«actor»

Gestionar Sistema de
Seguridad contabilidad

Gestionar
Administrador Usuarios 10
del sistema
Diagramas de Caso de Uso
Relaciones

z Relaciones
R l i entre
t d dos casos d
de uso
{Generalización
z “Es
“E un caso particular
ti l d de …””
z Herencia de clases en POO (overriding)
z También se puede tener esta relación entre dos actores
{Inclusión (include)
z “Implica hacer también …”
{Extensión (extend)
z “Se insertará en …” un determinado punto (llamado “punto de
extensión”) dependiendo de una condición
condición.
z Si un caso de uso depende de varios casos de uso mediante
“extend” tendrá un punto de extensión para cada uno.
11
Ejemplo
Gestión de Pacientes

Cancel Appointment

Scheduler
Make Appointment
<<include>>
<<include>>
Check Patient Record

Patient Request Medication

Doctor
<<extend>> Defer Payment

Pay Bill

Extensions Points Clerk


More Treatment
Bill Insurance 12
Ejemplo
Gestión de Proyectos

13
Casos de Uso

z Son útiles en tres áreas:

{ Especificación de requisitos

{ Comunicación con los clientes


z Su simplicidad los convierte en excelentes medios de
comunicación

{ Generación de casos de prueba


z A partir de los escenarios de un Caso de Uso

14
Indice
z Diagramas de Casos de Uso.
z Diagramas de Estructura.
{Clases y Objetos.
{Componentes.
{Estructuras Compuestas.
{Despliegue.
{Paquetes.
q
z Diagramas de Comportamiento.
z OCL.
z Herramientas.
z Ejemplos.
z Bibliografía. 15
Clases y Objetos
z Los diagramas de Clases y de Objetos son los
principales modos de representar los aspectos
estructurales en UML.

z Diagramas de clases. Estructura del sistema.


{ Clases.
Clases
z Atributos: Tipos, valores iniciales.
z Operaciones: visibilidad.
{ Relaciones con otras clases: Asociaciones

z Diagramas de objetos. Estructura del sistema en


ti
tiempo de
d ejecución.
j ió
{ Objetos. Instancias de una Clase.
z Atributos (valores actuales).
{ Links. Relaciones entre objetos, instancias de asociaciones.
16
Clases y Objetos
Elemento

Diagrama
ag a a de
clases
Carbono Hidrógeno

:Hidrógeno :Hidrógeno

Diagrama de
Di d
objetos :Hidrógeno :Carbono :Carbono :Hidrógeno

17
:Hidrógeno :Hidrógeno
Clases y Objetos
En cursiva si es
Nombre abstracta
de la clase Circulo
-radio: double
-centrox:
t double
d bl At ib t
Atributos
visibilidad -centroy: double

+Area(): double
+Perímetro(): double
Operaciones

Nombre Clase
d l objeto
del bj unCirculo: Circulo del objeto
radio = 3.4
centrox = 2.0
20 Valores de
centroy = 2.0 los atributos 18
Clases
Atributos
z Notación p
para atributos:

[visibilidad] [/] nombre [: tipo] [multiplicidad] [= valor] [{ propiedad }]

z Visibilidad (opcional):
{ Pública: +
{ Privada: -
{ Protegida: #
{ Paquete: ~
z “/” indica que el atributo es derivado.
z La multiplicidad va entre [ ] y por defecto vale 1.
z Propiedades válidas: {readOnly},
{readOnly} {union},
{union} {subsets <property
<property-
name>}, {redefines <property-name>}, {ordered}, {bag}, {seq},
{sequence}, y {composite}.
z Un atributo subrayado es estático.
19
Clases
Ejemplo atributos

ClaseA
name: String
shape: Rectangle
+ size: Integer [0..1]
/ area: Integer {readOnly}
h i ht IInteger
height: t =5
width: Integer
# pos: Point

ClaseB
id: {redefines name}
shape: Square
20
Clases
Métodos
z Notación
N t ió para métodos:
ét d

[[visibilidad]] nombre ( [lista-parametros]


[ p ] ) : [{propiedad}]
[{p p }]

z Visibilidad (opcional).
z nombre del método
z lista de parámetros formales, separados por coma:
direccion nombre : tipo [multiplicidad] = valor [{propiedad}]
z Los métodos estáticos se subrayan.

z Ejemplos:
display ()
-hide ()
+createWindow (location: Coordinates
Coordinates, container: Container [0
[0..1]):
1]): Window
+toString (): String 21
Asociaciones
Composición
z Un Círculo contiene un Punto
z Se representa con una Composición

Círculo Punto

z Relación del tipo todo/parte


{ El todo es el Círculo
{ La parte es el Punto
z Es una relación fuerte
{ Si el Círculo es destruido o copiado, también lo es el Punto
{ La cardinalidad en la parte del todo es 0..1 o 1.
22
Asociaciones
Navegación, Roles, Cardinalidad
z Las asociaciones pueden tener etiquetas:
{ Nombre
{ Roles en la relación
{ Multiplicidad (cardinalidad) navegación

centro
Círculo Punto
1
z Ejemplos
Ej l ded cardinalidad:
di lid d zN
zNavegación:

1..* mínimo 1, no hay máximo Unidireccional
0..*
0.. mínimo 0, no hay máximo Bidireccional
0..1 mínimo 0, máximo 1
No especificado.
1,2,4 uno, dos o cuatro
3 exactamente tres No navegable (x)
23
Asociaciones
Ejemplos de Navegación y Cardinalidad

24
Ejercicio
z Representa mediante un diagrama de clases la siguiente
especificación:
{ Una aplicación necesita almacenar información sobre
empresas, sus empleados y sus clientes.
{ Ambos se caracterizan por su nombre y edad.
{ Los
L empleados
l d tienen
ti un sueldo
ld bruto,
b t los
l empleados
l d que
son directivos tienen una categoría, así como un conjunto de
empleados
p subordinados.
{ De los clientes además se necesita conocer su teléfono de
contacto.
{ La
L aplicación
li ió necesita
it mostrar
t l
los d t
datos d empleados
de l d y
clientes.

25
Ejercicio
Persona
- nombre
- edad
+ mostrar()

Empleado Cliente
subordinados
- sueldo_bruto - telefono_de_contacto
nombre_empresa
0..*
+ mostrar
t ()
+ calcular_salario_neto()
+mostrar()
1..*
empleados 0..* clientes
1..*
Directivo
0..* Empresa
- categoria 1
- nombre
b
+ mostrar () 26
Asociaciones: Agregación

zCuando 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

27
Asociaciones y Dependencia.
Dependencia
z Existen relaciones de conocimiento entre clases que no
implican una relación todo/parte

titular cuentas
Cliente Cuenta
1 *
1.. 0 *
0..

z Dependencia: relación muy débil.


susFiguras Figura
Ventana
0..*
Draw(ContextoDibujo)

suContexto

ContextoDibujo
28
Dependencia
Clases Asociativas

zAsociación con atributos propios.

Nombre asociación

casado con >


Empleado Persona
1 1
testigos 2
Matrimonio
fecha
0..*

Clase Asociativa 29
Clases y Objetos
j
Estilo

z Los atributos no deben ser objetos (utilizar


relaciones en tal caso).

z En los diagramas de clases no suelen aparecer


(son detalles de implementación y no de
diseño):
{Constructores
{Métodos de acceso (“get/set”)
( get/set )
{Métodos de gestión de elementos de una asociación o
agregación (por ejemplo, “add/remove”)
30
Ejemplo

Cliente Orden
nombre 1 0..* fecha
dirección estado

calcImpuesto
calcTotal
1..* 1
Pago calcPesoTotal

monto 1

línea 1..*

Crédito Efectivo Cheque DetalleOrden Item

fecha moneda nombre cantidad 0 *


0.. 1 peso
número identifBanco tipoImpuesto descripción
tipo
autorizado calcSubtotal precioPorCantidad
autorizado calcPeso obtenerPeso

31
Ejercicio
z Especificar un diagrama de clases que describa redes
de ordenadores.
z Los elementos que se pueden incluir en la red son:
{ Servidor,
S id PC, PC Impresora.
I
{ Hub, Cable de red.
z Los PCs pueden conectarse con un único Hub, Hub los
servidores con uno o varios.
z Los Servidores y PCs pueden generar mensajes, con
una cierta longitud.
z 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.
z Las impresoras pueden averiarse, con cierta
probabilidad, durante cierto tiempo. 32
Ejercicio Posible Solución.
Ejercicio. Solución

“Los PCs pueden conectarse con un único Hub, los servidores con uno o varios”
33
Podemos modelarlo como una restricción OCL, o bien añadir asociaciones desde
Servidor y PC
Más sobre asociaciones
Asociaciones n-arias

zAsociaciones entre más de dos clases:

Año
temporada
d

E i
Equipo equipo pichichi
J
Jugador
d

34
Más sobre asociaciones
Adornos en asociaciones y fin de asociación.

zAAsociaciones
i i d
derivadas
i d ((con un “/” d
delante
l t d dell nombre).
b )
z Propiedades, cerca del nombre de la asociación.
z Los finales de la asociación pueden adornarse con:
{ Multiplicidad.
{ Nombre (rol).
( )
{ Propiedades:
z {subsets <nombre-prop>}.
z {redefine <nombre-fin-asoc>}
<nombre-fin-asoc>}.
z {union}.
z {ordered} (un conjunto ordenado).
z {bag} (conjunto con repetición)
repetición).
z {sequence} o {seq} (bag ordenado).

35
Más sobre asociaciones
Adornos en asociaciones y fin de asociación: Ejemplos

a b
A 0..1 *
B
{ordered}

d
C 1 0..1
D
{subsets b}

z Para un objeto de tipo C, la colección d es un subconjunto de la colección b.

36
Más sobre asociaciones
Asociaciones Cualificadas

z Un cualificador declara una partición del conjunto de instancias asociadas con


respecto a la instancia cualificada.
Tablero
Banco Ajedrez
fila: Fila
NumCuenta
col: Colum
* 1
0..1 1
Persona Casilla

z Dado un objeto cualificado, el número de objetos al otro lado de la asociación


viene
i d
dado
d por lla multiplicidad
lti li id d d
declarada.
l d
{ 0..1 : el valor del cualificador es único.
{ 0..* : el conjunto de instancas asociadas se particiona en subconjuntos.
z Similar a un array asociativo,
asociativo map o tabla hash
hash.
37
Pre y Post
Pre- Post- Condiciones,
Condiciones Notas
pre-condición

body-condition

post-condición

38
Interfaces
<<interface>>
Clase MiInterfaz Clase
métodos MiInterfaz

Clase
MiInterfaz

39
Plantillas

Una clase anónima ligada:


FArray<T -> Point> {T -> Point
{K -> 10 40
Ejercicio
Examen Junio 2008.
Realiza el diseño de una aplicación para la gestión de pedidos. La aplicación deberá
manejar clientes (se guarda su nombre, dirección, teléfono y e-mail), que pueden
realizar p
pedidos de p productos,, de los cuales se anota la cantidad en stock. Un
cliente puede tener una o varias cuentas para el pago de los pedidos. Cada
cuenta está asociada a una tarjeta de crédito, y tiene una cierta cantidad
disponible de dinero, que el cliente debe aumentar periódicamente para poder
realizar nuevos pedidos.
Un cliente puede empezar a realizar un pedido sólo si tiene alguna cuenta con dinero
disponible. Al realizar un pedido, un cliente puede agruparlos en pedidos simples
o compuestos. Los pedidos simples están asociados a una sola cuenta de pago y
(por restricciones en la distribución) contienen un máximo de 20 unidades del
mismo o distinto tipo de producto. A su vez, un pedido compuesto contiene dos o
más pedidos, que pueden ser simples o compuestos. Como es de esperar, el
sistema debe garantizar que todos los pedidos simples que componen un pedido
compuesto se paguen con cuentas del mismo cliente.cliente Además,
Además sólo es posible
realizar peticiones de productos en stock.
Existe una clase (de la cual debe haber una única instancia en la aplicación)
responsable
p del cobro, orden de distribución y confirmación de los ppedidos. El
cobro de los pedidos se hace una vez al día, y el proceso consiste en comprobar
todos los pedidos pendientes de cobro, y cobrarlos de la cuenta de pago
correspondiente. Si una cuenta no tiene suficiente dinero, el pedido se rechaza (si
es pparte de un ppedido compuesto,
p , se rechaza el p
pedido entero).
) Una vez qque el
pedido está listo para servirse, se ordena su distribución, y una vez entregado,
pasa a estar confirmado. 41

Se pide un diagrama de clases de diseño.


Solución

42
Solucion (ii)
z Nota: pedidos_simples es una asociación derivada. El atributo total de
Pedido es derivado
derivado.
z Habría que incluir las siguientes restricciones OCL:

Context
C t t realizar_pedido:
li did
pre: self.cuentas->exists(c | c.disponible > 0)

Context Pedido Compuesto:


inv: self.pedidos_simples->cuenta->cliente->asSet()->size() = 1

Context Pedido:
inv: self.t_productos.num->sum() <= 20

Context añadir_pedido(p:
añadir pedido(p: Producto
Producto, num: int):
pre: p.stock>=num

z Se usa el composite y el singleton (para la clase “Controlador


Controlador
Pedidos”, aunque esto no queda reflejado en el diseño a este nivel 43
de
abstracción).
Ejercicio: Biblioteca
z Una biblioteca tiene copias de libros
libros. Estos últimos se
caracterizan por su nombre, tipo (novela, teatro, poesía,
ensayo), editorial, año y autor.
z Los autores se caracterizan por su nombre, nacionalidad
y fecha de nacimiento.
z Cada copia tiene un identificador
identificador, y puede estar en la
biblioteca, prestada, con retraso o en reparación.
z Los lectores pueden tener un máximo de 3 libros en
préstamo.
préstamo
z Cada libro se presta un máximo de 30 días, por cada día
de retraso, se impone
p una “multa” de dos días sin
posibilidad de coger un nuevo libro.
z Realiza un diagrama de clases y añade los métodos
necesarios para realizar el prestamo y devolución de
libros.
Libro
Copia
- titulo : string
- id : Identifier ejemplar libro - tipo: tipoLibro
- estado: estadoCopia 1..* 1 - editorial: string
0..3 prestamos - anyo: int
i t
1..* obras
Prestamo
fechas - inicio: Date
- fin: Date 1 autor

0..1 lector Autor


- nombre:
b string
ti
Lector - nacionalidad: string
- nSocio : Identifier - fechaNacimiento: Date
- nombre: string
- telefono: string <<enumeration>>
- direccion: string tipoLibro

+ devolver(id: Identifier, fechaAct: Date) 1 novela


teatro
{precondition: prestamos.notEmpty()} poesia
i
+ prestar(id: Identifier, fechaAct: Date) ensayo
{precondition: multa==0} multa 0..1
- multar(dias : int) <<enumeration>>
Multa estadoCopia
prestado
- fInicio: Date retraso
- fFin: Date biblioteca
reparacion
Persona
- nombre
- edad
+ mostrar()

Objetos
Empleado Cliente
subordinados
- sueldo_bruto - nombre_empresa
+ mostrar () - telefono_de_contacto
+ calcular_salario_neto()
l l l i t ()
+mostrar()
empleados clientes

Directivo
Empresa
- categoria
- nombre
+ mostrar ()

e2 : Empleado e1 : Empleado
- nombre=“María” - nombre=“Pedro”
- edad
edad=25
25 - edad
edad=23
23
- sueldo_bruto=36000 - sueldo_bruto=30000
subordinados empleados empleados

d1 : Directivo empleados
Empresa
- nombre=“Luis” - nombre=“HGJ”
- edad=35
d d 35
- sueldo_bruto=36000
- categoria=“C1” clientes
c1 : Cliente
- nombre=“Luis”
- edad=35 46
- nombre_empresa=“Macroware”
- telefono_de_contacto=91555666
Componentes
z Componente
C t = “Unidad
“U id d Modular
M d l con interfaces
i t f
bien definidos que es reemplazable en su
entorno .
entorno”

z Énfasis
É f i en reutilización
tili ió y encapsulamiento.
l i t

z Servicios que provee y requiere (interfaces).

z Componentes lógicos (componentes de negocio,


de proceso) y físicos (EJB, CORBA, COM+, .NET,
…) 47
Componentes

Interfaces Interfaces
que ofrece que requiere

48
Componentes
Vi t d
Vista de caja
j bl
blanca

49
Estructuras Compuestas
z Composición
C i ió de
d elementos
l t ( l ifi d
(clasificadores o
colaboraciones)

z Instancias en tiempo de ejecución que colaboran


a través de enlaces para alcanzar objetivos
comunes.

z Colaboraciones: a través de roles.

z Se añade a las clases estructura internas y


puertos.
50
Estructuras Compuestas
Estructura interna de una clase.
clase

Estructura interna de una clase. Multiplicidades.

51
Estructuras Compuestas
Alternativa a relaciones de composición

A li ti
Application

2
Window Button

Application

2
Window Button

52
Estructuras Compuestas

Estructura interna de una clase. Constructor.

53
Estructuras Compuestas
p
Colaboración.
E t t
Estructura iinterna
t d
de una colaboración.
l b ió

54
Estructuras Compuestas
p
Colaboración.
O
Ocurrencia
i de
d una colaboración
l b ió en otra.
t Binding.
Bi di

55
Estructuras Compuestas
p
Colaboración.

Template de colaboración.

56
Despliegue
z Definen
D fi lla arquitectura
it t d
de ejecución
j ió dde un sistema.
i t

z Representa la asignación de artefactos software a nodos


nodos.

z Nodos = elementos hardware, o entornos


de ejecución software.

z Artefactos = elementos concretos (p.e.:


ficheros) que son el resultado del proceso
de desarrollo.

57
Despliegue
p g
Relaciones entre artefactos.

“Manifestación” de
elementos a través de
artefactos
58
Despliegue
p g
Ejemplo.

59
Paquetes
z Un paquete es un contenedor que agrupa elementos
relacionados.

z Los diagramas de paquetes muestran la estructura de alto


nivel de la aplicación.
aplicación

60
Paquetes
q
Ejemplo.

61
Indice
z Diagramas de Casos de Uso
Uso.
z Diagramas de Estructura.
zDiagramas de Comportamiento
Comportamiento.
{ Diagramas de Interacción.
z Diagramas de Comunicación.
z Diagramas de Secuencia.
z Diagramas de visión de conjunto de la interacción.
z Diagramas de tiempo.
{ Diagramas de Estados.
{ Diagramas de Actividad.
z OCL
z Herramientas.
z Ejemplos
Ejemplos.
z Bibliografía. 62
Diagramas de Interacción
z El comportamiento
t i t se representa
t a través
t é de d
colaboraciones:

{ Colección de objetos:

z Instancias

z Roles

{ Especifica cómo los objetos y las asociaciones cooperan

z En un contexto dado

z Con un propósito específico 63


Diagramas de Interacción
z El patrón
tó d
de mensajes
j d t
dentro d
de una
colaboración es una interacción:

{Mensajes: señales, invocaciones, interacciones implícitas


a través de condiciones y eventos temporales.

{Especifica secuencia de mensajes para cumplir el


objetivo de la colaboración

{Para especificar la interacción, es necesario especificar


primero la colaboración

{Semántica basada en trazas.


64
Diagramas de Interacción
z Diagrama de Comunicación

{ Muestra un contexto y una interacción.


interacción

z Diagrama
Di d Secuencia
de S i

{Representación explícita de la secuencia de


comunicaciones, eje temporal.

{Es más apropiado para aplicaciones de Tiempo Real


y escenarios complicados
65
Diagramas de Interacción

z Estructura
E t t d
de llos participantes
ti i t
zDiagramas de Comunicación
z Patrones de comunicación
zDiagramas de Comunicación
zDiagramas de Secuencia
z Temporización
p de la comunicación.
zDiagramas de Secuencia
zDiagramas de Tiempo.
z Estructuración de las interacciones
zDiagrama
g de visión de conjunto
j de la
interacción.
66
Diagramas de Comunicación
z Representa
R t los
l objetos
bj t ( l
(roles o instancias)
i t i )
necesarios para una interacción y sus
relaciones.

z Puede también representar la secuencia de


mensajes

{ Especifica el orden relativo mediante números

z Similar a un diagrama de objetos, muestra el


contexto necesario para una colaboración.
67
Diagramas de Comunicación
participantes
p p

:Window
Wi d / Observer
Ob : SlidingBarIcon
Slidi B I

roles
l
relaciones

/Subject :CallQueue

68
Diagramas de Comunicación

:Window
Wi d / Observer
Ob : SlidingBarIcon
Slidi B I

restricción

{
{Observer.reading=length(Subject.queue)
g g ( j q )
/Subject :CallQueue and
Observer.range = (0..Subject.capacity)}

69
Diagramas de Comunicación

Llamadas anidadas:
realizarPago(cantidad) 1: realizarPago(cantidad)
:Registro :Venta

1.1: crear(cantidad)

:Pago

Iteraciones:
Ejectuar() 1*[i:=1..N]: num:= nextInt()
:Simulador :Random

70
Diagramas
g de Comunicación
Multiobjetos.

z R
Representan
t conjuntos
j t d instancias
de i t i en ell
extremo “muchos” de una relación 1:N o M:N

z Una operación sobre cada instancia requiere


d mensajes:
dos j

{Iteración para obtener referencias a las instancias


individuales

{Mensaje a cada instancia, usando la referencia


temporal
71
Diagramas
g de Comunicación
Multiobjetos.

servers
:Client :Server
:Server
1:aServer:=find(specs)

aServer <<local>>
:Server
2:process

72
Diagramas
g de Comunicación
Condiciones.

e:ClaseE

2 msg6()
2: 6()

msg1() 1a [test]: msg2()


a:ClaseA b:ClaseB

1b
b [not
[ ot test]:
test] msg4()
sg () 1a.1:
a msg3()
sg3()

d:ClaseD c:ClaseC
1b 1 msg5()
1b.1: 5()

73
Ejercicio: Biblioteca
z Una biblioteca tiene copias de libros
libros. Estos últimos se
caracterizan por su nombre, tipo (novela, teatro, poesía,
ensayo), editorial, año y autor.
z Los autores se caracterizan por su nombre, nacionalidad
y fecha de nacimiento.
z Cada copia tiene un identificador
identificador, y puede estar en la
biblioteca, prestada, reservada, con retraso o en
reparación.
z Los lectores pueden tener un máximo de 3 libros en
préstamo.
z Cada libro se ppresta un máximo de 30 días, p por cada día
de retraso, se impone una “multa” de dos días sin
posibilidad de coger un libro.
z Realiza el diagrama de colaboración para el método
devolver()
Solución
1.3 [retraso>0]: multar(retraso)

1: devolver(id,
( , fecha))
prestamos
:Lector 1.1: dev:=remove(id)
:Copia
1.3.1a [multa=0]: multa:=
create(fecha,retraso)

multa:Multa
lt M lt
{new} 1.2: retraso:=getRetraso(fecha)
dev:Copia

multa:Multa
1.3.1b [multa<>0]: anyade(fecha,retraso)
Solución
1.3 [retraso>0]: multar(retraso)

1: devolver(id,
( , fecha))
prestamos
:Lector 1.1: fec:=remove(id)
:Copia
1.3.1a [multa=0]: multa:=
create(fecha,retraso)

multa:Multa
lt M lt fechas
{new} fec:Fecha
1.2: retraso:=getRetraso(fecha)

multa:Multa
1.3.1b [multa<>0]: anyade(fecha,retraso)

76
Diagramas
g de Comunicación
Etiquetas de las flechas.
predecesor
d orden-secuencial
d i l valor-retorno
l t
:= nombre-mensaje lista-argumentos

z Predecesor
{ Lista separada por “,” terminada en “/”
{ El mensaje
j no está
tá habilitado
h bilit d hhasta
t que no ocurran llos
mensajes en la lista
z Orden en la secuencia
{ Lista separada por “.”, terminada en “:”
{ C d té
Cada término
i representa t nivel
i ld de anidamiento
id i t procedural
d l
{ Iteración: *[cláusula interación]
{ Bifurcación: [condición]
77
Diagramas
g de Comunicación
Etiquetas de las flechas.

zEjemplos:
{2: display(x,y)
display(x y)
{1.3.1: p:=find(specs)
{4 [x<0]: invert(x, color)
{A3,B4/ C3.1:update()
{1.1 *[i:=1..n]: lecturer()

78
Diagramas
g de Comunicación
Ejemplo.
redisplay()
:Controller :Window

1:displayPositions(window) 1.1.3.1:add(self)

1.1*[i:=1..n]: drawSegment(i)
contents {new}
wire
<< local >> line
wire:Wire :Line
Li {new}
{ }
<< self >> 1.1.2: create(r0,r1)
i-1 i 1.1.3: display(window)
1 1 1 r0:=
1.1.1a: 0 position()
i i () 1 1 1b r1:=
1.1.1b: 1 position()
i i ()

left:Bead right:Bead
g
79
Diagramas
g de Comunicación
Objetos Activos.

zPoseen
P su propio
i hilo
hil de
d control
t l

zUn objeto pasivo sólo almacena datos

{ Puede enviar mensajes mientras procesa un


pedido (mensaje) que haya recibido

zLos
L objetos
bj t activos
ti se representan
t
frecuentemente con componentes internas
80
Diagramas
g de Comunicación
Objetos Activos. Ejemplo.

:FactoryManager
:FactoryScheduler
job
1:start(job)
A2,B2/2:completed(job)
currentJob:TransferJob
<<local>> job :FactoryJobMgr

B2:completed A2:completed
1/B1:start(job) 1/A1:start(job)

:Robot :Oven

81
Diagramas
g de Comunicación
Objetos Activos. Ejemplo.

Tipos de Flujos de Control


Llamada a procedimiento u otra forma de llamada con
anidamiento de control. La secuencia anidada termina
antes de que siga la operación que invocó
invocó. Puede
usarse para procesos concurrentes cuando el mensaje
es síncrono.
Comunicación asincróna, sin anidamiento de control.
El objeto que envía no se detiene a esperar respuesta.

Retorno de una llamada a procedimiento. Esta flecha


puede omitirse si queda claro por el fin de la
activación.
82
Diagramas de Secuencia
z R
Representat conjunto
j t ded mensajesj entre
t roles
l
(o instancias) en una interacción

z Dos dimensiones:
{Tiempo (generalmente vertical); puede ser una escala si
el sistema es de tiempo real

{Diferentes
{Dif t instancias
i t i ((generalmente
l t h
horizontal);
i t l) ell
orden relativo no tiene importancia

z Se muestra la existencia y duración de las


instancias, pero no sus relaciones
83
Diagramas de Secuencia
z Traza: secuencia de ocurrencias de eventos <e1 e2 ...en>

z La semántica de una interacción es un par de conjuntos


de trazas (válidas e inválidas) [P, I].

zP
Pueden
d existir
i ti trazas
t no incluidas
i l id en los
l d
dos conjuntos
j t
anteriores.

z Equivalencia de interacciones, si sus conjuntos de trazas


son iguales.

z Una interacción se puede especializar: se añaden más


j
trazas al conjunto.
84
Diagramas de Secuencia

:caller :exchange :receiver

a: lift receiver
b: dial tone
Objetos c: dial
di l digit
di it
...
Focos de d: route
Control
ringing tone phone rings
Mensajes answer phone

stop tone stop ringing


85
Diagramas de Secuencia
sd Authenticate User

ac: ds:
LoginPage: CurrentUser:
Authentication UserData
Servlet UserData
C
Controller
ll S i
Service
validateCredentials(“Dan”, “b4_23”)
restoreUserData(“Dan”)
create(“Dan”,”Administrator”)
currentUser
currentUser

86
Diagramas de Secuencia

operador guarda marco


preferente usual
:Pedido
:Distribuidor
Di t ib id :Distribuidor
Di t ib id
entregar()

loop [for each producto]


procedure entregar()
alt [value > 10000] foreach producto:
if p
producto.value>10000
entregar() preferente.entregar()
else
usual.entregar()
[else] end if
entregar() end for
end procedure
Diagramas de Secuencia

Gate (formal),
con nombre
out Unlock
out_Unlock
88
Diagramas de Secuencia

Referencias (Ocurrencias de Interacciones)

z Copian el contenido de
la interacción referida.

z Substitución de
parámetros y conexión
de las puertas (gates)
formales y actuales.
actuales
89
Diagramas
g de Secuencia
Operadores sobre interacciones.
z Fragmentos combinados,
combinados operadores (i):

{ Alternativa (alt).
z Elección (mediante una guarda) de una interacción.
interacción

{ Aserción (assert).
z La
a secue
secuencia
c a espec
especificada
cada po
por e
el ope
operador
ado es la
aúúnica
ca válida.
á da

{ Opción (opt).
z Equivalente a un operador alt con un solo fragmento.

{ Ruptura (break).
z El operando se ejecuta en lugar del resto de la interacción englobada en el
fragmento “padre”.
padre .

{ Paralelo (par).
z Mezcla de las trazas de los operandos (cualquier entrelazado es válido
mientras preserve el orden de los eventos de cada operando).
operando)
90
Diagramas
g de Secuencia
Operadores sobre interacciones.
{ Secuenciación débil (seq).
(seq)
z Define un conjunto de trazas que cumple:
z 1. Se mantiene el orden de eventos de los operandos
z 2.
2 Eventos de otras líneas de vida de otros operandos pueden venir
en cualquier orden.
z 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).


z Secuenciación estricta en el orden de los eventos de los operandos.

{ Negativa (neg).
z Define trazas inválidas.

{ Región crítica (critical).


z Los eventos del operando no pueden mezclarse con ningún otro.
91
Diagramas
g de Secuencia
Operadores sobre interacciones. Alternativa.

92
Diagramas
g de Secuencia
Operadores sobre interacciones. Alternativa.

93
Diagramas
g de Secuencia
Operadores sobre interacciones. Opción.

94
Diagramas
g de Secuencia
Operadores sobre interacciones. Bucle.

95
Diagramas
g de Secuencia
Operadores sobre interacciones. Región Crítica.

96
Diagramas de Secuencia
Ejemplo
Sd Alarm Activation

:SystemHandler :CellHandler :Sensor :Alarm :CellConfigurationInformation


T = now

assert
Activate()
ReadConfiguration()
Configuration Information Returned

seq SelfTest()
ACK

Activate()

SelfTest()
par opt Test()

opt Validate
{t..t+5}

ACK 97
ACK
Diagramas
g de Secuencia
Retorno de Valores

98
Diagramas
g de Secuencia
Tiempo
z Restricciones temporales (duración)

z Duración de mensajes y señales (duration)


z Intervalos de tiempo ({t..t+3}) y restricciones temporales.
z Observaciones temporales (tiempo actual, now)
99
Diagramas
g de Secuencia
Descomposición en partes

La estructura interna de
ACS
ACSystem tiene
i una
interacción
“AC_UserAccess” que se
invoca en este fragmento.

100
Diagramas
g de Secuencia
Descomposición en partes

101
Diagramas
g de Secuencia Coregión: s[u]
co-región recibe los mensajes
en cualquier orden.

102
Diagramas
g de Secuencia
Invariantes
z Invariantes.
Invariantes

En este momento la traza


<v w q> no es válida

z Se comprueban justo antes de la ocurrencia del próximo


evento
t (puede
( d haber
h b mensajes
j no mostrados
t d en ell
diagrama). 103
Diagramas
g de Secuencia
Binding

104
Ejercicio
Especificar
f el diagrama de secuencia de la operación
“crearLaberinto”

public class JuegoLaberinto {


public Laberinto crearLaberinto () {
Laberinto lab = new Laberinto();
Habitacion h1 = new Habitacion();
Habitacion h2 = new Habitacion();
Puerta puerta = new Puerta(h1, h2);
lab.añadeHabitacion(h1);
lab.añadeHabitacion(h2);
h1.añadePuerta(puerta);
return lab;
}
}
Solución

:JuegoLaberinto
crearLaberinto()
l bL b i t
lab:Laberinto

h1:Habitacion

h2:Habitacion
create(h1,h2)
puerta:Puerta
añadeHabitacion(h1)

añadeHabitacion(h2)

añadePuerta(puerta)
Ejercicio
Especificar el diagrama de secuencia de la operación
“crearLaberinto”
public class JuegoLaberinto {
private Laberinto lab;
private boolean conVentana;

public JuegoLaberinto() {
lab = new Laberinto();
conVentana = true;
}

public void crearLaberinto () {


Habitacion h;
for (int i=0; i<10; i++) {
h = new Habitacion();
if (conVentana == true)
h.añadeVentana(new Ventana());
lab.añadeHabitacion(h);
}
}
Solución

:JuegoLaberinto lab:Laberinto
crearLaberinto()

loop [for i = 1 to 10]


h:Habitacion

opt [conVentana==true]

v:Ventana
añadeVentana(v)

añadeHabitacion(h)
Ejercicio

Especificar el diagrama de secuencia de la operación


“realizarJugada” definida en la clase Jugador, para el juego del
parchís
* 2
Jugador Dado
- casillaActual:
ill A t l iintt
+ realizarJugada(): void + tirar(): int
+ casillaActual(): int
*
1
Tablero

+ mover(int actual,
int unidades):
boolean
Solución

:Jugador d1:Dado d2:Dado :Tablero


realizarJugada()

par tirar()

n1

tirar()

n2

ca:=casillaActual()

mover(ca,n1+n2)

movRealizado
Ejercicio
Identificar las clases relevantes y realizar el diagrama de
secuencia para el siguiente caso de uso, que corresponde a
la realización de una llamada desde un teléfono móvil.

z El usuario pulsa los dígitos del número de teléfono


z Para cada dígito
g
{ la pantalla se actualiza para añadir el dígito marcado
{ se emite un tono por el receptor
z El usuario pulsa el botón “Enviar”
Enviar
z El indicador “en uso” se ilumina en pantalla
z El móvil establece conexión con la red
z L dí
Los dígitos
it acumulados
l d se mandan d a lla red
d
z Se establece la conexión con el número marcado
Solución

:Button :Dialer :Display :Speaker send:Button :CellularRadio

loop [for i = 1 to 9]
digit(code)
displayDigit
(code) emitTone
(code)

send()

connect(pno)

inUse()

¿Diagrama de colaboración
equivalente?
Solución
Visión de Conjunto de la Interacción

z D
Define
fi las
l interacciones
i t i a ttravés
é dde una
variante de los diagramas de actividad.

z Visión general del flujo de control.

z Usa elementos de los diagramas de actividad


para especificar:

{ Alternativas entre interacciones.


{ Paralelismo de interacciones.
{ Bucles de interacciones.
114
Visión de Conjunto de la Interacción

115
Tiempo

zMuestran
M t i t
interacciones
i d d
donde es
importante razonar sobre el tiempo.

zRepresenta condiciones que cambian en


una o varias líneas de vida, en un eje
lineal de tiempo.
tiempo

zCambios en el estado de un objeto con el


tiempo en respuesta a eventos.
116
Tiempo

Diagrama temporal
correspondiente
p
a la interacción

117
Tiempo

118
Tiempo

119
Máquinas de Estados
z “Statecharts”
“St t h t ” [Harel]
[H l]

z Representan el comportamiento de entidades ( p


p.e.
e
instancias de clases).

z Especifican reacción ante eventos

z Describen posibles secuencias de estados y acciones


por las que pueden pasar las entidades.

z De comportamiento vs. de protocolo.

120
Máquinas de Estados

Comienzo Estados Fin

digit(n)
start Partial Dial

digit(n)

Transiciones

121
Máquinas de Estados
z Un
U ttransición
i ió puede
d ttener:
{ Evento.
z 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).
)
122
Máquinas de Estados
z Un estado tiene:
{ Nombre

{ Transiciones internas: lista de acciones ejecutadas en ese


estado (entry/exit/do)
( y )

z Ejemplo:
j p

Typing Password Nombre


entry/set
t / t echo
h invisible
i i ibl
exit/set echo normal Transiciones
character/handle character
help/display help
internas
123
Máquinas de Estados
Start Partial Dial
digit(n)
entry/start dial tone entry/number.append(n)
exit/stop dial tone

Estado compuesto: digit(n)

Dialing

Start Partial Dial [number.isValid()]


digit(n)
entry/start
y dial tone entry/number.append(n)
y pp ( )
exit/stop dial tone

124
digit(n)
Ejercicio: Biblioteca
z Una biblioteca tiene copias de libros
libros. Estos últimos se
caracterizan por su nombre, tipo (novela, teatro, poesía,
ensayo), editorial, año y autor.
z Los autores se caracterizan por su nombre, nacionalidad
y fecha de nacimiento.
z Cada copia tiene un identificador
identificador, y puede estar en la
biblioteca, prestada, reservada, con retraso o en
reparación.
z Los lectores pueden tener un máximo de 3 libros en
préstamo.
z Cada libro se ppresta un máximo de 30 días, p por cada día
de retraso, se impone una “multa” de dos días sin
posibilidad de coger un libro.
z Realiza el diagrama de estados de la clase “copia”
copia .
Solucion

Con devolver()
Con reservar(id) /
Retraso y
en Retraso usrRes = id
reser ado
reservado
reparacion
reparado() devolver() [getDate()>fp+30] [getDate()>fp+30]
reparar()

en prestar(id,fecha)/ reservar(id) /
prestado reservado
biblioteca fp=fecha usrRes = id
devolver()
prestar(id, fecha) devolver()
[usrRes==id]/
fp=fecha
t (2 days)
tm(2 d ) en
reserva
Solucion: Estados Jerárquicos

Con
Con reservar(id) / Retraso y
en Retraso usrRes = id reser ado
reservado
reparacion
reparado() [getDate()>fp+30] [getDate()>fp+30]
reparar()

en prestar(id,fecha)/ reservar(id) /
prestado reservado
biblioteca fp=fecha usrRes = id

devolver() prestar(id, fecha) devolver()


[usrRes==id]/
t (2 days)
tm(2 d ) fp=fecha en
reserva

127
Máquinas
q de Estados
Componentes Ortogonales

Incomplete
lab done
Lab1 Lab2

Term project done Passed


Project

Final pass
Test

fail
128
Failed
Máquinas
q de Estados
Componentes Ortogonales: Utilidad

z Modelo de un sistema formado por un proceso


en red sin componentes ortogonales.

ack

transmit
Idle Message Sending
arr.

time out arr


arr

129
Máquinas
q de Estados
Componentes Ortogonales: Utilidad
ack1

Idle
d 1 Mess
ss1 trans1 Send
d1
Idle2 arr1 Idle2 Idle2
arr1
arr2 arr2 tout1 arr2
arr1
arr2 arr2
arr1
Idle1 Mess1 trans1 Send1
Mess2 arr1 Mess2 Mess2
tout1 arr1
ack1 trans2
trans2 tout2
ack2 tout2
ack2 arr1
Idle1 Mess1 z Dos
Send2 Send2
arr1
arr2 procesos 130
Máquinas
q de Estados
Componentes Ortogonales: Utilidad
ack P 1
Proc-1

transmit
Idle Message Sending
arr.
arr
time out arr

P 2
Proc-2
ack

transmit
Idle Message Sending
arr.
arr
time out arr 131
Máquinas
q de Estados
Componentes Ortogonales: Utilidad
P 1
Proc-1
ack/ channel = free
arr
transmit
Wait [channel
Idle Message Sending
arr channel ==free ] /
channel = busy
arr
time out / channel = free

P 2
Proc-2
ack/ channel = free
arr
transmit
Wait [channel
Idle Message Sending
arr channel ==free ] /
channel = busy
arr
time out / channel = free 132
Máquinas de Estados
Pseudo
P d - estados:
t d
z Fork / Join.
z Initial.
z Deep History / Shallow History. H* H
z Junction.
z Choice.
z Entry / Exit point.
z Terminate.

A1 A2
Setup Cleanup
B1 B2

133

Fork Join
Máquinas
q de Estados
Estado Histórico

B
H

t4

B1 B2
I
t1: ev0 B12
t2
B21 t3
B11
t3: ev1

t4: ev2

134
Máquinas
q de Estados
Estado Histórico (ii)

B
H
H*

t4

B1 B2
I
t1: ev0 B12
t2
B21 t3
B11
t3: ev1

t4: ev2

135
Máquinas
q de Estados
Estado Histórico. Ejercicio.

zModelar el comportamiento de una


cadena de música. Esta ppuede 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.

136
Máquinas
q de Estados
Estado Histórico. Ejercicio. Solución

On

Standby power mode mode


CD

power H

Radio Tape
mode

M d l ell mismo
Modelar i sistema
i t sin
i usar estado
t d histórico.
hi tó i

137
Máquinas
q de Estados
Estado Histórico. Ejercicio. Solución (ii)

Standby On
power
lastCD CD mode
power
mode
power
lastRadio
power
Radio Tape
mode
lastTape power

power

138
Máquinas de Estados
Pseudo - estados: Junction.

Pseudo - estados: Choice.

139
Máquinas de Estados
Puntos de Entrada/Salida, Estados Sub-Máquina

140
Ejemplo. Reproductor CDs.
ReproductorCD
p
I
InterfazUsuario
f U i Li C i
ListaCanciones
- Tpausa: Tiempo 1 disco
... ...
- NumActual: Entero 1
... + obtenerCancion(Orden: Entero):
+ stop()
t () Cancion
+ pause() + numCanciones(): Entero
+ play() 1 ....
+ eject()
j ()
+ apagar()
+ finCancion()
- buscaDisco(d: InfoDisco): pista 0..*
1
ListaCanciones Cancion
player 1 actual
- titulo: Cadena
driver 1 - duracion: Tiempo
p
ControladorCD - Artista: Cadena
- Orden: Entero
...
...
+ play(act:
l ( t Cancion,
C i desde: d d Tiempo)
Ti )
+ stop() : Tiempo
+ detectarDisco() : InfoDisco
+ detectarAbierto()
() : Logico
g
+ abrir()
+ cerrar() 141

+ apagar()
Diagrama de estados para la clase
ReproductorCD
p
[(info=driver.detectarDisco())!=NULL]/
[not driver. disco=buscaDisco(info)
detectarAbierto()] NumActual = 1; [else]/ driver.stop();
actual = disco.obtenerCancion(ordenActual)
( ) NumActual=1;;
actual= disco.obtenerCancion(NumActual)
[drriver.detectarrAbierto()]

Cerrado
endOfSong()/
NumActual+=1
driver.cerrarr ()

Play()/
driver.abrir (()

Stop driver.play(actual, 0) Play


eject ()/
()/

[NumActual<=

pausa)
eject

disco.numCanciones()]/

p()
Tpausa = driver.stop
driver.pllay(actual, Tp
d
e

actual=
t l
eject ()/
Abierto disco.obtenerCancion
driver.stop(); stop()/
(NumActual)
driver.abrir() driver.stop();
driver.play(actual,0)
NumActual=11
NumActual

Pause())/
actual=

Play()/
disco.obtenerCancion(NumActual)

Pause

apagar ()/
driver.stop();
142
driver.apagar()
Máquinas de Estados de Protocolo
z Asociadas a un clasificador,, interface o p
puerto.

z Especifican qué operaciones del clasificador se pueden


llamar en qué condiciones.
condiciones

z Las operaciones que no generan transición no se


representan.

z Má
Máquinas
i d estado
de t d declarativas:
d l ti E
Especifican
ifi l
las
transiciones legales (no su condición) para cada
operación. “Contrato” para el usuario del clasificador.

z Máquinas de estado Ejecutables: Especifican todos


los eventos que un clasificador puede recibir y tratar,
tratar
con las transiciones implicadas. 143
Máquinas de Estados de Protocolo
z Máquinas de estados de
protocolo. Ejemplo (declarativa).

z Los estados de máquinas de


protocolo no tienen asociadas Cleanup
acciones exit/entry/do,
exit/entry/do pero [inv]
pueden tener invariantes.

z Las transiciones no tienen


acciones, pero sí pueden tener [pre-cond] Evt/ [post-cond]
pre- y post- condiciones.

144
Máquinas
q de Estados
Generalización
z Una máquina de estados es generalizable
generalizable.

z Se pueden añadir regiones, estados y transiciones.

z Se puede cambiar el destino y estado de una transición siempre


que la fuente y evento se mantenga.

z En caso de herencia múltiple de máquinas de estado (por herencia


de los clasificadores asociados), se crea una región ortogonal por
cada máquina heredada
heredada, mas una por la máquina de estados del
clasificador específico.

z Se anota con <<extended>> junto al nombre de la máquina


máquina.

z Los estados heredados se muestran con líneas punteadas o en gris.

145
Máquinas
q de Estados
Generalización: Ejemplo, cajero autómatico.

146
Máquinas
q de Estados
Generalización: Ejemplo, cajero autómatico.
Extensión:
E ió posibilidad
ibilid d de
d
teclear el importe a
retirar, y de que este se
pueda rechazar.

147
Ejercicio
z M
Modelar
d l ell comportamiento
t i t reactivo ti de
d un reloj
l j de
d pulsera.
l
z El valor del tiempo se debe actualizar cada segundo, incluso cuando no se
muestra (p.ej. crono encendido).
z El botón de la parte superior derecha enciende la luz, luz que se mantiene
encendida tanto como el botón está apretado, una vez que se suelta, la luz
está encendida durante 2 segundos más y se apaga.
z El botón superior izquierdo alterna entre el modo de crono y de reloj. El
sistema empieza en el modo reloj,
reloj en el que se muestra la hora en formato
HH:MM:SS.
z En el modo crono, el tiempo discurrido se muestra en formato MM:SS:CC
((CC son centésimas de segundo). g ) Inicialmente el crono empieza
p en
00:00:00. El botón inferior derecho se usa para activar el crono. Éste
É se
actualiza en incrementos de 1/100 segundos. Presionando el botón inferior
derecho pausa o continua el crono (si el reloj está en modo crono).
Pulsando el botón inferior izquierdo
q resetea el crono a 00:00:00 si el relojj
está en modo crono y el crono ha sido pausado antes. El crono continua
corriendo (si está corriendo) o mantiene su valor (si está en pausa) incluso
cuando el reloj está en un modo de display distinto (por ejemplo, cuando se
muestra la hora).
148
Ejercicio
z 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() : ver refreshTimeDisplay().
{ 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
z Eventos de botones recibidos:
{ topRightPressed.
{ topRightReleased.
p g
{ topLeftPressed.
{ topLeftReleased.
{ bottomRightPressed.
{ bottomRightReleased
bottomRightReleased.
{ bottomLeftPressed. 149
{ bottomRightReleased.
Posible Solución.
Solución

150
Máquinas de Estados
Ejemplo. Herramienta de Dibujo (i)

/setup widgets
setup
t bibindings
di

Active

wmQuit
exitButton

151
Máquinas
q de Estados
Ejemplo. Herramienta de Dibujo (ii)

Shapes Canvas

Modes

152
Máquinas
q de Estados
Ejemplo. Herramienta de Dibujo (iii)

Shapes

shapeSelected(Triangle)

shapeSelected(Rectangle) shapeSelected(Circle)
Triangle

shapeSelected(Triangle)
p ( g )

shapeSelected(Circle)
h S l t d(Ci l )
Rectangle Circle
shapeSelected(Rectangle)

153
Máquinas
q de Estados
Ejemplo. Herramienta de Dibujo (iv)

Modes

modeSelect(Insert)/
Canvas.Insert
modeSelect(Delete)/
Canvas.Delete
Insert
modeSelect(Move)/
Canvas.Move
modeSelect(Insert)/
Canvas.Insert

modeSelect(Delete)/
( )/
Canvas.Delete
Move Delete
modeSelect(Move)/
C
Canvas.Move
M
154
Máquinas de Estados
Ejemplo Herramienta de Dibujo (v)
Ejemplo.
Canvas

[Shapes in Circle]/
Inserting
g
d
drawCircle(x,y)
Ci l ( )
[Shapes in Rectangle]/
Idle drawRectangle(x,y)
[Shapes in Triangle]/
onDrawingMouse1Press(x,y) drawTriangle(x,y)
C
delete insert
move insert

Deleting
Moving
Idle
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)
Idle Moving
move
onDrawingMouse1Motion(x,y)/
oldCoords=coords(movingObject)
delete 155
move(movingObject, distance(oldCoords, (x,y)))
Diagramas de Actividad
z 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.

z Flujos dirigidos por procesamiento interno (en los


diagramas de estados normales son dirigidos por eventos
externos).

z Semántica basada en Redes de Petri. No obstante no se


da una transformación a Redes de Petri. 156
Diagramas
g de Actividad
Ejemplo
Put Coffee Put Filter
in Filter in Machine
Turn on
Machine
[found
coffee] Add Water / coffeePot.turnOn
to Reservoir
Find Brew
Beverage
g coffee

[no coffee] Get light goes out


Cups
Pour
Coffee
[found cola] Get cans
of cola

Drink

[no cola]

157
Diagramas de Actividad
Swimlanes

158
Diagramas de Actividad
Pesos en los enlaces

159
Diagramas de Actividad
Parámetros y Eventos Temporales
Parámetros/Pins/Excepciones

E
Eventos
t Temporales
T l

160
Diagramas de Actividad
Excepciones/Pins

161
Diagramas de Actividad
Regiones de
Expansión
z Regiones de expansión,
procesamiento paralelo
(también iterative y
streaming).
t i )

162
Diagramas de Actividad
Regiones Interrumpibles

163
Diagramas de Actividad
Particiones

164
Diagramas de Actividad
Flujos de Objetos: Objectflows

165
Indice

zDiagramas de Casos de Uso.


zDiagramas de Estructura.
Estructura
zDiagramas de Comportamiento.
zOCL.
zHerramientas.
zEjemplos.
zEjemplos
zBibliografía.
166
OCL: Object Constraint Language
z Lenguaje de restricciones para expresar condiciones
adicionales que no podemos expresar con diagramas y
cardinalidades.

z Combinar diagramas y especificaciones textuales.

z Lenguaje preciso, no ambiguo, declarativo, tipado, basado


en matemáticas (lógica de predicados y teoría de
conjuntos).
conjuntos)

z Útil p
para obtener modelos p
precisos ((no anotaciones en
lenguaje natural).

z Se utiliza fundamentalmente junto a los diagramas de


clases. 167
Ejemplos
Flight Airplane
0 *
0.. 1
Flightnr: Integer numberOfSeats: Integer
flights plane
availableSeats(): Integer
flights 0..
0 *

También es un lenguaje de consultas (mismo


passengers 0..*
poder expresivo que SQL).
P
Person Context Flight::availableSeats(): Integer
name: String body: plane.numberOfSeats – passengers->size()

z ¿Cómo se expresa el hecho de que en ningún vuelo puede haber


más p
pasajeros
j que asientos tiene el avión?
q

z Restricción OCL:
Context Flight
168
Inv: passengers->size() <= plane.numberOfSeats
Ejemplos
Casa Persona
0 *
0.. 1 numSegSoc:
S S Id
Identificador
ifi d
valor: Dinero
casas propietario sueldo: Dinero

aval 1 contratarHipoteca(sum: Dinero,


aval: Casa))
Hipoteca 1 contratante
principal: Dinero
0..* mensual: Dinero 0..*
hipotecas fechaInicio: Fecha hipotecas
fechaFinal: Fecha

Reglas adicionales:

1. Una persona puede tener una hipoteca sobre una casa sólo si es el
propietario.
2.
2 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. 169
Ejemplos Las restricciones OCL se escriben
en el contexto de una instancia de
un tipo específico.
Context
C t t Hipoteca
Hi t
Inv: aval.propietario = contratante

Context Hipoteca
Inv: fechaInicio < fechaFin self hace referencia a la instancia
del contexto.
Context Persona
Inv: Persona::allInstances()->isUnique(numSegSoc)

Context Persona::contratarHipoteca(sum: Dinero, aval: Casa)


pre: self.hipotecas.mensual->sum()+sum <= self.sueldo * 0.70

Context Persona::contratarHipoteca(sum: Dinero, aval: Casa)


pre: aval.valor >= aval.hipotecas.principal->sum()

170
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 171
Ejercicio
“Un Hub no puede conectarse consigo mismo a través de
un puerto”

Context Cable_Hubs
Inv: Puerto_Hub.hub->asSet()->size() = 2

172
¿Dónde usar OCL?
z Clases:
{ Invariantes. Expresión OCL de tipo booleano, la expresión debe
ser true para cada instancia de la clase en todo momento de la
ejecución.
ejecución
z Operaciones:
{ Pre-condición. Condición que debe ser verdadera para ejecutar
l operación
la ió en una d
determinada
t i d iinstancia.
t i
{ Post-condición. Condición que debe ser verdadera al terminar
una operación.
{ Body.
B d Especificación
E ifi ió del
d l cuerpo d
de una operación
ió dde ti
tipo query.
z Atributos y finales de asociación:
{ Valor inicial. expresión
p p
para dar el valor inicial a un atributo o
final de asociación. Se evalua al crear la instancia.
{ Valor derivado.
z Transiciones de máquinas de estados:
{ Guarda.
Ejemplos

parents
0..*

children 0..*

174
Ejemplos
z Especificación
E ifi ió ddell valor
l iinicial
i i lyd
derivado
i d d de atributos/association
t ib t / i ti ends:
d
context Person::income : Integer
init: parents.income->sum() * 1% -- pocket allowance
d i d if self.age
derived:if lf < 18
then parents.income->sum() * 1% -- pocket allowance
else job.salary -- income from regular job
endif

z Subexpresiones (let):
context Person inv:
let income : Integer = self.job.salary->sum() in
if isUnemployed then
income < 100
else
income >= 100
endif
175
Ejemplos Colecciones.
Ejemplos. Colecciones

zTipos: Set, OrderedSet, Bag, Sequence.

zOperaciones 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 Company
C i
inv:
self.employee->select(age < 25)->notEmpty()

context Company inv:


self.employee->select(gender=female)->notEmpty() 176
Ejemplos Colecciones.
Ejemplos. Colecciones
collect(expr): devuelve la colección que resulta de evaluar expr
para cada elemento de la colección fuente.

self employee >collect( birthDate ))->asSet()


self.employee->collect( >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 )
i
inv: self.employee->forAll(
lf l >f All( p : PPerson | p.isUnemployed
i U l d=FFalse
l )
177
Ejemplos Colecciones.
Ejemplos. 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> | expresion-logica-
con-elem-y-acc
l )
collection->collect(x : T | x.property)
( : T;; acc : T2 = Bag{}
collection->iterate(x g{} | acc->including(x.property))
g( p p y))
añade un elemento a una colección 178
Colecciones Otras Operaciones
Colecciones. Operaciones.
z Otras operaciones
p de bucle:
{ source->any(iterator|body)
z source->select(iterator|body)->asSequence()->first()
{ source
source->collectNested(iterators|body)
collectNested(iterators|body)
z Bag de elementos que resultan de aplicar body a cada elemento de
source.
{ source->isUnique(iterators|body)
( | y)
z True si body se evalua a un valor diferente para cada elemento de
source.
{ source->one(expr)
z Devuelve true si existe exactamente un elemento de source que cumple
la condición.
{ source->reject(expr)
z Devuelve una colección con los elementos de source que no cumplen la
condición.
{ source->sortedBy(expr)
z Ordena source,
source resulta en un OrderedSet
179
Indice

zDiagramas de Casos de Uso.


zDiagramas de Estructura.
Estructura
zDiagramas de Comportamiento.
zOCL.
zHerramientas.
zHerramientas
zEjemplos.
j p
zBibliografía.
180
Herramientas I
Herramientas,
z Dibujo
Dib j dde di
diagramas
{Soporte a la correccción de los diagramas en base a su
semántica
{Apoyo para simplificar la facilidad de comprensión de
los diagramas (layout, etc.)
z Archivo de información
{Comprobación de inconsistencias
{Detección de trabajo a realizar y mejoras
{Generación de informes
{Soporte a la reutilización
{Soporte al rediseño (refactorings).

181
Herramientas II
Herramientas,

z Soporte a la navegación
{Vistas compuestas
{Elaboración de conexiones entre información
relacionada
{Bú
{Búsquedad
{Visión con diferentes niveles de granularidad
(expansión y contracción de partes de la vista)
{Filtros
{Operaciones sobre componentes de la vista

182
Herramientas III
Herramientas,
z Soporte al trabajo multiusuario
{ Bloqueo de información
{ Trabajo
j colaborativo
z Generación de código
{ Esqueletos con información estática (clases)
{ Generación a partir de diagramas de comportamiento
(máquinas de estados).
{ Integración con lenguajes especiales (SQL, …)
{ Desarrollo Dirigido por Modelos (MDA
(MDA,
http://www.omg.org/mda/)
z Ingeniería inversa
{ Construcción de un modelo de diseño a partir de código
{ Diseño iterativo: incorporación al modelo de detalles
implementados
183
Herramientas IV
Herramientas,

z 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 requisitos
{Herramientas de gestión de proyectos y soporte al
proceso de
d di
diseño
ñ yd desarrollo
ll

184
Herramientas V
Herramientas,

zDistintos niveles de abstracción


zIntercambio de información
{Especificación OMG de representación de
modelos UML en XMI (XML Metadata
Interchange)

185
Poseidon for UML
Indice

zDiagramas de Casos de Uso.


zDiagramas de Estructura.
Estructura
zDiagramas de Comportamiento.
zOCL.
zHerramientas.
zHerramientas
zEjemplos.
Ejemplos.
zBibliografía.
187
Ejemplo de Análisis
Aplicación para una Galería de Arte

Diagrama de casos de uso inicial

Comprar un
cuadro
Vendedor
Vender un
cuadro
Agente
Galería
Producir Informe
C
Comprador
d
Actualizar
Coeficiente de
moda
188
Diagrama Comprar
p una
Obra maestra
refinado
Comprar una
O
Obra representativa
Vendedor
Comprar una
Obra representativa

Vender un
cuadro

Producir Informe Comprador


compras
Agente
Galería Producir Informe
ventas

Producir Informe
tendencias

Actualizar
189
Coeficiente de moda
Caso de uso: comprar una obra maestra

Actores primarios:
p
Agente Galería, vendedor
Interesados y Objetivos:
• Agente: quiere obtener una recomendación lo más acertada posible del
precio máximo recomendado de manera rápida.
• Vendedor: quiere vender el cuadro a un precio razonable de manera rápida.
Precondiciones:
El agente ha entrado en la aplicación.
Garantía de éxito (post-condiciones):
Se registra la venta.
E
Escenarioi Principal
P i i l ded Éxito:
É it
1. El agente introduce la descripción del cuadro.
2. El sistema busca el cuadro más parecido del mismo autor.
3 El sistema presenta el precio recomendado
3. recomendado.
4. El agente hace una propuesta por debajo del precio recomendado, y el
vendedor acepta la oferta.
5 El agente introduce información de la venta
5. venta.
Extensiones:
2a. No hay ningún cuadro parecido del mismo autor, así que el sistema
no presenta una recomendación
recomendación.
4a. El vendedor no acepta la oferta y la venta no se produce. 190
Diagrama de clases inicial Cuadro
nombreDelArtista
apellidosDelArtista
Sistema
Si t G
Gestion
ti Titulo
Galeria AñoCreacion
Alto
Ancho
Tecnica
Tema

Cuadro Galeria Cuadro Subastado


Clasificacion fechaSubasta
fechaCompra precioSubasta
Fechaventa
nombreVendedor
direccionVendedor
precioCompraMaximo
precioCompraReal
precioVentaDeseado
precioVenta
nombreComprador
direccionComprador

Obra Maestra Cuadro de Otro Tipo Moda


usa nombreArtista
appelidosArtista
coeficiente 191
Obra Representativa
Diagrama de clases asociado al caso de uso vender una obra maestra

Proporciona los datos introducidos


por el agente
Vendedor

Obra maestra

GUI Calcular Precio


Agente
A t
Obra Maestra
Galería
Cuadro
Cuad o
Subastado

192
: GUI : Calcular Precio
Vendedor Agente : Cuadro
Obra Maestra
Galería Subastado
1: proporcionar
datos obra 2: transferir detalles
maestra : Obra maestra
3: crear objeto
nuevo

Datos
4: devolver objeto
proporcionados nuevo
por el vendedor 5: buscar cuadros
subastados
6: devolver cuadro
7: proporcionar
8: mostrar subastado
precio
precio

9: proporcionar
detalles del 10: transferir detalles
vendedor 11: solicitar
vendedor
actualización

13: confirmación 12: confirmación


14: mostrar
confirmación

193
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.

194
195
196
197
0
1
11
1.1
2
2.1
3
3.1 3.1.1

3.2
3.2.1

198
199
200
201
202
203
Indice

zDiagramas de Casos de Uso.


zDiagramas de Estructura.
Estructura
zDiagramas de Comportamiento.
zOCL.
zHerramientas.
zHerramientas
zEjemplos
zBibliografía.
204
Bibliografía: UML
UML
{ Dan
D Pil Pilone; N
Neilil Pi
Pitman. “UML 2
2.0
0 iin a N
Nutshell”.
t h ll” O’R
O’Reilly,
ill 2005
2005.
{ Martin Fowler. “UML Distilled: A Brief Guide to the Standard Object Modeling
Language, 3rd Edition”. Addison Wesley, 2003.
{ Web de la OMG sobre UML: http://www.uml.org
{ Perdita Stevens, Rob Pooley. “Utilización de UML en Ingeniería del Software con
Objetos
j y Componentes”.
p Addison Wesley, y, 2002.
{ Grady Booch, James Rumbaugh, Ivar Jacobson. “The Unified Modeling
Language User Guide”. Addison-Wesley, 1999.
{ Eriksson,
Eriksson H.H E.,
E Penker,
Penker M.,
M Lyons,
Lyons B B., Fado
Fado, D
D. “UML
UML 2 Toolkit”
Toolkit . OMG Press,
Press
Wiley. 2004.
{ Craig Larman. “Applying UML and Patterns”. Prentice Hall. 2002.

OCL
{ Warmer,
Warmer Kleppe.
Kleppe “The Object Constraint Language 2nd Edition
Edition. Getting your
Models Ready for MDA”. Addison-Wesley. 2003. 205

{Especificación de OCL 2.0: http://www.omg.org/docs/ptc/03-10-14.pdf


Bibliografía: Statecharts
z Harel D.
D “On Visual Formalisms”.
Formalisms” Communications of the
ACM. Vol 31, No. 5. Pp.: 514-530. Mayo 1988.

z Harel D., Naamad A. “The STATEMATE Semantics of


Statecharts”. ACM Transactions on Software
Engineering and Methodology,
Methodology Vol.
Vol 5,
5 No.
No 4,
4 Oct.
Oct 1996,
1996
pp.: 293-233.

z D
David
id Harel
H l and d Eran
E G
Gery. E
Executable
bl object
bj
modeling with statecharts. IEEE Computer, pages 31-42,
1997.

206

Potrebbero piacerti anche