Leng Unified Modelado

Proceso Software
Captulo 1
El Lenguaje Unificado de Modelado, UML
Francisco Javier Bermdez Ruiz fjavier@um.es Departamento de Informtica y Sistemas Universidad de Murcia
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 Componentes
2
Contenidos
Modelado del Comportamiento Diagramas de interaccin Diagramas de actividades Mquinas de estado Modelado de la Implementacin Artefactos y despliegue Diagramas de despliegue Colaboraciones Formalizacin de UML: MOF y metamodelo
3
Bibliografa
G. Booch, J. Rumbaugh, I. Jacobson, El lenguaje unificado de modelado, 2 Edicin, Addison-Wesley, 2006. C. Larman, UML y Patrones: Una introduccin al
anlisis y diseo orientado a objetos y al proceso unificado,
Prentice-Hall, 2003. 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
5
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.uml.org
6
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)
8
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, 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.
10
Modelado del Software

El modelado es el 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
11
Utilidad del modelado
Una empresa software con xito es aquella que produce de manera consistente software de calidad que satisface las necesidades de los usuarios
El modelado es la parte esencial de todas las actividades que conducen a la produccin de software de calidad
12

Por qu no escribo cdigo directamente?
Sera lo ideal pero .... .... necesitamos escribir modelos, aunque la mayora de desarrolladores todava no practican el modelado
13
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?

Hay estructuras que trascienden lo representable en un lenguaje de programacin. Se facilita la comunicacin entre el equipo al existir un lenguaje comn. Se dispone de documentacin que trasciende al proyecto.
15

Visualizar cmo es o queremos que sea el sistema Especificar la estructura y comportamiento del sistema Proporciona plantillas que guan la construccin del sistema. Documentan las decisiones.
16
Modelos en otras reas
17
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.
18
Qu es un modelo software?
Un modelo es una descripcin de un aspecto del sistema, escrita en un lenguaje bien definido.
Diferentes tipos de modelos:
Anlisis vs. Diseo, Comportamiento vs. Estructural Negocio vs. Software Nivel de detalle ....
19
Un modelo software
Usuario nombre 1 nif 1 0.. n Pedido id tot al 1 1..n LineaPedido unidade s 0..n
1 CarroCompra total ItemCarro unidades
1 Product o nombre preci o desc ripcion
0..n
0..n
20
Modelos en UML
Modelado de Casos de Uso
Diagrama de Casos de Uso
Modelado Estructural
Diagrama de Clases
Diagramas no son modelos
Modelado de Comportamiento
Diagramas de Interaccin Diagramas de Estados
Modelado de flujos de Actividades

Diagramas de actividades
Modelado Implementacin
Diagrama de Componentes
Modelado de Despliegue
Diagramas de Despliegue
21
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.
22
Modelos de Negocio y de Software

Modelo del Negocio
derivado de
describe
Modelo Software
describe
Empresa
Sistema software
Sistema de la empresa
23
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.
24
Construimos software de calidad?

Retrasos en los plazos Proyectos cancelados Rpido 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 solucin?
25
Contenidos
Modelado del software
Presentacin de UML
Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases
26
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

27
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
Mecanismos comunes
Especificaciones, Extensibilidad, Dicotoma clase-instancia, Dicotoma interfaz-realizacin
28
Elementos Estructurales
Partes estticas de un modelo
Ventana origen tamao abrir() cerrar() mover() dibujar()
<<Interface>> IAvisable
colaboracin
IAvisable
Interface
Gestin Pedidos
clase
ValidarTransaccion
caso de uso
29
Elementos Estructurales
Gestor Eventos suspender() vaciarCola()
clase activa
FormularioPedido
componente
<<artifact>>
window.dll
Servidor
nodo artefacto
30
Elementos de Comportamiento
Son las partes dinmicas de UML.
Interaccin Conjunto de mensajes intercambiados entre un conjunto de objetos con un propsito particular.
dibujar
mensaje
31
Elementos de Comportamiento
Son las partes dinmicas de UML.
Mquina de estados Secuencia de estados por las que pasa un objeto durante su vida en respuesta a eventos.
activado
estado
32
Elementos de Agrupacin
Son las partes de organizacin de los modelos UML
Modelo del Negocio
paquete
Un paquete incluye un conjunto de elementos de cualquier naturaleza. Tiene una naturaleza conceptual.
33
Elementos de Anotacin
Son las partes explicativas de los modelos UML
Retorna 0 si no existe el valor
Nota
34
Relaciones
Dependencia
0..1 *
patron
empleado
Asociacin
Generalizacin Realizacin
35
Ejemplo
IteradorCuenta
Cuenta 1 0..n
Domiciliacion
Ahorro
Corriente Operacion Periodica
36
Pedido Desayuno direccin fecha hora descuento calcularPrecio() +pedido 1 Cliente +pedidos 1.. n +cliente 1 crearPedido() numeroCuent a direccion
+des ayuno
1..n Desayuno numero 0..n
Desayuno Estandar nombre precio estilo 0.. n Comestible nombre cantidadMinima precio 1..n formaTransporte Parte cantidad
Cambio cantidad
0..n
Diagramas de UML
Diagrama de Clases Diagrama de Objetos Diagramas no Diagrama de Componentes son modelos Diagrama de Estructura Compuesta 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
38
Modelos en UML
Diagrama de Casos de Uso
Diagrama de Clases
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
Modelado Implementacin
Diagrama de Componentes
Modelado de Despliegue
Diagramas de Artefactos Diagramas de Despliegue
39
Responsable
Servicio PE
Alumno
Sistema
Registrar Curso Aprobar Curso Preinscripcin
Modelo del Negocio

