Departamento de

Informtica y
Sistemas

Ingeniera en Informtica
Anlisis y Diseo de Software

Tema 1. El Lenguaje Unificado de

Modelado, UML

Jess Garca Molina

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

Contenidos

Introduccin al modelado del software

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

Paquetes

Contenidos

Modelado del Comportamiento

Componentes
Modelado de la Implementacin

Diagramas de interaccin
Diagramas de actividades
Mquinas de estado

Artefactos y despliegue
Diagramas de despliegue

Colaboraciones
UML, Metamodelado y MDA

Bibliografa

G. Booch, J. Rumbaugh, I. Jacobson, El lenguaje unificado de

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

Contenidos

Introduccin al modelado del software

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

Paquetes

El lenguaje unificado de modelado, UML

A mediados de los noventa existan muchos

mtodos de anlisis y diseo OO

Mismos conceptos con distinta notacin

Mucha confusin.

En 1994, Booch, Rumbaugh y Jacobson deciden

unificar las notaciones de sus mtodos:
Unified Modeling Language (UML)

Proceso de estandarizacin promovido por el OMG

http://www.omg.org

Explosin de mtodos OO en los noventa

OMT
Booch
Jacobson
Shlaer-Mellor
Wirfs-Broks
Fusion
Catalysis

Coad/Yourdon
Champeaux
Martin/Odell
OOram
BON
Open

Y muchos ms!

Guerra
de
mtodos
!

Evolucin UML

Grady Booch y Jim Rumbaugh comenzaron a unificar sus

mtodos (Octubre, 1994).
Borrador de UML (versin 0.8) (Octubre, 1995)
Ivar Jacobson se une al proyecto (Noviembre, 1995).
UML 0.9 y se crea un consorcio (Junio, 1996)
OMG lanza una peticin para un lenguaje unificado (1996)
UML 1.0 es ofrecido al OMG (Enero, 1997)
Se extiende el consorcio (Enero-Julio, 1997)
UML 1.1 es ofrecido al OMG (Julio, 1997)
OMG adopta UML 1.1 (Noviembre, 1997)
Se crea el UML RTF (1998)
UML 1.3 (Mayo 1999)
UML 2.0 (principios de 2005)

OMG (Object Management Group)

Propone, elabora y mantiene especificaciones

para aplicaciones empresariales distribuidas e
interoperables.
Estndares OMG

Corba
UML y perfiles UML
OCL
MOF, XMI
MDA

Ventajas de la unificacin

Reunir los puntos fuertes de cada mtodo

Idear nuevas mejoras
Proporcionar estabilidad al mercado

Proyectos basados en un lenguaje maduro

Aparicin de potentes herramientas

Eliminar confusin en los usuarios

Objetivos en el diseo de UML

Modelar sistemas, desde los requisitos hasta los

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

Modelado del Software

El modelado es el anlisis y diseo de aplicaciones

software antes de escribir el cdigo.
Se crean un conjunto de modelos (planos del
software) que permiten especificar aspectos del
sistema como los requisitos, la estructura y el
comportamiento.
Los modelos

ayudan a razonar sobre el sistema

favorecen la comunicacin
permiten documentar las decisiones
permiten una generacin automtica de cdigo

Modelos en otras reas

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

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

0..n

Pedido
id
total

1..n

0..n

1
CarroCompra
total

LineaPedido
unidades

0..n

ItemCarro
unidades

0..n

Producto
nombre
precio
descripcion

El lenguaje unificado de modelado, UML

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

Utilidad del modelado

Por qu no escribo cdigo
directamente?

Sera lo ideal pero ....

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

Participante
nombre
apellidos
numID
domicilio
direccionEnv io
telef ono
reputacion

Modelo de
Estructural

+p

PagoAnuncio
+pa

PujaOrdinaria

+pc

datosTarjeta
estado

+puja

Adjudicacion

+as

PagoCuota

+art

+as

Esto representa
la especif icacin
de un artculo.

+pujas
+adjudicaciones
AnuncioSubasta
EdicionSubasta
idEdicion
f echaInicio
f echaCierre
estado

+anuncios

+es

pv pRecomend
pujaMinima
cuota
gastosEnv io
plazo
f ormaPago
anticipo

Articulo
+articulos

ArticuloConcreto
codArticulo

+articulos

idEspec
caracteristicas
pv pRecomend

1. cerrarEdicionSubasta(es)

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

:
ControladorAnuncios
: Sistema
2. cerrar()

5. numAdjs = calcularAdjudicaciones()

9. [1..numAdjs]* add(adj)

4. * cerrar()
: AnuncioSubasta

as :
AnuncioSubasta

: EdicionSubasta

adjudicaciones :
Adjudicacion

3. * as := get()

8. [1..numAdjs]* adj := crear(as, pg, a)

6. [1..numAdjs]* pg := get()
pujas :
PujaOrdinaria

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

7. [1..numAdjs]* a:= get()

adj :
Adjudicacion
: ArticuloConcreto

Modelo de
Comportamiento

Se crean tantas adjudicaciones

como pujas ganadoras haya.
Cada adjudicacin se asocia
con un ArticuloConcreto, una
puja adjudicataria y con la
subasta.

Utilidad del modelado

Hay estructuras que no son visibles en los

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

Ha surgido un nuevo paradigma de desarrollo de software

a partir de modelos (p.e. MDA de OMG)

Utilidad del modelado

Los modelos:

visualizan cmo es o queremos que sea el

sistema
especifican la estructura y comportamiento del
sistema.
guan la construccin del sistema.
documentan las decisiones.

Por qu la mayora de
empresas no practican el
modelado?

Se obtienen beneficios con el modelado?

Un coste en formacin y tiempo

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

Modelos en UML

Modelado de Casos de Uso

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

Tipos de modelo

En qu etapa del proceso se usa? Anlisis o

Diseo?
Cul es su grado de detalle? Abstracto o
detallado?
Qu sistema describe? Modelo de negocio o
modelo software?
Qu aspecto describe? Estructural o de
comportamiento?
Es especfico o independiente de la plataforma?
A qu plataforma va dirigido? EJB, JDBC, .NET,
CORBA, etc.

Propiedades del modelado

La eleccin de los modelos tiene una profunda

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

Contenidos

Modelado del software

Presentacin de UML

Modelado de Casos de Usos

Diagramas de casos de uso
Modelado Estructural
Diagramas de Clases

Paquetes

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

UML es una notacin, no es un proceso

Se han definido muchos procesos para UML.

Rational ha ideado RUP, elproceso unificado.

Utilizable para sistemas que no sean software

Marco Conceptual de UML

Bloques bsicos de construccin

Elementos
Estructurales, Comportamiento, Agrupacin,
Anotacin

Reglas para combinar bloques

Relaciones
Diagramas
Establecen qu es un modelo bien formado

Mecanismos comunes

Especificaciones, Extensibilidad, Dicotoma claseinstancia, Dicotoma interfaz-realizacin

Elementos Estructurales

Partes estticas de un modelo

Ventana
origen
tamao
abrir()
cerrar()
mover()
dibujar()

colaboracin

<<Interface>>
IAvisable

IAvisable

interface

Gestin Pedidos

clase
RealizarCompra

caso de uso

Elementos Estructurales
Gestor Eventos

clase activa
FormularioPedido

suspender()
vaciarCola()

componente
<<artifact>>

window.dll
Servidor

nodo
artefacto

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

mensaje

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

activado

estado

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

Modelo del Negocio

paquete

Un paquete incluye un conjunto de elementos de cualquier

naturaleza.
Tiene una naturaleza conceptual.

Elementos de Anotacin
Son las partes explicativas de los modelos UML

Retorna 0 si no
existe el valor

Nota

Relaciones
Dependencia
0..1
patron

*
empleado

Asociacin

Generalizacin
Realizacin

Ejemplo de diagrama de clases

IteradorCuenta

Cuenta

Domiciliacion
1

Ahorro

0..n

Corriente
Operacion
Periodica

Pedido Desayuno
direccin
fecha
+pedidos
hora
1..n
descuento

+cliente

Cliente
numeroCuenta
direccion

1
crearPedido()

calcularPrecio()
+pedido

+desayuno

