Departamento de Informtica y Sistemas

Ingeniera en Informtica Anlisis y Diseo de Software

Tema 1. El Lenguaje Unificado de Modelado, UML

Jess Garca Molina Departamento de Informtica y Sistemas Universidad de Murcia http://dis.um.es/~jmolina

Contenidos

Introduccin al modelado del software Presentacin de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases

Paquetes

Contenidos

Modelado del Comportamiento

Diagramas de interaccin Diagramas de actividades Mquinas de estado

Componentes Modelado de la Implementacin

Artefactos y despliegue Diagramas de despliegue

Colaboraciones UML, Metamodelado y MDA

Bibliografa

G. Booch, J. Rumbaugh, I. Jacobson, El lenguaje unificado de modelado, 2 Edicin, Addison-Wesley, 2006. Craig Larman, UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado, PrenticeHall, 2003. Jim Arlow, Ila Neustadt, UML 2, Anaya Multimedia, 2006. http://www.uml.org/

Contenidos

Introduccin al modelado del software

Presentacin de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases

Paquetes

El lenguaje unificado de modelado, UML

A mediados de los noventa existan muchos mtodos de anlisis y diseo OO

Mismos conceptos con distinta notacin Mucha confusin.

En 1994, Booch, Rumbaugh y Jacobson deciden unificar las notaciones de sus mtodos: Unified Modeling Language (UML) Proceso de estandarizacin promovido por el OMG
http://www.omg.org

Explosin de mtodos OO en los noventa

OMT Booch Jacobson Shlaer-Mellor Wirfs-Broks Fusion Catalysis Coad/Yourdon Champeaux Martin/Odell OOram BON Open
Guerra de mtodos!

Y muchos ms!

Evolucin UML

Grady Booch y Jim Rumbaugh comenzaron a unificar sus mtodos (Octubre, 1994). Borrador de UML (versin 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 peticin 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)

OMG (Object Management Group)

Propone, elabora y mantiene especificaciones para aplicaciones empresariales distribuidas e interoperables. Estndares OMG

Corba UML y perfiles UML OCL MOF, XMI MDA

Ventajas de la unificacin

Reunir los puntos fuertes de cada mtodo Idear nuevas mejoras Proporcionar estabilidad al mercado

Proyectos basados en un lenguaje maduro Aparicin de potentes herramientas

Eliminar confusin en los usuarios

Objetivos en el diseo de UML

Modelar sistemas, desde los requisitos hasta los artefactos ejecutables desplegados en nodos, utilizando tcnicas OO. Cubrir las cuestiones relacionadas con el tamao propias de los sistemas complejos y crticos. Lenguaje utilizable por las personas y las mquinas Encontrar equilibrio entre expresividad y simplicidad.

Modelado del Software

El modelado es el anlisis y diseo de aplicaciones software antes de escribir el cdigo. 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 favorecen la comunicacin permiten documentar las decisiones permiten una generacin automtica de cdigo

Modelos en otras reas

Qu es un modelo?
Un modelo es una simplificacin de la realidad Un modelo es resultado de un proceso de abstraccin y ayuda a comprender y razonar sobre una realidad.

Qu es un modelo software?
Es una descripcin de un aspecto del sistema,
escrita en un lenguaje bien definido.

El lenguaje unificado de modelado, UML

UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos (modelos) de un sistema software, desde una perspectiva orientada a objetos.
Of the 14 million or so software professionals around the world, many know of the existence of the UML yet only a modest percent use the UML on a daily basis (Grady Booch, 2002)

Utilidad del modelado

Por qu no escribo cdigo directamente?

Sera lo ideal pero ....

.... necesitamos escribir modelos, aunque la mayora de desarrolladores todava no practican el modelado

Modelo de Estructural

1. cerrarEdicionSubasta(es) : ControladorAnuncios : Sistema 2. cerrar()

int numAjudicaciones = Minimo(pujas.length(), articulos.length());

5. numAdjs = calcularAdjudicaciones()

9. [1..numAdjs]* add(adj) 4. * cerrar() : AnuncioSubasta 3. * as := get() : EdicionSubasta as : AnuncioSubasta adjudicaciones : Adjudicacion

8. [1..numAdjs]* adj := crear(as, pg, a) 6. [1..numAdjs]* pg := get() pujas : PujaOrdinaria 7. [1..numAdjs]* a:= get()

Se recorre la coleccin de pujas obteniendo las pujas ganadoras (consideramos que la coleccin est ordenada de mayor a menor valor de puja).

adj : Adjudicacion : ArticuloConcreto Se crean tantas adjudicaciones como pujas ganadoras haya. Cada adjudicacin se asocia con un ArticuloConcreto, una puja adjudicataria y con la subasta.

Modelo de Comportamiento

Utilidad del modelado

Hay estructuras que no son visibles en los programas. Ayuda a razonar sobre el cmo se implementa. Se facilita la comunicacin entre el equipo al existir un lenguaje comn. Se dispone de documentacin que trasciende al proyecto. Generacin de cdigo a partir de modelos

Ha surgido un nuevo paradigma de desarrollo de software a partir de modelos (p.e. MDA de OMG)

Utilidad del modelado

Los modelos:

visualizan cmo es o queremos que sea el sistema especifican la estructura y comportamiento del sistema. guan la construccin del sistema. documentan las decisiones.

Por qu la mayora de empresas no practican el modelado?

Se obtienen beneficios con el modelado?

Un coste en formacin y tiempo

Una mejora de la productividad? Una mejora de la calidad del software?

Modelos en UML

Modelado de Casos de Uso Modelado Estructural Modelado de Comportamiento Modelado de flujos de Actividades Modelado Implementacin Modelado de Despliegue

Tipos de modelo

En qu etapa del proceso se usa? Anlisis o Diseo? Cul 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 especfico o independiente de la plataforma? A qu plataforma va dirigido? EJB, JDBC, .NET, CORBA, etc.

Propiedades del modelado

La eleccin de los modelos tiene una profunda influencia sobre cmo se acomete el problema y se moldea la solucin. Todo modelo debe estar ligado a la realidad. Un nico modelo no es suficiente. Cualquier sistema trivial se aborda mejor a travs de un pequeo conjunto de modelos casi independientes.

Contenidos

Modelado del software

Presentacin de UML
Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases

Paquetes

UML y el modelado
UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos (modelos) de un sistema que involucra una gran cantidad de software, desde una perspectiva orientada a objetos.

UML es una notacin, no es un proceso Se han definido muchos procesos para UML.

Rational ha ideado RUP, elproceso unificado.

Utilizable para sistemas que no sean software

Marco Conceptual de UML

Bloques bsicos de construccin

Elementos
Estructurales, Comportamiento, Agrupacin, Anotacin

Relaciones Diagramas

Reglas para combinar bloques

Establecen qu es un modelo bien formado Especificaciones, Extensibilidad, Dicotoma claseinstancia, Dicotoma interfaz-realizacin

Mecanismos comunes

Elementos Estructurales

Partes estticas de un modelo

Ventana origen tamao abrir() cerrar() mover() dibujar()
<<Interface>> IAvisable

colaboracin
IAvisable

interface

Gestin Pedidos

clase
RealizarCompra

caso de uso

Elementos Estructurales
Gestor Eventos suspender() vaciarCola()

clase activa
FormularioPedido

componente
<<artifact>>

window.dll
Servidor

nodo

artefacto

Elementos de Comportamiento
Son las partes dinmicas de UML.
Interaccin Conjunto de mensajes intercambiados entre varios objetos con un propsito particular.
cerrarPuja()

mensaje

Elementos de Comportamiento
Mquina de estados Secuencia de estados por las que pasa un objeto durante su vida en respuesta a eventos.

activado

estado

Elementos de Agrupacin
Son las partes de organizacin de los modelos UML paquete

Modelo del Negocio

Un paquete incluye un conjunto de elementos de cualquier naturaleza.

Tiene una naturaleza conceptual.

Elementos de Anotacin
Son las partes explicativas de los modelos UML

Retorna 0 si no existe el valor

Nota

Relaciones
Dependencia
0..1 *

patron

empleado

Asociacin

Generalizacin Realizacin

Ejemplo de diagrama de clases

IteradorCuenta

Cuenta 1 0..n

Domiciliacion

Ahorro

Corriente Operacion Periodica

Diagramas de UML 2.0

Diagrama de Clases Diagrama de Objetos Diagramas no Diagrama de Componentes Diagrama de Estructura Compuesta son modelos Diagrama de Casos de Uso Diagrama Secuencia Diagrama Comunicacin (antes de Colaboracin) Diagrama de Estados Diagrama de Actividades Diagrama de Despliegue Diagrama de Artefactos Diagrama de Paquetes Diagrama de Tiempos

Diagramas de UML 2.0

Modelos en UML

Modelado de Casos de Uso

Diagrama de Casos de Uso Diagrama de Clases

Modelado Estructural

Modelado de Comportamiento

Diagramas de Interaccin: Secuencia y Comunicacin Diagramas de Estados

Modelado de flujos de actividades (p.e. Modelo del Negocio)

Diagramas de actividades Diagrama de Componentes

Modelado Implementacin

Modelado de Despliegue

Diagramas de Artefactos Diagramas de Despliegue

Responsable

Serv icio PE

Alumno

Sistema

Registrar Curso Aprobar Curso Preinscripcin

Modelo del Negocio

Avisar Admitidos

Matriculacin Hay alumnos?

no Cambiar admitidos

Hay alumnos? no

Diagrama de actividades

Cancelar Curso

Crear Proyecto Cerrar Curso

Modelo Casos de Usos

Realizar puja ordinaria Cerrar edicin de subasta

Pujador

Cancelar puja ordinaria Realizar pago de subasta ordinaria

Rechazar adjudicacin Sistema Notif icar adjudicatario Teleoperador Participante