Avisar Admitidos
Matriculacin Hay alumnos?
no Cambiar admitidos
Hay alumnos? no
Cancelar Curso
Diagrama de actividades
Crear Proyecto Cerrar Curso
R eali zar puja ordinari a
C errar edic in de s ubas ta
Pujador
C anc elar puja ordinaria R ealizar pago de s ubas ta ordinaria
R ec h azar ad judic ac in Sis tem a N otif icar adjudicatario Teleoperador Participant e
C rear edic in de s ubas ta
Anular anunc io de s ubast a
Adm inis trador Anular edic i n de suba s ta
Modelo Casos de Usos
Diagrama de casos de uso
Partic ipante n omb re a pelli dos n umI D d omic i lio d ir ecc i onEnv io t el efono r eput ac i on
Diagrama de clases
Modelo Estructural
+p +pa +pc PujaOrdinaria dato s Tarjet a es ta do +puja Adjudic ac ion
PagoAnunc io
+as
PagoC uota +as
+art Es to repres enta la es pec if ic ac in de un artc ulo.
+pujas +adjudic ac iones Anunc ioSubas ta Edic ionSubas ta idEdic ion f ec haInic io f ec haC ierre es tado +anunc ios +es p v pR ec om end p uja Mini ma c uota g as to s Env io p laz o f orm aPago a nti ci po +a rt ic u los Artic uloC onc reto c o dArt ic u lo +artic ulos Artic ulo idEs pe c c a rac ter is ti c as pv p Re c om end
1. cerrarEdi ci onSubasta(es) : Control adorAnunci os : Si stem a 2. cerrar()
i nt num Aj udi caci ones = M i ni m o(puj as.l ength(), arti cul os.l ength());
Diagrama de comunicacin
5. num Adj s = cal cul arAdj udi caci ones()
9. [1..num Adj s]* add(adj ) 4. * cerrar() : Anunci oSubasta 3. * as := ge t() : Edi ci onSubasta as : Anunci oSubasta adj udi caci ones : Ad j udi c ac io n
8. [1..num Adj s]* adj := crear(as, pg, a) 6. [1..num Adj s]* pg := g et () puj as : Pu j aOrdi naria 7. [1..num Adj s]* a: = get()
Se recorre l a col ecci n de puj as obteni endo l as puj as ganadoras (consi deram os que l a col ecci n est ordenada de m ayor a m enor val or de puj a).
ad j : Adj udi caci on : Arti culo Concre to Se crean tantas adj udi caci ones com o puj as ganadoras haya. Cada adj udi caci n se asoci a con un Arti cul oConcreto, una puj a adj udi catari a y con l a 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
44
Mecanismos comunes de UML

Dicotoma clasificador /instancia
Persona nombre direccion telefono
Elena
Elena : Persona
: Persona
45

Dicotoma interfaz / implementacin
IOrtografia IDiccionario
asistenteOrtografico
IUnknown
46

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.
47
Mecanismos 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.
Valores etiquetados
Extienden las propiedades de un estereotipo, permitiendo crear nueva informacin en la especificacin del estereotipo. Par etiqueta/valor: { etiqueta = valor }
Restricciones
Especifican condiciones que una configuracin de tiempo de ejecucin debe satisfacer para conformar con el modelo.
48
Ejemplos de estereotipos predefinidos

Clase estereotipada Clase estereotipada
<<Interface>> IComparator compare()
<<Actor>> Cl iente
IComparator
Cl iente
49

estereotipo
<<authored>> ColaEventos <<Exception>> aadir() quitar() vaciar() <<authored>> version: 3.2; autor: jgm
valor etiquetado
Overflow
{ordenado}
restriccin
50

Empresa
Cuenta
{xor}
restricciones
Persona sexo
0.. 1 +esposa
0..1 +esposo
{Self.esposa.sexo = mujer and self.esposo.sexo = hombre}
51
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()
52
Diagrama de Clases
Applet
HolaMundo paint()
Graphics
(from awt)
53
Component (from awt) ImageObserver

(from im age)
imageUpdate() Container
(from awt)
Panel
(from awt)
Applet
HolaMundo paint()
Graphics
(from awt)
Organizacin en Paquetes
Hol aMundo paint()
java (from Logical View)
55
Diagrama de Secuencia
root : Thread : Toolkit : ComponentPeer target : HolaMundo
run callbackLoop
handleExpose
paint
56
Diagrama de Artefactos
HolaMundo <<manifest>> <<artifact>> HolaMundo.class <<manifest>> hola.java
hola.html
hola.jpg
57
Contenidos
Introduccin al modelado del software
Presentacin de UML Modelado de Casos de Usos

Diagramas de casos de uso Modelado Estructural Diagramas de Clases
58

Un caso de uso especifica un comportamiento deseado del sistema. Representan los 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.
59

Partes 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 Un caso de uso realiza un trabajo tangible.
60
Emisor
Centralita
Receptor
listo( )
tono
marcar_numero
tono_sonando timbre_sonando
Escenario
para_tono
telefono_cogido
para_timbre
Casos de uso son ideados por Jacobson a principios de los noventa, Inspirados en los escenarios utilizados para describir procesos.
Otras definiciones de caso de uso

Describe un conjunto de interacciones entre actores externos y el sistema en 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]
62
Ejemplo Caso de Uso

actor caso de uso
Re s ponsabl e Pr est amo s
Ges tionar P rs tam os
asociacion
63
Ejemplo de caso de uso

Realizar Venta (en un terminal de punto de venta)
Actor : Cajero Secuencia: 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. 5. El sistema calcula el total de la compra y lo muestra.
64
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 automticamente por el sistema) No forman parte del sistema.
65
Actores
Un usuario puede jugar diferentes roles. En la realizacin 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.
66
Actores
Dos tipos de actores:
Principal: Requiere al sistema el cumplimiento de un objetivo Secundarios: El sistema necesita de ellos para satisfacer un objetivo
67
Escenarios y Casos de Uso

Un caso de uso describe un conjunto de secuencias de interacciones entre actores y el sistema (escenarios): flujo principal y flujos alternativos o excepcionales. Un escenario es una instancia de un caso de uso Un escenario es una historia particular de uso de un sistema. Escenarios principales vs. Escenarios secundarios
68
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.
69
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.
Describir el flujo de eventos

Texto estructurado informal Texto estructurado formal (plantillas) Pseudocdigo Notaciones grficas: diagramas de secuencia
Debe ser legible y comprensible para un usuario no experto. Debe indicar: actores, flujos principal y excepcionales.
70

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

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

Validar Usuario (en un cajero automtico)
Flujo Principal: El sistema pide el NIP. El cliente lo introduce a travs del
teclado y pulsa Enter. El sistema comprueba la validez del NIP. Si es vlido el sistema acepta la entrada y finaliza el caso de uso.
Flujo Excepcional: El cliente puede cancelar la transaccin en cualquier

momento, pulsando el botn Cancelar, reiniciando el caso de uso.
Flujo Excepcional: Si el NIP introducido es invlido entonces se reinicia el

caso de uso. Si esto ocurre tres veces, el sistema cancela la transaccin completa y se queda con la tarjeta.
73
Cajero
Realizar Venta
Cliente
:Sistema
: Cajero crearNuevaVenta() * introducirItem(upc,cantidad) finalizarVenta() hacerPago(cantidad)
Ejemplo diagrama de casos de uso

Registrar curso
Responsable
Rebajar Mnimo
Aprobar curso
Servicio CPE
Cerrar curso Crear proyecto Servicio Contabilidad
Fin matriculacion
Realizar preinscripcin
Sist ema
Avisar admitidos Alumno
Matriculacin Cancelar curso

