Transcript Casos de Uso

Análisis y Diseño del Software
Curso 2004/2005
Capítulo 1
El Lenguaje Unificado de Modelado,
UML
Jesús García Molina
Departamento de Informática y Sistemas
Universidad de Murcia
http://dis.um.es/~jmolina
Contenidos
• Modelado del software
• Presentación de UML
• Modelado de Casos de Usos
– Diagramas de casos de uso
• Modelado Estructural
– Diagramas de Clases
2
Contenidos
• Modelado del Comportamiento
– Diagramas de interacción
– Diagramas de actividades
– Máquinas de estado
• Modelado de la Implementación
– Diagramas de componentes
– Diagramas de despliegue
• Colaboraciones
• Formalización de UML: MOF y metamodelo
3
Contenidos
• Modelado del software
• Presentación de UML
• Modelado de Casos de Usos
– Diagramas de casos de uso
• Modelado Estructural
– Diagramas de Clases
4
Bibliografía
G. Booch, J. Rumbaugh, I. Jacobson, “El lenguaje
unificado de modelado”, Addison-Wesley, 1999.
C. Larman, “UML y Patrones: Una introducción al
análisis y diseño orientado a objetos y al proceso unificado”,
Prentice-Hall, 2003.
http://www.uml.org/
5
El lenguaje unificado de modelado, UML
• A mediados de los noventa existían muchos métodos
A/DOO
– Mismos conceptos con distinta notación
– Mucha confusión.
• En 1994, Booch, Rumbaugh y Jacobson deciden unificar
las notaciones de sus métodos:
Unified Modeling Language (UML)
• Proceso de estandarización promovido por el OMG
http://www.uml.org
6
Explosión de métodos OO en los noventa
OMT
Booch
Jacobson
Shlaer-Mellor
Wirfs-Broks
Fusion
Catalysis
Coad/Yourdon
Champeaux
Martin/Odell
OOram
BON
Open
¡Y muchos más!
¡Guerra de
Métodos!
7
Evolución UML
• Grady Booch y Jim Rumbaugh comenzaron a unificar sus métodos
(Octubre, 1994).
• Borrador de UML (versión 0.8) (Octubre, 1995)
• Ivar Jacobson se une al proyecto (Noviembre, 1995).
• UML 0.9 y se crea un consorcio (Junio, 1996)
• OMG lanza una petición para un lenguaje unificado (1996)
• UML 1.0 es ofrecido al OMG (Enero, 1997)
• Se extiende el consorcio (Enero-Julio, 1997)
• UML 1.1 es ofrecido al OMG (Julio, 1997)
• OMG adopta UML 1.1 (Noviembre, 1997)
• Se crea el UML RTF (1998)
• UML 1.3 (Mayo 1999)
• UML 2.0 (principios de 2005)
8
Ventajas de la unificación
• Reunir los puntos fuertes de cada método
• Idear nuevas mejoras
• Proporcionar estabilidad al mercado
– Proyectos basados en un lenguaje maduro
– Aparición de potentes herramientas
• Eliminar confusión en los usuarios
9
Objetivos en el diseño de UML
• Modelar sistemas, desde los requisitos hasta los
artefactos ejecutables, utilizando técnicas OO.
• Cubrir las cuestiones relacionadas con el
tamaño propias de los sistemas complejos y
críticos.
• Lenguaje utilizable por las personas y las
máquinas
• Encontrar equilibrio entre expresividad y
simplicidad.
10
Modelado del Software
• El modelado es el diseño de aplicaciones software
antes de escribir el código.
• Se crean un conjunto de modelos (“planos del
software”) que permiten especificar aspectos del
sistema como los requisitos, la estructura y el
comportamiento.
• Los modelos
– ayudan a razonar sobre el sistema
– permiten documentar las decisiones
– Permiten una generación automática de código
11
¿Qué es un modelo?
“Un modelo es una simplificación de la realidad”
“Un modelo es una descripción de un sistema,
escrito en un lenguaje bien definido”
12
Tipos de modelo
• ¿En qué etapa del proceso se usa? ¿Análisis o Diseño?
• ¿Cuál es su grado de detalle? ¿Abstracto o detallado?
• ¿Qué sistema describe? ¿Modelo de negocio o modelo
software?
• ¿Qué aspecto describe? ¿Estructural o de comportamiento?
• ¿Es específico o independiente de la plataforma?
• ¿A qué plataforma va dirigido? EJB, JDBC, .NET,
CORBA, etc.
13
Modelos de Negocio y de Software
Modelo del Negocio
describe
derivado de
Modelo Software
describe
Empresa
Sistema
software
Sistema de
la empresa
14
Utilidad del modelado
“Una empresa software con éxito es aquella
que produce de manera consistente software
de calidad que satisface las necesidades de
los usuarios”
“El modelado es la parte esencial de todas las
actividades que conducen a la producción
de software de calidad”
15
Utilidad del modelado
¿Escribimos código
directamente?
Sería lo ideal pero ....
.... necesitamos escribir modelos
16
Utilidad del modelado
• Hay estructuras que trascienden lo representable en un
lenguaje de programación.
• Se facilita la comunicación entre el equipo al existir un
lenguaje común.
• Se dispone de documentación que trasciende al proyecto.
17
Utilidad del modelado
• Visualizar cómo es o queremos que sea el sistema
• Especificar la estructura y comportamiento del sistema
• Proporciona plantillas que guían la construcción del
sistema.
• Documentan las decisiones.
18
Propiedades del modelado
• La elección de los modelos tiene una profunda
influencia sobre cómo se acomete el problema y se
moldea la solución.
• Todo modelo debe estar ligado a la realidad.
• Un único modelo no es suficiente. Cualquier sistema
trivial se aborda mejor a través de un pequeño conjunto
de modelos casi independientes.
19
¿Por qué las empresas no hacen modelado?
• Hasta ahora, la mayor parte de las empresas software
no realizan ningún modelado.
• El modelado requiere:
– aplicar un proceso de desarrollo
– formación del equipo en la técnicas
– concienciación de su importancia
• ¿Se obtienen beneficios con el modelado?
20
¿Construimos software de calidad?
•
•
•
•
•
•
•
Retrasos en los plazos
Proyectos cancelados
Rápido deterioro del sistema instalado
Tasa de defectos o fallos
Requisitos mal comprendidos
Cambios frecuentes en el dominio del problema
Buenos programadores se cansan y dejan el equipo
¿Modelado es la solución?
21
Contenidos
• Modelado del software
• Presentación de UML
• Modelado de Casos de Usos
– Diagramas de casos de uso
• Modelado Estructural
– Diagramas de Clases
22
UML y el modelado
UML es un lenguaje para visualizar, especificar,
construir y documentar los artefactos (modelos) de un
sistema que involucra una gran cantidad de software,
desde una perspectiva orientada a objetos.
• UML es una notación, no es un proceso
• Se han definido muchos procesos para UML.
– Rational ha ideado RUP, el“proceso unificado”.
• Utilizable para sistemas que no sean software
23
Marco Conceptual de UML
• Bloques básicos de construcción
– Elementos
Estructurales, Comportamiento, Agrupación, Anotación
– Relaciones
– Diagramas
• Reglas para combinar bloques
– Establecen qué es un modelo bien formado
• Mecanismos comunes
– Especificaciones, Extensibilidad, Dicotomía clase-instancia,
Dicotomía interfaz-realización
24
Elementos Estructurales
• Partes estáticas de un modelo
Ventana
origen
tamaño
abrir()
cerrar()
mover()
dibujar()
clase
<<Interface>>
IAvisable
IAvisable
Interface
ValidarTransaccion
caso de uso
25
Elementos Estructurales
Gestor Eventos
clase activa
Hola
Mundo.class
suspender()
vaciarCola()
componente
colaboración
Gestión Pedidos
Servidor
nodo
26
Elementos de Comportamiento
Son las partes dinámicas de UML.
Interacción
Conjunto de mensajes intercambiados entre un conjunto
de objetos con un propósito particular.
dibujar
mensaje
27
Elementos de Comportamiento
Son las partes dinámicas de UML.
Máquina de estados
Secuencia de estados por las que pasa un objeto durante
su vida en respuesta a eventos.
activado
estado
28
Elementos de Agrupación
Son las partes de organización de los modelos UML
Modelo del Negocio
Paquete
Un paquete incluye un conjunto de elementos de cualquier
naturaleza.
Tiene una naturaleza conceptual.
29
Elementos de Anotación
Son las partes explicativas de los modelos UML
Retorna 0 si no
existe el valor
Nota
30
Relaciones
Dependencia
0..1
patron
*
empleado
Asociación
Generalización
Realización
31
Ejemplo
IteradorCuenta
Cuenta
Domiciliacion
1
Ahorro
0..n
Corriente
Operacion
Periodica
32
Diagramas de UML
•
•
•
•
•
•
•
•
Diagramas de Casos de Uso
Diagramas de Clases
Diagramas de Objetos
Diagramas de Interacción
– Diagrama Secuencia
– Diagrama Colaboración
Diagramas de Estados
Diagramas de Actividades
Diagramas de Componentes
Diagramas de Despliegue
Diagramas no
son modelos
34
Modelos en UML
• Modelado de Casos de Uso
– Diagrama de Casos de Uso
• Modelado Estructural
– Diagrama de Clases
• Modelado de Comportamiento
– Diagramas de Interacción
– Diagramas de Estados
• Modelado de flujos de actividades (p.e. Modelo del Negocio)
– Diagramas de actividades
• Modelado Implementación
– Diagrama de Componentes
• Modelado de Despliegue
– Diagramas de Despliegue
35
Responsable
Serv icio PE
Alumno
Sistema
Registrar Curso
Modelo del
Negocio
Aprobar Curso
Preinscripción
Avisar
Admitidos
Matriculación
Hay alumnos?
no
Cambiar
admitidos
Hay alumnos?
no
Cancelar Curso
Crear Proyecto
Cerrar Curso
Diagrama de
actividades
Realizar puja ordinaria
Pujador
Cerrar edición de subasta
Cancelar puja ordinaria
Realizar pago de subasta ordinaria
Rechazar adjudicación
Sistema
Notif icar adjudicatario
Teleoperador
Participante
Crear edición de subasta
Anular anuncio de subasta
Administrador
Anular edición de subasta
Diagrama de
casos de
uso
Modelo
Casos de Usos
Diagrama de
clases
Modelo
Estructural
1. cerrarEdicionSubasta(es)
int numAjudicaciones =
Minimo(pujas.length(),
articulos.length());
:
ControladorAnuncios
Diagrama de
colaboración
: Sistema
2. cerrar()
5. numAdjs = calcularAdjudicaciones()
9. [1..numAdjs]* add(adj)
4. * cerrar()
: AnuncioSubasta
as :
AnuncioSubasta
: EdicionSubasta
adjudicaciones :
Adjudicacion
3. * as := get()
8. [1..numAdjs]* adj := crear(as, pg, a)
6. [1..numAdjs]* pg := get()
pujas :
PujaOrdinaria
Se recorre la colección de
pujas obteniendo las pujas
ganadoras (consideramos
que la colección está
ordenada de mayor a menor
valor de puja).
7. [1..numAdjs]* a:= get()
adj :
Adjudicacion
: ArticuloConcreto
Modelo de
Comportamiento
Se crean tantas adjudicaciones
como pujas ganadoras haya.
Cada adjudicación se asocia
con un ArticuloConcreto, una
puja adjudicataria y con la
subasta.
Máquina de Estado
Diagrama de
estado
introducirProducto
Espera Venta
introducirProducto
Introduccion
Productos
Terminar Venta
manejarRespuesta
efectuar Pago Efectivo
Espera
Pago
Autorizacion
Pago
efectuar Pago Tarjeta
40
Mecanismos comunes de UML
• Especificaciones
– Proporcionan una semántica para cada elemento
– Los diagramas son proyecciones de esa base
• Adornos
– La notación gráfica básica de cada elemento puede incluir
adornos textuales o gráficos para resaltar algunas
propiedades de la especificación.
41
Mecanismos comunes de UML
• Dicotomía clasificador /instancia
CLASE
Persona
nombre
direccion
telefono
Casi todos lo bloque de construcción UML
presentan esta dicotomía Clase/Objeto:
UML distingue un objeto utilizando el mismo
símbolo de la clase y subrayando el nombre del
objeto
Objetos
Elena
Elena :
Persona
: Persona
Objeto de la clase Persona que no se
muestra en forma explícita
Se indica en forma explícita que es un
objeto Persona
Objeto Persona anónimo
Ej. Caso uso e instancia de caso de uso
Componente e instancias de componentes
Nodos e instancias de nodos
42
Mecanismos comunes de UML
• Dicotomía interfaz / implementación
Una Interfaz declara un contrato y una implementación
representa una realización concreta de ese contrato,
responsable de hacer ejecutar de forma fidedigna la
semántica completa de la interfaz
asistente
Ortografico.dll
IOrtografia
Casi todos los bloques de construcción UML presentan esta dicotomía
interfaz/implementación.
Ej.
Casos de uso y las colaboraciones que los realizan
operaciones y los métodos que los implementan
43
Mecanismos de extensibilidad de UML
• Estereotipos
– Extienden el vocabulario de UML, permiten definir nuevos
tipos elementos y relaciones a partir de los existentes.
– Algunos son predefinidos en UML
• Valores etiquetados
– Extienden las propiedades de un elemento, añadiendo nueva
información.
– Par etiqueta/valor: { etiqueta = “valor” }
• Restricciones
– Restricciones semánticas a elementos o relaciones. Definidos
por el modelador o incluidos en UML.
– Ejemplo: { emp.vacaciones < 28 }
44
Ejemplo Estereotipo predefinido
Cliente
<<Actor>>
Cliente
Cliente
Clase
Clase
estereotipada
45
Ejemplo Estereotipo Predefinido
IComparator
Clase
estereotipada
46
Mecanismos de extensibilidad de UML
valor etiquetado
estereotipo
ColaEventos {version 3.2; autor: jgm}
<<Exception>>
Overflow
añadir()
quitar()
vaciar()
{ordenado}
restricción
47
¡Hola, Mundo!
Paquete Java en el cual se encuentra la
Clase Graphics
Operación
La clase Graphics esta disponible para
el código que sigue
Introduce la nueva clase
Holamundo especificando que es
una subclase de Applet que se
encuentra en paquete java.applet
import java.awt.Graphics;
class HolaMundo extends java.applet.Applet {
public void paint (Graphics g) {
parámetro
g.drawString (“¡Hola, Mundo!”,10,10);
}
Operación invocada por paint
}
HolaMundo
g.drawString
("Hola, mundo”)
paint()
ABSTRACCIONES claves para HolaMundo
( captura los aspectos básicos de la aplicación
“¡HolaMundo!” pero deja fuera varias cosas)
48
Diagrama de Clases
La Clase Applet se utiliza como padre
de HolaMundo
Y la clase Graphics se utiliza en la
signatura e implementación de una
de sus operaciones, paint.
generalización
dependencia
49
Component implementa a ImageObserver
Al revisar las bibliotecas de
Java para Applet y Graphics
se verá que son parte de una
jerarquía mayor
Jerarquía de Herencia de HolaMundo
Organización en Paquetes
Organización de paquetes de HolaMundo
51
Organización en Paquetes
java
HolaMundo
Applet
awt
lang
52
Diagrama de Secuencia
Mecanismos para Dibujar ( se establece el orden de los eventos)
: Thread
: Toolkit
: ComponentPeer
target : HolaMundo
activación
1. run()
1.1. callbackLoop()
Nombre del objeto
Operaciones
invocadas
1.1.1. handleExpose()
1.1.1.1. paint()
La figura muestra la colaboración de varios objetos , incluida una
instancia de la clase HolaMundo. Los objetos son parte del entorno Java
53
Diagrama de Componentes
Componente ejecutable
hola.java
HolaMundo.class
Código fuente de la clase
HolaMundo
Página Web
Cada uno de los íconos de esta figura
representa un elemento UML en la vista
de implementación del sistema
hola.html
hola.jpg
54
Contenidos
• Modelado del software
• Presentación de UML
• Modelado de Casos de Usos
– Diagramas de casos de uso
• Modelado Estructural
– Diagramas de Clases
55
Modelado de Casos de Uso
• Un caso de uso especifica un comportamiento deseado del
sistema.
• Representan los requisitos funcionales del sistema.
“Un caso de uso especifica una secuencia de acciones,
incluyendo variantes, que el sistema puede ejecutar y que
produce un resultado observable de valor para un
particular actor”
• Describen qué hace el sistema, no cómo lo hace.
56
Emisor
Centralita
Receptor
listo( )
tono
marcar_numero
tono_sonando
timbre_sonando
ESCENARIO
telefono_cogido
para_tono
para_timbre
• Casos de uso son ideados por Jacobson a principios de los noventa
• Se inspira en los escenarios utilizados para describir procesos
Otras definiciones de caso de uso
• “Describe un conjunto de interacciones entre actores externos y el
sistema en consideración orientadas a satisfacer un objetivo de un
actor”.
[D. Bredemeyer]
• “Es una colección de posibles secuencias de interacciones entre el
sistema en discusión y sus actores externos, relacionado con un
objetivo particular”.
[A. Cockburn]
• “Es una colección de escenarios de éxito y fracaso relacionados
que describe a los actores que usan un sistema para conseguir un
objetivo”
[C. Larman]
58
Ejemplo Caso de Uso
actor
Responsable
Prestamos
caso de uso
Gestionar Préstamos
asociacion
59
Actores
Un actor representa un conjunto coherente de roles que
juegan los usuarios de los casos de uso al interaccionar
con el sistema.
• Roles jugados por personas, dispositivos, u otros
sistemas.
• El tiempo puede ser un actor (“procesos iniciados por el
sistema”)
• No forman parte del sistema
60
Actores
• Un usuario puede jugar diferentes roles.
• En la realización de un caso de uso pueden intervenir
diferentes actores.
• Un actor puede intervenir en varios casos de uso.
• Identificar casos de uso mediante actores y eventos
externos.
• Un actor necesita el caso de uso y/o participa en él.
61
Actores
A. Cockburn distingue dos tipos de actores:
– Primarios:
Requieren al sistema el cumplimiento de un objetivo
– Secundarios:
El sistema necesita de ellos para satisfacer un objetivo
62
Propiedades de los casos de uso
• Son iniciados por un actor con un objetivo en mente y es
completado con éxito cuando el sistema lo satisface.
• Puede incluir secuencias alternativas que llevan al éxito y
fracaso en la consecución del objetivo.
• El sistema es considerado como una “caja negra” y las
interacciones se perciben desde fuera.
• El conjunto completo de casos de uso especifica todas las
posibles formas de usar el sistema, esto es el
comportamiento requerido.
63
Escenarios y Casos de Uso
• Un caso de uso describe un conjunto de secuencias de
interacciones o escenarios: flujo principal y flujos
alternativos o excepcionales
• Un escenario es una instancia de un caso de uso
• Escenarios principales vs. Escenarios secundarios
• Especificación con diagramas de secuencia o textual.
64
Descripción de un caso de uso
• Describir el flujo de eventos
–
–
–
–
Texto estructurado informal
Texto estructurado formal (plantillas)
Pseudocódigo
Notaciones gráficas: diagramas de secuencia
• Debe ser legible y comprensible para un usuario no
experto.
• Debe indicarse: inicio y final, actores, objetos que fluyen, flujo
principal y flujos excepcionales.
65
Descripción de un caso de uso
Comprar artículos (en un terminal de punto de venta)
Flujo Principal: Un cliente llega al TPV con un conjunto de articulos. El Cajero
registra los artículos y se genera un ticket. El cliente paga en efectivo y recoge los
artículos.
1. El cliente llega al TPV con los artículos.
2. El cajero registra el identificador de cada artículo.
3. El sistema obtiene el precio de cada artículo y añade la información a la
transacción de venta.
4. Al acabar el cajero indica la finalización de la introducción de artículos.
5. El sistema calcula el total de la compra y lo muestra.
66
Descripción de un caso de uso
Comprar articulos (en un terminal de punto de venta)
6. El Cajero le dice al cliente el total.
7. El cliente realiza el pago.
8. El cajero registra la cantidad de dinero recibida.
9. El sistema muestra la cantidad a retornar al cliente y genera un recibo.
10. El cajero deposita el dinero recibido y saca la cantidad a devolver que
entrega al cliente junto al ticket de compra.
11. El sistema almacena la compra completada.
12. El cliente recoge los artículos comprados.
67
Comprar Articulos
Cajero
Cliente
:Sistema
: Cajero
introducirItem(upc,cantidad)
finalizarVenta()
hacerPago(cantidad)
Descripción de un caso de uso
Validar Usuario (contexto de un cajero automático)
Flujo Principal: El sistema pide el NIP. El cliente lo introduce a través del
teclado y pulsa Enter. El sistema comprueba la validez del NIP. Si es válido el
sistema acepta la entrada y finaliza el caso de uso.
Flujo Excepcional: El cliente puede cancelar la transacción en cualquier
momento, pulsando el botón Cancelar, reiniciando el caso de uso.
Flujo Excepcional: Si el NIP introducido es inválido entonces se reinicia el
caso de uso. Si esto ocurre tres veces, el sistema cancela la transacción
completa y se queda con la tarjeta.
69
Ejemplo diagrama de casos de uso
Registrar curso
Rebajar Mínimo
Aprobar curso
Servicio CPE
Responsable
Cerrar curso
Crear proyecto
Servicio Contabilidad
Fin matriculacion
Realizar preinscripción
Sistema
Avisar admitidos
Alumno
Matriculación
Cancelar curso
Ejemplo diagrama de casos de uso
Actores
Secundario
Alumno
Realizar preinscripción
Gestión Expedientes
Actor
Principal
Matriculación
Entidad Bancaria
Ejemplo diagrama de casos de uso
Reservar Libro
Prestamo revista
Profesor
Prestamo Libro
Devolver revista
Devolver libro
Actualizar catalogo
Socio
Extender Prestamo
Consultar
Bibliotecario
Socio
72
Casos de uso y Colaboraciones
• Con un caso de uso se describe un comportamiento
esperado del sistema, pero no se especifica cómo se
implementa.
• Una caso de uso se implementa a través de una
colaboración:
“Sociedad de clases y otros elementos que colaborarán para
realizar el comportamiento expresado en un caso de uso”
• Una colaboración tiene una parte estática (diagramas de
clases) y una parte dinámica (diagramas de secuencia).
73
Casos de uso y Colaboraciones
caso de uso
colaboración
Hacer Pedido
Gestión Pedidos
realización
74
Casos de uso y Colaboraciones
“El objetivo de la arquitectura del sistema es
encontrar el conjunto mínimo de colaboraciones
bien estructuradas, que satisfacen el
comportamiento especificado en todos los casos
de uso del sistema”
75
Organización de Casos de uso
• Tres tipos de relaciones:
– Generalización
• Un cdu hereda el comportamiento y significado de otro
– Inclusión
• Un cdu base incorpora explícitamente el comportamiento de
otro en algún lugar de su secuencia.
– Extensión
• Un cdu base incorpora implícitamente el comportamiento de
otro cdu en el lugar especificado indirectamente por este otro
cdu
76
Ejemplo
Relación de extensión
«extend»
Hacer Pedido
(establecer
prioridad)
«include»
Relación de
inclusión
Seguir Pedido
Validar Usuario
«include»
Hacer Pedido
Urgente
Comprobar clave
Generalización
Examinar retina
77
Relación de inclusión
• Permite factorizar un comportamiento en un caso de
uso aparte y evitar repetir un mismo flujo en diferentes
casos de uso.
• Ejemplo caso de uso “Hacer Pedido”:
“Obtener y verificar el número de pedido. Include (Validar
usuario). Examinar el estado de cada parte del pedido y
preparar un informe para el usuario”.
78
Relación de extensión
• El caso de uso base incluye una serie de puntos de
extensión.
• Sirve para modelar
– la parte opcional del sistema
– un subflujo que sólo se ejecuta bajo ciertas condiciones
– varios flujos que se pueden insertar en un punto
• Ejemplo caso de uso “Hacer Pedido”:
“ Include (Validar usuario). Recoger los ítems del pedido
del usuario. (establecer prioridad). Enviar pedido para ser
procesado.
79
Obtención de casos de uso
1) Identificar los usuarios del sistema.
2) Encontrar todos los roles que juegan los usuarios
y que son relevantes al sistema.
3) Para cada rol identificar todas las formas
(objetivos) de interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso. (¡Cuidado!)
6) Revisar y validar con el usuario.
80
Plantilla para casos de uso
(D. Coleman)
Caso de Uso
identificador / historia
Descripción
objetivo a conseguir
Actores
lista de actores
Asunciones
condiciones que deben cumplirse
Pasos
interacciones entre los actores y el
sistema necesarias para obtener el objetivo
(opcional) cualquier variación en los pasos
Variaciones
No-funcional (opcional) lista requisitos no funcionales
Cuestiones
lista de cuestiones que permanecen por
resolver
81
Plantilla para casos de uso
(D. Coleman)
Ejemplo campo “pasos”:
1. Operador es notificado de problema en la red
2. Operador inicia una sesión de reparación
3. REPETIR
3.1. Operador ejecuta aplicación diagnósticos en la red.
3.2. Operador identifica elementos que deben cambiarse y sus
nuevos valores para los parámetros.
3.3. EN PARALELO
3.3.1. Ingeniero mantenimiento comprueba elementos
en la red ||
3.3.2. Ingeniero mantenimiento envía informe fallo
4. Operador cierra sesión
82
Plantilla para casos de uso
(D. Coleman)
Relación de uso: PERFORM c.d.u.
Relación de extensión:
Caso de uso extensión c.d.u. extends c.d.u.
Cambio
objetivo que debe conseguirse
Pasos
...
Variaciones
...
No funcional
...
Cuestiones
...
83
Plantilla usecases.org (Larman)
•
•
•
•
•
•
•
•
•
•
Actor Principal
Personas involucradas e Intereses
Precondiciones
Postcondiciones
Escenario Principal (Flujo Básico)
Extensiones (Flujos Alternativos)
Requisitos especiales
Tecnología y Lista Variaciones de datos
Frecuencia
Cuestiones abiertas
84
¿Por qué casos de uso?
• “Ofrecen un medio sistemático e intuitivo para capturar
los requisitos funcionales, centrándose en el valor añadido
para el usuario”
• Dirigen todo el proceso de desarrollo puesto que la
mayoría de actividades (planificación, análisis, diseño,
validación, test,..) se realizan a partir de los casos de uso.
• Mecanismo importante para soportar “trazabilidad” entre
modelos.
85
Críticas a los casos de uso
(B.Meyer)
• Los casos de uso no son adecuados en el modelado
orientado a objetos porque:
i) Favorecen un enfoque funcional, basado en procesos
ii) Se centran en secuencias de acciones
iii) Se basan en los escenarios actuales del sistema
“Solo deben ser usados por equipos expertos en
desarrollo OO”
• Útiles para validación
86
Utilidad de los casos de uso
• Hay consenso en considerar casos de uso como
esenciales para capturar requisitos y guiar el modelado.
• Pero existe (¿ha existido?) mucha confusión sobre
cómo usarlos.
• Diferentes opiniones sobre el número de casos de uso
conveniente:
– 20 para un proyecto 10 personas/año (Jacobson)
– depende de la granularidad
87
Granularidad
• Diferente granularidad
• Un caso de uso puede describir:
– Un objetivo o propósito del usuario
– Una interacción con el sistema
• Un objetivo implica una o más interacciones.
• Construir un caso de uso por cada objetivo del usuario.
88
Granularidad
• Ambito
(A. Cockburn)
Caso de uso
– Sistema
• Funcionalidad requerida del sistema
– Organización
Caso de uso
del negocio
• Objetivo estratégico para la empresa, de mucho valor
• Especificidad
– Objetivo del usuario
cdu
– Colecciones de objetivos de usuario
– Subfunciones
inclusión de cdu
cdu negocio
89
Granularidad
(A. Cockburn)
• Especificidad
– Objetivo del usuario
• Tarea del usuario o “proceso de negocio elemental”
– Colecciones de objetivos de usuario
• Recoge casos de uso de usuario relacionados
– Subfunciones
• Un paso en la descripción de un caso de uso (validar, buscar, log on)
• Detalle de la interacción
– Interfaz de dialogo o Interfaz semántica
90
Tipos de casos de uso
• Según el nivel de detalle
– Breve : Descripción en unas pocas líneas
– Informal : Varios párrafos que cubren varios escenarios
– Expandido : Descripción detallada con una plantilla
• Según la importancia
– Primario, secundario u opcional
• Según el nivel de abstracción
– Esencial : ¿Qué hace el sistema?
– Concreto : Se contemplan detalles de implementación (GUI y
tecnología)
91
Recomendaciones
• Especificar casos de uso no es una actividad de dibujar
diagramas sino de escribir con el detalle necesario el
flujo principal y los flujos alternativos: “centrado en la
escritura en vez del dibujo”
• No hay que preocuparse demasiado por las relaciones
entre casos de uso ni entre actores.
• El objetivo inicial es identificar los actores y a partir de
sus objetivos encontrar los casos de uso, el diagrama de
casos de uso es una ayuda visual.
• Los actores deben interactuar con el sistema
92
Recomendaciones
• ¿Qué granularidad es apropiada para un caso de uso?
• En un sistema de venta por internet,
– “Añadir producto al carro de la compra”
– “Introducir datos facturación”
¿son casos de uso?
• Deben ser objetivos del usuario
• Error común: no identificar como casos de uso las tareas
que inicia el propio sistema
– “Anular reservas pasados quince días”
93
Recomendaciones
• No incluir como caso de uso las operaciones CRUD
sobre un objeto de negocio (alta, consulta, borrado,
actualización): función del sistema aparte, excepto si se
trata de operaciones relevantes para el sistema, como
“registrar cliente” en un sistema de venta por internet
• Cuidado con el empleo de la relación “include”
¡NO HACER UNA DESCOMPOSICION FUNCIONAL!
• Escribir casos de uso independientes de la interfaz o de
detalles de implementación, escribirlos a nivel esencial.
• ¿A qué nivel de detalle se describe un caso de uso?
– Primero informal, luego expandido
94
Recomendaciones
• Hay que comprobar que los casos de uso incluyen toda la
funcionalidad del sistema.
• Preocupación por mantener la validez y consistencia del
conjunto de casos de uso.
• Cada compañía debe tener un manual sobre uso de los
casos de uso.
• Los casos de uso sólo consideran los requisitos
funcionales del proyecto, hay que añadir los nofuncionales.
95
Referencias
• http://alistair.cockburn.us/usecases/usecases.html
• “Writing effective uses case”, Alistair Cockburn, Addison-Wesley, 2000
• C. Larman, “UML y Patrones: Una introducción al análisis y diseño orientado
a objetos y al proceso unificado”, Prentice-Hall, 2003.
96
Contenidos
• Modelado del software
• Presentación de UML
• Modelado de Casos de Usos
– Diagramas de casos de uso
• Modelado Estructural
– Diagramas de Clases
97
Modelado estructural
• Se describen los tipos de objetos de un sistema y las
relaciones estáticas que existen entre ellos.
– Clases
– Interfaces
– Relaciones de dependencia, realización, generalización y
asociación (agregación, composición)
– También pueden incluir paquetes y colaboraciones
• Un diagrama de clase es una representación gráfica de
un modelo estructural.
98
Modelado estructural
• Diferentes perspectivas.
• Modelado Conceptual
– Conceptos del dominio del problema: atributos, restricciones y
relaciones entre ellos.
• Modelo del Análisis
– Clases que corresponden a conceptos del dominio
– Atributos y métodos
• Modelo de Diseño
– Incluye clases que corresponden a decisiones del diseño
• Modelo de Implementación
– Clases que corresponden a un lenguaje de programación
99
Modelo
Conceptual
Del Modelo Conceptual a las clases
• Los modelos de análisis se obtienen a partir del
modelo conceptual:
– Conceptos a clases
– Atributos de un concepto a atributos de la clase
– Añadir comportamiento (métodos)
101
Modelo de
diseño
IteradorCuenta
Cuenta
Domiciliacion
1
Ahorro
0..n
Corriente
Operacion
Periodica
¿Modelo Conceptual
o de Análisis?
1. cerrarEdicionSubasta(es)
int numAjudicaciones =
Minimo(pujas.length(),
articulos.length());
:
ControladorAnuncios
: Sistema
2. cerrar()
5. numAdjs = calcularAdjudicaciones()
9. [1..numAdjs]* add(adj)
4. * cerrar()
: AnuncioSubasta
as :
AnuncioSubasta
: EdicionSubasta
adjudicaciones :
Adjudicacion
3. * as := get()
8. [1..numAdjs]* adj := crear(as, pg, a)
6. [1..numAdjs]* pg := get()
pujas :
PujaOrdinaria
Se recorre la colección de
pujas obteniendo las pujas
ganadoras (consideramos
que la colección está
ordenada de mayor a menor
valor de puja).
7. [1..numAdjs]* a:= get()
adj :
Adjudicacion
: ArticuloConcreto
Modelo de
Comportamiento
Se crean tantas adjudicaciones
como pujas ganadoras haya.
Cada adjudicación se asocia
con un ArticuloConcreto, una
puja adjudicataria y con la
subasta.
Colaboración (parte estática)
105
Colaboración (parte dinámica)
: Usuario
11: recalcularTotal()
1: añadirItem(codigo)
4: añadirItem(codigo)
2: añadirItem(codigo)
: MostrarProductos
3: [primer producto] crear()
: Añadir
: CarroCompras
6: [!nuevoItem]incrementarUnidades()
10: [nuevoItem]put(codigo,i)
5: i:=getItemCarro(codigo)
: ItemCarro
7: [nuevoItem]p:=get(codigo)
9: [nuevoItem]i:=creaItem(p)
: CatalagoProductos
i : ItemCarro
8: [nuevoItem]p:=buscar(codigo)
: Producto
106
Patrón de diseño (Parte Estática)
Subject
subjectState
Attach()
Detach()
Notify()
Observer
+observers
1..*
1..1
Update()
for all o in observers
{o.update()}
ConcreteSubject
subjectState
getState()
setState()
+subject
ConcreteObserver
observerState
update()
observerState=
subject.getState()
107
Patrón de diseño (Parte dinámica)
o1 : Observer
: Subject
o2 : Observer
1. setState()
1.1. notify()
1.1.1. update()
1.1.2. update()
108
Ingeniería directa e Inversa
• Ingeniería directa
– Transformar modelos en código en un lenguaje de
programación determinado
• Ingeniería inversa
– Obtener un modelo a partir de código.
– Más difícil ya que hay pérdida de información al
pasar de los modelos al código.
109
Atributos
[visibilidad] nombre [: tipo] [= valor_inicial ] [{propiedades}]
+ = pública
# = protegida
- = privada
visibilidad
nombre:
nombre del atributo
tipo:
tipo del atributo
valor_inicial:
valor inicial o por defecto
propiedades: {frozen} {addOnly}
110
Atributos
• Nivel Conceptual: “Los clientes tienen un nombre”
• Nivel de Especificación: “El cliente puede almacenar y
consultar su nombre”
• Nivel de Implementación: “Una instancia de Cliente tiene un
campo de tipo String que almacena su nombre y un método que
lo devuelve”
111
Operaciones
[visibilidad] nombre [(lista_parametros)] [: tipo_retorno] [{propiedades}]
visibilidad
+ = pública
# = protegida
- = privada
nombre: nombre de la operación
lista_parámetros:
lista de parámetros separados por comas
tipo retorno:
tipo de valor devuelto por la operación
propiedades:
{isQuery}, {sequential}, {concurrent}
112
Operaciones
Atributos
Operacione
s
113
Clases Parametrizadas
G
Tabla
Clase
Parametrizada
count
capacity
put(G)
item() : G
«bind» <Empleado>
Empleados
Instanciación
Tabla<Cliente>
114
Otras propiedades
• Clases y métodos diferidos
• Multiplicidad
• Variables y métodos de clase
<<abstract>>
Figura
rotar()
trasladar()
visualizar()
115
Clases Estereotipadas
<<metaclass>>
MetaclaseCuenta
<<exception>>
FueraRango
Clases y valores etiquetados
116
Relaciones
• Dependencia
Un cambio en la especificación de un elemento afecta a otro
PlanDelCurso
Window
position
parent
children
size
open()
close()
move()
resize()
Curso
añadir(c : Curso)
eliminar(c : Curso)
Clock
Nodo
Lista
<<friend>>
117
Estereotipos para dependencias
• bind: entre una clase genérica y una instanciación
• friend: dependencia de clase amiga
• refine: relación de refinamiento
• use: relación de uso
• import: un paquete importa los elementos de otro.
• extend: para casos de uso
• include: para casos de uso
118
Relaciones
• Generalización
– “Es-un-tipo-de”
Cuenta
CuentaAhorro
Window
CuentaCorriente
TextWindow
BoxDialog
119
Generalización
• Nivel Conceptual
– “Todas las instancias de CuentaCorriente son instancias de
Cuenta”
• Nivel Especificación
– “La interfaz de CuentaCorriente incluye la interfaz de Cuenta”
– Principio Sustitución
• Nivel Implementación
– Herencia
120
Asociación
• Asociación
– Relación estructural que especifica que los objetos de un tipo
están conectados con los de otro.
Persona
+empleado
+patron
1..*
Empresa
*
impartido
Curso
*
Profesor
1..*
121
Asociaciones
• Agregación
– Caso especial de asociación
– Relación estructural parte-de
Empresa
1..1
*
Departamento
122
Asociaciones
• Nivel Conceptual
– Muestran la relación conceptual entre dos clases.
“Un cliente tiene varios pedidos”
• Nivel de Especificación
– Representan responsabilidades
– Detectamos los mensajes del protocolo de una clase con
respecto a la otra
• Nivel de Implementación
– Establecer atributos: navegabilidad
123
Asociaciones
• Especificación:
class Pedido {
public Cliente getCliente();
public Set
getLineaPedido();... }
• Implementación
…}
class Pedido {
private Cliente
private HashSet
_cliente;
_lineasPedido;
124
Navegación
• Posibilidad de limitar la navegación a una sola dirección
• Determina si una clase de la asociación tiene “conocimiento” de la
otra.
• Nivel de especificación o implementación
impartido
Curso
*
Profesor
1..*
125
Visibilidad
• Pública:
+propietario
• Protegida: #propietario
• Privada:
-propietario
GrupoUsuarios
Usuario
*
*
+propietario
1..1
-clave
Clave
*
126
Asociaciones calificadas
• Nivel Conceptual: “Dentro del mismo pedido no pueden existir
dos líneas con el mismo producto”
• Nivel Especificación: “El acceso a ItemPedido es indexado
por productos”
• Nivel Implementación: “Se usa una tabla para almacenar las
líneas de pedido”
127
Asociaciones calificadas
Class Pedido {
private Hashtable _lineasPedido;
public ItemPedido getItemPedido(Producto unProducto);
public void addItemPedido (Integer cantidad, Producto elProducto);
…
}
128
Agregación
• Dos criterios:
– Dependencia:
¿La existencia de una parte va ligada a la del agregado?
– Exclusividad:
¿Una parte puede pertenecer a más de un agregado?
• Cuatro posibles tipos de agregación
129
Composición
• Es un caso particular de agregación:
exclusiva y dependiente
• Las partes pueden crearse después del agregado
compuesta al que pertenecen, pero una vez creadas
viven y mueren con ella.
• La parte sólo puede formar parte de un agregado.
• El agregado gestiona la creación y destrucción de las
partes.
• Las partes se pueden eliminar antes de eliminar el
agregado.
130
Composición
agregado /todo
Ventana
1..1
composición
*
Marco
parte
131
Composición
POLIGONO
1
Relleno:Diseño
1
{ordered}
{ordered} 3..*
Punto
132
Clases Asociación
• Una asociación que también es una clase
• Una clase asociación añade una restricción:
“Sólo puede existir una instancia de la asociación
entre cualquiera par de objetos participantes”
• No podríamos modelar que una persona tiene diferentes
contratos para una misma compañía a lo largo del tiempo.
133
Ejemplo de clase asociación
134
Ejemplo de clase asociación
135
Asociaciones derivadas
Asociación
Derivada
136
Asociaciones derivadas
recibe
Estudiante
Asignatura
/enseña
imparte
Profesor
Asociación
Derivada
137
Restricciones para Asociaciones
Empresa
Cuenta
{or}
Persona
Departamento
*
*
{subconjunto}
+miembro
1..*
+Director
1..1
Persona
138
Restricciones para Asociaciones
operario
*
0..1
jefe
Persona
empleado
*
patrón
0..1
Compañia
{Persona.patrón=
Persona.jefe.patrón }
139
Realización
Relación entre clasificadores, un clasificador especifica
un contrato que otro clasificador garantiza que cumplirá.
<<Interface>>
IPila
Pila
push()
pop()
top()
Pila
IPila
140
Clases Abstractas e Interfaces
Interfaz
InputStream
(from io)
InputStreamReader
(from io)
DataInput
Clase
Abstracta
(from io)
FilterInputStream
(from io)
DataInputStream
(from io)
141
Clases Abstractas e Interfaces
InputStream
<<Interface>>
DataInput
(from io)
InputStreamReader
(from io)
(from io)
Interfaz
FilterInputStream
(from io)
DataInputStream
(from io)
142
Paquetes
•
•
•
•
•
Elemento organizativo
Puede agrupar elementos de cualquier tipo.
Un elemento es exclusivo a un paquete.
Establece un espacio de nombres
Posibilidad de anidar paquetes.
Modelo
Modelo
+ Producto
+ CarroCompra
+ Comercio
143
Importación/Exportación en paquetes
• “Los paquetes permiten controlar la complejidad del manejo de un
gran número de abstracciones, controlando los accesos mediante la
importación”.
• Relaciones de importación, acceso y generalización
• La parte pública de un paquete son sus exportaciones.
• Las partes públicas son visibles en los paquetes que
importan al paquete contenedor.
• La importación no es transitiva.
• Los paquetes anidados pueden ver todo lo que ven los
paquetes que los contienen.
144
Cliente
+ FormularioPedido
+ FormularioDeSeguimiento
- Pedido
Servidor
+ BaseDeDatos
+ ServicioDeRegistro
<<import>>
Politicas
+ ReglasPedidos
+ GUI:Ventana
GUI
+ Ventana
+ Formulario
# GestorEventos
<<import>>
Generalización de Paquetes
GUI
+ Ventana
+ Formulario
# GestorEventos
WindowsGUI
+ GUI:Ventana
+ Formulario
# GUI:GestorEventos
+ VBForm
MacGUI
146
Paquetes
• Un paquete bien estructurado debe:
–
–
–
–
ser cohesivo
estar poco acoplado
pocos anidamientos
conjunto equilibrado de elementos
148
Uso de los paquetes
<<subsystem>>
Pedidos
<<model>>
Diseño
<<layer>>
Servicios
Básicos
<<framework>>
Struts
149
Uso de los paquetes
• Agrupar elementos relacionados para manejarlo en
conjunto.
Paquete “Clases e interfaces del modelo”
Paquete “Interfaces de usuario”
Paquete “Servicios base de datos”
Paquete “Modelo del análisis”
• Un modelo es un paquete incluyendo todos los
elementos que constituyen una particular vista del
sistema modelado.
150
Sistema, modelo, vista, diagrama
• Un sistema es aquello que se está desarrollando y para lo
que se crean modelos.
• Un sistema debe ser modelado desde dos puntos de vista:
– Modelar el problema: comprender el problema
– Modelar el producto a crear: diseñar la solución
• Modelado OO ofrece una correspondencia directa entre
los dos puntos de vista, a través del concepto de “objeto”
151
Sistema, modelo, vista, diagrama
• Un modelo captura una vista de un sistema físico. Es una
abstracción de ese sistema con cierto propósito, por
ejemplo modelar su comportamiento en relación a unas
personas que tienen determinado interés.
• Un modelo contiene todos los elementos de modelado
necesarios, organizados en una jerarquía de paquetes/
subsistemas.
• Un modelo y sus elementos tienen una especificación.
• Un modelo y sus elementos se representan mediante
diagramas, que expresan una vista del modelo.
152
Subsistema
• Un subsistema es una “unidad de comportamiento” en
el sistema.
• Permite descomponer el sistema
• Un subsistema ofrece interfaces, tiene operaciones, y
distingue entre especificación e implementación.
153
Vistas UML
vocabulario
funcionalidad
ensamblado
gestion conf.
Vista de Implementacion
Vista de Diseño
comportamiento
Vista de Procesos
Funcionamiento
escalabilidad
rendimiento
Vista de casos de uso
Vista de Despliegue
topología
entrega
distribución
instalación
Modelo de la Arquitectura de un sistema
156
Vistas UML
clases
interfaces
colaboraciones
componentes
Vista de Implementacion
Vista de Diseño
casos de uso
Vista de Procesos
clases activas
Vista de casos de uso
Vista de Despliegue
nodos
157
Vistas UML
Diagramas de clase
Diagramas de interacción
Diagramas de estado
Vista de Implementación
Vista de Diseño
Diagramas de casos de uso
Vista de Procesos
Diagramas de clase
Diagramas de interacción
Diagramas de estado
Diagramas de componentes
Diagrama de interacción
Diagramas de estado
Vista de casos de uso
Vista de Despliegue
Diagramas de despliegue
Diagrama de interacción
Diagramas de estado
158
Diagrama de Objetos
Modelan las instancias de los
elementos contenidos en los
diagramas de clases
: Cuenta
Muestra un conjunto de
objetos y sus relaciones en
un momento concreto
Multiobjeto (colección
de objetos anónimos)
Enlace
: Cliente
: CodigoCuenta
: Tarjeta
: Transaccion
Objeto
: Perfil
Se utilizan para modelar la vista de diseño
estática o la vista de procesos estática de
un sistema
159
Diagrama de Objetos
: Curso
: Alumno
: Profesor
: Tarjeta
: Expediente
: Departamento
director : Profesor
: Tarjeta
: GrupoInvestigacion
160
Contenidos
• Modelado del Comportamiento
– Diagramas de interacción
– Diagramas de actividades
– Máquinas de estado
• Modelado de la Implementación
– Diagramas de componentes
– Diagramas de despliegue
• Colaboraciones
• Formalización de UML: MOF y metamodelo
161
Enlaces y Asociaciones
• Un enlace es :
– una conexión semántica entre objetos.
– una instancia de una asociación.
– un camino por el cual enviar un mensaje
enlace
p:Persona
:Empresa
1: asignar(desarrollo)
mensaje
162
Interacciones y Mensajes
• Interacción: Comportamiento que comprende un
conjunto de mensajes intercambiados entre un conjunto
de objetos dentro de un contexto para lograr un
propósito.
• Mensaje: especificación de una comunicación entre
objetos que transmite información, con la expectativa
de desencadenar una actividad.
163
Modelado del comportamiento
• Se describe cómo los objetos colaboran entre sí para
realizar cierta actividad.
• Se expresan mediante los diagramas de interacción:
– Diagramas de Secuencia y Diagramas de Colaboración.
• También se describe las máquinas de estado que
caracterizan a los objetos
– Diagramas de estado
– Diagramas de actividades
164
Diagramas de Interacción
• Describen una interacción.
• Dos tipos: Diagramas de Secuencia y Colaboración
• Diagramas de Secuencia:
– Destacan la ordenación temporal de los mensajes
• Diagramas de Colaboración:
– Destacan la organización estructural de los objetos
participantes.
• Equivalencia semántica
165
Diagramas de Secuencia
• Incluye:
–
–
–
–
Objetos y su línea de tiempo
Focos de control o activación
Mensajes: a instancias o de creación
Mensaje self ( especifica que el objeto correspondiente es
visible porque es el emisor del mensaje)
– Información de control: condiciones ( entre corchetes)y
marcas de iteración ( asterisco)
– Indicar el objeto devuelto por el mensaje: return
(añadirlos sólo cuando ayuden a clarificar la interacción)
166
Mensajes
•
•
•
•
•
Simple:
Creación de objetos:
Condición:
Iteración:
Asignación:
metodo(arg)
<<create>>
[cond] metodo()
* metodo()
v:= getObjeto()
• Numeración jerárquica o secuencial o ninguna
167
Diagramas de Secuencia
:
:
: Pedido
: LineaPedido
: Item
InterfacePedido
ControladorPedido
1: preparar()
2: preparar()
3: * preparar()
4: hayStock:=check()
5: [hayStock] eliminar()
6: pedir?:= necesarioPedir()
7: [pedir?] <<create>>
: ItemPedido
8:
9: [hayStock] <<create>>
: ItemEntregado
168
Diagramas de Colaboración
1: preparar()
:
InterfacePedido
2: preparar()
: ControladorPedido
6: pedir?:= necesarioPedir()
3: * preparar()
4: hayStock:=check()
5: [hayStock] eliminar()
: Item
7: [pedir?] <<create>>
: ItemPedido
: Pedido
:
LineaPedido
8: [hayStock] <<create>>
:
ItemEntregado
169
Diagrama de Secuencia
c:Cliente
p:ProxyODBC
<<create>>
:Transaccion
establecerAcciones
establecerValores
establecerValores
tiempo
Línea de vida
exito
<<destroy>>
Foco de
control
170
Diagrama de Colaboración
1: <<create>>
2: establecerAcciones
6: <<destroy>>
c:Cliente
:Transac
cion
5: exito
3: establecerValores
4: establecerValores
p:Proxy
ODBC
171
Diagrama de Secuencia
c:Cliente
a:Ayuda
Planificacion
<<create>>
:AgenteBilletes
establecerItinerario(i)
calcularRuta
ruta
<<destroy>>
notificar
172
Diagrama de Colaboración
3: calcularRuta
1: <<create>>
2: establecerItinerario(i)
5: <<destroy>>
c:Cliente
:Agente
Billetes
4: ruta
6: notificar
a:Ayuda
Planificacion
173
Numeración secuencial
2: m2()
1: m1()
:A
3: m3()
:B
:C
4: m4()
:D
Confusión en el flujo de ejecución
174
Numeración jerárquica
:C
:B
:A
:D
1. m1()
1.1. m2()
1.2. m3()
1.3. m4()
175
Numeración jerárquica
1.1. m2( )
1. m1( )
:A
1.2. m3( )
:B
:C
1.3. m4( )
:D
176
Numeración jerárquica
:A
:B
:C
:D
1. m1( )
1.1. m2( )
1.1.1. m3( )
1.2. m4( )
177
Numeración jerárquica
1.1. m2( )
1. m1( )
:A
1.1.1. m3( )
:B
:C
1.2. m4( )
:D
178
Numeración jerárquica
1.1. m2()
1. m1()
:A
1.2. m3()
:B
:C
1.3. m4()
:D
179
Tipos de mensajes
• Simple
– Llamada de operación o flujo anidado de control
• Síncrono (llamada)
– El emisor espera hasta recibir el resultado
• Asíncrono
– El emisor no espera a recibir el resultado
• Retorno
– Indica el retorno de una llamada
180
Uso de los diagramas de interacción
• Modelado del aspecto dinámico.
• Modelado del flujo de control que caracteriza el
comportamiento de un sistema:
–
–
–
–
–
casos de uso
colaboraciones
patrones
frameworks
operaciones
183
Caso de Uso (Escenario)
: Cliente
:ReceptorPedidos
:AgenteTarjeta
Credito
:GestionPedido
:AgenteFacturacion
enviarPedido
procesarTarjeta
tramitarPedido
emitirFactura
confirmarPedido
184
Caso de uso (Colaboración)
: Technical
Responsible
: Launch
Manufacturing GUI
:OrderManager
:EvaluatedOrders
o : Order
: OrderLine
: Product
: WorkOrder
selectOrder()
selectOrder(cod)
o:=find(cod)
launchManufacturing()
launchManufacturing(cod)
launch manufacturing()
*generateWO()
tpl:=getTemplate()
createWO(tpl)
185
Caso de uso de negocio
viajero: Empleado
encargado: Empleado
contable : Empleado
pagador : Empleado
solicitudPermisoViaje()
PermisoViaje()
informeGastos(unInforme)
OKgastos(unInforme)
solicitudPago(viajero)
186
Caso de uso de negocio
: Cliente
: JefeTecnico
: Comercial
darCursoPedido()
: JefeProduccion
estudiarPedido()
* analizarFabricacionProducto()
planificarFabricacion()
informarAnalisisPedido()
acceptarPedido()
187
Diagramas de Secuencia vs. Diagramas de
Colaboración
• Equivalencia semántica
• Simples para comportamientos simples.
• Si hay mucho comportamiento condicional, usar
diferentes escenarios.
• Diagramas de secuencia muestran mejor el orden en que
se ejecutan los mensajes
• Diagramas de colaboración muestran claramente los
objetos con que interactúa un determinado objeto.
188
Diagramas de Actividades
• Muestran un flujo de actividades.
• Es un caso especial de máquina de estados.
• Incluye:
– estados actividad y estados acción
– transiciones
– objetos
• Una actividad produce alguna acción que produce algún
cambio en el sistema o retorna un valor.
189
Estados Acción y Estados Actividad
• Un estado acción no se puede descomponer, representa
una computación atómica.
• Un estado actividad no es atómico, se compone de
otros estados acción y actividad.
• Al entrar se ejecuta la acción o actividad, al terminar el
flujo de control pasa a la siguiente acción o actividad.
• Misma notación
Procesar
Pedido
190
Transiciones
estado inicial
Planificar
Proceso
Asignar Tareas
transiciones
estado final
191
Bifurcación
Planificar
Proceso
[ no hay materiales ]
Volver a
Planificar
[ hay materiales ]
Asignar Tareas
192
División y Unión
Preparar conversación
división
Descomprimir
Gesticular
Mover boca
Emitir audio
unión
Limpieza
193
Solicitar Producto
Procesar Pedido
Extraer Articulos
Enviar Pedido
Recibir Producto
Pagar Factura
Facturar al cliente
Cerrar Pedido
Cliente
Ventas
Almacen
Solicitar Producto
Procesar Pedido
Extraer Articulos
Enviar Pedido
Recibir Producto
Facturar al cliente
Calles
Pagar Factura
Cerrar Pedido
Cliente
Ventas
Almacen
Solicitar Producto
Procesar Pedido
Extraer Articulos
o: Pedido
[en progreso]
Recibir Producto
Facturar al cliente
b: Factura
[impagada]
Pagar Factura
Cerrar Pedido
Enviar Pedido
o: Pedido
[completado]
: Cliente
: Comercial
: JefeTecnico
: JefeProduccion
:Catalogo
Rellenar Pedido
p:Pedido
[propuesto]
:Plantilla de
Produccion
p:Pedido
[en_evaluacion]
Cursar pedido
Analizar viabilidad
p:Pedido
[evaluado]
[ NO ]
Notificar rechazo
de pedido
:Producto
Especial
¿Viable ?
[ SI ]
Fin KO
Mucha
información
p:Pedido
[rechazado]
Notificar aceptacion
de pedido
:Plantilla de
Produccion
Ordenar fabricacion
:Orden de
Trabajo
[pendiente]
Planificar produccion
p:Pedido
[aceptado]
Fin OK
Cliente
Comercial
Jefe Tecnico
Jefe Produccion
Inicio
Introducir
Pedido
Analizar Pedido
Viable
Cursar Pedido
Denegar Pedido
Viable
[no]
[si]
Aceptar Pedido
Ordenar
Fabricacion
Planificar
Produccion
Utilidad de los diagramas de actividades
• Modelado de flujos de trabajo (workflow) como son los
procesos de negocio (business process).
• Se puede asociar a cualquier elemento de modelado,
pero lo más normal es asociarlo a una operación:
diagrama de flujo de las acciones.
199
Eventos
• Un evento es un acontecimiento que ocupa un lugar en el
tiempo y espacio.
• Un evento es un estímulo que dispara una transición en
una máquina de estados.
• Eventos externos vs. Eventos internos.
• Tipos de eventos:
–
–
–
–
Señales (excepciones)
Llamadas
Paso de tiempo
Cambio de estado
200
Señales
Modelado Excepciones
<<exception>>
Excepcion
establecerManejador()
primerManejador()
ultimoManejador()
<<exception>>
Duplicado
Conjunto
añadir()
eliminar()
<<send>>
<<exception>>
Overflow
<<send>>
<<send>>
<<exception>>
Underflow
Estados
• Un estado es una situación en la vida de un objeto en la
que satisface cierta condición, realiza alguna actividad
o espera algún evento.
• Elementos de un estado
–
–
–
–
–
Nombre
Acciones entrada/salida
Transiciones internas
Subestados
Eventos diferidos
203
Estados
acción entrada
transición interna
evento diferido
Rastreando
entry/ activarModo(enRastreo)
exit / activarModo(noRastreo)
nuevoObjetivo/rastreador.adquirir
do / seguirObjetivo
autotest / defer
acción salida
actividad
204
Transiciones
• Una transición de un estado A a un estado B, se
produce cuando se origina el evento asociado y se
satisface la condición especificada, en cuyo caso se
ejecuta la acción de salida de A, la acción de entrada a
B y la acción asociada a la transición.
• Elementos de una transición:
–
–
–
–
Estados origen y destino
Evento de disparo
Condición de guarda
Acción
205
Máquina de estados
• Especifica la secuencia de estados por las que pasa un
objeto a lo largo de su vida en respuesta a eventos, junto
con sus respuestas a esos eventos.
• Útil si las instancias de una clase tienen un comportamiento
que depende de su historia o que deben responder a eventos
externos: objetos reactivos.
• Se representa mediante un diagrama de estados.
206
After (2 sec) send c.estaActivo
ruido
Inactivo
objetivoEn(p)
[representaAmenaza]
/ t.añadirObjetivo(p)
Buscando
Configuración
Acoplamiento
Rastreando
contactar
Diagrama de Estado (Caso de Uso)
introducirProducto
Espera Venta
introducirProducto
Introduccion
Productos
Terminar Venta
manejarRespuesta
efectuar Pago Efectivo
Espera
Pago
Autorizacion
Pago
efectuar Pago Tarjeta
208
Diagrama de Estado (Caso de Uso)
cerrarPedido( (codigoCuenta, direcciónEnvio, fechaTarjeta,.. )
Establecer Cliente y
Verificar pago
enviarCargo (codigoCuenta,..)
Pago
rechazarPago
Pago No
apobado
enviarCargo (codigoCuenta,..)
pagoAprobado
Envio
pedidoEntregado
Entregado
209
Subestados secuenciales
introducirTarjeta
Activo
entry/leerTarjeta
exit/expulsarTarjeta
Inactivo
Validación
cancelar
[continuar]
mantener
Selección
Mantenimiento
Procesando
[no continuar]
Impresión
210
Subestados concurrentes
Mantenimiento
mantener
Inactivo
Pruebas
Probar
perifericos
Manejo Ordenes
AutoDiagnosis
[continuar]
Orden
Espera
Pulsar tecla
[no continuar]
211
Subestados Concurrentes
212
Contenidos
• Modelado del Comportamiento
– Diagramas de interacción
– Diagramas de actividades
– Máquinas de estado
• Modelado de la Implementación
– Diagramas de componentes
– Diagramas de despliegue
• Colaboraciones
• Formalización de UML: MOF y metamodelo
213
Componentes
• Un componente es una parte física y reemplazable de un
sistema, que conforma con un conjunto de interfaces y
proporciona su implementación.
• Modela artefactos tales como: ejecutables, bibliotecas,
tablas, ficheros, documentos,..
• Representa el empaquetamiento físico de elementos
lógicos tales como clases, interfaces,..
• Residirán en los nodos del sistema
Estereotipos: executable, library, file, table, document
214
Componentes (UML 1.5)
“Es una parte de un sistema reemplazable, modular y
desplegable que encapsula una implementación y expone
un conjunto de interfaces. Normalmente especificado por
uno o más clasificadores (clases, interfaces, tipo de
dato,..) que residen en el componente, y un conjunto de
ellos define su interfaz externa. Conforma a las interfaces
que expone al exterior, y puede ser implementado por un
fichero binario, ejecutable o script. Puede ser desplegado
sobre un nodo”
215
Propiedades de un componente
•
•
•
•
•
•
•
•
Es una unidad de despliegue independiente.
Puede ser conectado con otros componentes
En una aplicación dada existirá una única copia
Es una parte sustituible de un sistema (conforma con
una interfaz)
Realiza una función bien definida (cohesión física y
lógica)
Abarca más de una colaboración de clases
Existe en el contexto de una arquitectura bien definida.
Presupone una infraestructura tecnológica en la que se
piensa utilizar
Propiedades de un componente
Interfaz
Componente
Interfaz soportada
1..*
*
Especificación
Componente
1
*
realización
Implementación
Componente
1
*
Instancia
Componente
instancia
*
1
instalación
Instalación
Componente
217
Componentes
<<EXE>>
Explorador
agenteFraudes.dll
Realiza
agenteFraudes
politicaFraudes
busquedaPatrones
218
Componentes
explorador.java
JerarquíaElementos
arbol.java
El componente arbol.java puede ser reemplazado por otro
que proporcione la interfaz JerarquíaElementos.
219
Componentes
AsignacionAula.exe
AsignaturaUSP
Asignacion
AulaUSP
Reserva
220
Tipos de componentes
• Despliegue
– Necesarios y suficientes para formar un sistema ejecutable:
librerías dinámicas (dll), ejecutables (exe),..
• Productos del trabajo
– Permanecen al final del proceso de desarrollo: archivos código
fuentes, ficheros de datos,..
– Con ellos se crean los componentes de despliegue
• De ejecución
– Se crean durante la ejecución: objeto COM, instanciado a partir
de una dll.
221
Diagrama de Componentes
• Modelado de ejecutables y bibliotecas
• Modelado de código fuente
• Modelado de una API
222
Modelado de ejecutables
v.exe
Vwbas20.dll
vwdev20.dll
vwsrc20.dll
223
Componentes (UML 2.0)
• “Es una parte modular de un sistema que encapsula su
contenido y cuya manifestación se puede reemplazar en
su entorno”
• Define su comportamiento en términos de las interfaces
que requiere y proporciona.
• Puede actuar como un tipo.
• Es una unidad auto-contenida que encapsula el estado y
comportamiento de clasificadores (cdu, clases, interfaces)
224
Componentes (UML 2.0)
Interfaces
proporcionadas
Interfaces
requeridas
225
Componentes (UML 2.0)
Interfaz
proporcionada
Interfaz
requerida
226
Componentes (UML 2.0)
227
Componentes (UML 2.0)
228
Nodos
• Un nodo es un elemento físico que existe en tiempo de
ejecución y representa un recurso computacional que
puede tener memoria y capacidad de procesamiento.
• Los componentes se ejecutan en nodos
• Los nodos representan el despliegue físico de los
componentes.
229
Diagramas de Despliegue
• Muestra la configuración de los nodos que participan en
la ejecución y de los componentes que residen en los
nodos.
• Incluye nodos y arcos que representan conexiones físicas
entre nodos.
• Modelado de sistemas empotrados, sistemas clienteservidor, sistemas distribuidos.
230
Diagrama de Despliegue
terminal
<<10-T-Ethernet>>
servidor
Unidad
RAID
<<RS-232>>
Consola
231
Modem
<<procesador>>
servidor cache
<<procesador>
servidor cache
internet
<<red>> red local
<<procesador>
servidor
principal
<<procesador>
servidor
<<procesador>>
servidor
<<procesador>>
servidor
Contenidos
• Modelado del Comportamiento
– Diagramas de interacción
– Diagramas de actividades
– Máquinas de estado
• Modelado de la Implementación
– Diagramas de componentes
– Diagramas de despliegue
• Colaboraciones
• Formalización de UML: MOF y metamodelo
234
Colaboraciones
• Sociedad de clases, interfaces y otros elementos que
colaboran para proporcionar un comportamiento
cooperativo mayor que la suma de los comportamientos
de los elementos.
• Parte estructural (diagrama de clases) y parte de
comportamiento (diagrama de secuencia).
235
Colaboraciones
• El núcleo de la arquitectura de un sistema está formado
por un conjunto de colaboraciones que representan las
decisiones de diseño más importantes.
• Un sistema orientado a objetos bien estructurado se
compone de un conjunto relativamente pequeño de
colaboraciones.
• Modelado de un caso de uso, operación o mecanismo
(patrón o framework)
236
Casos de uso y Colaboraciones
caso de uso
colaboración
Hacer Pedido
Gestión Pedidos
realización
237
Ejercicio
Diseña una colaboración de un mecanismo Object Trading que
separa la representación de una información de su presentación
y edición; las clases que representan a los objetos información
no conocen a las clases que representan editores y viceversa.
Un mismo editor puede editar diferentes tipos de información y
una misma información puede ser editada por diferentes
editores.
El propósito del mecanismo es seleccionar un editor que
colaborará adecuadamente con el objeto información, creará un
objeto editor y lo ligará con el objeto información.
Un objeto cliente solicitará a un objeto Trader editar cierta
información.
238
Mecanismo trading (Parte estática)
Cli enteDeGestor
Trader
1..n
1..1
FactoriaEdi tor
1..1
1..n
1..1
0..n
especifi ca
necesita editar
1..1
editado con
ObjetoInformaci on
1..n
1..n
Editor
1..n
239
Mecanismo trading (Comportamiento)
: ClienteDeGestor
: Trader
: FactoriaEditor
info :
ObjetoInformacion
editar(info)
* i:= getInterfaz()
p:= soportaInterfaz(i)
[p] crearEditor(info)
<<create>>
¿Clases Cliente, Editor y ObjetoInformacion?
: Editor
240
Mecanismo trading (Comportamiento)
2: * i:= getInterfaz()
4: [p] crearEditor(info)
1: editar(info)
:
Cliente...
: Trader
3: p:= soportaInterfaz(i)
info :
ObjetoInformacion
: FactoriaEditor
5: <<create>>
: Editor
¿Clases Cliente, Editor y ObjetoInformacion?
241
Colaboraciones Parametrizadas
Modelado de patrones de diseño
Subject
Observer
Observer
Subject
Alarma
Observer
Ventana
242
Patrón de diseño (Parte Estática)
Subject
subjectState
Attach()
Detach()
Notify()
Observer
+observers
1..*
1..1
Update()
for all o in observers
{o->update}
ConcreteSubject
subjectState
getState()
setState()
+subject
ConcreteObserver
observerState
update()
observerState=
subject->getState()
243
Patrón de diseño (Parte dinámica)
: Subject
one : Observer
another : Observer
SetState( )
Notify( )
Update( )
GetState( )
Update( )
GetState( )
244
Contenidos
• Modelado del Comportamiento
– Diagramas de interacción
– Diagramas de actividades
– Máquinas de estado
• Modelado de la Implementación
– Diagramas de componentes
– Diagramas de despliegue
• Colaboraciones
• Formalización de UML: MOF y metamodelo
245
Lenguajes OMG
•
•
•
•
MOF (Meta Object Facility)
UML
OCL
AS (Action Semantics)
– Definir semántica de modelos de comportamiento
– Muy bajo nivel
– No define una sintaxis concreta
246
Lenguajes OMG
• Perfiles UML (Profiles)
– Subconjunto de UML con extensiones para un dominio
concreto
– Perfiles estándar OMG: EDOC, Corba, EAI,..
• QVT (Query, Views,Transformations)
– Lenguaje estándar para definir transformaciones
247
Metamodelo UML
• ¿Cómo se define formalmente un lenguaje de modelado?
• UML es definido con un metamodelo escrito es un
metalenguaje, MOF.
• Los cuatro niveles de modelado del OMG
–
–
–
–
Nivel MO: el sistema
Nivel M1: el modelo del sistema
Nivel M2: el modelo del modelo
Nivel M3. el modelo de M2
248
Arquitectura de cuatro capas del OMG
the MOF
MMM
a UML
model m
another
use of m
an execution
X of
program P
a particular
use of m
another UML
model m’
the CWM
MM
a Pascal
program P
Level M1
Level M0
the UML
MM
the SPEM
MM
the Pascal
grammar
Level M2
EBNF
Level M3
249
Metamodelo UML
• Nivel M0
– Sistema de pedidos por internet
• Nivel M1
– Un modelo estructural que incluye un diagrama de
clases UML
– Clase Pedido con atributos fecha y producto
• Nivel M2
– Metamodelo
– Especificación de clase o atributo UML
• Nivel M3
– Metametamodelo (Lenguaje estándar MOF)
250
Arquitectura de cuatro capas del
OMG
Metamodelo UML
ModelElement
Classifier
+type
Typed
0..n
0..1
DataType
Class
Interface
1
0..n
Feature
Parameter
252
MOF
• Proporciona conceptos y herramientas para
razonar sobre lenguajes de modelado y
transformaciones.
• Repositorio MOF
• Define un formato de intercambio para modelos de
M1 llamado XMI (XML Metadata Interchange),
basado en XML.
253
MDA (Model Driven Architecture)
• Nuevo paradigma de desarrollo de software
(noviembre, 2000):
– Desarrollo dirigido por el modelado
– Ingeniería de modelos
• Artefactos del proceso de desarrollo
– Modelo Independiente de la Plataforma, PIM
– Modelo Específico de la Plataforma, PSM
– Código
254
MDA
“MDA separa la especificación de la funcionalidad del sistema de
la especificación de la implementación de esa funcionalidad sobre
una plataforma específica, y proporciona un conjunto de guías
para estructurar especificaciones expresadas como modelos”
“ El paradigma MDA y los estándares que lo soportan permiten
especificar en un modelo la funcionalidad del sistema que debe ser
realizada sobre diferentes plataformas mediante mappings
estándar para cada plataforma, y permite que diferentes
aplicaciones puedan ser integradas relacionando explícitamente
sus modelos, permitiendo integración e interoperabilidad y
soportar la evolución del sistema conforme las tecnologías van
cambiando”
PIM y PSM
• PIM describe la funcionalidad de un sistema
software (nivel de captura de requisitos y
análisis).
• PSM incorpora al PIM los aspectos
relacionados con la plataforma (nivel de
diseño).
• Un PIM puede transformarse en uno o más
PSM para una misma aplicación
256
PIM
Transformaciones de modelos
PIM
TMM
PSM
TMC
L2
L1
Definición
Transformación
Código
L3
Definición
Transformación
258
OCL (Object Constraint Language )
• Lenguaje de especificación para escribir expresiones
sobre modelos, p.e. queries, reglas de derivación de
atributos, el cuerpo de operaciones de consulta, pre y
postcondiciones o el invariante, guardas.
• Extiende la potencia expresiva de UML y permite crear
modelos más precisos y más completos.
• Es tipado, cada expresión OCL tiene un tipo.
• Utilizado para escribir las restricciones
259
Expresiones OCL
context c : Company inv enoughEmployees:
c.numberOfEmployees > 50
context Company inv:
self.employee.select(p : Person | p.age > 50)->notEmpty()
context Person::getCurrentSpouse() : Person
pre: self.isMarried = true
body: self.mariages->select( m | m.ended = false ).spouse
260
Expresiones OCL
context Job
inv: self.employer.numberOfEmployees >= 1
inv: self.employee.age > 21
context Person::birthdayHappens()
post: age = age@pre + 1
context Company::hireEmployee(p : Person)
post: employees = employees@pre->including(p) and
stockprice() = stockprice@pre() + 10
261
Profiles UML (Perfiles)
• Mecanismo de especialización.
• Un profile (perfil) define una forma específica
de usar UML.
• Agrupación de un conjunto de estereotipos,
valores etiquetados y restricciones, con su
correspondiente notación para adaptar UML a
un dominio concreto: EJB, aplicaciones web,
CORBA, modelado del negocio,...
262
Perfiles UML
• Un perfil define un metamodelo mediante la
especialización de un subconjunto del
metamodelo de UML.
• Usados como lenguajes de un PSM
• Dos alternativas para extender UML
– Definir un perfil
– Un nuevo lenguaje definido con MOF (por ejemplo
CWM)
263
Perfiles UML
• Profile = Packages
• Estereotipos
definir nuevas meta-clases
• Valores etiquetados
definir nuevos metaatributos y nuevas asociaciones
• Definir restricciones
• Modelar gráficamente los perfiles
264
Ejemplo de definición de Perfil UML
“Modelar conexiones
entre elementos de un sistema
de información conectados
según la topología estrella”
«metamodel»
MyTopology
+localnodes
Node
*
location: String
LocalEdge
+target
*
MainNode
1
* +source
Edge
265
Ejemplo de definición de un Perfil UML
«profile»
TopologyProfile
«metaclass»
Class
«stereotype»
Node
location: String
«stereotype»
MainNode
«stereotype»
Egde
«metaclass»
Association
«stereotype»
LocalEdge
266
Ejemplo Perfil UML
«profile»
WeightsAndColors
«metaclass»
Class
«stereotype»
Colored
Estereotipos
color: Color
«metaclass»
Association
«stereotype»
Weighed
weight: Integer
«enumeration»
Color
Valores
etiquetados
green
yellow
red
blue
267
Ejemplo de definición de un Perfil UML
context MyTopology::MainNode
inv :
self.localnodes ->forAll (n : Node | n.location = self.location)
inv:
self.target ->forAll(n : MainNode | n.location <> self.location )
context UML::InfrastructureLibrary::Core::Constructs::Class
inv :
self.isStereotyped(“Node”) implies
self.connection->select(isStereotyped(“LocalEdge”))->size = 1 and
self.connection->select(isStereotyped(“Edge”))->isEmpty
context UML::InfrastructureLibrary::Core::Constructs::Association
inv :
self.isStereotyped(“LocalEdge”) implies
self.connection->select(participant.isStereotyped(“Node”) or
participant.isStereotyped(“MainNode”) ) -> forAll(n1, n2 | n1.location =
n2.location)
inv :
self.isStereotyped(“LocalEdge”) implies
self.connection-> exists(participant.isStereotyped(“MainNode”) and
multiplicity.min=1 and multiplicity.max=1)
inv :
self.isStereotyped(“Edge”) implies
self.connection->select(participant.isStereotyped(“Node”))->isEmpty and
self.connection->select(participant.isStereotyped(“MainNode”) ) ->
forAll(n1, n2 | n1.location <> n2.location)
268
Uso de un Perfil UML
«profile»
«profile»
WeightsAndColors
TopologyProfile
«apply»
«apply»
MyApplication
«Node»
«Weighed»
«MainNode»
location=”uma.es”
weight=10
location=”uma.es”
«Colored»
«Node»
Branch
1..10
1
«LocalEdge, Weighed»
«MainNode, Colored»
CentralOffice
color=red