Crear edicin de subasta

Anular anuncio de subasta

Diagrama de casos de uso

Administrador Anular edicin de subasta

Diagrama de clases

Modelo Estructural

1. cerrarEdicionSubasta(es) : ControladorAnuncios : Sistema 2. cerrar()

int numAjudicaciones = Minimo(pujas.length(), articulos.length());

Diagrama de comunicacin
9. [1..numAdjs]* add(adj)

5. numAdjs = calcularAdjudicaciones()

4. * cerrar() : AnuncioSubasta 3. * as := get() : EdicionSubasta as : AnuncioSubasta adjudicaciones : Adjudicacion

8. [1..numAdjs]* adj := crear(as, pg, a) 6. [1..numAdjs]* pg := get() pujas : PujaOrdinaria 7. [1..numAdjs]* a:= get()

Se recorre la coleccin de pujas obteniendo las pujas ganadoras (consideramos que la coleccin est ordenada de mayor a menor valor de puja).

adj : Adjudicacion : ArticuloConcreto Se crean tantas adjudicaciones como pujas ganadoras haya. Cada adjudicacin se asocia con un ArticuloConcreto, una puja adjudicataria y con la subasta.

Modelo de Comportamiento

Mquina de Estado
Diagrama de estado
Espera Venta introducirProducto introducirProducto

Introduccion Productos

Terminar Venta manejarRespuesta efectuar Pago Efectivo Espera Pago

Autorizacion Pago efectuar Pago Tarjeta

Mecanismos comunes de UML

Dicotoma clasificador /instancia

Persona nombre direccion telefono

Elena : Persona

Elena : Persona

: Persona

: Persona

Mecanismos comunes de UML

Dicotoma interfaz / implementacin

IOrtografia IDiccionario
asistenteOrtografico

IUnknown

Mecanismos comunes de UML

Dicotoma rol / tipo

Pedido

cliente: Persona

El tipo declara la clase de una entidad, por ejemplo un objeto o parmetro, y el rol describe el significado de la entidad en un determinado contexto, tal como una clase, componente o colaboracin.

Mecanismo de extensibilidad de UML

Estereotipos

Extienden el vocabulario de UML, permitiendo definir nuevos tipos de elementos y relaciones a partir de los existentes pero especficos de un problema o dominio. Algunos son predefinidos en UML.
Extienden las propiedades de un estereotipo, permitiendo crear nueva informacin en la especificacin del estereotipo. Especifican condiciones sobre los elementos del modelo.

Valores etiquetados

Restricciones

Perfiles UML

UML es una familia de lenguajes Lenguaje core + Perfiles Un perfil define una extensin de UML mediante la especializacin de UML. Un perfil define una forma especfica de usar UML para un dominio concreto: EJB, aplicaciones web, CORBA, modelado del negocio, esquemas relacionales, .. Agrupacin de un conjunto de estereotipos, valores etiquetados y restricciones, con su correspondiente notacin.

Ejemplos de estereotipos predefinidos

Clase estereotipadas

<<Actor>> Cliente

Cliente

IComparator

Estereotipos y Valores Etiquetados

<<BusinessEntity>>

<<Table>>

Empleado
<<key>> dni : String nombre : String edad : int
1

Cliente
<<UniqueId>> id : String
nombre : String apellido : String <<Query>> findByLastName()

Estereotipo: Table Valores Etiquetados: key

Estereotipo: BusinessEntity Valores Etiquetados: UniqueID y Query

Restricciones

Se expresan en OCL Permiten asociar informacin que no se puede expresar en UML Ejemplo: Dos tablas de un mismo esquema
relacional deben tener distinto nombre.
context Table inv: tablasDistintoNombre tablas -> forAll ( t1, t2 | t1.name = t2.name implies t1 = t2) end

Restricciones

{xor}

restricciones

{self.esposa.sexo = mujer and self.esposo.sexo = hombre}

Hola, Mundo!
import java.awt.Graphics; class HolaMundo extends java.applet.Applet { public void paint (Graphics g) { g.drawString (Hola, Mundo!,10,10); } }
HolaMundo g.drawString

