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