Desayuno
Estandar
nombre
precio
estilo

1..n
Desayuno
numero
0..n

0..n

Cambio
cantidad

0..n

Comestible
nombre
cantidadMinima
precio
1..n
formaTransporte
Parte
cantidad

Diagramas de UML 2.0

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

Diagramas de UML 2.0

Modelos en UML

Modelado de Casos de Uso

Modelado Estructural

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)

Modelado Implementacin

Diagramas de actividades
Diagrama de Componentes

Modelado de Despliegue
Diagramas de Artefactos
Diagramas de Despliegue

Responsable

Serv icio PE

Alumno

Sistema

Modelo del
Negocio

Registrar Curso
Aprobar Curso
Preinscripcin

Avisar
Admitidos

Matriculacin
Hay alumnos?

no
Cambiar
admitidos

Hay alumnos?
no

Cancelar Curso

Crear Proyecto
Cerrar Curso

Diagrama de
actividades

Modelo
Casos de Usos
Realizar puja ordinaria

Pujador

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

Diagrama de
casos de uso

Participante
nombre
apellidos
numID
domicilio
direccionEnv io
telef ono
reputacion

Diagrama
de clases

Modelo
Estructural

+p

PagoAnuncio
+pa

PujaOrdinaria

+pc

datosTarjeta
estado

+puja

Adjudicacion

+as

PagoCuota

+art

Esto representa
la especif icacin
de un artculo.

+as

+pujas
+adjudicaciones
AnuncioSubasta
EdicionSubasta
idEdicion
f echaInicio
f echaCierre
estado

+anuncios

+es

pv pRecomend
pujaMinima
cuota
gastosEnv io
plazo
f ormaPago
anticipo

Articulo
+articulos

ArticuloConcreto
codArticulo

+articulos

idEspec
caracteristicas
pv pRecomend

1. cerrarEdicionSubasta(es)

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

:
ControladorAnuncios

Diagrama de
comunicacin

: Sistema
2. cerrar()

5. numAdjs = calcularAdjudicaciones()

9. [1..numAdjs]* add(adj)

4. * cerrar()
: AnuncioSubasta

as :
AnuncioSubasta

: EdicionSubasta

adjudicaciones :
Adjudicacion

3. * as := get()

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

Modelo de
Comportamiento

Se crean tantas adjudicaciones

como pujas ganadoras haya.
Cada adjudicacin se asocia
con un ArticuloConcreto, una
puja adjudicataria y con la
subasta.

Mquina de Estado
Diagrama
de estado

introducirProducto

Espera Venta

introducirProducto

Introduccion
Productos

Terminar Venta
manejarRespuesta
efectuar Pago Efectivo

Autorizacion
Pago
efectuar Pago Tarjeta

Espera
Pago

Mecanismos comunes de UML

Dicotoma clasificador /instancia

Persona
nombre
direccion
telefono

Elena :
Persona

Elena :
Persona

: Persona

: Persona

Mecanismos comunes de UML

Dicotoma interfaz / implementacin

IOrtografia
IDiccionario

asistenteOrtografico

IUnknown

Mecanismos comunes de UML

Dicotoma rol / tipo

Pedido

cliente: Persona

El tipo declara la clase de una entidad, por ejemplo un objeto o

parmetro, y el rol describe el significado de la entidad en un
determinado contexto, tal como una clase, componente o
colaboracin.

Mecanismo de extensibilidad de UML

Estereotipos

Valores etiquetados

Extienden el vocabulario de UML, permitiendo definir

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

Restricciones

Especifican condiciones sobre los elementos del

modelo.

Perfiles UML

UML es una familia de lenguajes

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

Ejemplos de estereotipos predefinidos

Clase estereotipadas

<<Actor>>
Cliente

<<Interface>>
IComparator
compare()

Cliente

IComparator

Estereotipos y Valores Etiquetados

<<BusinessEntity>>

<<Table>>

Cliente

Empleado

<<UniqueId>> id : String
nombre : String

<<key>> dni : String

nombre : String
edad : int

Estereotipo: Table
Valores Etiquetados: key

apellido : String
<<Query>> findByLastName()

Estereotipo: BusinessEntity
Valores Etiquetados: UniqueID y Query

Restricciones

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

Restricciones
Empresa

Cuenta

{xor}

restricciones
Persona
sexo

0..1
+esposo

0..1
+esposa

{self.esposa.sexo = mujer and

self.esposo.sexo = hombre}

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

g.drawString
("Hola, mundo)

paint()

Diagrama de Clases
Applet

HolaMundo

Graphics
(from awt)

paint()

Component
(from awt)
ImageObserver
(from image)

imageUpdate()
Container
(from awt)

Panel
(from awt)

Applet

HolaMundo

Graphics
(from awt)

paint()

Organizacin en Paquetes

HolaMundo

java
(from Logical View)

paint()

Organizacin en Paquetes
java
HolaMundo
applet
awt

lang

Diagrama de Secuencia
root : Thread

: Toolkit

: ComponentPeer

target : HolaMundo

run
callbackLoop

handleExpose

paint

Diagrama de Artefactos
HolaMundo
<<manifest>>

<<manifest>>
hola.java

<<artifact>>
HolaMundo.class

hola.html

hola.jpg

Contenidos

Introduccin al modelado del software

Presentacin de UML
Modelado de Casos de Usos

Diagramas de casos de uso

Modelado Estructural
Diagramas de Clases

Paquetes

Casos de Uso

Un caso de uso especifica un comportamiento

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

Describen qu hace el sistema, no cmo lo hace.

Casos de Uso

Elementos de un caso de uso

Conjunto de secuencias de acciones; cada

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

Casos de uso

Casos de uso son ideados por Jacobson a

principios de los noventa,
Inspirados en el concepto de escenario.
Escenarios haban sido utilizados para describir
procesos.

Emisor

Centralita

Receptor

listo( )

tono

marcar_numero

tono_sonando
timbre_sonando

telefono_cogido
para_tono
para_timbre

Escenario

Otras definiciones de caso de uso

Describe un conjunto de interacciones entre actores

externos y el sistema en consideracin orientadas a
satisfacer un objetivo de un actor.
[D. Bredemeyer]

Es una coleccin de posibles secuencias de interacciones

entre el sistema en discusin y sus actores externos,
relacionado con un objetivo particular.
[A. Cockburn]

Es una coleccin de escenarios de xito y fracaso

relacionados que describe a un actor que usa un sistema
para conseguir un objetivo
[C. Larman]
67

Ejemplo de Caso de Uso

actor

Cajero

caso de uso

Realizar Venta

asociacion

Ejemplo de caso de uso

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

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

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

Roles son jugados por personas, dispositivos, u otros

sistemas.
Ejemplos: Cliente, Pujador, Alumno, SistemaPago,
El tiempo puede ser un actor (procesos iniciados
automticamente por el sistema)
No forman parte del sistema.

Actores

Un actor necesita el caso de uso y/o participa en l.

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

Identificacin de actores

Quin y qu utiliza el sistema?

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

Actores

Dos tipos de actores:

Principal:
Requiere al sistema el cumplimiento de un objetivo

Secundarios:
El sistema necesita de ellos para satisfacer un objetivo

Escenarios de un casos de uso

Un caso de uso describe un conjunto de

secuencias de interacciones entre actores y el
sistema (escenarios):

Principal y secundarios.

Cada escenario acaba con xito o fracaso.

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

Propiedades de los casos de uso

Son iniciados por un actor con un objetivo en mente

y es completado con xito cuando el sistema lo
satisface.
Puede incluir secuencias alternativas que llevan al
xito y fracaso en la consecucin del objetivo.
El sistema es considerado como una caja negra y
las interacciones se perciben desde fuera.
El conjunto completo de casos de uso especifica
todas las posibles formas de usar el sistema, esto es
el comportamiento requerido.

75

Descripcin de un caso de uso

Son documentos de texto, no son diagramas.

Describir el flujo de eventos

El modelado de casos de uso consiste en escribir texto, no

en dibujar diagramas.
Texto estructurado informal
Texto estructurado formal (plantillas)
Pseudocdigo
Notaciones grficas: diagramas de secuencia

Debe ser legible y comprensible para un usuario no

experto.
Debe indicar: actores, flujos principal y excepcionales.
76

Descripcin de un caso de uso

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

Descripcin de un caso de uso

Realizar Venta (en un terminal de punto de venta, TPV)
5. El sistema calcula el total de la compra y lo muestra.
6. El Cajero le dice al cliente el total.
7. El cliente realiza el pago.
8. El cajero registra la cantidad de dinero recibida.
9. El sistema muestra la cantidad a retornar al cliente y genera un recibo.
10. El cajero deposita el dinero recibido y saca la cantidad a devolver que
entrega al cliente junto al ticket de compra.
11. El sistema almacena la compra completada.
12. El cliente recoge los artculos comprados.

Realizar Venta

Cajero

Cliente

:Sistema

: Cajero
crearNuevaVenta()

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

Interacciones

Ejemplo de diagrama de casos de uso

Registrar curso

Responsable

Rebajar Mnimo

Aprobar curso

Servicio CPE

Cerrar curso
Crear proyecto

Servicio Contabilidad

Fin matriculacion
Realizar preinscripcin

Sistema

Avisar admitidos
Alumno

Matriculacin
Cancelar curso

Ejemplo diagrama de casos de uso

Alumno

Actor
Principa
l

Realizar preinscripcin

Matriculacin

Gestin Expedientes

Entidad Bancaria

Actores
Secundarios

Ejemplo diagrama de casos de uso

Reservar Libro

Prstamo revista

Profesor

Prstamo Libro

Devolver revista

Devolver libro

Actualizar catalogo

Socio

Extender Prstamo

Consultar

Bibliotecario

Socio
82

Casos de uso y Colaboraciones

Con un caso de uso se describe un

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

Una colaboracin tiene una parte esttica

(diagramas de clases) y una parte dinmica
(diagramas de secuencia).

Casos de uso y Colaboraciones

caso de uso

colaboracin

Hacer Pedido
Gestin Pedidos
realizacin

Casos de uso y Colaboraciones

El objetivo de la arquitectura del

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

Organizacin de casos de uso

Tres tipos de relaciones:

Generalizacin

Inclusin

Un cdu hereda el comportamiento y significado de otro

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

Generalizacin

Los casos de uso hijo son una

especializacin del caso de uso padre.
Produce confusin y se debera evitar su uso

Buscar Producto

Cliente

Buscar libro

Buscar CD

Ejemplo
Extensin
extend
Realizar Pedido

(establecer
prioridad)

include

Realizar Pedido
Urgente

Comprobar clave

Inclusin
Validar Usuario

Generalizacin
include
Consultar Pedido

Examinar retina

Relacin de inclusin

Permite factorizar un comportamiento en un

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

Relacin de extensin

El caso de uso base incluye una serie de puntos de

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

la parte opcional del sistema

un subflujo que slo se ejecuta bajo ciertas condiciones
varios flujos que se pueden insertar en un punto

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

Relacin de extensin
Devolver Libro
Puntos de extensin
libro retrasado

extend

Poner multa

Bibliotecario

Nombre: Devolver libro

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

Relacin de extensin

Produce confusin y no debera utilizarse.

Conviene su uso slo para insertar un nuevo
comportamiento no previsto en un caso de uso
existente.

Obtencin de casos de uso

1) Identificar los usuarios del sistema.