Actores Secundarios
Alumno
Realizar preinscripcin
Gest in Expedient es
Actor Principal
Matriculacin Ent idad Banc aria
Reservar Libro
Prestamo revista
Profesor
Prestamo Libro
Devolver revista
Socio Devolver libro Actualizar catalogo
Bibliotecario
Extender Prestamo
Consultar
Socio
77
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).
78

caso de uso colaboracin
Hacer Pedido
Gestin Pedidos
realizacin
79
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
80
Organizacin de Casos de uso

Tres tipos de relaciones: Generalizacin
Un cdu hereda el comportamiento y significado de otro
Inclusin
Un cdu base incorpora explcitamente el comportamiento de otro en algn lugar de su secuencia.
Extensin
Un cdu base incorpora implcitamente el comportamiento de otro cdu en el lugar especificado indirectamente por este otro cdu
81
Ejemplo
Relacin de extensin
extend
Hacer Pedido
(establecer prioridad)
Hacer Pedido Urgente
include
Relacin de inclusin
Comprobar clave
Validar Usuario
Generalizacin
Seguir Pedido
include
Examinar retina
82
Relacin de inclusin
Permite factorizar un comportamiento en un caso de uso aparte y evitar 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
83
Relacin de extensin
El caso de uso base incluye una serie de puntos de extensin. 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
84
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.
85
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.
86
Plantilla para casos de uso

Caso de Uso Descripcin Actores Asunciones Pasos
identificador / historia objetivo a conseguir lista de actores
(D. Coleman)
condiciones que deben cumplirse interacciones entre los actores y el sistema necesarias para obtener el objetivo
Variaciones (opcional) cualquier variacin en los pasos No-funcional (opcional) lista requisitos no funcionales Cuestiones lista de cuestiones que permanecen por
resolver
87

Ejemplo campo pasos:
(D. Coleman)
1. Operador es notificado de problema en la red 2. Operador inicia una sesin de reparacin 3. REPETIR 3.1. Operador ejecuta aplicacin diagnsticos en la red. 3.2. Operador identifica elementos que deben cambiarse y sus nuevos valores para los parmetros. 3.3. EN PARALELO 3.3.1. Ingeniero mantenimiento comprueba elementos en la red || 3.3.2. Ingeniero mantenimiento enva informe fallo 4. Operador cierra sesin
88
(D. Coleman)
Relacin de uso: PERFORM c.d.u. Relacin de extensin:

Caso de uso extensin c.d.u. extends c.d.u. Cambio objetivo que debe conseguirse Pasos ... Variaciones ... No funcional ... Cuestiones ...
89
Plantilla usecases.org (Larman)

Actor Principal Personas involucradas e Intereses Precondiciones Postcondiciones Escenario Principal (Flujo Bsico) Extensiones (Flujos Alternativos) Requisitos especiales Tecnologa y Lista Variaciones de datos Frecuencia Cuestiones abiertas
90
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 se identifica y autentica Postcondiciones: Se registra la venta. Se calcula el impuesto. Se actualiza contabilidad e inventario...
91

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
92

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

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?
94
Por qu 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.
95
Crticas a los casos de uso
(B. Meyer)
Los casos de uso no son adecuados en el modelado orientado a objetos porque:

i) Favorecen un enfoque funcional, basado en procesos ii) Se centran en secuencias de acciones iii) Se basan en los escenarios actuales del sistema
Solo deben ser usados por equipos expertos en desarrollo OO tiles para validacin
96
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 confusin sobre cmo usarlos.
Nmero de casos de uso apropiado en un proyecto? Qu casos de uso hay en el sistema?
97
Granularidad
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.
98
Granularidad
Casos de uso del negocio
Procesos de Negocio: Objetivo estratgico de la empresa (Ej. Vender productos)
Casos de uso del sistema

Objetivo de un usuario (Ej. Realizar una compra)
Casos de uso de inclusin

Forman parte de otro, son como subfunciones (Ej. Buscar, Validar, Login, )
99
Tipos de casos de uso

Segn el nivel de detalle
Breve : Descripcin en unas pocas lneas Informal : Varios prrafos que cubren varios escenarios Expandido : Descripcin detallada con una plantilla
Segn la importancia
Primario, secundario u opcional
Segn el nivel de abstraccin

Esencial : Qu hace el sistema? Concreto : Se contemplan detalles de implementacin (GUI y tecnologa)
100
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
101
Recomendaciones
Qu granularidad es apropiada para un caso de uso?
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 Introducir datos facturacin ?
Error comn: no identificar como casos de uso las tareas que inicia el propio sistema
Anular reservas pasados quince das
102
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 DESCOMPOSICION FUNCIONAL!
Escribir casos de uso independientes de la interfaz o de detalles de implementacin, escribirlos a nivel esencial. A qu nivel de detalle se describe un caso de uso?
Primero informal, luego expandido
103
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. Los casos de uso slo consideran los requisitos funcionales del proyecto, hay que aadir los nofuncionales.
104
Referencias
http://alistair.cockburn.us/usecases/usecases.html
A. Cockburn,Writing effective uses case, AddisonWesley, 2000 C. Larman, UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado, Prentice-Hall, 2003.
105
Contenidos
Introduccin al modelado del software
Presentacin de UML
Modelado de Casos de Usos Diagramas de casos de uso
Diagramas de Clases
106
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 y colaboraciones
Un diagrama de clase es una representacin grfica de un modelo estructural.

107
Modelado estructural
Diferentes perspectivas. Modelado Conceptual
Conceptos del dominio del problema: atributos, restricciones y relaciones entre ellos.
Modelo del Anlisis

Clases que corresponden a conceptos del dominio Atributos y mtodos
Modelo de Diseo
Incluye clases que corresponden a decisiones del diseo
Modelo de Implementacin
Clases que corresponden a un lenguaje de programacin
108
+des ayuno
Modelo Conceptual
Cambio cantidad
0..n
Del Modelo Conceptual a las clases

Los modelos de anlisis se obtienen a partir del modelo conceptual:
Conceptos se convierten en clases Atributos de un concepto a atributos de la clase Aadir comportamiento (mtodos)
110
Partic ipante n omb re a pelli dos n umI D d omic i lio d ir ecc i onEnv io t el efono r eput ac i on
Modelo Conceptual o de Anlisis?
PagoAnunc io +pa +pc PagoC uota
+p PujaOrdinaria dato s Tarjet a es ta do +puja Adjudic ac ion
+as
+art Es to repres enta la es pec if ic ac in de un artc ulo.
+as
+pujas +adjudic ac iones Anunc ioSubas ta Edic ionSubas ta idEdic ion f ec haInic io f ec haC ierre es tado +anunc ios +es p v pR ec om end p uja Mini ma c uota g as to s Env io p laz o f orm aPago a nti ci po +a rt ic u los Artic uloC onc reto c o dArt ic u lo +artic ulos Artic ulo idEs pe c c a rac ter is ti c as pv p Re c om end
Del anlisis al diseo

