Uml y Mda2005

Anlisis y Diseo del Software Curso 2004/2005
Captulo 1
El Lenguaje Unificado de Modelado, UML
Jess Garca Molina Departamento de Informtica y Sistemas Universidad de Murcia http://dis.um.es/~jmolina
Contenidos
Modelado del software Presentacin de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases
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
3
Contenidos
Modelado del software
Presentacin de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases
Bibliografa
G. Booch, J. Rumbaugh, I. Jacobson, El lenguaje unificado de modelado, Addison-Wesley, 1999. 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/
El lenguaje unificado de modelado, UML

A mediados de los noventa existan muchos mtodos A/DOO
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 permiten documentar las decisiones Permiten una generacin automtica de cdigo
11
Qu es un modelo?
Un modelo es una simplificacin de la realidad
Un modelo es una descripcin de un sistema, escrito en un lenguaje bien definido
12
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.
13
Modelos de Negocio y de Software

Modelo del Negocio
derivado de
describe
Modelo Software
describe
Empresa
Sistema software
Sistema de la empresa
14
Utilidad del modelado

Una empresa software con xito es aquella que produce de manera consistente software de calidad que satisface las necesidades de los usuarios
El modelado es la parte esencial de todas las actividades que conducen a la produccin de software de calidad
15

Escribimos cdigo directamente?
Sera lo ideal pero .... .... necesitamos escribir modelos

16

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

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.
18
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.
19
Por qu las empresas no hacen modelado?

Hasta ahora, la mayor parte de las empresas software no realizan ningn modelado. El modelado requiere: aplicar un proceso de desarrollo formacin del equipo en la tcnicas concienciacin de su importancia
Se obtienen beneficios con el modelado?
20
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?
21
Contenidos
Presentacin de UML
Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases
22
UML y el modelado
UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos (modelos) de un sistema que involucra una gran cantidad de software, desde una perspectiva orientada a objetos.
UML es una 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

23
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
24
Elementos Estructurales
Partes estticas de un modelo
Ventana origen tamao abrir() cerrar() mover() dibujar()
<<Interface>> IAvisable
IAvisable
Interface
clase
ValidarTransaccion
caso de uso
25
Elementos Estructurales
Gestor Eventos
suspender() vaciarCola()
clase activa
Hola Mundo.class
colaboracin
componente
Gestin Pedidos
Servidor
nodo
26
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
27
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
28
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.

29
Elementos de Anotacin
Son las partes explicativas de los modelos UML
Retorna 0 si no existe el valor
Nota
30
Relaciones
Dependencia
0..1 *
patron
empleado
Asociacin
Generalizacin Realizacin
31
Ejemplo
IteradorCuenta
Cuenta 1 0..n
Domiciliacion
Ahorro
Corriente Operacion Periodica
32
Diagramas de UML
Diagramas de Casos de Uso Diagramas de Clases Diagramas de Objetos Diagramas de Interaccin Diagrama Secuencia Diagrama Colaboracin Diagramas de Estados Diagramas de Actividades Diagramas de Componentes Diagramas de Despliegue
Diagramas no son modelos
34
Modelos en UML
Modelado de Casos de Uso
Diagrama de Casos de Uso
Modelado Estructural
Diagrama de Clases
Modelado de Comportamiento
Diagramas de Interaccin 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 Despliegue
35
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
Cancelar Curso
Diagrama de actividades
Crear Proyecto Cerrar Curso
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
Administrador Anular edicin de subasta
Modelo Casos de Usos
Diagrama de casos de uso
Diagrama de clases
Modelo Estructural
1. cerrarEdicionSubasta(es) : ControladorAnuncios : Sistema 2. cerrar()
int numAjudicaciones = Minimo(pujas.length(), articulos.length());
Diagrama de colaboracin
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
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
40
Mecanismos comunes de UML

Especificaciones
Proporcionan una semntica para cada elemento Los diagramas son proyecciones de esa base
Adornos
La notacin grfica bsica de cada elemento puede incluir adornos textuales o grficos para resaltar algunas propiedades de la especificacin.
41

Dicotoma clasificador /instancia
CLASE Objetos Objeto de la clase Persona que no se muestra en forma explcita
UML distingue un objeto utilizando el mismo smbolo de la clase y subrayando el nombre del objeto
Persona nombre direccion telefono
Elena
Elena : Persona
Se indica en forma explcita que es un objeto Persona
Casi todos lo bloque de construccin UML presentan esta dicotoma Clase/Objeto: Ej. Caso uso e instancia de caso de uso Componente e instancias de componentes Nodos e instancias de nodos
: Persona
Objeto Persona annimo
42

Dicotoma interfaz / implementacin
Una Interfaz declara un contrato y una implementacin representa una realizacin concreta de ese contrato, responsable de hacer ejecutar de forma fidedigna la semntica completa de la interfaz
asistente Ortografico.dll
IOrtografia
Casi todos los bloques de construccin UML presentan esta dicotoma interfaz/implementacin. Ej. Casos de uso y las colaboraciones que los realizan
operaciones y los mtodos que los implementan

43
Mecanismos de extensibilidad de UML

Estereotipos
Extienden el vocabulario de UML, permiten definir nuevos tipos elementos y relaciones a partir de los existentes. Algunos son predefinidos en UML
Valores etiquetados
Extienden las propiedades de un elemento, aadiendo nueva informacin. Par etiqueta/valor: { etiqueta = valor }
Restricciones
Restricciones semnticas a elementos o relaciones. Definidos por el modelador o incluidos en UML. Ejemplo: { emp.vacaciones < 28 }
44
Ejemplo Estereotipo predefinido

<<Actor>> Cliente
Cliente
Cliente
Clase
Clase estereotipada
45
Ejemplo Estereotipo Predefinido
IComparator
Clase estereotipada
46
Mecanismos de extensibilidad de UML