("Hola, mundo)
paint()

Diagrama de Clases

Organizacin en Paquetes

Organizacin en Paquetes
java
HolaMundo applet awt

lang

Diagrama de Secuencia
root : Thread : Toolkit : ComponentPeer target : HolaMundo

run callbackLoop

handleExpose

paint

Diagrama de Artefactos
HolaMundo

<<manifest>>
<<artifact>>

<<manifest>>

hola.java

HolaMundo.class

hola.html

hola.jpg

Contenidos

Introduccin al modelado del software

Presentacin de UML Modelado de Casos de Usos

Diagramas de casos de uso Modelado Estructural Diagramas de Clases

Paquetes

Casos de Uso

Un caso de uso especifica un comportamiento deseado del sistema (trabajo tangible). Representan requisitos funcionales del sistema. Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor (Definicin en UML)

Describen qu hace el sistema, no cmo lo hace.

Casos de Uso

Elementos de un caso de uso

Conjunto de secuencias de acciones; cada secuencia representa un posible comportamiento del sistema Actores, roles que pueden jugar los usuarios Variantes: versiones especializadas, un cdu que extiende a otro o un cdu que incluye a otro

Casos de uso

Casos de uso son ideados por Jacobson a principios de los noventa, Inspirados en el concepto de escenario. Escenarios haban sido utilizados para describir procesos.

Emisor

Centralita

Receptor

listo( )

tono

marcar_numero

tono_sonando timbre_sonando

telefono_cogido para_tono para_timbre

Escenario

Otras definiciones de caso de uso

Describe un conjunto de interacciones entre actores externos y el sistema en consideracin orientadas a satisfacer un objetivo de un actor. [D. Bredemeyer]

Es una coleccin de posibles secuencias de interacciones entre el sistema en discusin y sus actores externos, relacionado con un objetivo particular. [A. Cockburn] Es una coleccin de escenarios de xito y fracaso relacionados que describe a un actor que usa un sistema para conseguir un objetivo [C. Larman]
67

Ejemplo de Caso de Uso

actor caso de uso

Cajero

Realizar Venta

asociacion

Ejemplo de caso de uso

Realizar Venta (en un terminal de punto de venta, TPV)
Actor : Cajero Descripcin:
Un cliente llega al TPV con un conjunto de artculos. El Cajero registra los artculos y se genera un ticket. El cliente paga en efectivo y recoge los artculos.

Flujo:
1. El cliente llega al TPV con los artculos. 2. El cajero registra el identificador de cada artculo. 3. El sistema obtiene el precio de cada artculo y aade la informacin a la transaccin de venta. 4. Al acabar el cajero indica la finalizacin de la introduccin de artculos. 5. El sistema calcula el total de la compra y lo muestra.

Actores
Un actor representa un rol que juegan los agentes que interactan con el sistema.

Roles son jugados por personas, dispositivos, u otros sistemas. Ejemplos: Cliente, Pujador, Alumno, SistemaPago, El tiempo puede ser un actor (procesos iniciados automticamente por el sistema) No forman parte del sistema.

Actores

Un actor necesita el caso de uso y/o participa en l. Un mismo usuario puede jugar diferentes roles. En la realizacin de un caso de uso pueden intervenir diferentes actores: Principal y Secundarios Un actor puede intervenir en varios casos de uso. Se pueden identificar casos de uso a partir de actores y eventos externos.

Identificacin de actores

Quin y qu utiliza el sistema? Qu roles desempean en la interaccin? Quin mantiene el sistema? Quin o que inicia y cierra el sistema? Qu otros sistemas interactan con el sistema? Quin o qu consigue o proporciona informacin al sistema? Sucede algo en un momento dado de forma automtica?

Actores

Dos tipos de actores:

Principal: Requiere al sistema el cumplimiento de un objetivo Secundarios: El sistema necesita de ellos para satisfacer un objetivo

Escenarios de un casos de uso

Un caso de uso describe un conjunto de secuencias de interacciones entre actores y el sistema (escenarios):

Principal y secundarios.

Cada escenario acaba con xito o fracaso. Un escenario es una instancia de un caso de uso, una historia particular de uso del sistema. Un flujo principal y varios flujos secundarios. Flujo principal: Todo va bien Flujos secundarios: Alternativas y Excepciones

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

75

Descripcin de un caso de uso

Son documentos de texto, no son diagramas.

El modelado de casos de uso consiste en escribir texto, no en dibujar diagramas. Texto estructurado informal Texto estructurado formal (plantillas) Pseudocdigo Notaciones grficas: diagramas de secuencia

Describir el flujo de eventos

Debe ser legible y comprensible para un usuario no experto. Debe indicar: actores, flujos principal y excepcionales.
76

Descripcin de un caso de uso

Realizar Venta (en un terminal de punto de venta, TPV)
Actor Principal: Cajero Flujo Principal: Un cliente llega al TPV con un conjunto de artculos. El
Cajero registra los artculos y se genera un ticket. El cliente paga en efectivo y recoge los artculos. 1. El cliente llega al TPV con los artculos. 2. El cajero registra el identificador de cada artculo. 3. El sistema obtiene el precio de cada artculo y aade la informacin a la transaccin de venta. 4. Al acabar el cajero indica la finalizacin de la introduccin de artculos.

Descripcin de un caso de uso

Realizar Venta (en un terminal de punto de venta, TPV)
5. El sistema calcula el total de la compra y lo muestra. 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 artculos comprados.

Cajero

Realizar Venta

Cliente

:Sistema

: Cajero
crearNuevaVenta()

* introducirItem(upc,cantidad)
finalizarVenta() hacerPago(cantidad)

Interacciones

Ejemplo de diagrama de casos de uso

Registrar curso

Rebajar Mnimo Responsable

Aprobar curso

Servicio CPE

Cerrar curso Crear proyecto Servicio Contabilidad

Fin matriculacion

Realizar preinscripcin

Sistema

Avisar admitidos Alumno

Matriculacin Cancelar curso

Ejemplo diagrama de casos de uso

Alumno

Realizar preinscripcin

Gestin Expedientes

Actor Principal
Matriculacin Entidad Bancaria

Actores Secundarios

Ejemplo diagrama de casos de uso

Reservar Libro

Prstamo revista

Profesor

Prstamo Libro

Devolver revista

Socio Devolver libro Actualizar catalogo

Bibliotecario

Extender Prstamo

Consultar

Socio

82

Casos de uso y Colaboraciones

Con un caso de uso se describe un comportamiento esperado del sistema, pero no se especifica cmo se implementa. Una caso de uso se implementa a travs de una colaboracin:
Sociedad de clases y otros elementos que colaborarn para realizar el comportamiento expresado en un caso de uso

Una colaboracin tiene una parte esttica (diagramas de clases) y una parte dinmica (diagramas de secuencia).

Casos de uso y Colaboraciones

caso de uso

colaboracin

Hacer Pedido

Gestin Pedidos realizacin

Casos de uso y Colaboraciones

El objetivo de la arquitectura del sistema es encontrar el conjunto mnimo de colaboraciones bien estructuradas, que satisfacen el comportamiento especificado en todos los casos de uso del sistema

Organizacin de casos de uso

Tres tipos de relaciones: Generalizacin

Un cdu hereda el comportamiento y significado de otro Un cdu base incorpora explcitamente el comportamiento de otro en algn lugar de su secuencia. Un cdu base incorpora implcitamente el comportamiento de otro cdu en el lugar especificado indirectamente por este otro cdu

Inclusin

Extensin

Generalizacin

Los casos de uso hijo son una especializacin del caso de uso padre. Produce confusin y se debera evitar su uso

Cliente

Buscar Producto

Buscar libro

Buscar CD

Ejemplo
Extensin extend
Realizar Pedido Realizar Pedido Urgente

(establecer prioridad)

include
Inclusin
Validar Usuario

Comprobar clave

Generalizacin include
Consultar Pedido
Examinar retina

Relacin de inclusin

Permite factorizar un comportamiento en un caso de uso aparte y evita repetir un mismo flujo en diferentes casos de uso. Ejemplo:
Hacer Pedido:
Obtener y verificar el nmero de pedido; Incluir (Validar usuario); para cada lnea en el pedido: Consultar el estado; Preparar un informe para el usuario

Relacin de extensin

El caso de uso base incluye una serie de puntos de extensin. El caso de uso base no conoce los casos de uso de extensin, est completo sin las extensiones. Los puntos de extensin no son parte del flujo principal. Sirve para modelar

la parte opcional del sistema un subflujo que slo se ejecuta bajo ciertas condiciones varios flujos que se pueden insertar en un punto

Relacin de extensin
Ejemplo:
Hacer Pedido: Incluir Validar usuario; Recoger los tem del pedido del usuario; establecer prioridad: punto de extensin Enviar pedido para ser procesado.

Relacin de extensin
Devolver Libro
Puntos de extensin libro retrasado

extend

Poner multa

Bibliotecario

Nombre: Devolver libro Nombre: Poner multa Actor principal: Bibliotecario Precondicin: Libro devuelto fuera de plazo Precondicin: Bibliotecario est autenticado Flujo: Flujo: 1. El bibliotecario introduce detalles multa 1. El bibliotecario introduce id del prestatario 2. El sistema registra e imprime la multa 2. El sistema muestra datos del prestatario y los libros que tiene prestados 3. El bibliotecario selecciona libro a devolver punto de extensin: libro retrasado 4. El sistema registra devolucin 5. ...

Relacin de extensin

Produce confusin y no debera utilizarse. Conviene su uso slo para insertar un nuevo comportamiento no previsto en un caso de uso existente.

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

Plantilla usecases.org (Larman)

Nombre del caso de uso Actor Principal Personas involucradas e Intereses (Actores secundarios) Precondiciones (estado del sistema antes de empezar) Postcondiciones (estado del sistema al finalizar) Escenario Principal (Flujo Bsico) Extensiones (Flujos Alternativos) Requisitos especiales Tecnologa y Lista Variaciones de datos Frecuencia Cuestiones abiertas

Caso de uso Realizar Venta

Resumen: Un cliente llega al TPV con un conjunto de artculos.
El Cajero registra los artculos y se genera un ticket. El cliente paga en efectivo y recoge los artculos.

Actor Principal: Cajero

Personal Involucrado e Intereses:

Cajero: quiere entradas precisas, rpida y sin errores de pago Compaa: quiere registrar transacciones y satisfacer clientes. ...

Precondicin: El cajero est autenticado Postcondiciones: Se registra la venta. Se calcula el impuesto. Se actualiza contabilidad e inventario...

Caso de uso Realizar Venta

Flujo Bsico:
1. A: El cliente llega al TPV con los artculos. 2. A: El cajero inicia una nueva venta 3. A: El cajero introduce el identificador de cada artculo. 4. S: El sistema registra la lnea de venta y presenta descripcin del artculo, precio y suma parcial. El Cajero repite los pasos 3 y 4 hasta que se indique. 5. S: El Sistema presenta el total 6. A: El Cajero le dice al Cliente el total a pagar 7. S: El Cliente paga y el sistema gestiona el pago. 8. S: El Sistema registra la venta completa y actualiza Inventario. 9. S: El Sistema presenta recibo

Caso de uso Realizar Venta

Extensiones (Flujos Alternativos):
3a. Identificador no vlido 1. El Sistema seala el error y rechaza la entrada 3-6a. El Cliente pide eliminar un artculo de la compra 1. El Cajero introduce identificador a eliminar 2. El sistema actualiza la suma ... 7a. Pago en efectivo 1. El Cajero introduce cantidad entregada por el cliente 2. El Sistema muestra cantidad a devolver ... ....

Caso de uso Realizar Venta

Requisitos especiales:
- Interfaz de usuario con pantalla tctil en un monitor de pantalla plana. El texto debe ser visible a un metro de distancia. - Tiempo de respuesta para autorizacin de crdito de 30 sg. El 90% de las veces ...

Lista de Tecnologa y Variaciones de Datos:

- El identificador podra ser cualquier esquema de cdigo UPC, EAN,.. - La entrada de informacin de la tarjeta se realiza mediante un lector de tarjetas. ...

Cuestiones Pendientes:
- Explorar cuestiones de recuperacin de accesos a servicios remotos - Qu adaptaciones son necesarias para diferentes negocios?

Utilidad de los casos de uso

Ofrecen un medio sistemtico e intuitivo para capturar los requisitos funcionales, centrndose en el valor aadido para el usuario Dirigen todo el proceso de desarrollo puesto que la mayora de actividades (planificacin, anlisis, diseo, validacin, test,..) se realizan a partir de los casos de uso. Mecanismo importante para soportar trazabilidad entre modelos.

Utilidad de los casos de uso

Hay consenso en considerar casos de uso como esenciales para capturar requisitos y guiar el modelado. Pero ha existido mucha confusin sobre cmo usarlos.

Nmero de casos de uso apropiado en un proyecto? Qu casos de uso hay en el sistema?

Granularidad de los casos de uso

Diferente granularidad Un caso de uso se puede asociar a un objetivo del usuario o a una interaccin bsica con el sistema. Un objetivo implica una o ms interacciones. Se debe definir un caso de uso por cada objetivo del usuario.

Granularidad

Casos de uso del negocio

Procesos de Negocio: Objetivo estratgico de la empresa

Ej. Venta productos Objetivo de un usuario Ej. Realizar una compra Forman parte de otro, son como subfunciones Ej. Buscar, Validar, Login

Casos de uso del sistema

Casos de uso de inclusin

Granularidad

Qu granularidad es apropiada para un caso de uso del sistema?

Sirven para planificar el proyecto Se les asocia un flujo de interacciones actor-sistema Deben ser objetivos del usuario En un sistema de venta por internet, son casos de uso Aadir producto al carro de la compra o Introducir datos facturacin ?

Tipos de casos de uso

Segn el nivel de detalle

Breve : Descripcin en unas pocas lneas Informal : Varios prrafos que cubren varios escenarios Completo : Descripcin detallada con una plantilla Primario, secundario u opcional Esencial : intenciones del usuario y responsabilidades del sistema Concreto : Se contemplan detalles de implementacin (GUI y tecnologa)

Segn la importancia

Segn el nivel de abstraccin

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 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. El texto de los casos de uso debe ser claro. No abusar de la relacin de inclusin.
No hacer una descomposicin funcional!

Las relaciones de generalizacin y extensin no deberan utilizarse.

Recomendaciones

Un caso de uso debe tener una granularidad apropiada, especifica una interaccin en la que se produce un resultado de valor para un actor.

No identificar como caso de uso lo que son interacciones que forman parte de una interaccin mayor que las engloba y no son casos de uso de inclusin.

Un error comn es no identificar como casos de uso las tareas que inicia el propio sistema (Actor Tiempo)

Anular reservas pasados quince das

Recomendaciones

No incluir como caso de uso las operaciones CRUD sobre un objeto de negocio (alta, consulta, borrado, actualizacin): funcin 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 relacin include
No hacer una descomposicin funcional!

Escribir casos de uso independientes de la interfaz o de detalles de implementacin, escribirlos a nivel esencial. Centrarse en el qu no en el cmo.

Recomendaciones

Hay que comprobar que los casos de uso incluyen toda la funcionalidad del sistema. Preocupacin por mantener la validez y consistencia del conjunto de casos de uso. Cada compaa debe tener un manual sobre uso de los casos de uso. Algunos requisitos funcionales no conviene expresarlos como casos de uso.

Mal uso de los casos de uso

<<include>>

<<include>>

Aadir libro

<<include>> Mantener libros

Eliminar libro

<<include>> <<include>>

Aadir peticin

Bibliotecario

Gestionar biblioteca

Mantener peticiones

<<include>>

<<include>>

Eliminar peticin

<<include>> Devolver libro

Mantener prestamos

<<include>>

Prestar libro

Referencias de Casos de Uso

Craig Larman, UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado, Prentice-Hall, 2003. Jim Arlow e Ila Neustdt, UML 2, captulos 4 y 5, Anaya Multimedia, 2006. Alistair Cockburn,Writing effective use cases, AddisonWesley, 2000. http://alistair.cockburn.us/

Contenidos

Introduccin al modelado del software

Presentacin de UML
Modelado de Casos de Usos Diagramas de casos de uso

Modelado Estructural

Diagramas de Clases

Paquetes

Modelado estructural

Se describen los tipos de objetos de un sistema y las relaciones estticas que existen entre ellos.

Clases Interfaces Relaciones de dependencia, realizacin, generalizacin y asociacin (agregacin, composicin) Tambin pueden incluir paquetes.

Un diagrama de clase es una representacin grfica de un modelo estructural.

Modelado estructural

Diferentes perspectivas. Modelado Conceptual

Conceptos del dominio del problema: atributos, restricciones y relaciones entre ellos. Clases que corresponden a conceptos del dominio Atributos y mtodos Incluye clases que corresponden a decisiones del diseo Clases que corresponden a un lenguaje de programacin

Modelo del Anlisis

Modelo de Diseo

Modelo de Implementacin

Modelo Conceptual

Modelo Anlisis

IteradorCuenta

Modelo de diseo

Cuenta 1 0..n

Domiciliacion

Ahorro

Corriente Operacion Periodica

11: enviarPago(pagoAlumno) matric : Matricula 3: c := get(idCurso) :SistemaContabilidad

: Catlogo Curso

: Curso

10: [matriculable = true] create(a) 2: c := getCurso(idCurso)

esMatriculable indica si el alumno puede matricularse en el curso segn los criterios de seleccin del mismo.

1: realizarMatricula(idCurso,dniAlumno) : ControladorMatrculacionCurso

7: addMatricula(a) c : Curso

9: matriculable:= esAdmitido() p : Preinscripcin

: Alumno

4: a := getAlumno(dniAlumno)

8: p:= get(a.dni) 12: add(matric)

13: addMatricula(matric)

: Alumno 6: create(datosAlumno)

: CatalogoAlumnos : Alumno : Preinscripcin : Matricula

14: add(matric) : Matricula

5: datosAlumno:= getDatosAlumno(dniAlum...

:SistemaGestinAcadmica Si el alumno no est en el catlogo se piden sus datos, se crea y se aade al catlogo.

Modelo del Comportamiento

Modelado estructural y del comportamiento

Colaboraciones y Patrones de diseo tienen una parte estructural y otra de comportamiento.

Realizar Compra

Realizar Compra

Patrn de diseo (parte esttica)

Subject subjectState Attach() Detach() Notify() +observers 1..1 1..* Observer Update()

for all o in observers {o.update()}

ConcreteSubject subjectState getState() setState() +subject

ConcreteObserver observerState update() observerState= subject.getState()

Patrn de diseo (parte dinmica)

: Subject 1. setState() 1.1. notify() 1.1.1. update() 1.1.2. update() o1 : Observer o2 : Observer

Ingeniera directa e inversa

Ingeniera directa

Transformar modelos en cdigo en un lenguaje de programacin determinado Obtener un modelo a partir de cdigo. Ms difcil ya que hay prdida de informacin al pasar de los modelos al cdigo.

Ingeniera inversa

Clases

Atributos

Operaciones

No se tienen por qu mostrar todos las propiedades Se pueden agrupar operaciones: <<constructor>>, <<query>>

Clases

Clases y mtodos abstractos Multiplicidad Variables y mtodos de clase

1

Interfaces

Una interfaz es una coleccin de operaciones que especifica los servicios de una clase o componente.
<<Interface>> Collection add() remove() size() contains() iterator()

<<Interface>> Iterator next() hasNext()

Atributos
[visibilidad] nombre [: tipo] [[multiplicidad]] [= valor_inicial ] [property-string {, property-string}]
+ = # = = ~ = pblica protegida privada package

visibilidad nombre: tipo:

nombre del atributo

tipo del atributo

valor_inicial: valor inicial o por defecto propiedades: {frozen} {addOnly}

Atributos : Ejemplos

origen + origen origen : Punto nombre : String [0..30] origen : Punto = (0,0) id : Integer {readOnly}

Operaciones
[visibilidad] nombre [(lista_parametros)] [: tipo_retorno] [property-string {, property-string}]
+ = # = = ~ = pblica protegida privada package

visibilidad

nombre: nombre de la operacin lista_parmetros: lista de parmetros separados por comas tipo retorno: propiedades: tipo de valor devuelto por la operacin {isQuery}, {sequential}, {concurrent}

Operaciones: Ejemplos

dibujar + dibujar set (nombre : String) getID(): Integer arrancar() {guarded}

Formato parmetro:
[direccion] nombre : tipo [= valor-por-defecto] direccion puede ser : in, out o inout

Clases Parametrizadas
G

Clase Parametrizada

Tabla count capacity put(G) item() : G

bind <Empleado>

Instanciacin

Tabla<Cliente>

Empleados

Clases Estereotipadas
<<entity>> Cuenta <<control>> Controlador Ingreso <<boundary>> JFrameBanco

Cuenta

Controlador Ingreso

JFrameBanco

Cuenta

Controlador Ingreso

JFrameBanco

Clases del modelo o entidad, controlador e interface

Relaciones
Dependencia
Un cambio en la especificacin de un elemento afecta a otro elemento
Lista <<friend>> Nodo

Estereotipos para dependencias

<<use>>: relacin de uso, el ms comn entre clases y se da por

defecto

<<trace>>: cliente y proveedor representan el mismo concepto en

diferentes modelos

<<bind>>: entre una clase genrica y una instanciacin

<<friend>>: dependencia de clase amiga

<<import>>: un paquete importa los elementos de otro. <<access>>: similar a <<import>>

<<extend>>: para casos de uso

<<include>>: para casos de uso

Relaciones
Generalizacin

Es-un-tipo-de En el caso de un modelo de diseo o implementacin denota una relacin de herencia

Cuenta

Window

Cuenta Ahorro

Cuenta Corriente

TextWindow

BoxDialog

Relaciones
Asociacin

Relacin estructural que especifica que los objetos de un tipo estn conectados con los de otro.

Persona

+empleado 1..n trabaja para

+patron 0..n

Empresa

Multiplicidad (mnimo..mximo)
Ejemplos: 0..1, 1, 0..*, *, 1..*, 1..10, 2..25

Asociaciones
Agregacin

Caso especial de asociacin Relacin estructural parte-de

Empresa

1..1

Departamento

Navegabilidad

Asociaciones son bidireccionales Posibilidad de limitar la navegacin de una asociacin a una sola direccin Determina si una clase de la asociacin tiene conocimiento de la otra. Nivel de diseo o implementacin

Navegabilidad
class Pedido { private Hashtable _itemsPedido; private Date fecha; private boolean esCompleto; ...} class ItemPedido { private Producto producto; private int cantidad; ...} Class Producto { private Money precio; private String descripcin; }

Navegabilidad (UML 2.0)

A A B B
Navegabilidad indefinida Navegable de A a B, de B a A indefinida Navegable en ambos sentidos

A
A A

B
B B

Navegable slo de A a B No navegable en ningn sentido

Navegabilidad (Prctica habitual)

A A B B
Navegabilidad en ambos sentidos Navegable slo de A a B No se usa

A
A A

B
B B

No se usa No se usa

Visibilidad

Pblica: Protegida: Privada: Paquete:

+ # ~

propietario propietario propietario propietario

GrupoUsuarios 0..n 0..n

Usuario

+propietario 1

-clave 0..n

Clave

Asociaciones calificadas

Nivel Conceptual: Dentro del mismo pedido no pueden existir dos lneas con el mismo producto Nivel Anlisis: El acceso a ItemPedido es indexado por productos Nivel Implementacin: Se usa una tabla para almacenar las lneas de pedido

Asociaciones calificadas
Class Pedido { private Hashtable _lineasPedido;

public ItemPedido getItemPedido(Producto unProducto); public void addItemPedido (Integer cantidad, Producto elProducto); }

Agregacin

Dos criterios:

Dependencia:
La existencia de una parte va ligada a la del agregado?

Exclusividad:
Una parte puede pertenecer a ms de un agregado?

Habra cuatro posibles tipos de agregacin; en UML hay dos: agregacin y composicin

Composicin

Forma fuerte de agregacin Una parte pertenece a un nico agregado (exclusividad) Si se elimina un agregado se eliminan todas sus partes (dependiente) Una parte se puede aadir o eliminar en cualquier instante al agregado.

Composicin
Window 1 1 1

agregado

+scrollbar Slider
2

+title

1 +body Panel

Header

partes

Clases Asociacin

Una asociacin que tambin es una clase Una asociacin que posee sus propias caractersticas. Una clase asociacin aade una restriccin: Slo puede existir una instancia de la asociacin entre cualquiera par de objetos participantes No podramos modelar que una persona tiene diferentes contratos para una misma compaa a lo largo del tiempo.

Ejemplo de clase asociacin

Persona +empleado 1..n +patron 0..n Empresa

Contrato salario descripcion fechaContrato

Distinta semntica
Empresa 1..n 1

Contrato Persona 1 salario descripcion 0..n fechaContrato

Asociaciones derivadas
recibe Estudiante Asignatura

/ensea

imparte

Profesor

Asociacin Derivada

Restricciones para Asociaciones

Empresa
Departamento * *

Cuenta

{or}
Persona
+miembro

{subset}
1..* Persona +Director 1..1

Restricciones para Asociaciones

operario

empleado

patrn 0..1

*
0..1 jefe

Persona

Empresa

{ Persona.patrn= Persona.jefe.patrn }

Un empleado trabaja para la misma empresa que su jefe

Realizacin
Relacin entre clasificadores, un clasificador Especifica un contrato que otro clasificador garantiza que cumplir.
<<Interface>> ICollection List add() remove() contains()
List

ICollection

Interfaces, tipos y roles

Una interfaz es una coleccin de operaciones que especifican los servicios de una clase o componente. Las interfaces modelan las lneas de separacin o puntos de conexin (seams) de un sistema. Una interfaz permite separar la especificacin de la implementacin. Un tipo especifica un dominio de valores junto con operaciones (no mtodos) aplicables a esos valores. Un rol denota el comportamiento de una entidad dentro de un particular contexto.

Interfaces
Interfaz requerida Interfaz proporcionada
Observer

Target

TargetTracker

Target
Observer

TargetTracker

Clases Estructuradas
0..n Prestamo +prestamos 0..n libroPrestado 1 Libro +catalogo 0..n

1 Prestatario

+prestatarios 0..n 1

1 Biblioteca 1 1..n

Bibliotecario

Estudiante

Personal

estudiante: prestamos < 5 personal: prestamos < 10

Clases Estructuradas
Estructura interna de una clase
Biblioteca

estudiante: Prestatario [0..*]

0..* PrestamoEstud: Prestamo [0..4] 1

personal: Prestatario [0..*]

:Libro: [0..*] 1
0..* PrestamoPerso: Prestamo [0..9]

:Bibliotecario [1..*]

biblioConectado:Bibliotecario [0..1]

Diagrama de estructura compuesto

Biblioteca

estudiante: Prestatario [0..*]

0..*
PrestamoEstud: Prestamo [0..4] 1

personal: Prestatario [0..*]

Libro: [0..*]
1 0..* PrestamoPerso: Prestamo [0..9]

:Bibliotecario [1..*]

biblioConectado:Bibliotecario [0..1]

Contenidos

Introduccin al modelado del software Presentacin de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases

Paquetes

Paquetes

Elemento organizativo Puede agrupar elementos de cualquier tipo Permite agrupar elementos relacionados semnticamente Un elemento es exclusivo a un paquete:

Si eliminamos el paquete se elimina el elemento

Establece un espacio de nombres Posibilidad de anidar paquetes

Modelo

Modelo + Producto + CarroCompra + Comercio

Paquetes: Notacin

Importacin/Exportacin en paquetes

Visibilidad pblica y privada Relaciones de importacin y generalizacin. La parte pblica de un paquete son sus exportaciones. Cuando un paquete A importa a otro B, todos los elementos pblicos de B son aadidos a A, se accede a ellos sin calificar su nombre. La complejidad de un gran nmero de abstracciones es controlada a travs de los paquetes y de la importacin.

Importacin/Exportacin en paquetes

La relacin de acceso es igual que la importacin, pero los elementos pblicos son aadidos como privados. La relacin de importacin es transitiva. Importacin y acceso se representan mediante relaciones de dependencia estereotipadas con <<import>> y <<access>>. Los paquetes anidados tienen acceso al espacio de nombres del paquete que los contiene.

Cliente Servidor + BaseDeDatos + ServicioDeRegistro + FormularioPedido + FormularioDeSeguimiento - Pedido

<<import>>
Politicas + ReglasPedidos + GUI:Ventana

GUI + Ventana + Formulario # GestorEventos

<<import>>

Auxiliary

<<access>>
ShoppingCart WebShop

<<import>>
Types

<<import>>

Generalizacin de Paquetes
GUI + Ventana + Formulario - GestorEventos

WindowsGUI + GUI:Ventana + Formulario - GUI:GestorEventos + VBForm

MacGUI

Paquetes

Un paquete bien estructurado debe:

ser cohesivo estar poco acoplado pocos anidamientos conjunto equilibrado de elementos

Uso de los paquetes

Agrupar elementos relacionados para manejarlos en conjunto. Ejemplos:

Paquete Clases e interfaces del modelo Paquete Interfaces de usuario Paquete Servicios base de datos Paquete Modelo del anlisis

Uso de los paquetes

Modelo de Anlisis

<<framework>> Struts

Modelo

Un modelo captura una vista de un sistema fsico. Es una abstraccin de ese sistema con cierto propsito, para cierto conjunto de personas interesadas y a cierto nivel de abstraccin. Un modelo contiene todos los elementos de modelado necesarios. Un modelo y sus elementos se representan mediante diagramas, que expresan una vista del modelo.

Modelo

Vistas UML: 4 + 1
vocabulario funcionalidad ensamblado gestion conf.
Vista de Implementacion

Vista de Diseo

comportamiento

Vista de casos de uso

Vista de Interaccin

Vista de Despliegue

capacidad de procesamiento escalabilidad rendimiento

topologa entrega distribucin instalacin

Vistas UML: 4 +1
clases interfaces colaboraciones
Vista de Diseo Vista de Implementacion

componentes

casos de uso

Vista de casos de uso

Vista de Interaccin

Vista de Despliegue

clases activas

nodos

Vistas UML
Diagramas de clase Diagramas de interaccin Diagramas de estado
Vista de Diseo

Diagramas de componentes Diagrama de interaccin

Diagramas de estado
Vista de Implementacin

Diagramas de casos de uso Vista de casos de uso

Vista de Interaccin

Vista de Despliegue

Diagramas de clase Diagramas de interaccin

Diagramas de estado

Diagramas de despliegue

Contenidos

Modelado del Comportamiento

Diagramas de interaccin Diagramas de actividades Mquinas de estado

Componentes Modelado de la Implementacin

Artefactos y despliegue Diagramas de despliegue

Colaboraciones UML, Metamodelado y MDA

Enlaces y Conectores

Un enlace es :

una conexin semntica entre objetos. comnmente es una instancia de una asociacin. un camino por el cual enviar un mensaje

Una lnea de vida es un participante en una interaccin. Un conector es un enlace entre lneas de vida

Enlaces y Asociaciones

enlace
p:Persona 1: asignar(desarrollo) :Empresa

objeto mensaje

Enlaces

Restricciones para expresar la naturaleza del enlace:

association self global local parameter

Diagrama de Objetos
: Cuenta

: Cliente

: CodigoCuenta

: Tarjeta

: Transaccion

: Perfil

Diagrama de Objetos
: Curso

: Alumno : Profesor

: Tarjeta

: Departamento

: Expediente

: Tarjeta

director : Profesor

: GrupoInvestigacion

Diagrama de Objetos
: Curso

: Profesor

profesores *

: Alumno
alumnos *

: Tarjeta

: Departamento

: Expediente

: Tarjeta

grupos *

director : Profesor

: GrupoInvestigacion

Interacciones y Mensajes

Interaccin: Comportamiento que comprende

un conjunto de mensajes intercambiados entre un conjunto de lneas de vida dentro de un contexto para lograr un propsito.

Mensaje: especificacin de una particular

comunicacin entre lneas de vida de una interaccin que transmite informacin, con la expectativa de desencadenar una actividad.

Lneas de Vida

umu: Empresa

irene:Persona

asignar(desarrollo)

lnea de vida

mensaje

Lneas de Vida

conector
irene:Persona
1: asignar(desarrollo) p:Persona :Empresa :Empresa umu: Empresa

lnea de vida

mensaje

Tipos de mensajes
Sncrono

El emisor espera hasta recibir el resultado

El emisor no espera a recibir el resultado Indica el retorno de una llamada

Asncrono

Retorno

Creacin y destruccin

<<create>> y <<destroy>>

Modelado del comportamiento

Se describe cmo los objetos colaboran entre s para realizar cierta actividad. Se expresan mediante los diagramas de interaccin:

Diagramas de Secuencia y Diagramas de Comunicacin

Tambin se describe las mquinas de estado que caracterizan a los objetos y flujos de actividades

Diagramas de estado Diagramas de actividades

Diagramas de Interaccin

Describen una interaccin y hay dos tipos. Diagramas de Secuencia:

Destacan la ordenacin temporal de los mensajes Destacan la organizacin estructural de los objetos participantes.

Diagramas de Comunicacin:

Equivalencia semntica

Diagramas de Secuencia

Incluye:

Lneas de vida (antes objetos y su lnea de tiempo ) Focos de control o activacin Mensajes: a instancias o de creacin Mensaje self Informacin de control (en UML 2 slo en diagramas de comunicacin): condiciones y marcas de iteracin Indicar el objeto devuelto por el mensaje: return
(aadirlos slo cuando ayuden a clarificar la interaccin)

Mensajes
Simple: Creacin de objetos: Destruccin de objetos: Asignacin: Identificar hilo: metodo(arg) <<create>> <<destroy>> v:= mtodo(arg) nmero del mensaje en la secuencia precedido por el nombre del proceso o hilo

En UML 2.0 en diagramas de comunicacin: Condicin: [condicion] metodo(arg) Iteracin: * metodo(arg), [1..n] metodo(arg) Numeracin jerrquica o secuencial o ninguna

Mensajes
Simple: Condicin: Iteracin: Asignacin: Identificar hilo: preparar(), addPedido(p) [condicion] metodo(arg) * preparar() hayStock:= eliminar() D3 : activar()

Diagrama de Secuencia
sd Gestin Pedidos
: GUIPedido :GUIPedido : ControladorPedidos :ControladorPedidos ::Pedido Pedido : LineaPedido :LineaPedido : Item :Item : ItemPedido preparar( ) preparar( )

: ItemEntre

* preparar( )

hayStock:=check( ) [hayStock] eliminar( ) pedir:=checkPedir( ) [pedir]<<create>>

:ItemPedido
[hayStock] <<create>>

:Item Entregado

Diagrama de Comunicacin
sd Gestin Pedidos
1: preparar( ) : GUIPedido : ControladorPedidos 2: preparar( ) : Pedido 3: *preparar( ) 3: preparar() : LineaPedido

lneas *
4: hayStock:=check( ) 5: [hayStock] eliminar( ) 8: [hayStock]<<>create> 6: pedir:=checkPedir( )

: ItemPedido 7: [pedir]<<create>>

: Item

: ItemEntregado

Diagrama de Secuencia
c:Cliente <<create>> establecerAcciones establecerValores :Transaccion p:ProxyODBC

tiempo
exito

establecerValores

Lnea de vida

<<destroy>>

Foco de control

Diagrama de Comunicacin
1: <<create>> 2: establecerAcciones 6: <<destroy>>
c:Cliente :Transaccion {new}

t {local}
proxy {global} 3: establecerValores 4: establecerValores

p:ProxyODBC

Operadores de control

Ejecucin opcional (opt)

El cuerpo se ejecuta si se cumple una condicin El cuerpo se divide en varias regiones, cada una con una condicin asociada. Se ejecuta el cuerpo de la regin cuya condicin se satisface. El cuerpo se divide en varias regiones. Cada regin representa una computacin paralela. Se ejecuta de forma paralela el cuerpo de cada regin El cuerpo se ejecuta mientras se cumple una condicin El cuerpo hace referencia a otra interaccin

Ejecucin condicional (alt)

Ejecucin paralela (par)

Ejecucin iterativa (loop)

Ejecucin referencia (ref)

sd reintegro
usuario : Persona banco : CajeroAutomatico

loop(1,3)
[password incorrecto]
introducir (password)

Fragmento combinado

verificar(password)

opt
[password valido]

par

introducir(cuenta)

introducir(cantidad)

entregar(dinero)

Diagrama de actividad anidado

sd reintegro
usuario : Persona banco : CajeroAutomatico

ref
Obtener password

opt
[password valido]

ref
Obtener dinero

Numeracin secuencial
2: m2()

1: m1() :A :B

3: m3() :C

4: m4()

:D

Confusin en el flujo de ejecucin

Numeracin jerrquica
:A m1( ) :B :C :D

m2( ) m3( )

m4( )

Numeracin jerrquica
:A 1. m1() 1.1. m2() :B :C :D

1.2. m3()

1.3. m4()

Numeracin jerrquica
1.1. m2( )

1. m1( ) :A :B

1.2. m3( ) :C

1.3. m4( )

:D

Numeracin jerrquica
:A 1. m1( ) 1.1. m2( ) 1.1.1. m3( ) :B :C :D

1.2. m4( )

Numeracin jerrquica
1.1. m2( )

1. m1( ) :A :B

1.1.1. m3( ) :C

1.2. m4( )

:D

Diagrama de clases

11: enviarPago(pagoAlumno) matric : Matricula 3: c := get(idCurso) :SistemaContabilidad

: Catlogo Curso

: Curso

10: [matriculable = true] create(a) 2: c := getCurso(idCurso)

esMatriculable indica si el alumno puede matricularse en el curso segn los criterios de seleccin del mismo.

1: realizarMatricula(idCurso,dniAlumno) : ControladorMatrculacionCurso

7: addMatricula(a) c : Curso

9: matriculable:= esAdmitido() p : Preinscripcin

: Alumno

4: a := getAlumno(dniAlumno)

8: p:= get(a.dni) 12: add(matric)

13: addMatricula(matric)

: Alumno 6: create(datosAlumno)

: CatalogoAlumnos : Alumno : Preinscripcin : Matricula

14: add(matric) : Matricula

5: datosAlumno:= getDatosAlumno(dniAlum...

:SistemaGestinAcadmica Si el alumno no est en el catlogo se piden sus datos, se crea y se aade al catlogo.

Diagrama de Colaboracin UML 1.x

import java.io.*; public class EjemHilo extends Thread { static PrintWriter out = new PrintWriter (System.out, true); int num; public EjemHilo(String nombre, int n) { super(nombre); num = n; } public void run(){ for (int i=0; i<num;) { out.println(getName()+":"+ ++i); delay(); } } void delay() { long t = System.currentTimeMillis() + 500; while (System.currentTimeMillis() < t); } }

public class TestHilo { private EjemHilo h1, h2; public void inicio(){ h1 = new EjemHilo("Hilo 1", 4); h2 = new EjemHilo("Hilo 2", 6); EjemHilo.out.println(Preparados los dos hilos"); h1.start(); h2.start(); EjemHilo.out.println("Arrancados los dos hilos"); }

public static void main(String[] args) { TestHilo testHilo1 = new TestHilo(); testHilo1.inicio(); }
}

t: TestHilo new(Hilo 2, 4) inicio new(Hilo 2, 6) :h2: EjemHilo println(preparados los dos hilos) start() start() println(arrancan los dos hilos) delay() [1..4] :h1: EjemHilo

EjemHilo1.out:PrintWriter

run() run()

delay() [1..6]

Uso de los diagramas de interaccin

Modelado del aspecto dinmico. Modelado del flujo de control que caracteriza el comportamiento de un sistema:

casos de uso colaboraciones patrones frameworks operaciones

Diagramas de Secuencia vs. Diagramas de Comunicacin

Equivalencia semntica 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 colaboracin muestran claramente los objetos a los que est conectado un determinado objeto. Permiten la generacin de cdigo

Diagramas de Actividad

Representa una actividad. Basados en las redes de Petri. Formado por nodos conectados por arcos:

nodos accin y actividad nodos de control, como control de concurrencia y decisin nodos objeto flujos de control y de flujo de objetos

Una actividad o una accin produce algn efecto que provoca algn cambio en el sistema o retorna un valor.

Nodos de Actividad

Nodos de accin

Realizan un trabajo: llamadas a operaciones, actividades, comportamiento, envo de seales, aceptar un evento.
Controlan el flujo de la actividad Objetos o datos utilizados en la actividad

Nodos de control

Nodos de objetos

Flujo de control de la actividad Flujo de objetos en la actividad

Semntica actividades

Basada en el flujo de tokens. Un token contiene un dato, objeto o punto de control y est presente en un nodo. Un nodo inicia la ejecucin cuando se satisfacen las condiciones sobre sus tokens de entrada; al inicio acepta tokens de sus entrada y un token es colocado en el nodo; al finalizar ofrece tokens a sus arcos de salida y elimina el token. Existen reglas de flujo de tokens

Ejemplo
Fabricacin productos

inicio
Planificar tareas

Flujo

Asignar tareas

Realizar tareas

finalizacin

Bifurcacin
Obtener orden de trabajo

Nodo de decisin
[ material disponible ]

[ material no disponible ]

Volver a planificar

Asignar tareas

Nodo de fusin
Obtener siguiente orden de trabajo

Divisin y Unin
Disear producto

divisin

Comercializar producto

Fabricar producto

unin
Vender producto

Ejemplo

Ejemplo

Elegir sitio

Contratar arquitecto

Realizar planos

Pedir ofertas

[ no aceptado ]

Construir

Trabajo administrativo

Finalizar construccin

Certificado Habitabilidad [completado]

Solicitar Producto

Procesar Pedido
Extraer Artculos

Enviar Pedido

Recibir Producto

Facturar al cliente

Pagar Factura

Cerrar Pedido

Cliente

Ventas

Almacn

Solicitar Producto

Procesar Pedido
Extraer Artculos

Enviar Pedido

Recibir Producto

Facturar al cliente

Calles
Pagar Factura Cerrar Pedido

Cliente
Solicitar Producto

Ventas

Almacn Objetos

Procesar Pedido

o: Pedido [en progreso]

Extraer Artculos

Enviar Pedido

o: Pedido [completado] b: Factura [impagada] Recibir Producto

Facturar al cliente

Pagar Factura

b: Factura [pagada] Cerrar Pedido

Calles

Particiones de actividades

Pins

Regiones de Expansin

Recibir pedido :Pedido :LineaPedido

Obtener Item :Producto

Calcular coste
:Dinero

:Envio Enviar pedido

:Factura Enviar factura

Otras cuestiones

Conectores Enviar seales y aceptar eventos Caractersticas avanzadas de flujo de objetos Multidifusin y multireceptor Conjuntos de parmetros Nodo <<centralBuffer>>

Diagramas de visin de interaccin

Utilidad de los diagramas de actividad

Modelado de flujos de trabajo (workflow) como son los procesos de negocio (business process). Se puede asociar a cualquier elemento de modelado, pero lo ms normal es asociarlo a una operacin: diagrama de flujo de las acciones.

Eventos

Un evento es la especificacin de un acontecimiento que ocupa un lugar en el tiempo y espacio. En una mquina de estado, un evento es un estmulo que dispara una transicin. Eventos externos vs. eventos internos. Tipos de eventos:

Seales (excepciones) Llamadas Paso de tiempo Cambio de estado

Seales

Modelado Excepciones
<<exception>> Excepcion establecerManejador() primerManejador() ultimoManejador()

<<exception>> Duplicado

<<exception>> Overflow

<<exception>> Underflow

Conjunto aadir() eliminar()

<<send>>

<<send>>

<<send>>

Eventos de tiempo y cambio

Tiempo

Representa el paso de tiempo

at (3 Oct 2006, 1000 UT), at(14:45PM), after 2 seconds, after 1 ms exiting Activo

Cambio

Representa un cambio de estado o que se satisface una condicin. when expresin-booleana when (saldo < 0)

Mquina 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. tiles para objetos reactivos, las instancias de su clase

deben responder a eventos externos o internos tienen un comportamiento que depende de su historia tienen un ciclo de vida modelado como una progresin de estados, transiciones y eventos.

Se representa mediante un diagrama de estados.

Estados

Un estado es una situacin en la vida de un objeto en la que satisface cierta condicin, realiza alguna actividad o espera algn evento. Elementos de un estado:

Nombre Acciones entrada/salida Transiciones internas Subestados Eventos diferidos

Transiciones

Una transicin de un estado A a un estado B, se produce cuando se origina el evento asociado y se satisface la condicin especificada, en cuyo caso se ejecuta la accin de salida de A, la accin de entrada a B y la accin asociada a la transicin.
Elementos de una transicin:

Estados origen y destino Evento de disparo (cero o ms) Condicin de guarda (cero o ms) Accin (cero o ms)

apagar

Inactivo
haceFrio(tempDeseada) haceCalor(tempDeseada) tempOK

tempOK

Calentando
listo/encender()

Enfriando
haceCalor(tempDeseada) Activacin

haceFrio(tempDeseada)

Activo

after (2 sec) send c.estaActivo

ruido

Inactivo

Buscando

objetivoEn(p) [representaAmenaza] / t.aadirObjetivo(p)

Rastreando
contactar

Acoplamiento

Partes de un estado

accin entrada transicin interna evento diferido

Rastreando entry/ activarModo(enRastreo) exit / activarModo(noRastreo) nuevoObjetivo/rastreador.adquirir do / seguirObjetivo autotest / defer

accin salida actividad (accin)

Diagrama de Estado (Caso de Uso)

introducirProducto

Espera Venta

introducirProducto

Introduccion Productos

Terminar Venta manejarRespuesta efectuar Pago Efectivo Espera Pago

Autorizacion Pago efectuar Pago Tarjeta

Diagrama de Estado (Caso de Uso)

cerrarPedido( (codigoCuenta, direccinEnvio, fechaTarjeta,.. ) Establecer Cliente y Verificar pago

enviarCargo (codigoCuenta,..)

Pago

rechazarPago

Pago No apobado

pagoAprobado

enviarCargo (codigoCuenta,..)

Envio

pedidoEntregado

Entregado

Subestados no ortogonales
introducirTarjeta

Activo
Validacin

entry/leerTarjeta exit/expulsarTarjeta [continuar]

Inactivo
cancelar mantener Seleccin

Procesando

Mantenimiento

[no continuar]
Impresin

Subestados ortogonales

Subestados ortogonales
Mantenimiento
Pruebas mantener

Inactivo

Probar perifericos

AutoDiagnosis

Manejo Ordenes
Espera

[continuar] Orden

Pulsar tecla

[no continuar]

Contenidos

Modelado del Comportamiento

Diagramas de interaccin Diagramas de actividades Mquinas de estado

Componentes Modelado de la Implementacin

Artefactos y despliegue Diagramas de despliegue

Colaboraciones UML, Metamodelado y MDA

Componentes

Es una parte modular de un sistema que encapsula el estado y comportamiento de un conjunto de clasificadores (p.e. clases). Especifica un contrato de los servicios que proporciona y de los que requiere en trminos de interfaces requeridas y proporcionadas Es una unidad reemplazable que se puede sustituir en tiempo de diseo o ejecucin por otro componente que ofrezca la misma funcionalidad en base a la compatibilidad de sus interfaces. Vista externa vs. Vista interna

Componentes

Un componente es una parte reemplazable de un sistema, que conforma con/y proporciona la implementacin de un conjunto de interfaces. Un sistema basado en componentes est formado por componentes que implementan las interfaces, junto con otros que acceden a los servicios proporcionados por esas interfaces. Servicios independientes de la localizacin y reemplazables. Interfaces proporcionadas vs. Interfaces requeridas.

Propiedades de un componente
Interfaz Componente Especificacin Componente
1 *

1..*

Implementacin Componente
1 *

Instancia Componente

Instalacin Componente

Propiedades de un componente

Es una unidad de despliegue independiente. Puede ser conectado con otros componentes En una aplicacin dada existir una nica copia Es una parte sustituible de un sistema (conforma con una o ms interfaces) Realiza una funcin bien definida (cohesin fsica y lgica) Abarca ms de una colaboracin de clases Existe en el contexto de una arquitectura bien definida. Presupone una infraestructura tecnolgica en la que se piensa utilizar

Componentes
Persona
<<component>>

AsignacionItem

Seguimiento

Pedido

Factura

ItemPedido

Interfaces proporcionadas

Interfaces requeridas

Componentes

<<Interface>> Persona findByNombre() create() getDetalles()

<<component>>

Pedido

<<Interface>> ItemPedido create() validarDetalles() addLineaPedido()

Interfaz proporcionad a

Interfaz requerida

Componentes

JerarquaElementos
explorador.java arbol.java

Componentes

Puertos

Representan un punto de interaccin entre una instancia de un clasificador (clase, componente) con su entorno o con las instancias que contiene (estructura interna). Conjunto semnticamente cohesivo de interfaces. Las interfaces asociadas especifican la naturaleza de la interaccin.

Requeridas: especifican las peticiones que se pueden hacer al entorno Proporcionadas: especifican las peticiones que puede recibir del entorno

Puertos

Los puertos son normalmente parte de un componente Cuando se crea una instancia de un componente, se crean instancias de sus puertos

Un puerto tiene multiplicidad Un puerto tiene identidad: un nombre La instancia de un puerto es un objeto de una clase que implementa las interfaces proporcionadas.

Componente con puertos

Puerto
Reservar
ventas normales atracciones

Cargar espectculos

Ventas Ticket

Vendedor Ticket
Tarjetas Crdito
cobros
ventas prioritarias

Ventas Ticket

Conexin de componentes

:Inventario

:EncontrarItems

:EnviarItems

GestionPedido

Estructura Interna (Componentes)

Una parte es una unidad de implementacin de un componente, que tiene un nombre y un tipo. Una instancia de un componente puede contener una o ms instancias de cada una de sus partes. La estructura interna de un componente est formada por las partes que lo implementan junto con las conexiones entre ellas.

Las partes pueden ser componentes conectados a travs de sus puertos.

Estructura interna
Compilador

lex:AnalizadorLexico

parse: Parser

Compilar

gen: GeneradorCodigo

opt:Optimizador [1..3]

Estructura interna
Venta Ticket Vuelos

:AsignacionAsiento

normal:Venta

:GestionInventario

Prioridad:Venta

Estructura interna
Ventas por Catalogo

:Cumplimentar

:Inventario

:EncontrarItems

:EnviarItems

:PasarPedido :EntradaPedido Cobro:Credito

:CapturaPedido

GestionPedido

Estructura Interna

<<component>>

A I1 b:B I1
<<delegate>>

I2 c:C
<<delegate>>

I2

Conectores

Una conexin entre dos puertos se denomina conector y denota un enlace en una instancia del componente. Los componentes pueden ser conectados directamente o porque tienen interfaces compatibles. Un conector delegacin conecta un puerto interno a uno externo.

Componentes

Subsistemas

Unidad de descomposicin de un sistema que se define como componente con el estereotipo <<subsystem>>. Elemento lgico, en tiempo de ejecucin se pueden instanciar sus contenidos.
<<subsystem>>

GUI

<<subsystem>>

Lgica del Negocio

Contenidos

Modelado del Comportamiento Diagramas de interaccin Diagramas de actividades Mquinas de estado Componentes Modelado de la Implementacin Artefactos y despliegue Diagramas de despliegue Colaboraciones UML, Metamodelado y MDA

Artefactos

Un artefacto es una parte fsica de un sistema que existe a nivel de la plataforma de implementacin. Es una implementacin fsica de un conjunto de elementos lgicos tales como clases y componentes:

Relacin de dependencia estereotipada con manifest

Representan el empaquetamiento fsico de bits sobre la plataforma de implementacin. Residen en nodos.

Artefactos
artifact agente.java artifact agenteFraudes.dll

manifest
artifact agenteFraudes.dll manifest agenteFraudes PolticaFraudes

manifest

PatrnBsqueda

manifest
AgenteFraudes PolticaFraudes PatrnBsqueda

Tipos de Artefactos

Despliegue

Necesarios y suficientes para formar un sistema ejecutable: libreras dinmicas, ejecutables, script,.. Permanecen al final del proceso de desarrollo: archivos cdigo fuente y ficheros de datos a partir de los cuales se crean los artefactos de despliegue. Se crean durante la ejecucin: objeto .NET instanciado a partir de una DLL.

Productos del trabajo

De ejecucin

Estereotipos de Artefactos

<<file>> : Archivo fsico <<deployment spec>> : especificacin de detalles de despliegue <<document>> : Archivo genrico que contiene cierta informacin <<executable>> : Archivo ejecutable <<script>> : Un script ejecutable sobre un intrprete <<source>> : Archivo fuente <<library>> : Una biblioteca como una DLL o un archivo JAR

Modelado de ejecutables
artifact v.exe

artifact Vwbas20.dll

artifact Vwdev20.dll

artifact Wscr20.dll

Nodos

Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional que puede tener memoria y capacidad de procesamiento. Los artefactos se ejecutan en nodos Los artefactos se despliegan sobre los nodos. Dos tipos de nodos:

<<device>> : tipo de dispositivo fsico como un PC o un servidor <<execution environment>> : tipo de entorno de ejecucin de software, como el servidor web Apache o el contenedor EJB JBoss.

Nodos
Ventas
artifact pos.exe
artifact contactos.exe

manifest

manifest

Venta

Contrato

Diagramas de Despliegue

El despliegue es el proceso de asignar artefactos a nodos o instancias de artefactos a instancias de nodos Los diagramas de despliegue muestran el hardware sobre el que se ejecutar el sistema y cmo el software se despliega en ese hardware. Muestra la configuracin de los nodos que participan en la ejecucin y de los artefactos que residen en los nodos.

Forma de descriptor y forma de instancia Incluye nodos y arcos que representan conexiones fsicas entre nodos (o instancias de nodos y arcos).

Modelado de sistemas empotrados, sistemas clienteservidor, sistemas distribuidos.

Nodos

<<device>> PC Windows

<<device>> PC Linux

0..*
<<http>>

0..*

<<execution environment>>
FireFox

<<execution environment>> Apache

Diagrama de Despliegue

terminal

<<10-T-Ethernet>>

servidor

Unidad RAID

<<RS-232>> Consola

Contenidos

Modelado del Comportamiento Diagramas de interaccin Diagramas de actividades Mquinas de estado Modelado de la Implementacin Diagramas de componentes Diagramas de despliegue Colaboraciones UML, metamodelado y UML

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 (modelo de clases) y parte de comportamiento (modelo de interaccin).

Colaboraciones

El ncleo de la arquitectura de un sistema est formado por un conjunto de colaboraciones que representan las decisiones de diseo ms importantes. Un sistema orientado a objetos bien estructurado se compone de un conjunto relativamente pequeo de colaboraciones. Modelado de un caso de uso, operacin o mecanismo (patrn o framework)

Casos de uso y Colaboraciones

caso de uso

colaboracin
Hacer Pedido

Gestin Pedidos

realizacin

Modelo Estructural

Modelo Comportamiento
: Usuario 11: recalcularTotal() 1: aadirItem(codigo) 4: aadirItem(codigo) 2: aadirItem(codigo) 3: [primer producto] crear()

: MostrarProductos

: Aadir

: CarroCompras

6: [!nuevoItem]incrementarUnidades()

10: [nuevoItem]put(codigo,i)

5: i:=getItemCarro(codigo)

7: [nuevoItem]p:=get(codigo)

9: [nuevoItem]i:=creaItem(p)

: ItemCarro

: CatalagoProductos i : ItemCarro 8: [nuevoItem]p:=buscar(codigo)

: Producto

Ejercicio
Disea una colaboracin de un mecanismo Object Trading que separa la representacin de una informacin de su presentacin y edicin; las clases que representan a los objetos informacin no conocen a las clases que representan editores y viceversa. Un mismo editor puede editar diferentes tipos de informacin y una misma informacin puede ser editada por diferentes editores. El propsito del mecanismo es seleccionar un editor que colaborar adecuadamente con el objeto informacin, crear un objeto editor y lo ligar con el objeto informacin. Un objeto cliente solicitar a un objeto Trader editar cierta informacin.

Mecanismo trading (Parte esttica)

ClienteDeGestor 1..n 0..n 1..1

Trader 1..1 1..n

FactoriaEditor 1..1 especifica

necesita editar 1..1 ObjetoInformacion 1..n 1..n editado con 1..n Editor

Mecanismo trading (Comportamiento)

: ClienteDeGestor : Trader : FactoriaEditor info : ObjetoInformacion

editar(info) * i:= getInterfaz()

p:= soportaInterfaz(i)

[p] crearEditor(info) <<create>> : Editor

Clases Cliente, Editor y ObjetoInformacion?

Colaboraciones Plantilla
Modelado de patrones de diseo
Subject Observer
Observer Subject Observer

Alarma

Ventana

Patrn de diseo (Parte Esttica)

Subject subjectState Attach() Detach() Notify()

+observers 1..1 1..*

Observer

Update()

for all o in observers {o->update}

ConcreteSubject subjectState getState() setState()

+subject

ConcreteObserver observerState update()

observerState= subject->getState()

Patrn de diseo (Parte dinmica)

: Otra :Cliente 1. setEstado() 1.1. notify() 1.1.1. update() 1.1.2. update() : Subject :Subject o1 : Observer o1:Observ er o2 : Observer o2:Observ er

Contenidos

Modelado del Comportamiento Diagramas de interaccin Diagramas de actividades Mquinas de estado Modelado de la Implementacin Diagramas de componentes Diagramas de despliegue Colaboraciones UML, Metamodelado y MDA

Lenguajes OMG

MOF (Meta Object Facility) UML Perfiles UML OCL Action Semantics

Definir semntica de modelos de comportamiento Muy bajo nivel No define una sintaxis concreta Lenguaje estndar para definir transformaciones

QVT

Metamodelado

Un lenguaje de modelado o DSL se define formalmente mediante un metamodelo:

Sintaxis abstracta y restricciones Sintaxis concreta Semntica

OMG

Necesidad de un lenguaje de metamodelado:

MOF: EMOF y CMOF

Eclipse (EMF, Eclipse Modeling Framework)

Ecore

Otros: Herramientas de metamodelado existentes disponen de uno propio (XMF, Metaedit+, DSL Tools,...)

Metamodelado

Un metamodelo define los elementos de un lenguaje de modelado y las relaciones entre ellos, y las restricciones (semntica abstracta). Un metamodelo define formalmente un lenguaje de modelado o DSL. Crear un metamodelo es una actividad de modelado conceptual OO

Necesidad de conocer bien el dominio

Metamodelado
context StateMachine inv: EstadosDistintoNombre states-> forAll (s1 | states->forAll (s2 | s1.name = s2.name implies s1 = s2)) end
0..1 StateMachine 0..1

Event 0..n 1 +top 0..n State

+states

0..1 +trigger 0..n 0..n +transitions Transition

0..1

0..n

Sintaxis abstracta de una mquina de estados

CompositeState

Metamodelado
after (2 sec) send c.estaActivo

ruido

Inactivo

Buscando

objetivoEn(p) [representaAmenaza] / t.aadirObjetivo(p)

Rastreando
contactar

Acoplamiento

Sintaxis concreta de una mquina de estados

Metamodelado

MOF y Ecore se basan en elementos de modelado orientado a objetos:

Clases y Atributos Asociaciones en MOF y referencias entre objetos en Ecore Agregacin en MOF Generalizacin Paquetes

MOF (MetaObject Facility)

MOF es el lenguaje para crear metamodelos propuesto por OMG para MDA.

UML est definido como un metamodelo MOF. Aplicable a cualquier dominio. Lenguajes OMG: CWM, EJB, EAI, EDOC

Medio universal para definir lenguajes de modelado

Independiente de la plataforma

MOF (MetaObject Facility)

MOF es descrito con la notacin UML, OCL y texto informal. La notacin para metamodelos MOF es la sintaxis concreta de UML: Puede generar confusin al principio! Comparte elementos de modelado con UML: clases, atributos, generalizacin, etc.

MOF

Cada elemento del lenguaje de modelado se representa mediante una clase y sus propiedades como atributos Las relaciones entre elementos se representan como asociaciones. La generalizacin permite expresar que un elemento es una especializacin de otro. Se usa OCL para expresar la semntica esttica. Uso de paquetes si el metamodelo es muy grande

Arquitectura de cuatro niveles en MDA

Nivel M3 M2 M1 M0

Descripcin
MOF metamodelos, instancias de los elementos MOF modelos, instancia de un metamodelo MOF el sistema, objetos y datos, instancias de los elementos de un modelo

Arquitectura de cuatro niveles: Ejemplo

Nivel M3 M2 MOF Metamodelo de UML Ejemplo Elementos
Clase, Atributo, Asociacin,.. Clase, Atributo, Asociacin, Estado, Actividad, Caso de uso, Clase Cliente, atributo dni, asociacin Cliente-Pedido Cliente Pepe Prez, 87654321, Cliente Ana Haro, 1234567,

M1 M0

Modelo de clases UML para un sistema TPV Instancias de elementos en el modelo de clases del TPV

Arquitectura de cuatro niveles

OCL (Object Constraint Language )

Lenguaje de especificacin para escribir expresiones sobre modelos, p.e. queries, reglas de derivacin 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 ms precisos y ms completos. Es tipado, cada expresin OCL tiene un tipo. Utilizado para escribir las restricciones

Expresiones OCL
context c : Empresa inv suficientesEmpleados: c.numeroEmpleados > 50

context Empresa inv: self.empleados.select(p: Persona| p.edad>50)->notEmpty()

context Trabajo inv: self.empleador.numeroEmpleados >= 1 inv: self.empleado.edad > 21

Expresiones OCL
context Person::cumpleaos() post: edad = edad@pre + 1

context Empresa::contratar(p : Persona) post: empleados = empleados@pre->including(p) and precioAccion() = precioAccion@pre() + 10 context Persona::getEsposoActual() : Persona pre: self.estaCasada = true body: self.matrimonios->select( m | m.fin = false ).esposo

MDA

Propuesta basada en estndares de OMG: UML, MOF, XMI, JMI, QVT,... Separa la especificacin de la funcionalidad del sistema de su implementacin sobre una plataforma concreta. Distincin entre PIM y PSM Basada en la arquitectura de cuatro niveles

MOF es el lenguaje de metamodelado

MDA
PIM PSM

Cdigo

Modelo independiente de la plataforma

Modelo especfico de la plataforma

Nuevo paradigma de desarrollo de software:

Desarrollo dirigido por modelos

MDA
Transformaciones de modelos en MDA

PIM
L1
UML

Motor M2M

PSM
L2
UML

Motor M2C

Cdigo
L3

Definicin Transformacin L1 a L2
L4
Lenguaje M2M

Definicin Transformacin L2 a L3
L5

Java, C# XML, SQL,

Lenguaje M2C

PIM

PSM

Cdigo
public interface Cuenta extends EJBObject {...} public interface CuentaHome extends EJBHome {...} public abstract class CuentaBean implements EntityBean{...} ...

MDA

PIM

PSM Relacional

PSM EJB

PSM Web

Cdigo SQL

Cdigo EJB

Cdigo JSP/Servlets

307