Se elige un lenguaje de programacin y una plataforma. Aparecen las clases del diseo
Interfaces Patrones de diseo Estructuras de datos Persistencia Distribucin
112
IteradorCuenta
Modelo de diseo
Cuenta 1 0..n
Domiciliacion
Ahorro
Corriente Operacion Periodica
1. cerrarEdi ci onSubasta(es) : Control adorAnunci os : Si stem a 2. cerrar()
i nt num Aj udi caci ones = M i ni m o(puj as.l ength(), arti cul os.l ength());
5. num Adj s = cal cul arAdj udi caci ones()
9. [1..num Adj s]* add(adj ) 4. * cerrar() : Anunci oSubasta 3. * as := ge t() : Edi ci onSubasta as : Anunci oSubasta adj udi caci ones : Ad j udi c ac io n
8. [1..num Adj s]* adj := crear(as, pg, a) 6. [1..num Adj s]* pg := g et () puj as : Pu j aOrdi naria 7. [1..num Adj s]* a: = get()
Se recorre l a col ecci n de puj as obteni endo l as puj as ganadoras (consi deram os que l a col ecci n est ordenada de m ayor a m enor val or de puj a).
ad j : Adj udi caci on : Arti culo Concre to Se crean tantas adj udi caci ones com o puj as ganadoras haya. Cada adj udi caci n se asoci a con un Arti cul oConcreto, una puj a adj udi catari a y con l a subasta.
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
115
Colaboracin (parte esttica)

Usuario nombre nif email login 1 clave 1 Pedido numero tipoPago estado 1 caducidad ItemPedido unidades total 0..n
0..n
1..n
1 CarroCompra precio items 1 1.. n It emCarro unidades total 0..n 1
1 Producto nombre desc ripcion precio
116
Colaboracin (parte dinmica)

: 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
117
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()
118
Patrn de diseo (parte dinmica)

: Subject 1. setState() 1.1. notify() 1.1.1. update() 1.1.2. update() o1 : Observer o2 : Observer
119
Ingeniera directa e Inversa

Ingeniera directa
Transformar modelos en cdigo en un lenguaje de programacin determinado
Ingeniera inversa
Obtener un modelo a partir de cdigo. Ms difcil ya que hay prdida de informacin al pasar de los modelos al cdigo.
120
Clases
Cuenta ultimoCodigo codigo cliente saldo ultimasOperaciones getSaldo() getUltimasOperaciones() nuevoCodigo()
Atributos
Operaciones
No se tienen por qu mostrar todos los atributos y mtodos Agrupar los mtodos usando estereotipos: <<constructor>>, <<query>>,...
121
Interfaces
Una interfaz es una coleccin de operaciones que especifica los servicios de una clase o componente.
<<Interface>> Coll ection add() remove() size() contains() iterator()
<<Interface>> Iterator next() hasNext()
122
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 o por defecto
valor_inicial:
propiedades: {frozen} {addOnly}

123
Atributos : Ejemplos
origen + origen origen : Punto nombre : String [0..30] origen : Punto = (0,0) id : Integer {readOnly}
124
Atributos
Cliente nombre : String
Nivel Conceptual: Los clientes tienen un nombre Nivel de Especificacin: El cliente puede almacenar y consultar su nombre Nivel de Implementacin: Una instancia de Cliente tiene un campo de tipo String que almacena su nombre y un mtodo que lo devuelve
125
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}
126
Operaciones
dibujar + dibujar set (nombre : String) getID(): Integer arrancar() {guarded} Formato parmetro:
[direccion] nombre : tipo [= valor-por-defecto] direccion puede ser : in, out o inout
127
Clases Parametrizadas
G
Clase Parametrizada
Tabla count capacity put(G) item() : G
bind <Empleado>
Empleados
Instanciacin
Tabla<Cliente>
128
Otras propiedades
Clases y mtodos abstractos Multiplicidad Variables y mtodos de clase
Cuenta ultimoCodigo codigo cliente saldo ultimasOperaciones getSaldo() getUltimasOperaciones() nuevoCodigo()
CatalogoPedidos 1
Figura visualizar() rotar() trasladar()
pedidos instance addPedido() removePedido() getInstance()
129
Clases Estereotipadas
<<metaclass>> MetaclaseCuenta
<<exception>> FueraRango
Clases y valores etiquetados

Cuenta {autor: jgm, version: 2.0} ultimoCodigo codigo cliente saldo ultimasOperaciones getSaldo() getUltimasOperaciones() nuevoCodigo()
130
Relaciones
Dependencia
Un cambio en la especificacin de un elemento afecta a otro
PlanDelCurso
Window position parent children size open() close() move() resize()
Curso aadir(c : Curso) eliminar(c : Curso)
Clock
Nodo <<friend>>
Lista
131
Estereotipos para dependencias

bind: entre una clase genrica y una instanciacin friend: dependencia de clase amiga refine: relacin de refinamiento use: relacin de uso import: un paquete importa los elementos de otro. extend: para casos de uso include: para casos de uso
132
Relaciones
Generalizacin
Es-un-tipo-de
Cuenta
Window
CuentaAhorro
CuentaCorriente
TextWindow
BoxDialog
133
Generalizacin
Nivel Conceptual
Todas las instancias de CuentaCorriente son instancias de Cuenta
Nivel Especificacin
La interfaz de CuentaCorriente incluye la interfaz de Cuenta Principio Sustitucin
Nivel Implementacin
Herencia
134
Relaciones
Asociacin
Relacin estructural que especifica que los objetos de un tipo estn conectados con los de otro.
Persona
+empleado 1..*
+patron *
Empresa
Curso
*
impartido
1..*
Profesor
135
Asociaciones
Agregacin
Caso especial de asociacin Relacin estructural parte-de
Empresa 1..1
* Departamento
136
Asociaciones
Nivel Conceptual
Muestran la relacin conceptual entre dos clases. Un cliente tiene varios pedidos
Nivel de Especificacin
Representan responsabilidades Detectamos los mensajes del protocolo de una clase con respecto a la otra
Nivel de Implementacin
Establecer atributos: navegabilidad
137
Asociaciones
Especificacin:
class Pedido { public Cliente getCliente(); public Set getLineaPedido();... }
Implementacin
class Pedido { private Cliente private HashSet _cliente; _lineasPedido; }
138
Navegacin
Posibilidad de limitar la navegacin a una sola direccin Determina si una clase de la asociacin tiene conocimiento de la otra. Nivel de especificacin o implementacin
Curso *
impartido 1..*
Profesor
139
Visibilidad
Pblica: Protegida: Privada: Paquete: + # ~ propietario propietario propietario propietario
GrupoUsuarios 0..n 0..n
Usuari o
+propi etari o 1
-cl ave 0..n
Clave
140
Asociaciones calificadas
Pedido numero tipoPago producto estado caducidad 1 ItemPedido unidades total
Nivel Conceptual: Dentro del mismo pedido no pueden existir dos lneas con el mismo producto Nivel Especificacin: El acceso a ItemPedido es indexado por productos Nivel Implementacin: Se usa una tabla para almacenar las lneas de pedido
141
Asociaciones calificadas
Class Pedido { private Hashtable _lineasPedido;
public ItemPedido getItemPedido(Producto unProducto); public void addItemPedido (Integer cantidad, Producto elProducto); }
142
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
143
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.
144
Composicin
W indow 1 1 1
agregado
+scrollbar Slider
2
+title
1 +body Panel
Header
partes
145
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.
146
Ejemplo de clase asociacin