2) Encontrar todos los roles que juegan los

usuarios y que son relevantes al sistema.
3) Para cada rol identificar todas las formas
(objetivos) de interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso. (Cuidado!)
6) Revisar y validar con el usuario.

Plantilla usecases.org (Larman)

Nombre del caso de uso

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

Caso de uso Realizar Venta

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

Actor Principal: Cajero

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

Precondicin: El cajero est autenticado

Postcondiciones: Se registra la venta. Se calcula el
impuesto. Se actualiza contabilidad e inventario...

Caso de uso Realizar Venta

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

Caso de uso Realizar Venta

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

Caso de uso Realizar Venta

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

Lista de Tecnologa y Variaciones de Datos:

- El identificador podra ser cualquier esquema de cdigo UPC, EAN,..

- La entrada de informacin de la tarjeta se realiza mediante un lector
de tarjetas.
...

Cuestiones Pendientes:

- Explorar cuestiones de recuperacin de accesos a servicios remotos

- Qu adaptaciones son necesarias para diferentes negocios?

Utilidad de los casos de uso

Ofrecen un medio sistemtico e intuitivo para capturar

los requisitos funcionales, centrndose en el valor
aadido para el usuario

Dirigen todo el proceso de desarrollo puesto que la

mayora de actividades (planificacin, anlisis, diseo,
validacin, test,..) se realizan a partir de los casos de uso.

Mecanismo importante para soportar trazabilidad entre

modelos.

Utilidad de los casos de uso

Hay consenso en considerar casos de uso

como esenciales para capturar requisitos y
guiar el modelado.
Pero ha existido mucha confusin sobre
cmo usarlos.

Nmero de casos de uso apropiado en un

proyecto?
Qu casos de uso hay en el sistema?

Granularidad de los casos de uso

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

Granularidad

Casos de uso del negocio

Procesos de Negocio: Objetivo estratgico de la empresa

Ej. Venta productos

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

Granularidad

Qu granularidad es apropiada para un caso

de uso del sistema?

Sirven para planificar el proyecto

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

Tipos de casos de uso

Segn el nivel de detalle

Segn la importancia

Breve : Descripcin en unas pocas lneas

Informal : Varios prrafos que cubren varios escenarios
Completo : Descripcin detallada con una plantilla
Primario, secundario u opcional

Segn el nivel de abstraccin

Esencial : intenciones del usuario y responsabilidades del

sistema
Concreto : Se contemplan detalles de implementacin (GUI
y tecnologa)

Recomendaciones

Especificar casos de uso no es una actividad de

dibujar diagramas sino de escribir con el detalle
necesario el flujo principal y los flujos alternativos:
centrado en la escritura en vez del dibujo
El objetivo inicial es identificar los actores y a partir
de sus objetivos encontrar los casos de uso, el
diagrama de casos de uso es una ayuda visual.
El texto de los casos de uso debe ser claro.
No abusar de la relacin de inclusin.
No hacer una descomposicin funcional!

Las relaciones de generalizacin y extensin no

deberan utilizarse.

Recomendaciones

Un caso de uso debe tener una granularidad

apropiada, especifica una interaccin en la que se
produce un resultado de valor para un actor.

No identificar como caso de uso lo que son interacciones que

forman parte de una interaccin mayor que las engloba y no
son casos de uso de inclusin.

Un error comn es no identificar como casos de uso

las tareas que inicia el propio sistema (Actor Tiempo)

Anular reservas pasados quince das

Recomendaciones

No incluir como caso de uso las operaciones

CRUD sobre un objeto de negocio (alta, consulta,
borrado, actualizacin): funcin del sistema aparte,
excepto si se trata de operaciones relevantes para
el sistema, como registrar cliente en un sistema
de venta por Internet.
Cuidado con el empleo de la relacin include
No hacer una descomposicin funcional!

Escribir casos de uso independientes de la interfaz

o de detalles de implementacin, escribirlos a nivel
esencial. Centrarse en el qu no en el cmo.

Recomendaciones

Hay que comprobar que los casos de uso

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

Mal uso de los

casos de uso

<<include>>

Aadir libro

<<include>>
Mantener libros

Eliminar libro
<<include>>

<<include>>

Aadir peticin

<<include>>

Bibliotecario

Gestionar biblioteca

Mantener peticiones

<<include>>

Eliminar peticin

<<include>>

<<include>>
Devolver libro

Mantener prestamos

<<include>>

Prestar libro

Referencias de Casos de Uso

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

Contenidos

Introduccin al modelado del software

Presentacin de UML

Modelado de Casos de Usos

Diagramas de casos de uso

Modelado Estructural

Diagramas de Clases

Paquetes

Modelado estructural

Se describen los tipos de objetos de un sistema

y las relaciones estticas que existen entre
ellos.

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

Un diagrama de clase es una representacin

grfica de un modelo estructural.

Modelado estructural

Diferentes perspectivas.
Modelado Conceptual

Modelo del Anlisis

Clases que corresponden a conceptos del dominio

