El Lenguaje Unificado de Modelado, UML Análisis y Diseño del Software Curso 2004/2005 Capítulo 1...
-
Upload
odalys-salome -
Category
Documents
-
view
225 -
download
3
Transcript of El Lenguaje Unificado de Modelado, UML Análisis y Diseño del Software Curso 2004/2005 Capítulo 1...
El Lenguaje Unificado de Modelado, UML
Análisis y Diseño del Software
Curso 2004/2005
Capítulo 1
Jesús García MolinaDepartamento de Informática y Sistemas
Universidad de Murciahttp://dis.um.es/~jmolina
2
Contenidos
• Modelado del software• Presentación de UML• Modelado de Casos de Usos
– Diagramas de casos de uso• Modelado Estructural
– Diagramas de Clases
3
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
4
Contenidos
• Modelado del software• Presentación de UML• Modelado de Casos de Usos
– Diagramas de casos de uso• Modelado Estructural
– Diagramas de Clases
5
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/
6
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 OMGhttp://www.uml.org
7
Explosión de métodos OO en los noventa
OMT Coad/YourdonBooch ChampeauxJacobson Martin/OdellShlaer-Mellor OOramWirfs-Broks BONFusion OpenCatalysis
¡Y muchos más!¡Guerra
de Métodos!
8
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)
9
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
10
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.
11
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
12
¿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”
13
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.
14
Modelos de Negocio y de Software
Modelo del Negocio
Modelo Software
Empresa Sistema software
Sistema de la empresa
describe
describe
derivado de
15
Utilidad del modelado
“El modelado es la parte esencial de todas las actividades que conducen a la producción de software de calidad”
“Una empresa software con éxito es aquella que produce de manera consistente software de calidad que satisface las necesidades de los usuarios”
16
Utilidad del modelado
¿Escribimos códigodirectamente?
Sería lo ideal pero ....
.... necesitamos escribir modelos
17
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.
18
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.
19
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.
20
¿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?
21
¿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?
22
Contenidos
• Modelado del software
• Presentación de UML• Modelado de Casos de Usos
– Diagramas de casos de uso• Modelado Estructural
– Diagramas de Clases
23
UML y el modelado
• 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
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.
24
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
25
Elementos Estructurales
• Partes estáticas de un modelo
Ventana
origentamaño
abrir()cerrar()mover()dibujar()
clase
IAvisable<<Interface>>
IAvisable
Interface
ValidarTransaccioncaso de uso
26
Elementos Estructurales
Gestor Eventos
suspender()
vaciarCola()
clase activa
componente
Gestión Pedidos
colaboración
Servidor
nodo
Hola Mundo.class
27
Elementos de Comportamiento
Son las partes dinámicas de UML.
InteracciónConjunto de mensajes intercambiados entre un conjunto de objetos con un propósito particular.
mensajedibujar
28
Elementos de Comportamiento
Son las partes dinámicas de UML.
Máquina de estadosSecuencia de estados por las que pasa un objeto durantesu vida en respuesta a eventos.
estadoactivado
29
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 cualquiernaturaleza.
Tiene una naturaleza conceptual.
30
Elementos de Anotación
Son las partes explicativas de los modelos UML
NotaRetorna 0 si no existe el valor
31
Relaciones
Dependencia
Asociaciónpatron empleado
0..1 *
Generalización
Realización
32
Ejemplo
Cuenta Domiciliacion
0..n1
Ahorro Corriente
1 0..n
Operacion Periodica
IteradorCuenta
Cliente
numeroCuentadireccion
crearPedido()
Pedido Desayuno
direcciónfechahoradescuento
calcularPrecio()
11..n
+cliente
1
+pedidos
1..n
Desayuno
numero
1..n
1
+desayuno1..n
+pedido 1
Parte
cantidad
Desayuno Estandar
nombreprecioestilo
Comestible
nombrecantidadMinimaprecioformaTransporte
0..n
0..n
0..n
0..n
0..n
1..n
0..n
1..nCambio
cantidad
34
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
35
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
Modelo del Negocio
Cambiar admitidos
Registrar Curso
Hay alumnos?
no
Cerrar Curso
Aprobar Curso
Preinscripción
Matriculación
Cancelar Curso
Hay alumnos?
no
Avisar Admitidos
Crear Proyecto
SistemaAlumnoServ icio PEResponsable
Diagrama de actividades
ModeloCasos de Usos
Teleoperador Participante
Realizar puja ordinaria
Cancelar puja ordinaria
Rechazar adjudicación
Pujador
Anular anuncio de subasta
Anular edición de subasta
Crear edición de subasta
Administrador
Cerrar edición de subasta
Realizar pago de subasta ordinaria
Notif icar adjudicatario
Sistema
Diagrama de casos de
uso
ModeloEstructural
PujaOrdinaria
datosTarjetaestado
Esto representa la especif icación de un artículo.
Participante
nombreapellidosnumIDdomiciliodireccionEnv iotelef onoreputacion
PagoAnuncio
PagoCuota
Articulo
idEspeccaracteristicaspv pRecomend
EdicionSubasta
idEdicionf echaIniciof echaCierreestado
Adjudicacion
+p
+pa
+pc
+puja
ArticuloConcreto
codArticulo+articulos
+art
AnuncioSubasta
pv pRecomendpujaMinimacuotagastosEnv ioplazof ormaPagoanticipo
+es+anuncios
+as
+adjudicaciones+pujas
+as
+articulos
Diagrama de clases
Modelo deComportamiento
: Sistema
as : AnuncioSubasta
pujas : PujaOrdinaria
adj : Adjudicacion
: ArticuloConcreto
Se crean tantas adjudicaciones como pujas ganadoras haya. Cada adjudicación se asocia con un ArticuloConcreto, una puja adjudicataria y con la subasta.
: ControladorAnuncios
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).
adjudicaciones : Adjudicacion
: EdicionSubasta
int numAjudicaciones = Minimo(pujas.length(), articulos.length());
: AnuncioSubasta
5. numAdjs = calcularAdjudicaciones()
1. cerrarEdicionSubasta(es)
6. [1..numAdjs]* pg := get()
8. [1..numAdjs]* adj := crear(as, pg, a)
7. [1..numAdjs]* a:= get()
9. [1..numAdjs]* add(adj)
2. cerrar()
4. * cerrar()
3. * as := get()
Diagrama de colaboración
40
Máquina de Estado
Espera Venta Introduccion Productos
Espera Pago
introducirProducto
introducirProducto
Terminar Venta
Autorizacion Pago
efectuar Pago Efectivo
efectuar Pago Tarjeta
manejarRespuesta
Diagrama de estado
41
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.
42
Mecanismos comunes de UML
• Dicotomía clasificador /instancia
Persona
nombre
direccion
telefonoElena : Persona
: Persona
Elena
CLASE Objetos
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
UML distingue un objeto utilizando el mismo símbolo de la clase y subrayando el nombre del objeto
Casi todos lo bloque de construcción UML presentan esta dicotomía Clase/Objeto:
Ej. Caso uso e instancia de caso de uso
Componente e instancias de componentes
Nodos e instancias de nodos
43
Mecanismos comunes de UML
• Dicotomía interfaz / implementación
IOrtografia
asistente
Ortografico.dll
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
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
44
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 }
45
Ejemplo Estereotipo predefinido
Cliente<<Actor>>Cliente
ClaseClase
estereotipada
Cliente
46
Ejemplo Estereotipo Predefinido
Clase estereotipad
a
IComparator
compare()
<<Interface>>
IComparator
47
Mecanismos de extensibilidad de UML
Overflow
<<Exception>>
ColaEventos {version 3.2; autor: jgm}
añadir()
quitar()
vaciar()
{ordenado}
estereotipovalor etiquetado
restricción
48
import java.awt.Graphics;class HolaMundo extends java.applet.Applet {
public void paint (Graphics g) {g.drawString (“¡Hola, Mundo!”,10,10);
}}
¡Hola, Mundo!
HolaMundo
paint()
g.drawString
("Hola, mundo”)
Paquete Java en el cual se encuentra la Clase Graphics 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
Operación
Operación invocada por paint
ABSTRACCIONES claves para HolaMundo
( captura los aspectos básicos de la aplicación “¡HolaMundo!” pero deja fuera varias cosas)
parámetro
49
Diagrama de Clases
Applet
HolaMundo
paint()
Graphics(from awt)
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
Applet
Panel(from awt)
Container(from awt)
Component(from awt)
HolaMundo
paint()
Graphics(from awt)
ImageObserver
imageUpdate()
(from image)
Jerarquía de Herencia de HolaMundo
Al revisar las bibliotecas de Java para Applet y Graphics se verá que son parte de una
jerarquía mayor
Component implementa a ImageObserver
51
Organización en Paquetes
HolaMundo
paint()
java
(from Logical View)
Organización de paquetes de HolaMundo
52
Organización en Paquetes
java
lang
awt
AppletHolaMundo
53
Diagrama de Secuencia
: Toolkit : Thread : ComponentPeer target : HolaMundo
1. run()1.1. callbackLoop()
1.1.1. handleExpose()1.1.1.1. paint()
Mecanismos para Dibujar ( se establece el orden de los eventos)
La figura muestra la colaboración de varios objetos , incluida una instancia de la clase HolaMundo. Los objetos son parte del entorno Java
activación
Operaciones invocadas
Nombre del objeto
54
Diagrama de Componentes
HolaMundo.classhola.java
hola.html hola.jpg
Componente ejecutable
Cada uno de los íconos de esta figura representa un elemento UML en la vista de implementación del sistema
Código fuente de la clase HolaMundoPágina Web
55
Contenidos
• Modelado del software
• Presentación de UML
• Modelado de Casos de Usos– Diagramas de casos de uso
• Modelado Estructural– Diagramas de Clases
56
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.
Emisor Centralita Receptor
listo( )
tono
marcar_numero
tono_sonando
timbre_sonando
telefono_cogido
para_tono
para_timbre
ESCENARIO
• Casos de uso son ideados por Jacobson a principios de los noventa• Se inspira en los escenarios utilizados para describir procesos
58
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]
59
Ejemplo Caso de Uso
actor caso de uso
asociacion
Responsable Prestamos
Gestionar Préstamos
60
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
61
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.
62
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
63
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.
64
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.
65
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.
66
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.
67
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.
: Cajero
:Sistema
introducirItem(upc,cantidad)
finalizarVenta()
hacerPago(cantidad)
Cajero Comprar Articulos Cliente
69
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.
Ejemplo diagrama de casos de uso
Rebajar Mínimo
Registrar curso
Cerrar curso
Responsable
Aprobar curso Servicio CPE
Servicio ContabilidadCrear proyecto
Matriculación
Realizar preinscripción
AlumnoAvisar admitidos
Cancelar curso
Fin matriculacion
Sistema
Ejemplo diagrama de casos de uso
Realizar preinscripción Gestión ExpedientesAlumno
Matriculación Entidad Bancaria
Actores Secundar
io
Actor Principal
72
Ejemplo diagrama de casos de uso
Reservar Libro
Prestamo Libro
Devolver libro
Socio
Extender Prestamo
Prestamo revista
Profesor
Devolver revista
BibliotecarioActualizar catalogo
SocioConsultar
73
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).
74
Casos de uso y Colaboraciones
Hacer Pedido
Gestión Pedidos
caso de uso
colaboración
realización
75
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”
76
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
77
Ejemplo
Generalización
Comprobar clave
Examinar retina
Validar Usuario
Hacer Pedido
Seguir Pedido
(establecerprioridad)
Hacer Pedido Urgente
«extend»
Relación de extensión
«include»
«include»
Relación deinclusión
78
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”.
79
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.
80
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.
81
Plantilla para casos de uso (D. Coleman)
Caso de Uso identificador / historia
Descripciónobjetivo a conseguir
Actores lista de actores
Asunciones condiciones que deben cumplirse
Pasos interacciones entre los actores y el sistema necesarias para obtener el objetivo
Variaciones (opcional) cualquier variación en los pasos
No-funcional (opcional) lista requisitos no funcionales
Cuestiones lista de cuestiones que permanecen por resolver
82
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ón3. 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 fallo4. Operador cierra sesión
83
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 ...
84
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
85
¿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.
86
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 procesosii) 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
87
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
88
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.
89
Granularidad (A. Cockburn)
• Ambito– Sistema
• Funcionalidad requerida del sistema
– Organización• Objetivo estratégico para la empresa, de mucho valor
• Especificidad– Objetivo del usuario cdu– Colecciones de objetivos de usuario cdu negocio– Subfunciones inclusión de cdu
Caso de uso del negocio
Caso de uso
90
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
91
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)
92
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
93
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”
94
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
95
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 no-funcionales.
96
• 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.
Referencias
97
Contenidos
• Modelado del software
• Presentación de UML• Modelado de Casos de Usos
– Diagramas de casos de uso
• Modelado Estructural– Diagramas de Clases
98
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.
99
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
Modelo Conceptual
Cliente
numeroCuentadireccion
crearPedido()
Pedido Desayuno
direcciónfechahoradescuento
calcularPrecio()
11..n
+cliente
1
+pedidos
1..n
Desayuno
numero
1..n
1
+desayuno1..n
+pedido 1
Parte
cantidad
Desayuno Estandar
nombreprecioestilo
Comestible
nombrecantidadMinimaprecioformaTransporte
0..n
0..n
0..n
0..n
0..n
1..n
0..n
1..nCambio
cantidad
101
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)
Cuenta Domiciliacion
0..n1
Ahorro Corriente
1 0..n
Operacion Periodica
IteradorCuentaModelo de
diseño
¿Modelo Conceptual o de Análisis?
PujaOrdinaria
datosTarjetaestado
Esto representa la especif icación de un artículo.
Participante
nombreapellidosnumIDdomiciliodireccionEnv iotelef onoreputacion
PagoAnuncio
PagoCuota
Articulo
idEspeccaracteristicaspv pRecomend
EdicionSubasta
idEdicionf echaIniciof echaCierreestado
Adjudicacion
+p
+pa
+pc
+puja
ArticuloConcreto
codArticulo+articulos
+art
AnuncioSubasta
pv pRecomendpujaMinimacuotagastosEnv ioplazof ormaPagoanticipo
+es+anuncios
+as
+adjudicaciones+pujas
+as
+articulos
Modelo deComportamiento
: Sistema
as : AnuncioSubasta
pujas : PujaOrdinaria
adj : Adjudicacion
: ArticuloConcreto
Se crean tantas adjudicaciones como pujas ganadoras haya. Cada adjudicación se asocia con un ArticuloConcreto, una puja adjudicataria y con la subasta.
: ControladorAnuncios
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).
adjudicaciones : Adjudicacion
: EdicionSubasta
int numAjudicaciones = Minimo(pujas.length(), articulos.length());
: AnuncioSubasta
5. numAdjs = calcularAdjudicaciones()
1. cerrarEdicionSubasta(es)
6. [1..numAdjs]* pg := get()
8. [1..numAdjs]* adj := crear(as, pg, a)
7. [1..numAdjs]* a:= get()
9. [1..numAdjs]* add(adj)
2. cerrar()
4. * cerrar()
3. * as := get()
105
Colaboración (parte estática)
Pedido
numerotipoPagoestadocaducidad
Usuario
nombrenifemailloginclave
0..n1 0..n1
CarroCompra
precioitems
1
1
1
1
ItemCarro
unidadestotal
1..n1 1..n1
ItemPedido
unidadestotal
1..n1 1..n1
Producto
nombredescripcionprecio10..n 10..n
1
0..n0..n
1
106
Colaboración (parte dinámica)
: Usuario
: CarroCompras
: ItemCarro
i : ItemCarro
: Producto
: MostrarProductos : Añadir
: CatalagoProductos
11: recalcularTotal()
1: añadirItem(codigo)
5: i:=getItemCarro(codigo)
10: [nuevoItem]put(codigo,i)
6: [!nuevoItem]incrementarUnidades()
9: [nuevoItem]i:=creaItem(p)7: [nuevoItem]p:=get(codigo)
2: añadirItem(codigo) 3: [primer producto] crear()
4: añadirItem(codigo)
8: [nuevoItem]p:=buscar(codigo)
107
Patrón de diseño (Parte Estática)
Observer
Update()
Subject
subjectState
Attach()
Detach()
Notify()
1..*1..1 1..*
+observers
1..1
ConcreteSubject
subjectState
getState()
setState()
ConcreteObserver
observerState
update()
+subject
observerState=
subject.getState()
for all o in observers
{o.update()}
108
Patrón de diseño (Parte dinámica)
: Subject o1 : Observer o2 : Observer
1. setState()
1.1. notify()
1.1.1. update()
1.1.2. update()
109
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.
110
visibilidad
nombre: nombre del atributo
tipo: tipo del atributo
valor_inicial: valor inicial o por defecto
[visibilidad] nombre [: tipo] [= valor_inicial ] [{propiedades}]
+ = pública # = protegida - = privada
propiedades: {frozen} {addOnly}
Atributos
111
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”
Cliente
nombre : String
112
visibilidad
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}
+ = pública # = protegida - = privada
[visibilidad] nombre [(lista_parametros)] [: tipo_retorno] [{propiedades}]
Operaciones
113
Operaciones
Atributos
Operaciones
Cuenta
ultimoCodigocodigoclientesaldoultimasOperaciones
getSaldo()getUltimasOperaciones()nuevoCodigo()
114
Clases Parametrizadas
«bind» <Empleado>
G
Tabla
countcapacity
put(G)item() : G
EmpleadosTabla<Cliente>
ClaseParametrizada
Instanciación
115
Otras propiedades
• Clases y métodos diferidos• Multiplicidad• Variables y métodos de clase
Figura
rotar()trasladar()
visualizar()
<<abstract>>Cuenta
ultimoCodigocodigoclientesaldoultimasOperaciones
getSaldo()getUltimasOperaciones()nuevoCodigo()
116
Clases Estereotipadas
MetaclaseCuenta
<<metaclass>>
FueraRango
<<exception>>
Clases y valores etiquetados
Cuenta {autor: jgm, version: 2.0}
ultimoCodigocodigoclientesaldoultimasOperaciones
getSaldo()getUltimasOperaciones()nuevoCodigo()
117
Relaciones
• DependenciaUn cambio en la especificación de un elemento afecta a otro
Windowpositionparentchildrensize
open()close()move()resize()
Clock
PlanDelCurso
añadir(c : Curso)eliminar(c : Curso)
Curso
Nodo Lista
<<friend>>
118
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
119
Relaciones
• Generalización– “Es-un-tipo-de”
Window
TextWindow BoxDialog
Cuenta
CuentaAhorro CuentaCorriente
120
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
121
Asociación
• Asociación– Relación estructural que especifica que los objetos de un tipo
están conectados con los de otro.
Persona Empresa
*1..*
+patron+empleado
1..* *
Curso Profesor1..** 1..**
impartido
122
Asociaciones
• Agregación– Caso especial de asociación– Relación estructural parte-de
Empresa
1..1
*
Departamento
1..1
*
123
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
124
Asociaciones
• Especificación:
class Pedido {public Cliente getCliente();public Set getLineaPedido();... }
• Implementación
class Pedido {private Cliente _cliente;private HashSet _lineasPedido; …}
125
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
Curso Profesor
1..** 1..**
impartido
126
Visibilidad
• Pública: +propietario
• Protegida: #propietario
• Privada: -propietario
GrupoUsuarios Usuario
**
Clave
*1..1** *
-clave+propietario
1..1
127
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”
Pedido
numerotipoPagoestadocaducidad 1
producto
1
ItemPedido
unidadestotal
128
Asociaciones calificadas
Class Pedido {
private Hashtable _lineasPedido;
public ItemPedido getItemPedido(Producto unProducto);
public void addItemPedido (Integer cantidad, Producto elProducto);
…
}
129
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
130
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.
131
Composición
Marco
Ventana
1..1
*
1..1
*
agregado /todo
parte
composición
132
Composición
POLIGONO
1
Relleno:Diseño
Punto
{ordered} 3..*
1
Punto
Poligono
1
3..nDiseño
colortextura
11 1
3..n {ordered}
133
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.
134
Ejemplo de clase asociación
Empleado
id0..n0..n
HistoriaSalario
iniciofinsalario
NivelSalario
minmaxiniciofinnameid
0..n0..n
135
Ejemplo de clase asociación
Persona Compañia
*1..*
Trabajo
descripcionfechaContratosalario
+patron
*
+empleado
1..*
136
Asociaciones derivadas
Asociación
Derivada
Pedido
numerotipoPagoestadocaducidad
Cliente
nombredireccionemail
0..n
1
Factura
numerofechatotal0..11
0..n
1
1
0..n
1 0..1
/facturaCliente
1
0..n
137
Asociaciones derivadas
Asignatura
Profesor
imparte
Estudianterecibe
/enseña
Asociación
Derivada
138
Restricciones para Asociaciones
Empresa
Cuenta
Persona
{or}
Departamento
Persona
*
1..11..*
* *
+Director
1..1+miembro 1..*
*
{subconjunto}
139
Restricciones para Asociaciones
PersonaCompañia* 0..1
empleado*
0..1
{Persona.patrón=
Persona.jefe.patrón }
patrón
jefe
operario
140
Realización
Relación entre clasificadores, un clasificador especificaun contrato que otro clasificador garantiza que cumplirá.
IPila
push()pop()top()
<<Interface>>
Pila
IPila
Pila
141
Clases Abstractas e Interfaces
DataInput(from io)
DataInputStream(from io)
FilterInputStream(from io)
InputStream(from io)
InputStreamReader(from io)
Clase Abstracta
Interfaz
142
Clases Abstractas e Interfaces
DataInput(from io)
<<Interface>>
DataInputStream(from io)
FilterInputStream(from io)
InputStream(from io)
InputStreamReader(from io)
Interfaz
143
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
144
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.
Servidor
+ BaseDeDatos+ ServicioDeRegistro
Cliente
+ FormularioPedido+ FormularioDeSeguimiento- Pedido
GUI
+ Ventana+ Formulario# GestorEventos
Politicas
+ ReglasPedidos+ GUI:Ventana
<<import>>
<<import>>
146
Generalización de Paquetes
WindowsGUI
+ GUI:Ventana+ Formulario# GUI:GestorEventos+ VBForm
GUI
+ Ventana+ Formulario# GestorEventos
MacGUI
148
Paquetes
• Un paquete bien estructurado debe:– ser cohesivo– estar poco acoplado– pocos anidamientos– conjunto equilibrado de elementos
149
Uso de los paquetes
Struts<<framework>>
Diseño<<model>>
Pedidos<<subsystem>>
Servicios Básicos
<<layer>>
150
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.
151
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”
152
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.
153
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.
156
Vistas UML
Vista de DiseñoVista de Implementacion
Vista de Procesos Vista de Despliegue
Vista de casos de uso
vocabulariofuncionalidad
ensambladogestion conf.
topologíaentregadistribucióninstalación
Funcionamientoescalabilidadrendimiento
comportamiento
Modelo de la Arquitectura de un sistema
157
Vistas UML
Vista de DiseñoVista de Implementacion
Vista de Procesos Vista de Despliegue
Vista de casos de uso
clasesinterfacescolaboraciones
componentes
nodosclases activas
casos de uso
158
Vistas UML
Vista de DiseñoVista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
Diagramas de claseDiagramas de interacciónDiagramas de estado
Diagramas de componentesDiagrama de interacciónDiagramas de estado
Diagramas de despliegueDiagrama de interacciónDiagramas de estado
Diagramas de casos de uso
Diagramas de claseDiagramas de interacciónDiagramas de estado
159
Diagrama de Objetos
: Cuenta
: Tarjeta : Transaccion : Cliente : CodigoCuenta
: Perfil
Modelan las instancias de los elementos contenidos en los diagramas de clases
Muestra un conjunto de objetos y sus relaciones en un momento concreto
Se utilizan para modelar la vista de diseño estática o la vista de procesos estática de un sistema
Enlace
Objeto
Multiobjeto (colección de objetos anónimos)
160
Diagrama de Objetos
: Curso
: Profesor
: Alumno
: Expediente : Departamento
director : Profesor : GrupoInvestigacion
: Tarjeta : Tarjeta
161
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
162
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
Persona
calcularCompensacion()asignar()
Empresa
*1..*
+patron+empleado
*1..*
p:Persona :Empresa
1: asignar(desarrollo)
mensaje
enlace
163
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.
164
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
165
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
166
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)
167
Mensajes
• Simple: metodo(arg) • Creación de objetos: <<create>>• Condición: [cond] metodo()• Iteración: * metodo() • Asignación: v:= getObjeto()
• Numeración jerárquica o secuencial o ninguna
168
Diagramas de Secuencia
: InterfacePedido
: ControladorPedido
: Pedido : LineaPedido : Item
: ItemPedido
: ItemEntregado
1: preparar()2: preparar() 3: * preparar()
4: hayStock:=check()
5: [hayStock] eliminar()
6: pedir?:= necesarioPedir()
7: [pedir?] <<create>>8:
9: [hayStock] <<create>>
169
Diagramas de Colaboración
: InterfacePedido
: ControladorPedido : Pedido
: LineaPedido
: Item
: ItemPedido :
ItemEntregado
1: preparar() 2: preparar()
3: * preparar()
4: hayStock:=check()5: [hayStock] eliminar()
6: pedir?:= necesarioPedir()
7: [pedir?] <<create>> 8: [hayStock] <<create>>
170
Diagrama de Secuencia
c:Cliente
:Transaccion
p:ProxyODBC
<<create>>
establecerAcciones
establecerValores
exito
<<destroy>>
establecerValorestiempoLínea de vida
Foco de control
171
Diagrama de Colaboración
c:Cliente :Transaccion
p:ProxyODBC
1: <<create>>2: establecerAcciones
3: establecerValores
5: exito
4: establecerValores
6: <<destroy>>
172
Diagrama de Secuencia
c:Cliente
:AgenteBilletes
a:AyudaPlanificacion
<<create>>
establecerItinerario(i)
calcularRuta
ruta
<<destroy>>
notificar
173
Diagrama de Colaboración
a:AyudaPlanificacion
c:Cliente :AgenteBilletes
3: calcularRuta
1: <<create>>2: establecerItinerario(i)
5: <<destroy>>
4: ruta
6: notificar
174
Numeración secuencial
: A : B : C
: D
1: m1()
2: m2()
3: m3()
4: m4()
Confusión en el flujo de ejecución
175
Numeración jerárquica
: A : B : C : D
1. m1()
1.1. m2()
1.2. m3()
1.3. m4()
176
Numeración jerárquica
: A : B : C
: D
1. m1( )
1.1. m2( )
1.3. m4( )
1.2. m3( )
177
Numeración jerárquica
: A : B : C : D
1. m1( )1.1. m2( )
1.2. m4( )
1.1.1. m3( )
178
Numeración jerárquica
: A : B : C
: D
1. m1( )
1.1. m2( )
1.1.1. m3( )
1.2. m4( )
179
Numeración jerárquica
: A : B : C
: D
1. m1()
1.1. m2()
1.2. m3()
1.3. m4()
180
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
183
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
184
Caso de Uso (Escenario)
: Cliente:ReceptorPedidos :AgenteTarjeta
Credito:GestionPedido :AgenteFacturacion
enviarPedido
procesarTarjeta
tramitarPedido
confirmarPedido
emitirFactura
185
:OrderManager: TechnicalResponsible
: LaunchManufacturing GUI
:EvaluatedOrders o : Order : Product : WorkOrder : OrderLine
selectOrder()selectOrder(cod)
o:=find(cod)
launchManufacturing()launchManufacturing(cod)
launch manufacturing()*generateWO()
tpl:=getTemplate()
createWO(tpl)
Caso de uso (Colaboración)
186
Caso de uso de negocio
viajero: Empleado encargado: Empleado contable : Empleado pagador : Empleado
solicitudPermisoViaje()
PermisoViaje()
informeGastos(unInforme)
OKgastos(unInforme)
solicitudPago(viajero)
187
Caso de uso de negocio
: JefeTecnico: Cliente : Comercial : JefeProduccion
darCursoPedido()estudiarPedido()
* analizarFabricacionProducto()
informarAnalisisPedido()
planificarFabricacion()
acceptarPedido()
188
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.
189
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.
190
Estados Acción y Estados Actividad
Procesar Pedido
• 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
191
Transiciones
estado final
estado inicial
transiciones
Planificar Proceso
Asignar Tareas
192
Bifurcación
[ hay materiales ]
Planificar Proceso
Asignar Tareas
Volver a Planificar
[ no hay materiales ]
193
División y Unión
Preparar conversación
Limpieza
Emitir audio
Gesticular
Descomprimir
Mover boca
división
unión
Solicitar Producto
Procesar PedidoExtraer Articulos
Enviar Pedido
Recibir Producto Facturar al cliente
Pagar FacturaCerrar Pedido
Cliente Ventas Almacen
Solicitar Producto
Procesar PedidoExtraer Articulos
Enviar Pedido
Recibir Producto Facturar al cliente
Pagar FacturaCerrar Pedido
Calles
Cliente Ventas Almacen
Solicitar Producto
Procesar PedidoExtraer Articulos
Enviar Pedido
Recibir Producto Facturar al cliente
Pagar FacturaCerrar Pedido
o: Pedido[en progreso]
o: Pedido[completado]
b: Factura[impagada]
Rellenar Pedido
Cursar pedido
Notificar aceptacionde pedido
Fin OK
Notificar rechazode pedido
Fin KO
Analizar viabilidad
¿Viable ?[ NO ]
Planificar produccion
[ SI ]
: JefeProduccion: JefeTecnico : Comercial : Cliente
p:Pedido[propuesto]
p:Pedido[rechazado]
p:Pedido[aceptado]
:Orden deTrabajo
[pendiente]
:Plantilla deProduccion
:Catalogo
:ProductoEspecial
p:Pedido[en_evaluacion]
p:Pedido[evaluado]
:Plantilla deProduccion
Ordenar fabricacion
Mucha información
Inicio
Introducir Pedido
Cursar Pedido
Denegar Pedido
Aceptar Pedido
Analizar Pedido Viable
Viable
[no]
Ordenar Fabricacion
Planificar Produccion
[si]
Jefe ProduccionJefe TecnicoComercialCliente
199
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.
200
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
Señales
Modelado Excepciones
Conjunto
añadir()eliminar()
Excepcion
establecerManejador()primerManejador()ultimoManejador()
<<exception>>
Duplicado<<exception>>
Overflow<<exception>>
Underflow<<exception>>
<<send>><<send>> <<send>>
203
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
204
Estados
Rastreandoentry/ activarModo(enRastreo)exit / activarModo(noRastreo)nuevoObjetivo/rastreador.adquirirdo / seguirObjetivoautotest / defer
acción entradaacción salida
transición interna
evento diferido
acción entrada
actividad
205
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
206
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.
Inactivo
Rastreando
Buscando Configuración
Acoplamiento
ruido
After (2 sec) send c.estaActivo
contactar
objetivoEn(p)[representaAmenaza] / t.añadirObjetivo(p)
208
Diagrama de Estado (Caso de Uso)
Espera Venta Introduccion Productos
Espera Pago
introducirProducto
introducirProducto
Terminar Venta
Autorizacion Pago
efectuar Pago Efectivo
efectuar Pago Tarjeta
manejarRespuesta
209
Diagrama de Estado (Caso de Uso)
Establecer Cliente y Verificar pago
cerrarPedido( (codigoCuenta, direcciónEnvio, fechaTarjeta,.. )
Pago
Envio
enviarCargo (codigoCuenta,..)
Pago No apobado
rechazarPago
enviarCargo (codigoCuenta,..)
Entregado
pagoAprobado
pedidoEntregado
210
Subestados secuenciales
Selección
Mantenimiento
Activo
Validación
Inactivo
Procesando
Impresión
mantener
introducirTarjeta
cancelar[continuar]
[no continuar]
entry/leerTarjetaexit/expulsarTarjeta
211
Subestados concurrentes
Mantenimiento
Probarperifericos
InactivoAutoDiagnosis
mantener
[continuar]
[no continuar]
Pruebas
Espera Orden
Manejo Ordenes
Pulsar tecla
212
Subestados Concurrentes
213
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
214
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
215
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”
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
217
Propiedades de un componente
InterfazComponente
EspecificaciónComponente
ImplementaciónComponente
InstalaciónComponente
InstanciaComponente
1..* *1
*
1
*
1
*
Interfaz soportada
realización
instalación
instancia
218
Componentes
agenteFraudes.dll
Realiza
agenteFraudespoliticaFraudesbusquedaPatrones
Explorador<<EXE>>
219
Componentes
explorador.java arbol.java
El componente arbol.java puede ser reemplazado por otroque proporcione la interfaz JerarquíaElementos.
JerarquíaElementos
220
Componentes
AsignacionAula.exe
AsignaturaUSP
AulaUSP
Reserva
Asignacion
221
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.
222
Diagrama de Componentes
• Modelado de ejecutables y bibliotecas
• Modelado de código fuente
• Modelado de una API
223
Modelado de ejecutables
v.exe
Vwbas20.dll vwdev20.dllvwsrc20.dll
224
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)
225
Componentes (UML 2.0)
Interfaces proporcionadas
Interfaces requeridas
226
Componentes (UML 2.0)
Interfaz proporcionada
Interfaz requerida
227
Componentes (UML 2.0)
228
Componentes (UML 2.0)
229
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.
230
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 cliente-servidor, sistemas distribuidos.
231
Diagrama de Despliegue
servidor Unidad RAID
Consola
<<RS-232>>
terminal
<<10-T-Ethernet>>
servidor cache<<procesador>
servidor cache<<procesador>>
servidor principal
<<procesador>servidor
<<procesador>servidor
<<procesador>>servidor
<<procesador>>
<<red>> red local
internet
Modem
234
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
235
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).
236
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)
237
Casos de uso y Colaboraciones
Hacer Pedido
Gestión Pedidos
caso de uso
colaboración
realización
238
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.
239
Mecanismo trading (Parte estática)
FactoriaEdi tor
Editor
1..1
1..1
1..1
1..1
especifica
Trader
1..n1..1 1..n1..1
ObjetoInformacion
1..n1..n 1..n1..n
editado con
ClienteDeGestor
1..11..n 1..11..n
1..n
0..n
1..n
0..n
necesita editar
240
Mecanismo trading (Comportamiento)
: ClienteDeGestor : Trader : FactoriaEditor info : ObjetoInformacion
: Editor
editar(info)* i:= getInterfaz()
p:= soportaInterfaz(i)
[p] crearEditor(info)<<create>>
¿Clases Cliente, Editor y ObjetoInformacion?
241
Mecanismo trading (Comportamiento)
: Cliente... : Trader : FactoriaEditor
info : ObjetoInformacion : Editor
1: edi tar(info)
2: * i := getInterfaz()4: [p] crearEdi tor(info)
3: p:= soportaInterfaz(i )5: <<create>>
¿Clases Cliente, Editor y ObjetoInformacion?
242
Colaboraciones Parametrizadas
Observer
SubjectObserver
Alarma Ventana
Subject Observer
Modelado de patrones de diseño
243
Patrón de diseño (Parte Estática)
Observer
Update()
Subject
subjectState
Attach()Detach()Notify()
1..*1..1 1..*
+observers
1..1
ConcreteSubject
subjectState
getState()setState()
ConcreteObserver
observerState
update()
+subject
observerState= subject->getState()
for all o in observers {o->update}
244
Patrón de diseño (Parte dinámica)
: Subject one : Observer
Update( )
SetState( )
Notify( )
GetState( )
another : Observer
Update( )
GetState( )
245
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
246
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
247
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
248
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
249
Arquitectura de cuatro capas del OMG
the MOFMMM
the UMLMM
a UMLmodel m
a particularuse of m
the SPEMMM
the CWMMM
another UMLmodel m’
anotheruse of m
Level M3
Level M2
Level M1
Level M0
EBN
Fth
e Pascalgram
mar
a Pascalprogram
Pan ex
ecutionX
of program
P
250
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)
Arq
uite
ctura
de cu
atro
cap
as
del O
MG
252
Metamodelo UML
ModelElement
DataType Interface
TypedClassifier
0..1 0..n
+type
0..1 0..n
Parameter
Class
Feature
0..n
1
0..n
1
253
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.
254
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
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”
256
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
PIM
Cliente
numeroCuentadireccion
crearPedido()
Pedido Desayuno
direcciónfechahoradescuento
calcularPrecio()
11..n
+cliente
1
+pedidos
1..n
Desayuno
numero
1..n
1
+desayuno1..n
+pedido 1
Parte
cantidad
Desayuno Estandar
nombreprecioestilo
Comestible
nombrecantidadMinimaprecioformaTransporte
0..n
0..n
0..n
0..n
0..n
1..n
0..n
1..nCambio
cantidad
258
Transformaciones de modelos
PIM PSM CódigoTMM TMC
Definición Transformación
Definición Transformación
L3L2L1
259
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
260
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() : Personpre: self.isMarried = truebody: self.mariages->select( m | m.ended = false ).spouse
261
Expresiones OCL
context Jobinv: self.employer.numberOfEmployees >= 1inv: self.employee.age > 21
context Person::birthdayHappens()post: age = age@pre + 1
context Company::hireEmployee(p : Person)post: employees = employees@pre->including(p) andstockprice() = stockprice@pre() + 10
262
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,...
263
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)
264
Perfiles UML
• Profile = Packages• Estereotipos definir nuevas meta-clases• Valores etiquetados definir nuevos meta-
atributos y nuevas asociaciones• Definir restricciones• Modelar gráficamente los perfiles
265
Ejemplo de definición de Perfil UML
Node *
+localnodes
1 *
MainNode
*
+target
+source
Edge
«metamodel» MyTopology
LocalEdge
location: String
“Modelar conexiones entre elementos de un sistema de información conectadossegún la topología estrella”
266
Ejemplo de definición de un Perfil UML
«profile» TopologyProfile
«stereotype» Node
«stereotype» MainNode
location: String
«metaclass» Class
«metaclass» Association
«stereotype» Egde
«stereotype» LocalEdge
267
Ejemplo Perfil UML
«profile» WeightsAndColors
«stereotype» Colored
color: Color
«metaclass» Class
«metaclass» Association
«enumeration» Color
«stereotype» Weighed
weight: Integer
green yellow red blue
Estereotipos
Valores etiquetados
268
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 andself.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)
Uso de un Perfil UML
«profile»
WeightsAndColors «profile»
TopologyProfile
MyApplication
«apply» «apply»
«Node» location=”uma.es”
«MainNode, Colored» CentralOffice
«Node» Branch
«Weighed» weight=10
«LocalEdge, Weighed»
1..10 1
«MainNode» location=”uma.es” «Colored» color=red