Persona +empleado 1..n +patron 0..n Empresa
Contrato salario descripcion fechaContrato
Distinta semntica
Contrato Persona 1 salario descripcion 0..n fechaContrato Empresa 1..n 1
147
Asociaciones derivadas
Cliente nombre direccion email 1 /facturaCliente
Asociacin Derivada
0..n Pedido numero tipoPago estado 1 caducidad 0..n Factura numero fecha total
0..1
148
Asociaciones derivadas
recib e Estudiante Asignatura
/ensea
i mp arte
Profesor
Asociacin Derivada
149
Restricciones para Asociaciones

Empresa
D ep arta me nto * *
Cuenta
{or}
Persona
{subconjunto}
+m ie mb ro 1..* Persona +Director 1 ..1
150
Restricciones para Asociaciones

operario
empleado
patrn
* 0..1
jefe
Persona
0..1
Empresa
{ Persona.patrn= Persona.jefe.patrn }
Un operario trabaja para la misma empresa que su jefe

151
Realizacin
Relacin entre clasificadores, un clasificador especifica un contrato que otro clasificador garantiza que cumplir.
<<Interface>> ICollection List add() remove() contains()
List
ICollection
152
Clases Abstractas e Interfaces

Interfaz
DataInput
(from io)
I nputStream
(from io)
InputStreamReader
(from io)
Clase Abstracta
FilterInputStream
(from io)
DataInputStream
(from io)
153
Clases Abstractas e Interfaces

InputStream <<Interfac e>> DataInput
(from io) (from io)
InputStreamReader
(from io)
Interfaz
FilterInputStream
(from io)
DataInputStream
(from io)
154
Interfaces, tipos y roles

Una interfaz es una coleccin de operaciones que especifican los servicios de una clase o componente. 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. Las interfaces modelan las lneas de separacin o puntos de conexin (seams) de un sistema.
155
Interfaces
Interfaz requerida Interfaz proporcionada
Observer
Target
TargetTracker
Observable
Target id posicionActual setPosicion() setVelocidad() posicionEsperada() <<Interface>> Observer update()
Target Track er
156
Contenidos
157
Paquetes
Elemento organizativo Puede agrupar elementos de cualquier tipo. 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
158
Importacin/Exportacin en paquetes
Visibilidad pblica, protegida y privada Relaciones de importacin y generalizacin. La parte pblica de un paquete son sus exportaciones. Las partes pblicas son visibles en los paquetes que importan al paquete que los contiene. 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 at travs de los paquetes y de la importacin.
159
Importacin/Exportacin en paquetes
La relacin de acceso es igual que la importacin pero no se pueden re-exportar los elementos aadidos. Importacin y acceso se representan mediante relaciones de dependencia estereotipadas con <<import>> y <<access>>. La relacin de importacin es transitiva. Los paquetes anidados pueden ver todo lo que ven los paquetes que los contienen.
160
Cliente Servidor + BaseDeDatos + ServicioDeRegistro + FormularioPedido + FormularioDeSeguimiento - Pedido
<<import>>
Politicas + ReglasPedidos + GUI:Ventana
GUI + Ventana + Formulario # GestorEventos
<<import>>
Generalizacin de Paquetes
GUI + Ventana + Formulario # GestorEventos
WindowsGUI + GUI:Ventana + Formulario # GUI:GestorEventos + VBForm
MacGUI
162
Paquetes
Un paquete bien estructurado debe:
ser cohesivo estar poco acoplado pocos anidamientos conjunto equilibrado de elementos
164
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
165
Uso de los paquetes

<<subsystem> > Pedidos <<layer>> Servicios Bsicos
<<model>> Diseo
<<framework>> Struts
166
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: disear la solucin
Modelado OO ofrece una correspondencia directa entre los dos puntos de vista, a travs del concepto de objeto
167
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.
168
Modelo
169
Subsistema
Un subsistema es una unidad de comportamiento en el sistema. Permite descomponer el sistema Un subsistema ofrece interfaces, tiene operaciones, y distingue entre especificacin e implementacin.
170
Vistas UML
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