estereotipo valor etiquetado
ColaEventos {version 3.2; autor: jgm}
<<Exception>>
aadir()
quitar() vaciar()
Overflow
{ordenado}
restriccin
47
Hola, Mundo!
Paquete Java en el cual se encuentra la Clase Graphics
La clase Graphics esta disponible para el cdigo que sigue
Operacin
import java.awt.Graphics; class HolaMundo extends java.applet.Applet { public void paint (Graphics g) { parmetro g.drawString (Hola, Mundo!,10,10); } Operacin invocada por paint }
HolaMundo
Introduce la nueva clase Holamundo especificando que es una subclase de Applet que se encuentra en paquete java.applet
g.drawString
("Hola, mundo)
paint()
ABSTRACCIONES claves para HolaMundo ( captura los aspectos bsicos de la aplicacin HolaMundo! pero deja fuera varias cosas)
48
Diagrama de Clases
La Clase Applet se utiliza como padre de HolaMundo Y la clase Graphics se utiliza en la signatura e implementacin de una de sus operaciones, paint.
generalizacin
dependencia
49
Component implementa a ImageObserver
Al revisar las bibliotecas de Java para Applet y Graphics se ver que son parte de una jerarqua mayor
Jerarqua de Herencia de HolaMundo
Organizacin en Paquetes
Organizacin de paquetes de HolaMundo
51
Organizacin en Paquetes
java
HolaMundo Applet
awt
lang
52
Diagrama de Secuencia
Mecanismos para Dibujar ( se establece el orden de los eventos)
: Thread
activacin
: Toolkit 1. run()
: ComponentPeer
target : HolaMundo
1.1. callbackLoop()
Nombre del objeto Operaciones invocadas
1.1.1. handleExpose() 1.1.1.1. paint()
La figura muestra la colaboracin de varios objetos , incluida una instancia de la clase HolaMundo. Los objetos son parte del entorno Java
53
Componente ejecutable
hola.java
HolaMundo.class
Pgina Web
Cdigo fuente de la clase HolaMundo
Cada uno de los conos de esta figura representa un elemento UML en la vista de implementacin del sistema
hola.html
hola.jpg
54
Contenidos
Presentacin de UML Modelado de Casos de Usos

Diagramas de casos de uso Modelado Estructural Diagramas de Clases
55
Modelado de Casos de Uso

Un caso de uso especifica un comportamiento deseado del sistema. Representan los requisitos funcionales del sistema. Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor Describen qu hace el sistema, no cmo lo hace.
56
Emisor
Centralita
Receptor
listo( )
tono
marcar_numero
tono_sonando timbre_sonando
ESCENARIO
telefono_cogido para_tono
para_timbre
Casos de uso son ideados por Jacobson a principios de los noventa Se inspira en los escenarios utilizados para describir procesos
Otras definiciones de caso de uso

Describe un conjunto de interacciones entre actores externos y el sistema en 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 los actores que usan un sistema para conseguir un objetivo [C. Larman]
58
Ejemplo Caso de Uso

actor caso de uso
Responsable Prestamos
Gestionar Prstamos
asociacion
59
Actores
Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interaccionar con el sistema. Roles jugados por personas, dispositivos, u otros sistemas. El tiempo puede ser un actor (procesos iniciados por el sistema) No forman parte del sistema
60
Actores
Un usuario puede jugar diferentes roles. En la 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.
61
Actores
A. Cockburn distingue dos tipos de actores:
Primarios: Requieren al sistema el cumplimiento de un objetivo Secundarios: El sistema necesita de ellos para satisfacer un objetivo
62
Propiedades de los casos de uso

Son iniciados por un actor con un objetivo en mente y es completado con xito cuando el sistema lo satisface. Puede incluir secuencias alternativas que llevan al xito y fracaso en la 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.
63
Escenarios y Casos de Uso

Un caso de uso describe un conjunto de secuencias de interacciones o escenarios: flujo principal y flujos alternativos o excepcionales Un escenario es una instancia de un caso de uso Escenarios principales vs. Escenarios secundarios Especificacin con diagramas de secuencia o textual.
64
Descripcin de un caso de uso

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 indicarse: inicio y final, actores, objetos que fluyen, flujo
principal y flujos excepcionales.
65

Comprar artculos (en un terminal de punto de venta)
Flujo Principal: Un cliente llega al TPV con un conjunto de articulos. 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.
66

Comprar articulos (en un terminal de punto de venta)
6. El Cajero le dice al cliente el total. 7. El cliente realiza el pago. 8. El cajero registra la cantidad de dinero recibida. 9. El sistema muestra la cantidad a retornar al cliente y genera un recibo. 10. El cajero deposita el dinero recibido y saca la cantidad a devolver que entrega al cliente junto al ticket de compra. 11. El sistema almacena la compra completada. 12. El cliente recoge los artculos comprados.
67
Cajero
Comprar Articulos
Cliente
:Sistema
: Cajero introducirItem(upc,cantidad) finalizarVenta() hacerPago(cantidad)

Validar Usuario (contexto de 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.
69
Ejemplo 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

Actores Secundario
Alumno
Realizar preinscripcin
Gestin Expedientes
Actor Principal
Matriculacin Entidad Bancaria
Reservar Libro
Prestamo revista
Profesor
Prestamo Libro
Devolver revista
Socio Devolver libro Actualizar catalogo
Bibliotecario
Extender Prestamo
Consultar
Socio
72
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).
73
caso de uso colaboracin

Hacer Pedido
Gestin Pedidos
realizacin
74
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
75
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
76
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
77
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 caso de uso Hacer Pedido:
Obtener y verificar el nmero de pedido. Include (Validar usuario). Examinar el estado de cada parte del pedido y preparar un informe para el usuario.
78
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
Ejemplo caso de uso Hacer Pedido:

Include (Validar usuario). Recoger los tems del pedido del usuario. (establecer prioridad). Enviar pedido para ser procesado.
79
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.
80
Plantilla para casos de uso

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

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
82
(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 ...
83
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
84
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.
85
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
86
Utilidad de los casos de uso

Hay consenso en considerar casos de uso como esenciales para capturar requisitos y guiar el modelado. Pero existe (ha existido?) mucha confusin sobre cmo usarlos. Diferentes opiniones sobre el nmero de casos de uso conveniente:
20 para un proyecto 10 personas/ao (Jacobson) depende de la granularidad
87
Granularidad
Diferente granularidad Un caso de uso puede describir:
Un objetivo o propsito del usuario Una interaccin con el sistema
Un objetivo implica una o ms interacciones. Construir un caso de uso por cada objetivo del usuario.
88
Granularidad
Ambito
Sistema Organizacin
(A. Cockburn)
Caso de uso
Funcionalidad requerida del sistema
Caso de uso del negocio
Objetivo estratgico para la empresa, de mucho valor
Especificidad
Objetivo del usuario cdu Colecciones de objetivos de usuario Subfunciones inclusin de cdu
cdu negocio
89
Granularidad
Especificidad
Objetivo del usuario
(A. Cockburn)
Tarea del usuario o proceso de negocio elemental
Colecciones de objetivos de usuario

Recoge casos de uso de usuario relacionados
Subfunciones
Un paso en la descripcin de un caso de uso (validar, buscar, log on)
Detalle de la interaccin
Interfaz de dialogo o Interfaz semntica
90
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)
91
Recomendaciones
Especificar casos de uso no es una actividad de dibujar diagramas sino de escribir con el detalle necesario el flujo principal y los flujos alternativos: centrado en la escritura en vez del dibujo No hay que preocuparse demasiado por las relaciones entre casos de uso ni entre actores. El objetivo inicial es identificar los actores y a partir de sus objetivos encontrar los casos de uso, el diagrama de casos de uso es una ayuda visual. Los actores deben interactuar con el sistema
92
Recomendaciones
Qu granularidad es apropiada para un caso de uso? En un sistema de venta por internet,
Aadir producto al carro de la compra Introducir datos facturacin son casos de uso?
Deben ser objetivos del usuario Error comn: no identificar como casos de uso las tareas que inicia el propio sistema
Anular reservas pasados quince das
93
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
94
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.
95
Referencias
http://alistair.cockburn.us/usecases/usecases.html Writing effective uses case, Alistair Cockburn, Addison-Wesley, 2000 C. Larman, UML y Patrones: Una introduccin al anlisis y diseo orientado
a objetos y al proceso unificado, Prentice-Hall, 2003.
96
Contenidos
Presentacin de UML
Modelado de Casos de Usos Diagramas de casos de uso
Modelado Estructural
Diagramas de Clases
97
Modelado estructural
Se describen los tipos de objetos de un sistema y las relaciones 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.

98
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
99
Modelo Conceptual
Del Modelo Conceptual a las clases

Los modelos de anlisis se obtienen a partir del modelo conceptual:
Conceptos a clases Atributos de un concepto a atributos de la clase Aadir comportamiento (mtodos)
101
IteradorCuenta
Modelo de diseo
Cuenta 1 0..n
Domiciliacion
Ahorro
Corriente Operacion Periodica
Modelo Conceptual o de Anlisis?
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
Colaboracin (parte esttica)
105
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
106
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()
107
Patrn de diseo (Parte dinmica)

: Subject 1. setState() 1.1. notify() 1.1.1. update() 1.1.2. update() o1 : Observer o2 : Observer
108
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.
109
Atributos
[visibilidad] nombre [: tipo] [= valor_inicial ] [{propiedades}]
+ = pblica # = protegida - = privada
visibilidad nombre: tipo:
nombre del atributo tipo del atributo valor inicial o por defecto
valor_inicial:
propiedades: {frozen} {addOnly}

110
Atributos
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
111
Operaciones
[visibilidad] nombre [(lista_parametros)] [: tipo_retorno] [{propiedades}]
+ = pblica # = protegida - = privada
visibilidad
nombre: nombre de la operacin lista_parmetros: tipo retorno: propiedades: lista de parmetros separados por comas
tipo de valor devuelto por la operacin {isQuery}, {sequential}, {concurrent}

112
Operaciones
Atributos
Operacione s
113
Clases Parametrizadas
G
Clase Parametrizada
Tabla count capacity put(G) item() : G
bind <Empleado>
Empleados
Instanciacin
Tabla<Cliente>
114
Otras propiedades
Clases y mtodos diferidos Multiplicidad Variables y mtodos de clase
<<abstract>> Figura rotar() trasladar() visualizar()
115
Clases Estereotipadas
<<metaclass>> MetaclaseCuenta
<<exception>> FueraRango
Clases y valores etiquetados
116
Relaciones
Dependencia
Un cambio en la 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
Lista
<<friend>>
117
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
118
Relaciones
Generalizacin
Es-un-tipo-de
Cuenta
Window
CuentaAhorro
CuentaCorriente
TextWindow
BoxDialog
119
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
120
Asociacin
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
121
Asociaciones
Agregacin
Caso especial de asociacin Relacin estructural parte-de
Empresa
1..1
Departamento
122
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
123
Asociaciones
Especificacin: class Pedido { public Cliente getCliente(); public Set getLineaPedido();... } Implementacin class Pedido { private Cliente private HashSet
_cliente; _lineasPedido;
124
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
125
Visibilidad
Pblica: +propietario Protegida: #propietario Privada: -propietario
GrupoUsuarios * *
Usuario
+propietario
1..1
-clave
*
Clave
126
Asociaciones calificadas
Nivel Conceptual: Dentro del mismo pedido no pueden existir dos 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
127
Asociaciones calificadas
Class Pedido { private Hashtable _lineasPedido; public ItemPedido getItemPedido(Producto unProducto); public void addItemPedido (Integer cantidad, Producto elProducto); }
128
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?
Cuatro posibles tipos de agregacin
129
Composicin
Es un caso particular de agregacin:
exclusiva y dependiente
Las partes pueden crearse despus del agregado compuesta al que pertenecen, pero una vez creadas viven y mueren con ella. La parte slo puede formar parte de un agregado. El agregado gestiona la creacin y destruccin de las partes. Las partes se pueden eliminar antes de eliminar el agregado.
130
Composicin
Ventana
agregado /todo
1..1
composicin
* Marco
parte
131
Composicin
POLIGONO 1 Relleno:Diseo
{ordered} {ordered} 3..*
Punto
132
Clases Asociacin
Una asociacin que tambin es una clase 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.
133
Ejemplo de clase asociacin
134
Ejemplo de clase asociacin
135
Asociaciones derivadas
Asociacin Derivada
136
Asociaciones derivadas
recibe Estudiante Asignatura
/ensea
imparte
Profesor
Asociacin Derivada
137
Restricciones para Asociaciones

Empresa
Departamento * *
Cuenta
{or}
Persona
{subconjunto}
+miembro 1..* Persona +Director 1..1
138
Restricciones para Asociaciones

operario * 0..1 jefe Persona
empleado *
patrn 0..1
Compaia
{Persona.patrn= Persona.jefe.patrn }
139
Realizacin
Relacin entre clasificadores, un clasificador especifica un contrato que otro clasificador garantiza que cumplir.
<<Interface>> IPila Pila push() pop() top()
Pila
IPila
140
Clases Abstractas e Interfaces

Interfaz
DataInput
(from io)
InputStream
(from io)
InputStreamReader
(from io)
Clase Abstracta
FilterInputStream
(from io)
DataInputStream
(from io)
141
Clases Abstractas e Interfaces

InputStream <<Interface>> DataInput
(from io) (from io)
InputStreamReader
(from io)
Interfaz
FilterInputStream
(from io)
DataInputStream
(from io)
142
Paquetes
Elemento organizativo Puede agrupar elementos de cualquier tipo. Un elemento es exclusivo a un paquete. Establece un espacio de nombres Posibilidad de anidar paquetes.
Modelo
Modelo
+ Producto + CarroCompra + Comercio
143
Importacin/Exportacin en paquetes
Los paquetes permiten controlar la complejidad del manejo de un gran nmero de abstracciones, controlando los accesos mediante la importacin.
Relaciones de importacin, acceso y generalizacin La parte pblica de un paquete son sus exportaciones. Las partes pblicas son visibles en los paquetes que importan al paquete contenedor. La importacin no es transitiva. Los paquetes anidados pueden ver todo lo que ven los paquetes que los contienen.
144
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
146
Paquetes
Un paquete bien estructurado debe:
ser cohesivo estar poco acoplado pocos anidamientos conjunto equilibrado de elementos
148
Uso de los paquetes

<<subsystem>> Pedidos <<layer>> Servicios Bsicos
<<model>> Diseo
<<framework>> Struts
149
Uso de los paquetes

Agrupar elementos relacionados para manejarlo en conjunto.
Paquete Clases e interfaces del modelo Paquete Interfaces de usuario Paquete Servicios base de datos Paquete Modelo del anlisis
Un modelo es un paquete incluyendo todos los elementos que constituyen una particular vista del sistema modelado.
150
Sistema, modelo, vista, diagrama

Un sistema es aquello que se est desarrollando y para lo que se crean modelos. Un sistema debe ser modelado desde dos puntos de vista:
Modelar el problema: comprender el problema Modelar el producto a crear: disear la solucin
Modelado OO ofrece una correspondencia directa entre los dos puntos de vista, a travs del concepto de objeto
151
Sistema, modelo, vista, diagrama

Un modelo captura una vista de un sistema fsico. Es una abstraccin de ese sistema con cierto propsito, por ejemplo modelar su comportamiento en relacin a unas personas que tienen determinado inters. Un modelo contiene todos los elementos de modelado necesarios, organizados en una jerarqua de paquetes/ subsistemas. Un modelo y sus elementos tienen una especificacin. Un modelo y sus elementos se representan mediante diagramas, que expresan una vista del modelo.
152
Subsistema
Un subsistema es una unidad de comportamiento en el sistema. Permite descomponer el sistema Un subsistema ofrece interfaces, tiene operaciones, y distingue entre especificacin e implementacin.
153
Vistas UML
vocabulario funcionalidad ensamblado gestion conf.
Vista de Implementacion
Vista de Diseo
comportamiento
Vista de casos de uso
Vista de Procesos
Vista de Despliegue
Funcionamiento escalabilidad rendimiento
topologa entrega distribucin instalacin Modelo de la Arquitectura de un sistema

156
Vistas UML
clases interfaces colaboraciones
Vista de Diseo Vista de Implementacion
componentes
casos de uso
Vista de Procesos
Vista de Despliegue
clases activas
nodos
157
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 Procesos
Vista de Despliegue
Diagramas de clase Diagramas de interaccin Diagramas de estado
Diagramas de despliegue Diagrama de interaccin Diagramas de estado

158
Diagrama de Objetos
Modelan las instancias de los elementos contenidos en los diagramas de clases
: Cuenta
Muestra un conjunto de objetos y sus relaciones en un momento concreto

Multiobjeto (coleccin de objetos annimos)
Enlace
: Cliente
: CodigoCuenta
: Tarjeta
: Transaccion
Objeto
: Perfil
Se utilizan para modelar la vista de diseo esttica o la vista de procesos esttica de un sistema
159
Diagrama de Objetos
: Curso
: Alumno : Profesor
: Tarjeta
: Departamento
: Expediente
: Tarjeta
director : Profesor
: GrupoInvestigacion
160
Contenidos
161
Enlaces y Asociaciones
Un enlace es :
una conexin semntica entre objetos. una instancia de una asociacin. un camino por el cual enviar un mensaje
enlace
p:Persona 1: asignar(desarrollo) :Empresa
mensaje
162
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.
163
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
164
Diagramas de Interaccin
Describen una interaccin. Dos tipos: Diagramas de Secuencia y Colaboracin Diagramas de Secuencia:
Destacan la ordenacin temporal de los mensajes
Diagramas de Colaboracin:
Destacan la organizacin estructural de los objetos participantes.
Equivalencia semntica
165
Diagramas de Secuencia
Incluye:
Objetos y su lnea de tiempo Focos de control o activacin Mensajes: a instancias o de creacin Mensaje self ( especifica que el objeto correspondiente es
visible porque es el emisor del mensaje)
Informacin de control: condiciones ( entre corchetes)y marcas de iteracin ( asterisco) Indicar el objeto devuelto por el mensaje: return
(aadirlos slo cuando ayuden a clarificar la interaccin)
166
Mensajes
Simple: Creacin de objetos: Condicin: Iteracin: Asignacin: metodo(arg) <<create>> [cond] metodo() * metodo() v:= getObjeto()
Numeracin jerrquica o secuencial o ninguna
167
Diagramas de Secuencia
: : : Pedido : LineaPedido : Item InterfacePedido ControladorPedido 1: preparar() 2: preparar() 3: * preparar() 4: hayStock:=check()
5: [hayStock] eliminar()
6: pedir?:= necesarioPedir() 7: [pedir?] <<create>> 8: : ItemPedido
9: [hayStock] <<create>>
: ItemEntregado
168
Diagramas de Colaboracin
1: preparar() : InterfacePedido : ControladorPedido 2: preparar() : Pedido
6: pedir?:= necesarioPedir()
3: * preparar()
: Item
4: hayStock:=check() 5: [hayStock] eliminar()
: LineaPedido
7: [pedir?] <<create>>
8: [hayStock] <<create>>
: ItemPedido
: ItemEntregado
169
c:Cliente <<create>> establecerAcciones establecerValores :Transaccion p:ProxyODBC
tiempo
exito
establecerValores
Lnea de vida
<<destroy>>
Foco de control
170
Diagrama de Colaboracin
1: <<create>> 2: establecerAcciones 6: <<destroy>>
c:Cliente 5: exito :Transac cion
3: establecerValores 4: establecerValores
p:Proxy ODBC
171
c:Cliente
<<create>> :AgenteBilletes
a:Ayuda Planificacion
establecerItinerario(i)
calcularRuta ruta
<<destroy>>
notificar
172
Diagrama de Colaboracin
3: calcularRuta
1: <<create>> 2: establecerItinerario(i) 5: <<destroy>> c:Cliente 4: ruta 6: notificar :Agente Billetes
a:Ayuda Planificacion
173
Numeracin secuencial
2: m2()
1: m1() :A :B
3: m3() :C
4: m4()
:D
Confusin en el flujo de ejecucin

174
Numeracin jerrquica
:A 1. m1() 1.1. m2() :B :C :D
1.2. m3()
1.3. m4()
175
Numeracin jerrquica
1.1. m2( )
1. m1( ) :A :B
1.2. m3( ) :C
1.3. m4( )
:D
176
Numeracin jerrquica
:A 1. m1( ) 1.1. m2( ) 1.1.1. m3( ) :B :C :D
1.2. m4( )
177
Numeracin jerrquica
1.1. m2( )
1. m1( ) :A :B
1.1.1. m3( ) :C
1.2. m4( )
:D
178
Numeracin jerrquica
1.1. m2()
1. m1() :A :B
1.2. m3() :C
1.3. m4()
:D
179
Tipos de mensajes
Simple
Llamada de operacin o flujo anidado de control
Sncrono (llamada)
El emisor espera hasta recibir el resultado
Asncrono
El emisor no espera a recibir el resultado
Retorno
Indica el retorno de una llamada
180
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
183
Caso de Uso (Escenario)
: Cliente
:ReceptorPedidos enviarPedido
:AgenteTarjeta Credito
:GestionPedido
:AgenteFacturacion
procesarTarjeta
tramitarPedido
emitirFactura
confirmarPedido
184
Caso de uso (Colaboracin)

: Technical Responsible selectOrder() selectOrder(cod) o:=find(cod)
launchManufacturing() : Launch Manufacturing GUI
:OrderManager
:EvaluatedOrders
o : Order
: OrderLine
: Product
: WorkOrder
launchManufacturing(cod)
launch manufacturing() *generateWO() tpl:=getTemplate()
createWO(tpl)
185
Caso de uso de negocio

viajero: Empleado encargado: Empleado contable : Empleado pagador : Empleado
solicitudPermisoViaje() PermisoViaje()
informeGastos(unInforme) OKgastos(unInforme) solicitudPago(viajero)
186
Caso de uso de negocio

: Cliente : Comercial : JefeTecnico : JefeProduccion
darCursoPedido()
estudiarPedido() * analizarFabricacionProducto()
planificarFabricacion() informarAnalisisPedido() acceptarPedido()
187
Diagramas de Secuencia vs. Diagramas de Colaboracin

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 con que interacta un determinado objeto.
188
Diagramas de Actividades
Muestran un flujo de actividades. Es un caso especial de mquina de estados. Incluye:
estados actividad y estados accin transiciones objetos
Una actividad produce alguna accin que produce algn cambio en el sistema o retorna un valor.
189
Estados Accin y Estados Actividad

Un estado accin no se puede descomponer, representa una computacin atmica. Un estado actividad no es atmico, se compone de otros estados accin y actividad. Al entrar se ejecuta la accin o actividad, al terminar el flujo de control pasa a la siguiente accin o actividad. Misma notacin
Procesar Pedido
190
Transiciones
estado inicial
Planificar Proceso
Asignar Tareas
transiciones
estado final
191
Bifurcacin
Planificar Proceso
[ no hay materiales ]
Volver a Planificar
[ hay materiales ] Asignar Tareas
192
Divisin y Unin
Preparar conversacin
divisin
Descomprimir
Gesticular Mover boca Emitir audio
unin
Limpieza
193
Solicitar Producto
Procesar Pedido
Extraer Articulos
Enviar Pedido
Recibir Producto
Facturar al cliente
Pagar Factura
Cerrar Pedido
Cliente
Ventas
Almacen
Solicitar Producto
Procesar Pedido
Extraer Articulos
Enviar Pedido
Recibir Producto
Facturar al cliente
Calles
Pagar Factura Cerrar Pedido
Cliente
Ventas
Almacen
Solicitar Producto
Procesar Pedido
Extraer Articulos
o: Pedido [en progreso]
Enviar Pedido
Recibir Producto
Facturar al cliente
b: Factura [impagada]
o: Pedido [completado]
Pagar Factura
Cerrar Pedido
: Cliente
: Comercial :Catalogo
: JefeTecnico
: JefeProduccion
Rellenar Pedido
p:Pedido [propuesto] :Plantilla de Produccion Cursar pedido p:Pedido [en_evaluacion]
Analizar viabilidad
p:Pedido [evaluado] Notificar rechazo de pedido Fin KO [ NO ] Viable ? [ SI ]
:Producto Especial
Mucha informacin
p:Pedido [rechazado]
:Plantilla de Produccion
Notificar aceptacion de pedido
Ordenar fabricacion
:Orden de Trabajo [pendiente]
Planificar produccion p:Pedido [aceptado]
Fin OK
Cliente
Comercial
Jefe Tecnico
Jefe Produccion
Inicio
Introducir Pedido Cursar Pedido Analizar Pedido Viable
Denegar Pedido [no]
Viable [si]
Aceptar Pedido
Ordenar Fabricacion
Planificar Produccion
Utilidad de los diagramas de actividades

Modelado de flujos de trabajo (workflow) como son los procesos de negocio (business process). Se puede asociar a cualquier elemento de modelado, pero lo ms normal es asociarlo a una operacin: diagrama de flujo de las acciones.
199
Eventos
Un evento es un acontecimiento que ocupa un lugar en el tiempo y espacio. Un evento es un estmulo que dispara una transicin en una mquina de estados. Eventos externos vs. Eventos internos. Tipos de eventos:
Seales (excepciones) Llamadas Paso de tiempo Cambio de estado
200
Seales
Modelado Excepciones
<<exception>> Excepcion establecerManejador() primerManejador() ultimoManejador()
<<exception>> Duplicado
<<exception>> Overflow
<<exception>> Underflow
Conjunto aadir() eliminar()
<<send>>
<<send>>
<<send>>
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
203
Estados
accin entrada transicin interna evento diferido
Rastreando entry/ activarModo(enRastreo) exit / activarModo(noRastreo) nuevoObjetivo/rastreador.adquirir do / seguirObjetivo autotest / defer
accin salida actividad
204
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
205
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.
206
After (2 sec) send c.estaActivo
ruido Inactivo
Buscando
Configuracin
objetivoEn(p) [representaAmenaza] / t.aadirObjetivo(p)
Rastreando
Acoplamiento
contactar
Diagrama de Estado (Caso de Uso)

introducirProducto
Espera Venta
introducirProducto
Introduccion Productos
Terminar Venta manejarRespuesta efectuar Pago Efectivo Espera Pago
Autorizacion Pago efectuar Pago Tarjeta
208
Diagrama de Estado (Caso de Uso)

cerrarPedido( (codigoCuenta, direccinEnvio, fechaTarjeta,.. ) Establecer Cliente y Verificar pago
enviarCargo (codigoCuenta,..)
Pago
rechazarPago
Pago No apobado
pagoAprobado
enviarCargo (codigoCuenta,..)
Envio
pedidoEntregado
Entregado
209
Subestados secuenciales
introducirTarjeta Activo entry/leerTarjeta exit/expulsarTarjeta [continuar]
Procesando
Inactivo
Validacin
cancelar mantener
Seleccin
Mantenimiento
[no continuar]
Impresin
210
Subestados concurrentes
Mantenimiento mantener Pruebas
Probar perifericos AutoDiagnosis
Inactivo
Manejo Ordenes
Espera
[continuar] Orden Pulsar tecla
[no continuar]
211
Subestados Concurrentes
212
Contenidos
213
Componentes
Un componente es una parte fsica y reemplazable de un sistema, que conforma con un conjunto de interfaces y proporciona su implementacin. Modela artefactos tales como: ejecutables, bibliotecas, tablas, ficheros, documentos,.. Representa el empaquetamiento fsico de elementos lgicos tales como clases, interfaces,.. Residirn en los nodos del sistema
Estereotipos: executable, library, file, table, document
214
Componentes (UML 1.5)

Es una parte de un sistema reemplazable, modular y desplegable que encapsula una implementacin y expone un conjunto de interfaces. Normalmente especificado por uno o ms clasificadores (clases, interfaces, tipo de dato,..) que residen en el componente, y un conjunto de ellos define su interfaz externa. Conforma a las interfaces que expone al exterior, y puede ser implementado por un fichero binario, ejecutable o script. Puede ser desplegado sobre un nodo
215
Propiedades de un componente
Es una unidad de despliegue independiente. Puede ser conectado con otros componentes En una aplicacin dada existir una nica copia Es una parte sustituible de un sistema (conforma con una interfaz) 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
Propiedades de un componente
Interfaz Componente
Interfaz soportada
1..*
Especificacin Componente
1
realizacin
Implementacin Componente
1 *
instalacin
Instancia Componente
instancia
Instalacin Componente
217
Componentes
<<EXE>> Explorador
agenteFraudes.dll
Realiza agenteFraudes politicaFraudes busquedaPatrones
218
Componentes
explorador.java
JerarquaElementos
arbol.java
El componente arbol.java puede ser reemplazado por otro que proporcione la interfaz JerarquaElementos.
219
Componentes
AsignacionAula.exe
AsignaturaUSP
Asignacion
AulaUSP
Reserva
220
Tipos de componentes
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 fuentes, ficheros de datos,.. Con ellos se crean los componentes de despliegue
De ejecucin
Se crean durante la ejecucin: objeto COM, instanciado a partir de una dll.
221
Modelado de ejecutables y bibliotecas Modelado de cdigo fuente Modelado de una API
222
Modelado de ejecutables
v.exe
Vwbas20.dll
vwdev20.dll
vwsrc20.dll
223

Es una parte modular de un sistema que encapsula su contenido y cuya manifestacin se puede reemplazar en su entorno Define su comportamiento en trminos de las interfaces que requiere y proporciona. Puede actuar como un tipo. Es una unidad auto-contenida que encapsula el estado y comportamiento de clasificadores (cdu, clases, interfaces)
224
Interfaces proporcionadas
Interfaces requeridas
225
Interfaz proporcionada
Interfaz requerida
226
227
228
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.
229
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.
230
Diagrama de Despliegue
terminal
<<10-T-Ethernet>>
servidor
Unidad RAID
<<RS-232>> Consola
231
Modem
<<procesador> servidor cache
<<procesador>> servidor cache
internet
<<red>> red local
<<procesador> servidor principal
<<procesador> servidor
<<procesador>> servidor
<<procesador>> servidor
Contenidos
234
Colaboraciones
Sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de los elementos.
Parte estructural (diagrama de clases) y parte de comportamiento (diagrama de secuencia).
235
Colaboraciones
El 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)
236
caso de uso colaboracin

Hacer Pedido
Gestin Pedidos
realizacin
237
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.
238
Mecanismo trading (Parte esttica)
Cli enteDeGestor 1..n 0..n 1..1
Trader 1..1 1..n
FactoriaEdi tor 1..1 especifi ca
necesita editar 1..1 ObjetoInformaci on 1..n 1..n editado con 1..n Editor
239
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?
240
Mecanismo trading (Comportamiento)
1: editar(info) : Cliente... : Trader
2: * i:= getInterfaz() 4: [p] crearEditor(info) : FactoriaEditor
3: p:= soportaInterfaz(i)
5: <<create>>
info : ObjetoInformacion
: Editor
Clases Cliente, Editor y ObjetoInformacion?

241
Colaboraciones Parametrizadas
Modelado de patrones de diseo
Subject Observer
Observer Subject Observer
Alarma
Ventana
242
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()
243
Patrn de diseo (Parte dinmica)

: Subject SetState( ) Notify( ) one : Observer another : Observer
Update( ) GetState( ) Update( ) GetState( )
244
Contenidos
245
Lenguajes OMG
MOF (Meta Object Facility) UML OCL AS (Action Semantics)
Definir semntica de modelos de comportamiento Muy bajo nivel No define una sintaxis concreta
246
Lenguajes OMG
Perfiles UML (Profiles)
Subconjunto de UML con extensiones para un dominio concreto Perfiles estndar OMG: EDOC, Corba, EAI,..
QVT (Query, Views,Transformations)

Lenguaje estndar para definir transformaciones
247
Metamodelo UML
Cmo se define formalmente un lenguaje de modelado? UML es definido con un metamodelo escrito es un metalenguaje, MOF. Los cuatro niveles de modelado del OMG
Nivel MO: el sistema Nivel M1: el modelo del sistema Nivel M2: el modelo del modelo Nivel M3. el modelo de M2
248
Arquitectura de cuatro capas del OMG

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
249
Metamodelo UML
Nivel M0
Sistema de pedidos por internet
Nivel M1
Un modelo estructural que incluye un diagrama de clases UML Clase Pedido con atributos fecha y producto
Nivel M2
Metamodelo Especificacin de clase o atributo UML
Nivel M3
Metametamodelo (Lenguaje estndar MOF)
250
Arquitectura de cuatro capas del OMG
Metamodelo UML
ModelElement
Classifier
+type 0..1 0..n
Typed
DataType
Class 1
Interface
0..n Feature Parameter
252
MOF
Proporciona conceptos y herramientas para razonar sobre lenguajes de modelado y transformaciones. Repositorio MOF Define un formato de intercambio para modelos de M1 llamado XMI (XML Metadata Interchange), basado en XML.
253
MDA (Model Driven Architecture)

Nuevo paradigma de desarrollo de software (noviembre, 2000):
Desarrollo dirigido por el modelado Ingeniera de modelos
Artefactos del proceso de desarrollo

Modelo Independiente de la Plataforma, PIM Modelo Especfico de la Plataforma, PSM Cdigo
254
MDA
MDA separa la especificacin de la funcionalidad del sistema de la especificacin de la implementacin de esa funcionalidad sobre una plataforma especfica, y proporciona un conjunto de guas para estructurar especificaciones expresadas como modelos
El paradigma MDA y los estndares que lo soportan permiten especificar en un modelo la funcionalidad del sistema que debe ser realizada sobre diferentes plataformas mediante mappings estndar para cada plataforma, y permite que diferentes aplicaciones puedan ser integradas relacionando explcitamente sus modelos, permitiendo integracin e interoperabilidad y soportar la evolucin del sistema conforme las tecnologas van cambiando
PIM y PSM
PIM describe la funcionalidad de un sistema software (nivel de captura de requisitos y anlisis). PSM incorpora al PIM los aspectos relacionados con la plataforma (nivel de diseo). Un PIM puede transformarse en uno o ms PSM para una misma aplicacin
256
PIM
Transformaciones de modelos
PIM
TMM
PSM
TMC
Cdigo
L1
Definicin Transformacin
L2
Definicin Transformacin
L3
258
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
259
Expresiones OCL
context c : Company inv enoughEmployees: c.numberOfEmployees > 50
context Company inv: self.employee.select(p : Person | p.age > 50)->notEmpty()
context Person::getCurrentSpouse() : Person pre: self.isMarried = true body: self.mariages->select( m | m.ended = false ).spouse
260
Expresiones OCL
context Job inv: self.employer.numberOfEmployees >= 1 inv: self.employee.age > 21 context Person::birthdayHappens() post: age = age@pre + 1
context Company::hireEmployee(p : Person) post: employees = employees@pre->including(p) and stockprice() = stockprice@pre() + 10
261
Profiles UML (Perfiles)

Mecanismo de especializacin. Un profile (perfil) 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,...
262
Perfiles UML
Un perfil define un metamodelo mediante la especializacin de un subconjunto del metamodelo de UML. Usados como lenguajes de un PSM Dos alternativas para extender UML
Definir un perfil Un nuevo lenguaje definido con MOF (por ejemplo CWM)
263
Perfiles UML
Profile = Packages Estereotipos definir nuevas meta-clases Valores etiquetados definir nuevos metaatributos y nuevas asociaciones Definir restricciones Modelar grficamente los perfiles
264
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
265
Ejemplo de definicin de un Perfil UML

profile TopologyProfile
metaclass Class
stereotype Node
location: String
stereotype MainNode
stereotype Egde metaclass Association stereotype LocalEdge
266
Ejemplo Perfil UML

profile WeightsAndColors
metaclass Class
stereotype Colored
color: Color
Estereotipos
metaclass Association
stereotype Weighed
weight: Integer
enumeration Color
green yellow red blue
Valores etiquetados
267
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 context UML::InfrastructureLibrary::Core::Constructs::Association inv : self.isStereotyped(LocalEdge) implies self.connection->select(participant.isStereotyped(Node) or participant.isStereotyped(MainNode) ) -> forAll(n1, n2 | n1.location = n2.location) inv : self.isStereotyped(LocalEdge) implies self.connection-> exists(participant.isStereotyped(MainNode) and multiplicity.min=1 and multiplicity.max=1) inv : self.isStereotyped(Edge) implies self.connection->select(participant.isStereotyped(Node))->isEmpty and self.connection->select(participant.isStereotyped(MainNode) ) -> forAll(n1, n2 | n1.location <> n2.location)
268
Uso de un Perfil UML

profile WeightsAndColors apply apply profile TopologyProfile
MyApplication
Node location=uma.es
Weighed weight=10
MainNode location=uma.es Colored
Node
1..10
MainNode, Colored
color=red
Branch
LocalEdge, Weighed
CentralOffice

Uml y Mda2005

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Uml y Mda2005

Transféré par

Droits d'auteur :

Formats disponibles

Anlisis y Diseo del Software Curso 2004/2005

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

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

Un modelo es una descripcin de un sistema, escrito en un lenguaje bien definido

Modelos de Negocio y de Software

Utilidad del modelado

Utilidad del modelado

Sera lo ideal pero .... .... necesitamos escribir modelos

Utilidad del modelado

Utilidad del modelado

Propiedades del modelado

Por qu las empresas no hacen modelado?

Se obtienen beneficios con el modelado?

Construimos software de calidad?

Utilizable para sistemas que no sean software

Marco Conceptual de UML

Reglas para combinar bloques

Modelo del Negocio

Un paquete incluye un conjunto de elementos de cualquier naturaleza.

Tiene una naturaleza conceptual.

Retorna 0 si no existe el valor

Corriente Operacion Periodica

Diagramas no son modelos

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

Realizar puja ordinaria

Cerrar edicin de subasta

Cancelar puja ordinaria Realizar pago de subasta ordinaria

Rechazar adjudicacin Sistema Notif icar adjudicatario Teleoperador Participante

Crear edicin de subasta

Anular anuncio de subasta

Administrador Anular edicin de subasta

Modelo Casos de Usos

Diagrama de casos de uso

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

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

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

Terminar Venta manejarRespuesta efectuar Pago Efectivo Espera Pago

Autorizacion Pago efectuar Pago Tarjeta

Mecanismos comunes de UML

Mecanismos comunes de UML

Persona nombre direccion telefono

Se indica en forma explcita que es un objeto Persona

Objeto Persona annimo

Mecanismos comunes de UML

operaciones y los mtodos que los implementan

Mecanismos de extensibilidad de UML

Ejemplo Estereotipo predefinido

Ejemplo Estereotipo Predefinido

Mecanismos de extensibilidad de UML

Component implementa a ImageObserver

Jerarqua de Herencia de HolaMundo

Organizacin de paquetes de HolaMundo

Nombre del objeto Operaciones invocadas

1.1.1. handleExpose() 1.1.1.1. paint()

Cdigo fuente de la clase HolaMundo

Presentacin de UML Modelado de Casos de Usos