Atributos y mtodos

Modelo de Diseo

Conceptos del dominio del problema: atributos, restricciones

y relaciones entre ellos.

Incluye clases que corresponden a decisiones del diseo

Modelo de Implementacin

Clases que corresponden a un lenguaje de programacin

Modelo
Conceptual
CriteriosSeleccion

Requisitos

1..n
Curso
nombre
responsable
Prof-Universidad
duracion
fecha
numAlumnos
costeMatricula

1..n

Presupuesto
ingresos
gastos
Catalogo
Cursos

Edicion Curso
fecha
ao
id
1..n

impartido
1..n

Profesor
nombre
1..n
depto

Matricula
fecha

Expediente

1..n
Alumno
nombre
dni

Prof-Empresa

Preincripcion
fecha

Alumno
nombre
dni

Profesor

Modelo
Anlisis

0..n

nombre
dni

CatalogoProfesor

ProfesorContratado

ProfesorUniversitario

empresa
cuentaBancaria

EspecificacionCurso
nombre
horario
duracion
numCreditos
corteMatricula
numMaxAlum
numMinAlum
programa
criterioSeleccion
numEdiciones

0..n
ParticipacionCurso
asignarCargaDocente()

registra

1..n

CatalogoEspecificaciones
0..n

CriterioPreinscripcion
1

0..n

comprobar()

1
posee

Expediente
ponerNota()
1
0..1
1
Alumno

Curso
fechaInicio
numEdicion
plazoMatriculacion
plazoPreinscripcion

0..n

Matricula
nota
1

nuevaMatricula()
nuevaPreinscripcion()
asignarCarga()

0..n

tiene

0..n

setNota()

0..n

realiza
1

addMatricula()
addPreinscripcion()
0..n

1
0..n

1
CatalogoCurso

nombre
dni
email

Preinscripcion

posee

matriculable
0..n

esAdmitido()

realiza
1
CatalogoAlumnos

Modelo de
diseo

IteradorCuenta

Cuenta

Domiciliacion
1

Ahorro

0..n

Corriente
Operacion
Periodica

11: enviarPago(pagoAlumno)
matric :
Matricula
: Catlogo
Curso

3: c := get(idCurso)

:SistemaContabilidad

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

: Curso

10: [matriculable = true] create(a)

2: c := getCurso(idCurso)

1: realizarMatricula(idCurso,dniAlumno)

7: addMatricula(a)

9: matriculable:= esAdmitido()
c : Curso

: ControladorMatrculacionCurso

p : Preinscripcin

: Alumno

4: a := getAlumno(dniAlumno)

8: p:= get(a.dni)

13: addMatricula(matric)
12: add(matric)

: Alumno

: CatalogoAlumnos

14: add(matric)
: Alumno

6: create(datosAlumno)

: Preinscripcin

: Matricula

: Matricula