171
Vistas UML
clases interfaces colaboraciones
Vista de Diseo Vista de Implementacion
componentes
casos de uso
Vista de Interaccin
Vista de Despliegue
clases activas
nodos
172
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 Interaccin
Vista de Despliegue
Diagramas de clase Diagramas de interaccin Diagramas de estado
Diagramas de despliegue Diagrama de interaccin Diagramas de estado
Contenidos
174
Componentes
Es una unidad auto-contenida 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
175
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.
176
Propiedades de un componente
Interfaz Componente
Interfaz soportada
1..*
Especificacin Componente
1 *
realizacin
Implementacin Componente
1 *
instalacin
Instancia Componente
instancia
Instalacin Componente
177
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
AsignacionItem
<<component>>
Persona
Seguimiento
Pedido
Factura
ItemPedido
Interfaces proporcionadas
Interfaces requeridas
179
Componentes
<<Interface>> Persona findByNombre() create() getDetalles()
<<component>>
<<Interface>> ItemPedido create() validarDetalles() addLineaPedido()
Pedido
Interfaz proporcionada
Interfaz requerida
180
Componentes
JerarquaElementos
explorador.java arbol.java
181
Componentes
182
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). 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
183
Puertos
Los puertos son 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 relacionadas.
184
Componente
Puerto
Reservar
ventas normales atracciones
Cargar espectculos
Ventas Ticket
Vendedor Ticket
Tarjetas Crdito
cobros ventas prioritarias
Ventas Ticket
185
Estructura Interna
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.
186
Estructura interna
Compilador
lex:AnalizadorLexico
parse: Parser
Compilar
gen: GeneradorCodigo
opt:Optimizador [1..3]
187
Estructura interna
Venta Ticket Vuelos
:AsignacionAsiento
normal:Venta
:GestionInventario
Prioridad:Venta
188
Estructura interna
Ventas por Catalogo
:Cumplimentar
:Inventario
:EncontrarItems
:EnviarItems
:PasarPedido :EntradaPedido Cobro:Credito
:CapturaPedido
GestionPedido
189
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.
190
Componentes
191
Contenidos
192
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
Un rol es un objeto prototpico y un conector es un enlace entre objetos prototpicos.
193
Enlaces y Asociaciones
Persona calcularCom pensacion() asignar() +em pleado 1..* + patron *
Em presa
conector
irene:Persona
1: asignar(desarrollo) p:Persona :Em presa :Empresa UMU: Empresa
role mensaje
194
Enlaces y Asociaciones
Persona calcularCom pensacion() asignar() +em pleado 1..* + patron *
Em presa
enlace
p:Persona 1: asignar(desarrollo) :Em presa
objeto mensaje
195
Enlaces
Restricciones para expresar la naturaleza del enlace:
association self global local parameter
196
Diagrama de Objetos
: Cuenta
: Client e
: CodigoCuenta
: Tarjeta
: Transaccion
: Perfil
197
Diagrama de Objetos
: Curso
: Alumno : Profesor
: Tarjeta
: Departamento
: Expediente
: Tarjeta
director : Profesor
: GrupoInvestigacion
198
Interacciones y Mensajes
Interaccin: Comportamiento que comprende un
conjunto de mensajes intercambiados entre un conjunto de objetos dentro de un contexto para lograr un propsito.
Mensaje: especificacin de una comunicacin entre

objetos que transmite informacin, con la expectativa de desencadenar una actividad.
199
Tipos de mensajes
Simple
Llamada de operacin o flujo anidado de control
Sncrono
El emisor espera hasta recibir el resultado
Asncrono
El emisor no espera a recibir el resultado
Retorno
Indica el retorno de una llamada
Creacin y destruccin
<<create>> y <<destroy>>
200
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 Colaboracin.
Tambin se describe las mquinas de estado que caracterizan a los objetos

Diagramas de estado Diagramas de actividades
201
Diagramas de Interaccin
Describen una interaccin y hay dos tipos. Diagramas de Secuencia:
Destacan la ordenacin temporal de los mensajes
Diagramas de Comunicacin:
Destacan la organizacin estructural de los objetos participantes.
Equivalencia semntica
202
Diagramas de Secuencia
Incluye:
Objetos y su lnea de tiempo Focos de control o activacin Mensajes: a instancias o de creacin Mensaje self Informacin de control: condiciones y marcas de iteracin Indicar el objeto devuelto por el mensaje: return
(aadirlos slo cuando ayuden a clarificar la interaccin)
203
Mensajes
metodo(arg) <<create>> <<destroy>> [condicion] metodo(arg) * metodo(arg), [1..n] metodo(arg) v:= mtodo(arg) nmero del mensaje en la secuencia precedido por el nombre del proceso o hilo Numeracin jerrquica o secuencial o ninguna Simple: Creacin de objetos: Destruccin de objetos: Condicin: Iteracin: Asignacin: Identificar hilo:
204
Mensajes
Simple: Condicin: Iteracin: Asignacin: Identificar hilo: preparar(), addPedido(p) [condicion] metodo(arg) * preparar() hayStock:= eliminar() D3 : activar()
205
: GUIPedido :GUIPedido : ControladorPedidos :ControladorPedidos ::Pedido Pedido : LineaPedido :LineaPedido : Item :Item : ItemPedido : ItemEntregado preparar( ) preparar( ) preparar( )
hayStock:=check( ) [hayStock] eliminar( ) pedir:=checkPedir( ) [pedir]<<create>>
:ItemPedido
[hayStock] <<create>>
:ItemEntregado
206
Diagrama de Comunicacin
1: preparar( ) : GUIPedido : ControladorPedidos 2: preparar( ) : Pedido 3: preparar( ) : LineaPedido
4: hayStock:=check( ) 5: [hayStock] eliminar( ) 8: [haySt ock] <<>creat e> 6: pedir:=checkPedir( )
: ItemPedido 7: [pedir]<<create>>
: Item
: ItemEntregado
207
c:Cliente <<create>> establecerAcciones establecerValores :Transaccion p:ProxyODBC
tiempo
exito
establecerValores
Lnea de vida
<<destroy>>
Foco de control
208
Diagrama de Comunicacin
1: <<create>> 2: establecerAcciones 6: <<destroy>> c:Cliente t {local} proxy {global} 3: establecerValores 4: establecerValores :Transaccion {new}
p:ProxyODBC
209
Numeracin secuencial
2: m2()
1: m1 () :A :B
3: m3() :C
4: m4()
:D
Confusin en el flujo de ejecucin

210
Numeracin jerrquica
:A :B :C :D
m1( )
m2( ) m3( )
m4( )
211
Numeracin jerrquica
:A 1. m1() 1.1. m2 () :B :C :D
1.2. m3()
1.3. m4()
212
Numeracin jerrquica
1.1. m2( )
1. m1( ) :A :B
1.2. m3( ) :C
1.3. m4( )
:D
213
Numeracin jerrquica
:A 1. m1( ) 1.1. m2( ) 1.1.1. m3( ) :B :C :D
1.2. m4( )
214
Numeracin jerrquica
1.1. m2( )
1. m1( ) :A :B
1.1. 1. m3( ) :C
1.2. m4( )
:D
215
Numeracin jerrquica
1.1. m2()
1. m1 () :A :B
1.2. m3() :C
1.3. m4()
:D
216
Operadores de control
Ejecucin opcional (opt)
El cuerpo se ejecuta si se cumple una condicin
Ejecucin condicional (alt)

El cuerpo se divide en varias regiones, cada una con una condicin asociada. Se ejecuta el cuerpo de la regin cuya condicin se satisface.
Ejecucin paralela (par)

El cuerpo se divide en varias regiones. Cada regin representa una computacin paralela. Se ejecuta de forma paralela el cuerpo de cada regin
Ejecucin iterativa (loop)

El cuerpo se ejecuta mientras se cumple una condicin
217
sd reintegro
us uario : Persona banco : CajeroAutomatico
loop(1,3)
[password incorrecto]
introducir (password)
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
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
221
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
222
Diagramas de Actividad
Representa una actividad. Una actividad especifica una coordinacin de ejecuciones de comportamientos subordinados a travs de un modelo de flujo de datos y de control. Incluye:
nodos actividad construcciones de control, como control de concurrencia y decisin objetos flujos de control y de objetos
Una actividad produce algn efecto que provoca algn cambio en el sistema o retorna un valor. 223
Nodos Actividad y Acciones