5: datosAlumno:= getDatosAlumno(dniAlum...

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

Modelo del
Comportamiento

Modelado estructural y del

comportamiento

Colaboraciones y Patrones de diseo tienen una

parte estructural y otra de comportamiento.

Realizar Compra

Realizar Compra

Patrn de diseo (parte esttica)

Subject
subjectState
Attach()
Detach()
Notify()

Observer

+observers
1..*

1..1

Update()

for all o in observers

{o.update()}

ConcreteSubject
subjectState
getState()
setState()

+subject

ConcreteObserver
observerState
update()

observerState=
subject.getState()

Patrn de diseo (parte dinmica)

: Subject

o1 : Observer
1. setState()

1.1. notify()
1.1.1. update()
1.1.2. update()

o2 : Observer

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.

Clases
Cuenta
ultimoCodigo
codigo
cliente
saldo
ultimasOperaciones
getSaldo()
getUltimasOperaciones()
nuevoCodigo()

Atributo
s

Operacione
s

No se tienen por qu mostrar todos las propiedades

Se pueden agrupar operaciones: <<constructor>>, <<query>>

Clases

Clases y mtodos abstractos

Multiplicidad
Variables y mtodos de clase
Cuenta
ultimoCodigo
codigo
cliente
saldo
ultimasOperaciones
getSaldo()
getUltimasOperaciones()
nuevoCodigo()

CatalogoPedidos 1
Figura
visualizar()
rotar()
trasladar()

pedidos
instance
addPedido()
removePedido()
getInstance()

Interfaces

Una interfaz es una coleccin de operaciones que

especifica los servicios de una clase o componente.
<<Interface>>
Collection
add()
remove()
size()
contains()
iterator()

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

Atributos
[visibilidad] nombre [: tipo] [[multiplicidad]] [= valor_inicial ]
[property-string {, property-string}]

visibilidad

+ =
# =

pblica
protegida

=
~ =

privada
package

nombre:

nombre del atributo

tipo:

tipo del atributo

valor_inicial: valor inicial o por defecto

propiedades: {frozen} {addOnly}

Atributos : Ejemplos

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

Operaciones
[visibilidad] nombre [(lista_parametros)] [: tipo_retorno]
[property-string {, property-string}]

visibilidad

+ =
# =

pblica
protegida

=
~ =

privada
package

nombre: nombre de la operacin

lista_parmetros: lista de parmetros separados por comas
tipo retorno:

tipo de valor devuelto por la operacin

propiedades:

{isQuery}, {sequential}, {concurrent}

Operaciones: Ejemplos

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

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

Clases Parametrizadas
G

Clase
Parametrizada

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

Instanciacin

Tabla<Cliente>

bind <Empleado>

Empleados

Clases Estereotipadas
<<entity>>
Cuenta

Cuenta

Cuenta

<<control>>
Controlador Ingreso

Controlador Ingreso

Controlador Ingreso

<<boundary>>
JFrameBanco

JFrameBanco

JFrameBanco

Clases del modelo o entidad, controlador e interface

Relaciones
Dependencia
Un cambio en la especificacin de un elemento
afecta a otro elemento
Window
parent
children
position
size

Lista

Nodo
<<friend>>

DigitalClock

open()
close()
move()
resize()

PlanDeCurso
aadir(c : Curso)
eliminar(c : Curso)

Curso

Estereotipos para dependencias

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

defecto

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

diferentes modelos

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

<<friend>>: dependencia de clase amiga

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

<<access>>: similar a <<import>>

<<extend>>: para casos de uso

<<include>>: para casos de uso

Relaciones
Generalizacin

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

Window

Cuenta

Cuenta Ahorro

Cuenta Corriente

TextWindow

BoxDialog

Relaciones
Asociacin

Relacin estructural que especifica que los objetos de

un tipo estn conectados con los de otro.

Persona

+empleado
1..n

+patron
trabaja para

Empresa

0..n

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

Asociaciones
Agregacin

Caso especial de asociacin

Relacin estructural parte-de
Empresa
1..1

*
Departamento

Navegabilidad

Asociaciones son bidireccionales

Posibilidad de limitar la navegacin de una
asociacin a una sola direccin
Determina si una clase de la asociacin tiene
conocimiento de la otra.
Nivel de diseo o implementacin
Pedido
fecha
esCompleto 1

contiene
1..n

ItemPedido
cantidad

describe
0..n

Producto
precio
descripcion

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

Navegabilidad (UML 2.0)

A

Navegabilidad indefinida

Navegable de A a B, de B a A indefinida

Navegable en ambos sentidos

Navegable slo de A a B

No navegable en ningn sentido

Navegabilidad (Prctica habitual)

A

Navegabilidad en ambos sentidos

Navegable slo de A a B

No se usa

No se usa

No se usa

Visibilidad

Pblica:
Protegida:
Privada:
Paquete:

+
#

propietario
propietario
propietario
propietario

GrupoUsuarios

Usuario
0..n

0..n

+propietario
1

-clave
0..n

Clave

Asociaciones calificadas
Pedido
fecha
esCompleto

contiene

ItemPedido

producto
1

cantidad

Nivel Conceptual: Dentro del mismo pedido no pueden

existir dos lneas con el mismo producto

Nivel Anlisis: El acceso a ItemPedido es indexado por

productos

Nivel Implementacin: Se usa una tabla para almacenar

las lneas de pedido

Asociaciones calificadas
Class Pedido {
private Hashtable

_lineasPedido;

public ItemPedido getItemPedido(Producto unProducto);

public void addItemPedido (Integer cantidad,
Producto elProducto);

Agregacin

Dos criterios:

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

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

Habra cuatro posibles tipos de agregacin;

en UML hay dos: agregacin y composicin

Composicin

Forma fuerte de agregacin

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

Composicin
Window
1

agregado

+scrollbar
Slider

+title
2

Header

partes

1
+body
Panel

Clases Asociacin

Una asociacin que tambin es una clase

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

Ejemplo de clase asociacin

Persona

+empleado

+patron

1..n

Empresa

0..n

Contrato
salario
descripcion
fechaContrato

Distinta
semntica

Contrato
Persona
1

salario
descripcion
0..n fechaContrato

Empresa
1..n

Asociaciones derivadas
recibe
Estudiante

Asignatura

/ensea

imparte

Profesor

Asociaci
n
Derivada

Restricciones para Asociaciones

Empresa

Departamento
*

Cuenta

{or}
Persona

{subset}
+miembro

1..*
Persona

+Director
1..1

Restricciones para Asociaciones

operario

0..1

empleado

Persona

patrn
0..1

Empresa

jefe

{ Persona.patrn=
Persona.jefe.patrn }

Un empleado trabaja para la misma empresa que su jefe

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

ICollection

Interfaces, tipos y roles

Una interfaz es una coleccin de operaciones que

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

Interfaces
Target

Interfaz requerida
Interfaz
proporcionada

TargetTracker
Observer

Target

TargetTracker

Observable

Observer

Target
id
posicionActual
setPosicion()
setVelocidad()
posicionEsperada()

<<Interface>>
Observer
update()

TargetTracker

Clases Estructuradas
0..n

Prestamo
+prestamos

0..n

1
Prestatario

+catalogo

Personal

estudiante: prestamos < 5

personal: prestamos < 10

0..n

1
Biblioteca

+prestatarios
0..n

Estudiante

Libro

libroPrestado

Bibliotecario
1

1..n

Clases Estructuradas
Estructura interna de una clase
Biblioteca

estudiante: Prestatario [0..*]

PrestamoEstud: Prestamo [0..4]

0..*

personal: Prestatario [0..*]

1

:Libro: [0..*] 1

0..*

:Bibliotecario [1..*]

biblioConectado:Bibliotecario [0..1]

PrestamoPerso: Prestamo [0..9]

Diagrama de estructura compuesto

Biblioteca

estudiante: Prestatario [0..*]

PrestamoEstud: Prestamo [0..4]

0..*

personal: Prestatario [0..*]

1

Libro: [0..*]

0..*

:Bibliotecario [1..*]

biblioConectado:Bibliotecario [0..1]

PrestamoPerso: Prestamo [0..9]

Contenidos

Introduccin al modelado del software

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

Paquetes

Paquetes

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

Si eliminamos el paquete se elimina el elemento

Establece un espacio de nombres

Posibilidad de anidar paquetes

Modelo

Modelo
+ Producto
+ CarroCompra
+ Comercio

Paquetes: Notacin

Importacin/Exportacin en paquetes

Visibilidad pblica y privada

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

Importacin/Exportacin en paquetes

La relacin de acceso es igual que la importacin,

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

Cliente
+ FormularioPedido
+ FormularioDeSeguimiento
- Pedido

Servidor
+ BaseDeDatos
+ ServicioDeRegistro

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

GUI
+ Ventana
+ Formulario
# GestorEventos

<<import>>

Auxiliary

<<access>>
ShoppingCart

WebShop

<<import>>
Types

<<import>>

Generalizacin de Paquetes
GUI
+ Ventana
+ Formulario
- GestorEventos

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

MacGUI

Paquetes

Un paquete bien estructurado debe:

ser cohesivo
estar poco acoplado
pocos anidamientos
conjunto equilibrado de elementos

Uso de los paquetes

Agrupar elementos relacionados para

manejarlos en conjunto. Ejemplos:
Paquete Clases e interfaces del modelo
Paquete Interfaces de usuario
Paquete Servicios base de datos
Paquete Modelo del anlisis

Uso de los paquetes

Modelo de
Anlisis

<<framework>>
Struts

Modelo

Un modelo captura una vista de un sistema

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

Modelo

Vistas UML: 4 + 1
vocabulario
funcionalidad

ensamblado
gestion conf.
Vista de Implementacion

Vista de Diseo

comportamiento

Vista de casos de uso

Vista de Interaccin

capacidad de procesamiento
escalabilidad
rendimiento

Vista de Despliegue

topologa
entrega
distribucin
instalacin

Vistas UML: 4 +1
clases
interfaces
colaboraciones

componentes

Vista de Implementacion

Vista de Diseo

casos de uso

Vista de Interaccin

clases activas

Vista de casos de uso

Vista de Despliegue

nodos

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

Diagramas de componentes
Diagrama de interaccin
Diagramas de estado
Vista de Implementacin

Diagramas de casos de uso Vista de casos de uso

Vista de Interaccin

Diagramas de clase
Diagramas de interaccin
Diagramas de estado

Vista de Despliegue

Diagramas de despliegue

Contenidos

Modelado del Comportamiento

Componentes
Modelado de la Implementacin

Diagramas de interaccin
Diagramas de actividades
Mquinas de estado

Artefactos y despliegue
Diagramas de despliegue

Colaboraciones
UML, Metamodelado y MDA

Enlaces y Conectores

Un enlace es :

una conexin semntica entre objetos.

comnmente es una instancia de una asociacin.
un camino por el cual enviar un mensaje

Una lnea de vida es un participante en una

interaccin.
Un conector es un enlace entre lneas de vida

Enlaces y Asociaciones
Persona
calcularCompensacion()
asignar()

+empleado

+patron

1..*

Empresa
*

enlace
p:Persona

objeto

:Empresa
1: asignar(desarrollo)

mensaje

Enlaces

Restricciones para expresar la naturaleza del

enlace:

association
self
global
local
parameter

Diagrama de Objetos
: Cuenta

: Cliente

: Perfil

: CodigoCuenta

: Tarjeta

: Transaccion

Diagrama de Objetos
: Curso

: Alumno
: Profesor

: Tarjeta

: Expediente

: Departamento

director : Profesor

: GrupoInvestigacion

: Tarjeta

Diagrama de Objetos
: Curso

: Profesor

: Tarjeta

profesores *

alumnos *

: Expediente

: Departamento

grupos *

director : Profesor

: Alumno

:
GrupoInvestigacion

: Tarjeta

Interacciones y Mensajes

Interaccin: Comportamiento que comprende

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

Mensaje: especificacin de una particular

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

Lneas de Vida
Persona
calcularCompensacion()
asignar()

+empleado

+patron

1..*

umu: Empresa

lnea de
vida

Empresa

irene:Persona

asignar(desarrollo)

mensaje

Lneas de Vida
Persona
calcularCompensacion()
asignar()

+empleado

+patron

1..*

Empresa
*

conector
p:Persona

:Empresa
:Empresa
umu:
Empresa

irene:Persona

lnea de
vida

1: asignar(desarrollo)

mensaje

Tipos de mensajes

Sncrono

Asncrono

El emisor no espera a recibir el resultado

Retorno

El emisor espera hasta recibir el resultado

Indica el retorno de una llamada

Creacin y destruccin

<<create>> y <<destroy>>

Modelado del comportamiento

Se describe cmo los objetos colaboran entre s para

realizar cierta actividad.
Se expresan mediante los diagramas de
interaccin:

Diagramas de Secuencia y Diagramas de Comunicacin

Tambin se describe las mquinas de estado que

caracterizan a los objetos y flujos de actividades

Diagramas de estado
Diagramas de actividades

Diagramas de Interaccin

Describen una interaccin y hay dos tipos.

Diagramas de Secuencia:

Diagramas de Comunicacin:

Destacan la ordenacin temporal de los mensajes

Destacan la organizacin estructural de los objetos
participantes.

Equivalencia semntica

Diagramas de Secuencia

Incluye:

Lneas de vida (antes objetos y su lnea de tiempo )

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

Mensajes
Simple:
Creacin de objetos:
Destruccin de objetos:
Asignacin:
Identificar hilo:

metodo(arg)
<<create>>
<<destroy>>
v:= mtodo(arg)
nmero del mensaje en la
secuencia precedido por el nombre
del proceso o hilo

En UML 2.0 en diagramas de comunicacin:

Condicin:
[condicion] metodo(arg)
Iteracin:
* metodo(arg), [1..n] metodo(arg)
Numeracin jerrquica o secuencial o ninguna

Mensajes
Simple:
Condicin:
Iteracin:
Asignacin:
Identificar hilo:

preparar(), addPedido(p)
[condicion] metodo(arg)
* preparar()
hayStock:= eliminar()
D3 : activar()

Diagrama de Secuencia
sd Gestin Pedidos
: GUIPedido
:GUIPedido

: ControladorPedidos
:ControladorPedidos

preparar( )

preparar( )

::Pedido
Pedido

: LineaPedido
:LineaPedido

* preparar( )

: Item
:Item

: ItemPedido

: ItemEntre

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

:ItemPedido
[hayStock] <<create>>

:Item
Entregado

Diagrama de Comunicacin
sd Gestin Pedidos
1: preparar( )
: GUIPedido

3: *preparar(
)
3:
preparar()

2: preparar( )
: ControladorPedidos

: Pedido

: LineaPedido

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

: ItemPedido

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

: ItemEntregado

Diagrama de Secuencia
c:Cliente

p:ProxyODBC
<<create>>

:Transaccion

establecerAcciones
establecerValores

establecerValores

tiempo
exito

<<destroy>>

Foco de
control

Lnea de vida

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

c:Cliente
t {local}

proxy {global}
3: establecerValores
4: establecerValores

p:ProxyODBC

Operadores de control

Ejecucin opcional (opt)

Ejecucin condicional (alt)

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 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 ejecuta si se cumple una condicin

El cuerpo se ejecuta mientras se cumple una condicin

Ejecucin referencia (ref)

El cuerpo hace referencia a otra interaccin

sd reintegro
usuario : Persona

banco : CajeroAutomatico

loop(1,3)
[password incorrecto]

introducir (password)
verificar(password)

opt

[password valido]

par

introducir(cuenta)

introducir(cantidad)

entregar(dinero)

Fragmento
combinado

Diagrama de actividad anidado

sd reintegro
usuario : Persona

banco : CajeroAutomatico

ref
Obtener password

opt

[password valido]

ref
Obtener dinero

Numeracin secuencial
2: m2()

1: m1()
:A

3: m3()
:B

:C

4: m4()

:D

Confusin en el flujo de ejecucin

Numeracin jerrquica
:A

:B
m1( )

:C

m2( )
m3( )
m4( )

:D

Numeracin jerrquica
:A

:B

:C

1. m1()
1.1. m2()

1.2. m3()

1.3. m4()

:D

Numeracin jerrquica
1.1. m2( )

1. m1( )
:A

1.2. m3( )
:B

:C

1.3. m4( )

:D

Numeracin jerrquica
:A

:B

:C

1. m1( )
1.1. m2( )
1.1.1. m3( )

1.2. m4( )

:D

Numeracin jerrquica
1.1. m2( )

1. m1( )
:A

1.1.1. m3( )
:B

:C

1.2. m4( )

:D

Profesor
1

0..n

nombre
dni

CatalogoProfesor

Diagrama de
clases

ProfesorContratado

ProfesorUniversitario

empresa
cuentaBancaria

EspecificacionCurso
nombre
horario
duracion
numCreditos
corteMatricula
numMaxAlum
numMinAlum
programa
criterioSeleccion
numEdiciones

0..n
ParticipacionCurso
asignarCargaDocente()

registra

1..n

CatalogoEspecificaciones
0..n

CriterioPreinscripcion
1

0..n

comprobar()

1
posee

Expediente
ponerNota()
1
0..1
1
Alumno

Curso
fechaInicio
numEdicion
plazoMatriculacion
plazoPreinscripcion

0..n

Matricula
nota
1

nuevaMatricula()
nuevaPreinscripcion()
asignarCarga()

0..n

tiene

0..n

setNota()

0..n

realiza
1

addMatricula()
addPreinscripcion()
0..n

1
0..n

1
CatalogoCurso

nombre
dni
email

Preinscripcion

posee

matriculable
0..n

esAdmitido()

realiza
1
CatalogoAlumnos

11: enviarPago(pagoAlumno)
matric :
Matricula
: Catlogo
Curso

3: c := get(idCurso)

:SistemaContabilidad

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

: Curso

10: [matriculable = true] create(a)

2: c := getCurso(idCurso)

1: realizarMatricula(idCurso,dniAlumno)

7: addMatricula(a)

9: matriculable:= esAdmitido()
c : Curso

: ControladorMatrculacionCurso

p : Preinscripcin

: Alumno

4: a := getAlumno(dniAlumno)

8: p:= get(a.dni)

13: addMatricula(matric)
12: add(matric)

: Alumno

: CatalogoAlumnos

14: add(matric)
: Alumno

6: create(datosAlumno)

: Preinscripcin

: Matricula

: Matricula

5: datosAlumno:= getDatosAlumno(dniAlum...

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

Diagrama de Colaboracin
UML 1.x

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

public class TestHilo {

private EjemHilo h1, h2;
public void inicio(){
h1 = new EjemHilo("Hilo 1", 4);
h2 = new EjemHilo("Hilo 2", 6);
EjemHilo.out.println(Preparados los dos hilos");
h1.start();
h2.start();
EjemHilo.out.println("Arrancados los dos hilos");
}
public static void main(String[] args) {
TestHilo testHilo1 = new TestHilo();
testHilo1.inicio();
}
}

EjemHilo1.out:PrintWriter

t: TestHilo
new(Hilo 2, 4)

:h1: EjemHilo

inicio
new(Hilo 2, 6)
:h2: EjemHilo
println(preparados los dos hilos)
start()

run()

start()

run()

println(arrancan los dos hilos)

delay()
[1..4]

delay()
[1..6]

Uso de los diagramas de interaccin

Modelado del aspecto dinmico.

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

casos de uso
colaboraciones
patrones
frameworks
operaciones

Diagramas de Secuencia vs. Diagramas de

Comunicacin

Equivalencia semntica
Simples para comportamientos simples.
Si hay mucho comportamiento condicional,
usar diferentes escenarios.
Diagramas de secuencia muestran mejor el
orden en que se ejecutan los mensajes
Diagramas de colaboracin muestran
claramente los objetos a los que est
conectado un determinado objeto.
Permiten la generacin de cdigo

Diagramas de Actividad

Representa una actividad.

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

nodos accin y actividad

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

Una actividad o una accin produce algn

efecto que provoca algn cambio en el
sistema o retorna un valor.

Nodos de Actividad

Nodos de accin

Nodos de control

Controlan el flujo de la actividad

Nodos de objetos

Realizan un trabajo: llamadas a operaciones,

actividades, comportamiento, envo de seales,
aceptar un evento.

Objetos o datos utilizados en la actividad

Flujo de control de la actividad

Flujo de objetos en la actividad

Semntica actividades

Basada en el flujo de tokens.

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

Ejemplo
Fabricacin
productos

inicio
Planificar
tareas

Flujo

Asignar
tareas

Realizar
tareas

finalizacin

Bifurcacin
Obtener orden
de trabajo

Nodo de
decisin

[ material no disponible ]

[ material disponible ]
Asignar tareas

Nodo de
fusin
Obtener siguiente
orden de trabajo

Volver a
planificar

Divisin y Unin
Disear
producto

Comercializar
producto

divisin

Fabricar
producto

unin
Vender
producto

Ejemplo

Ejemplo

Elegir sitio

Contratar
arquitecto
Realizar planos

Pedir ofertas
[ no aceptado ]

Construir

Finalizar
construccin

Trabajo
administrativo

Certificado
Habitabilidad
[completado]

Solicitar Producto

Procesar Pedido

Extraer Artculos

Enviar Pedido

Recibir Producto

Pagar Factura

Facturar al cliente

Cerrar Pedido

Cliente

Ventas

Almacn

Solicitar Producto

Procesar Pedido

Extraer Artculos

Enviar Pedido

Recibir Producto

Pagar Factura

Facturar al cliente

Cerrar Pedido

Calles

Cliente

Ventas

Solicitar Producto

Procesar Pedido

Almacn
o: Pedido
[en progreso]

Objetos

Extraer Artculos

Enviar Pedido

o: Pedido
[completado]

Recibir Producto

Facturar al cliente
b: Factura
[impagada]

Pagar Factura

b: Factura
[pagada]
Cerrar Pedido

Calles

Particiones de actividades

Pins

Regiones de
Expansin

Recibir pedido
:Pedido
:LineaPedido

Obtener Item

Calcular coste

:Producto

:Dinero

:Envio

:Factura

Enviar pedido

Enviar factura

Otras cuestiones

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

Diagramas de
visin de
interaccin

Utilidad de los diagramas de actividad

Modelado de flujos de trabajo (workflow) como son

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

Eventos

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

Seales (excepciones)
Llamadas
Paso de tiempo
Cambio de estado

Seales

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

<<exception>>
Duplicado

Conjunto
aadir()
eliminar()

<<send>>

<<exception>>
Overflow

<<send>>

<<send>>

<<exception>>
Underflow

Eventos de tiempo y cambio

Tiempo

Representa el paso de tiempo

at (3 Oct 2006, 1000 UT), at(14:45PM),

after 2 seconds, after 1 ms exiting Activo

Cambio

Representa un cambio de estado o que se

satisface una condicin.
when expresin-booleana
when (saldo < 0)

Mquina de estados

Especifica la secuencia de estados por las que pasa

un objeto a lo largo de su vida en respuesta a
eventos, junto con sus respuestas a esos eventos.
tiles para objetos reactivos, las instancias de su
clase

deben responder a eventos externos o internos

tienen un comportamiento que depende de su historia
tienen un ciclo de vida modelado como una progresin de
estados, transiciones y eventos.

Se representa mediante un diagrama de estados.

Estados

Un estado es una situacin en la vida de un

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

Nombre
Acciones entrada/salida
Transiciones internas
Subestados
Eventos diferidos

Transiciones

Una transicin de un estado A a un estado B, se

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

Elementos de una transicin:

Estados origen y destino

Evento de disparo (cero o ms)
Condicin de guarda (cero o ms)
Accin (cero o ms)

apagar

Inactivo
haceFrio(tempDeseada)
haceCalor(tempDeseada)

tempOK
tempOK

Calentando

Enfriando
haceCalor(tempDeseada)

haceFrio(tempDeseada)

Activacin

listo/encender()

Activo

after (2 sec) send c.estaActivo

ruido

Inactivo

Buscando

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

Acoplamiento

Rastreando
contactar

Partes de un estado

accin entrada
transicin interna
evento diferido

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

accin
salida
actividad
(accin)

Diagrama de Estado (Caso de Uso)

introducirProducto

Espera Venta

introducirProducto

Introduccion
Productos

Terminar Venta
manejarRespuesta
efectuar Pago Efectivo

Autorizacion
Pago
efectuar Pago Tarjeta

Espera
Pago

Diagrama de Estado (Caso de Uso)

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

enviarCargo (codigoCuenta,..)

Pago

rechazarPago

Pago No
apobado

enviarCargo (codigoCuenta,..)

pagoAprobado

Envio

pedidoEntregado

Entregado

Subestados no ortogonales
introducirTarjeta

Activo

Inactivo

entry/leerTarjeta
exit/expulsarTarjeta

Validacin
cancelar
mantener

Mantenimiento

Seleccin

[continuar]
Procesando

[no continuar]
Impresin

Subestados ortogonales

Subestados ortogonales
Mantenimiento
mantener

Inactivo

Pruebas
Probar
perifericos

Manejo Ordenes

AutoDiagnosis

[continuar]
Orden

Espera
Pulsar tecla

[no continuar]

Contenidos

Modelado del Comportamiento

Componentes
Modelado de la Implementacin

Diagramas de interaccin
Diagramas de actividades
Mquinas de estado

Artefactos y despliegue
Diagramas de despliegue

Colaboraciones
UML, Metamodelado y MDA

Componentes

Es una parte modular de un sistema que encapsula

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

Componentes

Un componente es una parte reemplazable de un

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

Propiedades de un componente
Interfaz
Componente

1..*

Especificacin
Componente

1
*

Implementacin
Componente
1
*

Instancia
Componente

Instalacin
Componente

Propiedades de un componente

Es una unidad de despliegue independiente.

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

Componentes
Persona

AsignacionItem
<<component>>

Seguimiento

Pedido

Factura

ItemPedido

Interfaces
proporcionadas

Interfaces
requeridas

Componentes

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

Interfaz
proporcionad
a

<<component>>

Pedido

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

Interfaz
requerida

Componentes

JerarquaElementos
explorador.java

arbol.java

Componentes

Puertos

Representan un punto de interaccin entre una

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

Requeridas: especifican las peticiones que se pueden

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

Puertos

Los puertos son normalmente parte de un

componente
Cuando se crea una instancia de un
componente, se crean instancias de sus
puertos

Un puerto tiene multiplicidad

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

Componente con puertos

Puerto
Reservar
Cargar
espectculos

ventas
normales

Ventas Ticket

atracciones

Vendedor Ticket
Tarjetas Crdito

cobros
ventas
prioritarias

Ventas Ticket

Conexin de componentes

:Inventario

:EncontrarItems

:EnviarItems

GestionPedido

Estructura Interna (Componentes)

Una parte es una unidad de implementacin de un

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

Las partes pueden ser componentes conectados a travs

de sus puertos.

Estructura interna
Compilador

lex:AnalizadorLexico

parse: Parser

gen: GeneradorCodigo

opt:Optimizador [1..3]

Compilar

Estructura interna
Venta Ticket Vuelos

:AsignacionAsiento

normal:Venta

:GestionInventario

Prioridad:Venta

Estructura interna
Ventas por Catalogo

:Cumplimentar

:Inventario

:EncontrarItems

:EnviarItems

:PasarPedido
:EntradaPedido

Cobro:Credito

:CapturaPedido

GestionPedido

Estructura Interna

<<component>>

A
I2

I1
b:B
I1

<<delegate>>

c:C
<<delegate>>

I2

Conectores

Una conexin entre dos puertos se denomina

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

Componentes

Subsistemas

Unidad de descomposicin de un sistema que se define como

componente con el estereotipo <<subsystem>>.
Elemento lgico, en tiempo de ejecucin se pueden instanciar
sus contenidos.
<<subsystem>>

GUI

<<subsystem>>

Lgica del
Negocio

Contenidos

Modelado del Comportamiento

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

Artefactos

Un artefacto es una parte fsica de un sistema que

existe a nivel de la plataforma de implementacin.
Es una implementacin fsica de un conjunto de
elementos lgicos tales como clases y
componentes:

Relacin de dependencia estereotipada con manifest

Representan el empaquetamiento fsico de bits

sobre la plataforma de implementacin.
Residen en nodos.

Artefactos
artifact
agente.java

artifact
agenteFraudes.dll
manifest

artifact
agenteFraudes.dll
manifest
AgenteFraudes
PolticaFraudes
PatrnBsqueda

manifest
manifest

agenteFraudes

PolticaFraudes

PatrnBsqueda

Tipos de Artefactos

Despliegue

Productos del trabajo

Necesarios y suficientes para formar un sistema

ejecutable: libreras dinmicas, ejecutables, script,..
Permanecen al final del proceso de desarrollo: archivos
cdigo fuente y ficheros de datos a partir de los cuales se
crean los artefactos de despliegue.

De ejecucin

Se crean durante la ejecucin: objeto .NET instanciado a

partir de una DLL.

Estereotipos de Artefactos

<<file>> : Archivo fsico

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

Modelado de ejecutables
artifact
v.exe

artifact
Vwbas20.dll

artifact
Vwdev20.dll

artifact
Wscr20.dll

Nodos

Un nodo es un elemento fsico que existe en tiempo

de ejecucin y representa un recurso computacional
que puede tener memoria y capacidad de
procesamiento.
Los artefactos se ejecutan en nodos
Los artefactos se despliegan sobre los nodos.
Dos tipos de nodos:

<<device>> : tipo de dispositivo fsico como un PC o un

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

Nodos
Ventas
artifact
pos.exe
artifact
contactos.exe

manifest

Venta

manifest

Contrato

Diagramas de Despliegue

El despliegue es el proceso de asignar artefactos a

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

Forma de descriptor y forma de instancia

Incluye nodos y arcos que representan conexiones fsicas
entre nodos (o instancias de nodos y arcos).

Modelado de sistemas empotrados, sistemas clienteservidor, sistemas distribuidos.

Nodos

<<device>>
PC Windows

<<device>>
PC Linux
0..*

0..*
<<http>>

<<execution environment>>
FireFox

<<execution environment>>
Apache

Diagrama de Despliegue

terminal

<<10-T-Ethernet>>

servidor

<<RS-232>>
Consola

Unidad
RAID

Contenidos

Modelado del Comportamiento

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

Colaboraciones

Sociedad de clases, interfaces y otros elementos

que
colaboran
para
proporcionar
un
comportamiento cooperativo mayor que la suma
de los comportamientos de los elementos.

Parte estructural (modelo de clases) y parte de

comportamiento (modelo de interaccin).

Colaboraciones

El ncleo de la arquitectura de un sistema

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

Casos de uso y Colaboraciones

caso de uso
colaboracin
Hacer Pedido
Gestin Pedidos

realizacin

Modelo Estructural

Usuario
nombre
1
nif

0..n

Pedido
id
total

1..n

0..n

1
CarroCompra
total

LineaPedido
unidades

0..n

ItemCarro
unidades

0..n

Producto
nombre
precio
descripcion

Modelo Comportamiento
: Usuario
11: recalcularTotal()
1: aadirItem(codigo)
4: aadirItem(codigo)
2: aadirItem(codigo)

: MostrarProductos

3: [primer producto] crear()

: Aadir

: CarroCompras

6: [!nuevoItem]incrementarUnidades()

10: [nuevoItem]put(codigo,i)

5: i:=getItemCarro(codigo)

: ItemCarro

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

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

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

: Producto

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

Mecanismo trading (Parte esttica)

Cli enteDeGestor

Trader
1..n

1..1

FactoriaEditor
1..1

1..n
1..1

0..n
especifica

necesita editar

1..1
editado con

ObjetoInformacion
1..n

1..n

1..n

Editor

Mecanismo trading (Comportamiento)

: ClienteDeGestor

: Trader

editar(info)

: FactoriaEditor

info :
ObjetoInformacion

* i:= getInterfaz()

p:= soportaInterfaz(i)

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

: Editor

Clases Cliente, Editor y ObjetoInformacion?

Colaboraciones Plantilla
Modelado de patrones de diseo
Subject
Observer
Observer
Subject

Alarma

Observer

Ventana

Patrn de diseo (Parte Esttica)

Subject
subjectState
Attach()
Detach()
Notify()

Observer

+observers
1..*

1..1

Update()

for all o in observers

{o->update}

ConcreteSubject
subjectState
getState()
setState()

+subject

ConcreteObserver
observerState
update()
observerState=
subject->getState()

Patrn de diseo (Parte dinmica)

: Otra
:Cliente

: Subject
:Subject

o1
: Observer
o1:Observ
er

1. setEstado()
1.1. notify()
1.1.1. update()

1.1.2. update()

o2 : Observer
o2:Observ
er

Contenidos

Modelado del Comportamiento

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

Lenguajes OMG

MOF (Meta Object Facility)

UML
Perfiles UML
OCL
Action Semantics

Definir semntica de modelos de comportamiento

Muy bajo nivel
No define una sintaxis concreta

QVT

Lenguaje estndar para definir transformaciones

Metamodelado

Un lenguaje de modelado o DSL se define

formalmente mediante un metamodelo:

Sintaxis abstracta y restricciones

Sintaxis concreta
Semntica

Necesidad de un lenguaje de metamodelado:

OMG

Eclipse (EMF, Eclipse Modeling Framework)

MOF: EMOF y CMOF

Ecore

Otros: Herramientas de metamodelado existentes

disponen de uno propio (XMF, Metaedit+, DSL Tools,...)

Metamodelado

Un metamodelo define los elementos de un lenguaje

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

Necesidad de conocer bien el dominio

Metamodelado
0..1

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

StateMachine

0..1

Event

1
+top

0..n

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

0..n

0..n

State
+states

Sintaxis abstracta
de una mquina de
estados

0..1

CompositeState

0..n

Metamodelado
after (2 sec) send c.estaActivo

ruido

Inactivo

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

Buscando

Acoplamiento

Rastreando
contactar

Sintaxis concreta
de una mquina de
estados

Metamodelado

MOF y Ecore se basan en elementos de

modelado orientado a objetos:

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

MOF (MetaObject Facility)

MOF es el lenguaje para crear metamodelos

propuesto por OMG para MDA.

UML est definido como un metamodelo MOF.

Aplicable a cualquier dominio.
Lenguajes OMG: CWM, EJB, EAI, EDOC

Medio universal para definir lenguajes de

modelado

Independiente de la plataforma

MOF (MetaObject Facility)

MOF es descrito con la notacin UML, OCL y

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

MOF

Cada elemento del lenguaje de modelado se

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

Arquitectura de cuatro niveles en MDA

Nivel

Descripcin

M3

MOF

M2

metamodelos, instancias de
los elementos MOF

M1

modelos, instancia de un
metamodelo MOF

M0

el sistema, objetos y datos,

instancias de los elementos de
un modelo

Arquitectura de cuatro niveles: Ejemplo

Nivel

Ejemplo

Elementos

M3

MOF

Clase, Atributo,
Asociacin,..

M2

Metamodelo de UML

Clase, Atributo,
Asociacin, Estado,
Actividad, Caso de uso,

M1

Modelo de clases UML

para un sistema TPV

Clase Cliente, atributo

dni, asociacin
Cliente-Pedido

M0

Instancias de elementos
en el modelo de clases
del TPV

Cliente Pepe Prez,

87654321,
Cliente Ana Haro,
1234567,

Arquitectura de cuatro niveles

OCL (Object Constraint Language )

Lenguaje de especificacin para escribir

expresiones sobre modelos, p.e. queries, reglas
de derivacin de atributos, el cuerpo de
operaciones de consulta, pre y postcondiciones o
el invariante, guardas.
Extiende la potencia expresiva de UML y permite
crear modelos ms precisos y ms completos.
Es tipado, cada expresin OCL tiene un tipo.
Utilizado para escribir las restricciones

Expresiones OCL
context c : Empresa
inv suficientesEmpleados: c.numeroEmpleados > 50
context Empresa
inv: self.empleados.select(p: Persona| p.edad>50)->notEmpty()
context Trabajo
inv: self.empleador.numeroEmpleados >= 1
inv: self.empleado.edad > 21

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

MDA

Propuesta basada en estndares de OMG:

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

MOF es el lenguaje de metamodelado

MDA
PIM

Modelo
independiente
de la plataforma

PSM

Cdigo

Modelo
especfico de la
plataforma

Nuevo paradigma de desarrollo de software:

Desarrollo dirigido por modelos

MDA
Transformaciones de modelos en MDA

PIM

Motor M2M

PS
M

L1
UML

Motor M2C

Cdigo
L3

L2

Definicin
Transformacin
L1 a L2
L4
Lenguaje M2M

UML

Definicin
Transformacin
L2 a L3

Java, C#
XML,
SQL,

L5
Lenguaje M2C

PIM
<<BusinessEntity>>
Cuenta
<<UniqueID>> codigo : Integer
0..n
saldo : Float

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

PSM
<<EJBEntityBean>>
+cuenta
Cuenta
<<PrimaryKey>> codigo : Integer
0..n
saldo : Float

+cliente
1

<<EJBEntityBean>>
Cliente
<<PrimaryKey>> id : String
nombre : String
apellido : String
<<EJBFinderMethod>> findByLastName()

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

MDA

PIM

PSM
Relacional

Cdigo SQL

PSM
EJB

Cdigo EJB

PSM
Web

Cdigo
JSP/Servlets

307