Una accin no se puede descomponer, representa una computacin atmica. Un nodo actividad es una unidad organizacional dentro de una actividad. Es una agrupacin de acciones o nodos actividad anidados. Su ejecucin completa conlleva una duracin. Una accin es un nodo actividad que no puede ser descompuesto.
Procesar Pedido
224
Flujo de control
inicio
Planificar Proceso
Asignar Tareas
Flujos
finalizacin
225
Bifurcacin
Obtener orden de trabajo
[ mat erial no disponible ]
Volver a planificar
[ material disponible ] Asignar tareas
Obt ener siguiente orden de trabajo
226
Divisin y Unin
Preparar conversacin
divisin
Descomprimir
Gesticular Mover boca Emitir audio
unin
Limpiar
227
Elegir s it io
Contratar arquitecto
Realizar planos
Pedir ofertas
[ no aceptado ]
Construir
Trabajo administrativo
Finaliz ar 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 [completado]
Extraer Artculos
Enviar Pedido
o: Pedido [completado] b: Factura [impagada] Recibir Producto
Facturar al cliente
Pagar Factura
b: Factura [pagada] Cerrar Pedido
Cliente
Comercial
Jefe Tecnico
J efe Produ cci on
Inicio
Int roduc ir Pedido Cursar Pedido Analizar Pedido Viable
Denegar Pedido [ no]
Viable [si]
Aceptar Pedido
Ordenar Fabricacion
Planificar Produccion
Regiones de Expansin
Recibir pedido :Pedido :LineaPedido
Obtener Item :Producto
Calcular coste :Dinero
:Envio Enviar pedido
:Factura Enviar factura
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.
234
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
235
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)
238
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. 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.
239
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
240
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 Condicin de guarda Accin
241
apagar
Inactivo
haceFrio(tempDeseada) haceCalor(tempDeseada) tempOK tempOK
Calentando
listo/encender() Activacin
Enfriando
haceCalor(tempDeseada)
haceFrio(tempDeseada)
Activo
After (2 sec) send c.estaActivo
ruido
Inactivo
Buscando
Configuracin
objetivoEn(p) [representaAmenaza] / t.aadirObjetivo(p)
Rastreando
contactar
Acoplamiento
Partes de un estado
Rastreando entry/ activarModo(enRastreo) exit / activarModo(noRastreo) nuevoObjetivo/rastreador.adquirir do / seguirObjetivo autotest / defer
accin entrada transicin interna evento diferido
accin salida actividad
244
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
245
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
246
Subestados no ortogonales
introducirTarjeta
Activo
Validacin
Inactivo
cancelar mantener Seleccin
entry/leerTarjeta exit/expulsarTarjeta [continuar] Procesando
Mantenimiento
[no continuar] Impresin
247
Subestados ortogonales
Mantenimiento
mantener Pruebas
Probar perifericos AutoDiagnosis
Inactivo
Manejo Ordenes
Espera
[continuar] Orden Pulsar tecla [no continuar]
248
Subestados ortogonales
249
Contenidos
250
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.
251
Artefactos
artifact agente.java manifest artifact agenteFraudes.dll manifest AgenteFraudes PolticaFraudes PatrnBsqueda agenteFraudes manifest PolticaFraudes PatrnBsqueda artifact agenteFraudes.dll manifest
252
Artefactos
Despliegue
Necesarios y suficientes para formar un sistema ejecutable: libreras dinmicas (dll), ejecutables (exe),..
Productos del trabajo

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.
De ejecucin
Se crean durante la ejecucin: objeto .NET instanciado a partir de una DLL.
253
Modelado con artefactos

Modelado de ejecutables y bibliotecas Modelado de cdigo fuente Modelado de una API
254
Modelado de ejecutables
artifact v.exe
Vwbas20.dll
Vwdev20.dll
Wscr20.dll
255
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 componentes se ejecutan en nodos Los nodos representan el despliegue fsico de los componentes.
256
Nodos
Ventas
artifact pos.exe artifact contacts.exe
manifest
manifest
Venta
Contrato
257
Diagramas de Despliegue
Muestra la configuracin de los nodos que participan en la ejecucin y de los componentes que residen en los nodos. Incluye nodos y arcos que representan conexiones fsicas entre nodos. Modelado de sistemas empotrados, sistemas clienteservidor, sistemas distribuidos.
258
Diagrama de Despliegue
terminal
<<10-T-Ethernet>>
servidor
Unidad RAID
<<RS-232>> Consola
259
Modem
<<procesador> servidor cache
<<procesador>> servidor cache
internet
<<red>> red local
<<procesador> servidor principal
<<procesador> servidor
<<procesador>> servidor
<<procesador>> servidor
Contenidos
Modelado del Comportamiento Diagramas de interaccin Diagramas de actividades Mquinas de estado Modelado de la Implementacin Diagramas de componentes Diagramas de despliegue Colaboraciones Formalizacin de UML: MOF y metamodelo
261
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).
262
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)
263
caso de uso colaboracin

Hacer Pedido
Gestin Pedidos
realizacin
264
Modelo Estructural
Usuario nombre 1 nif 1 0.. n
Pedido id tot al 1 1..n
LineaPedido unidade s 0..n
0..n
0..n
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.
267
Mecanismo trading (Parte esttica)
Cli ent eDe Ge s or t 1.. n 0 .. n 1..1
Trader 1..1 1..n
FactoriaEdi tor 1..1 esp ecifi ca
necesita editar 1..1 ObjetoInf ormacion 1..n 1.. n edita do con 1..n E ditor
268
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?
269
Colaboraciones Parametrizadas
Modelado de patrones de diseo
Subject Observer Observer Subject Observer
Alarma
Ventana
270
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()
271
Patrn de diseo (Parte dinmica)

: Otra :Cliente 1. setEstado() 1.1. notify() 1.1.1. update() 1.1. 2. updat e() : Subject :Subject o1 : Observer o1:Observer o2 : Observer o2:Observer
272
Contenidos
Modelado del Comportamiento Diagramas de interaccin Diagramas de actividades Mquinas de estado Modelado de la Implementacin Diagramas de componentes Diagramas de despliegue Colaboraciones Formalizacin de UML: MOF y metamodelo
273
Lenguajes OMG
MOF (Meta Object Facility) UML OCL Action Semantics
Definir semntica de modelos de comportamiento Muy bajo nivel No define una sintaxis concreta
274
Lenguajes OMG
Perfiles UML (Profiles)
Subconjunto de UML con extensiones para un dominio concreto Perfiles estndar OMG: EDOC, Corba, EAI,..
QVT
Lenguaje estndar para definir transformaciones
275
Metamodelo UML
Cmo se define formalmente un lenguaje de modelado? UML es definido como 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
276
Arquitectura de cuatro niveles

Nivel M3 M2 M1 M0 Descripcin
MOF metamodelos, instancias de los elementos MOF modelos, instancias de los elementos de M2 el sistema, objetos y datos, instancias de los elementos de M1
277
Arquitectura de cuatro niveles
ModelE lement name : Name
MOF/UML
Generalizab leElement NameSpace isRoot : boolean isLeaf : boolean isAbstract : boolean
Feature +feature ownerScope : ScopeKind visibility : VisibilityKind 0..n
+owner Classifier 0..1
StructuralFeature multiplicity : Multiplicity ChangeableKind ScopeKind OrderingKind
BehavioralFeature isQ uery : bo olean
Class acti ve : boole an
At tribute initialValue : Expression
Operation concurrency : CallConcurrencyKind isRoot : boolean isLeaf : boolean isAbstract : boolean specification : String
Modelo de Clases
Usuario nombre 1 nif 1 0.. n Pedido id tot al 1 1..n
LineaPedido unidade s 0..n
0..n
0..n
280
Arquitectura de cuatro niveles del OMG

EBNF
Level M3
the MOF MMM
the Pascal grammar
Level M2
the SPEM MM
the UML MM
the CWM MM
a Pascal program P
Level M1
a UML model m
another UML model m
an execution X of program P
Level M0
a particular use of m
another use of m
281
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.
282
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
283
MDA
PIM
PSM
Cdigo
Modelo independiente de la plataforma
Modelo especfico de la plataforma
Nuevo paradigma de desarrollo de software:
Desarrollo dirigido por modelos

284
Transformaciones de modelos
PIM
TMM
PSM
TMC
Cdigo
L1
Definicin Transformacin
L2
Definicin Transformacin
L3
285
+des ayuno
PIM
Cambio cantidad
0..n
Lenguajes de Modelado
Lenguajes especficos de un dominio
Definicin de modelos PSM
Dos formas de creacin

Perfiles UML Metamodelos MOF
287
Sintaxis abstracta
table :Country do field :name, varchar(100),primary_key field :surface, integer table :Person do field :id, autoinc, primary_key field :name, varchar(200) field :country_id, varchar(100), foreign_key(:country) end
Sintaxis concreta
Profiles UML (Perfiles)

Define una forma especfica de usar UML. Agrupacin de un conjunto de estereotipos, valores etiquetados y restricciones, con su correspondiente notacin para adaptar UML a un dominio concreto: EJB, aplicaciones web, CORBA, modelado del negocio,.. Un perfil define un metamodelo mediante la especializacin de un subconjunto del metamodelo de UML. Usados como lenguajes de un PSM
289
Ejemplo de definicin de Perfil UML

Modelar conexiones entre elementos de un sistema de informacin conectados segn la topologa estrella
metamodel MyTopology Node

* location: String LocalEdge +target * +localnodes
MainNode
* +source
Edge
290
Ejemplo de definicin de un Perfil UML

profile TopologyProfile
Modelar conexiones entre elementos de un sistema de informacin conectados segn la topologa estrella
metaclass Class
stereotype Node
location: String
stereotype MainNode
stereotype Egde metaclass Association stereotype LocalEdge
291
Ejemplo de definicin de un Perfil UML

context MyTopology::MainNode inv : self.localnodes ->forAll (n : Node | n.location = self.location) inv: self.target ->forAll(n : MainNode | n.location <> self.location ) context UML::InfrastructureLibrary::Core::Constructs::Class inv : self.isStereotyped(Node) implies self.connection->select(isStereotyped(LocalEdge))->size = 1 and self.connection->select(isStereotyped(Edge))->isEmpty
Restricciones
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)
292
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
293
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
294
Expresiones OCL
context Person::cumpleaos() post: edad = edad@edad + 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
295

Leng Unified Modelado

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Leng Unified Modelado

Încărcat de

Drepturi de autor:

Formate disponibile

Proceso Software

Prentice-Hall, 2003. http://www.uml.org/

El lenguaje unificado de modelado, UML

Explosin de mtodos OO en los noventa

Eliminar confusin en los usuarios

Objetivos en el diseo de UML

Modelado del Software

Utilidad del modelado

Utilidad del modelado

Por qu la mayora de empresas no practican el modelado?

Utilidad del modelado

Utilidad del modelado

Modelos en otras reas

1 CarroCompra total ItemCarro unidades

1 Product o nombre preci o desc ripcion

Diagramas no son modelos

Modelado de flujos de Actividades

Modelos de Negocio y de Software

Propiedades del modelado

Construimos software de calidad?

Utilizable para sistemas que no sean software

Marco Conceptual de UML

Reglas para combinar bloques

Modelo del Negocio

Retorna 0 si no existe el valor

Corriente Operacion Periodica

1..n Desayuno numero 0..n

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

Registrar Curso Aprobar Curso Preinscripcin

Modelo del Negocio

Matriculacin Hay alumnos?

Crear Proyecto Cerrar Curso

R eali zar puja ordinari a

C errar edic in de s ubas ta

C anc elar puja ordinaria R ealizar pago de s ubas ta ordinaria

R ec h azar ad judic ac in Sis tem a N otif icar adjudicatario Teleoperador Participant e

C rear edic in de s ubas ta

Anular anunc io de s ubast a

Adm inis trador Anular edic i n de suba s ta

Modelo Casos de Usos

Diagrama de casos de uso

PagoC uota +as

+art Es to repres enta la es pec if ic ac in de un artc ulo.

1. cerrarEdi ci onSubasta(es) : Control adorAnunci os : Si stem a 2. cerrar()

5. num Adj s = cal cul arAdj udi caci ones()

Terminar Venta manejarRespuesta efectuar Pago Efectivo Espera Pago

Autorizacion Pago efectuar Pago Tarjeta

Mecanismos comunes de UML

Persona nombre direccion telefono

Mecanismos comunes de UML

Mecanismos comunes de UML

Mecanismos de extensibilidad de UML

Ejemplos de estereotipos predefinidos

Mecanismos de extensibilidad de UML

Mecanismos de extensibilidad de UML

Component (from awt) ImageObserver

Hol aMundo paint()

java (from Logical View)

Presentacin de UML Modelado de Casos de Usos

Modelado de Casos de Uso

Modelado de Casos de Uso

Otras definiciones de caso de uso

Ejemplo Caso de Uso

Re s ponsabl e Pr est amo s