Modelado Uml 2

Modelado de Software
Orientado a Objetos usando UML

Dr. Pedro Mejia Alvarez
Departamento de Computacion
CINVESTAV-IPN
Pedro Mejia
Curso de Ingeniera de Software, CINVESTAV-IPN
Contenido
1.
2.
3.
4.
5.
Pedro Mejia
Fundamentos del Modelado OO

Requisitos del software
Interaccin entre objetos
Clases y relaciones entre clases
Diagramas de UML
Diagramas de UML
Los diagramas expresan grficamente partes de un modelo
Use Case
Use Case
Diagramas de
Diagrams
Diagrams
Secuencia
Scenario
Scenario
Diagramas de
Diagrams
Diagrams
Colaboracin
Scenario
Scenario
Diagramas de
Diagrams
Diagrams
Estados
Pedro Mejia
Use Case
Use Case
Diagramas de
Diagrams
Diagrams
Casos de Uso
State
State
Diagramas de
Diagrams
Diagrams
Clases
State
State
Diagramas de
Diagrams
Diagrams
Componentes
Modelos
Diagramas de
Actividad
State
State
Diagramas de
Diagrams
Diagrams
Objetos
Component
Component
Diagrams
Diagramas
Diagrams de
Distribucin
Diagrama de Clases
El Diagrama de Clases es el diagrama principal
para el anlisis y diseo del sistema
Un diagrama de clases presenta las clases del
sistema con sus relaciones estructurales y de
herencia
La definicin de clase incluye definiciones para
atributos y operaciones
El modelo de casos de uso debera aportar
informacin para establecer las clases, objetos,
4
atributos y operaciones
Pedro Mejia
Objetos
Objeto = unidad atmica que encapsula estado y

comportamiento
La encapsulacin en un objeto permite una alta
cohesin y un bajo acoplamiento
La cohesion es la medida de la cercania de las
relaciones entre sus componentes.
El acoplamiento es una medida de la fuerza de las
interconecciones entre los componentes en el diseo.
Un objeto puede caracterizar una entidad fsica
(coche) o abstracta (ecuacin matemtica)
Pedro Mejia
Clases y Objetos
En UML, para distinguir
una clase y una instancia de
la clase (un objeto) se
representa por un rectngulo
con un nombre subrayado
Objeto = Identidad + Estado
+ Comportamiento
El estado est representado
por los valores de los
atributos los cuales tienen
una visibilidad.
Un atributo toma un valor
en un dominio concreto.
Pedro Mejia
Alumno
DNI : char[10]
nmero_exp : int
nombre : char[50]
alta()
poner_nota(asignatura : char *, ao : int, nota : float)
matricular(cursos : asignatura, ao : int)
listar_expediente()
Clases y objetos
La clase define el mbito de definicin de un conjunto de

objetos
Cada objeto pertenece a una clase
Los objetos se crean por instanciacin de las clases
Para distinguir entre una clase (el tipo) y un objeto (una

instancia del tipo), un objeto se muestra subrayado. Un objeto
puede representarse como anObject, anotherObject:Class, o
:Class.
Las clases y los objetos forman parte de varios diagramas UML.

Pedro Mejia
Clases: Notacin Grfica
Cada clase se representa en un

rectngulo con tres compartimientos:
Motocicleta
nombre de la clase
atributos de la clase
operaciones de la clase
Pedro Mejia
color
cilindrada
velocidad mxima
arrancar()
acelerar()
frenar()
Clases: Encapsulacin
La encapsulacin permite la cohesion y

presenta dos ventajas bsicas:
Se protegen los datos de accesos indebidos
El acoplamiento entre las clases se
disminuye
Favorece la modularidad y el mantenimiento
Los atributos de una clase no deberan ser

manipulables directamente por el resto de
objetos
Pedro Mejia
Los niveles de encapsulacin estn heredados de los
niveles
de C++, y explican si estos son visibles desde el exterior
de
la clase:
(-) Privado : es el ms fuerte. Esta parte es
totalmente invisible (excepto para clases friends en
terminologa C++)
(#) Los atributos/operaciones protegidos estn
visibles para las clases friends y para las clases
derivadas de la original
(+) Los atributos/operaciones pblicos son visibles
a otras clases (cuando se trata de atributos se est
10
transgrediendo
el principio de encapsulacin)
Pedro Mejia
Ejemplo:
Reglas de visibilidad
+ Atributo pblico : Integer
# Atributo protegido : Integer
- Atributo privado : Integer
+ "Operacin pblica"()
# "Operacin protegida"()
- "Operacin privada"()
Pedro Mejia
11
Diagramas de Clases
Un diagrama de clases describe los tipos de objetos
en el sistema y los distintos tipos de relaciones
estticas que existen entre ellos. Existen cuatro
relaciones:
Asociacin
Generalizacin/especializacin
Agregacin/composicin
Dependencia
Pedro Mejia
12
Asociacin
Departamento
dirige
director
0..1
Empresa
Profesor
1
empleador
trabajadores
Empleado
1..*
Cargo
nombre
sueldo
subordinado
superior
0..1
1..*
Permite asociar objetos.

La asociacion se representa mediante una lnea
que une las cajas de los dos objetos.
Pedro Mejia
13
Asociacin
Departamento
dirige
director
0..1
Profesor
1
Una asociacin se representa mediante una lnea que une las

cajas de las dos clases.
Esta asociacion tiene un nombre y opcionalmente una
pequea cabeza de flecha que indica la direccin en la cual
se debe leer el nombre de la asociacin.
En cada extremo de la lnea se sita la multiplicidad o
cuantas instancias de una clase se relacionan con una
instancia de la otra.
Se puede usar una flecha de lnea (stick arrow) para
representar la direccin de la navegabilidad.
Pedro Mejia
14
Asociacin
Ejemplo:
marido
casado-con
mujer
jefe
Administra
0..1
0..1
Persona
nombre
s.s.
emplea-a
Compaa
trabaja-para nombre
direccin
*
0..1
empleado
Pedro Mejia
15
Asociacin
Especificacin de multiplicidad
(mnima...mxima)
1 Uno y slo uno
0..1
Cero o uno
M..N
Desde M hasta N (enteros naturales)
* Cero o muchos
0..*Cero o muchos
1..*Uno o muchos (al menos uno)
La multiplicidad mnima >= 1 establece

una restriccin de existencia
Pedro Mejia
16
Generalizacin
Library item
Catalogue number
Acquisition date
Cost
Type
Status
Number ofcopies
Esta es una relacin de

tipo: es-un.
Una generalizacin se
representa como una flecha
que une a las subclases
(hijos) a la superclase
(padre), con la flecha
tocando la caja de la
superclase.
Acquire ()
Catalogue ()
Dispose ()
Issue ()
Return ()
Published item
Title
Medium
Title
Publisher
Book
Author
Edition
Publication date
ISBN
Pedro Mejia
Recorded item
Magazine
Year
Issue
Film
Director
Date of release
Distributor
Computer
program
Version
Platform
17
Generalizacin
Permite gestionar la complejidad mediante un

ordenamiento taxonmico de clases
Se obtiene usando los mecanismos de

abstraccin de Generalizacin y/o
Especializacin
La Generalizacin consiste en factorizar las

propiedades comunes de un conjunto de clases
en una clase ms general
Pedro Mejia
18
... Generalizacin
Nombres usados: clase padre - clase hija.

Otros nombres: superclase - subclase,
clase base - clase derivada
Las subclases heredan propiedades de

sus clases padre, es decir, atributos y
operaciones (y asociaciones) de la clase
padre estn disponibles en sus clases
hijas
Pedro Mejia
19
Relacion de Dependencia entre

Clases
Se usa para mostrar
relaciones entre paquetes
(grupos de clases)
Proveedor
Cliente
Pedro Mejia
20
Agregacion de Objetos
En este modelo se muestra como
las clases pueden estar compuestas
por otras clases.
Existe la relacion de agregacion y
la de composicion.
Son similares a los modelos de
entidad-relacion.
Study pack
Course title
Number
Year
Instructor
Credits
Exercises
#Problems
Description
Pedro Mejia
OHP slides
Assignment
Slides
Lecture
notes
Text
Videotape
Tape ids.
Solutions
Text
Diagrams
21
Agregacion de Objetos
Estas son relaciones todo/parte.
La relacin de composicin
(representada con un diamante relleno)
es la forma ms fuerte de relacin
todo/parte que la relacin de agregacin
(mostrada por un diamante vaco).
El diamante toca la caja de clase de la
clase (todo) compuesta/agregada.
Pedro Mejia
22
Ejemplos
Window
scrollbar[2] : Slider
title : Header
body : Panel
Study pack
Course title
Number
Year
Instructor
Son parte de
Assignment
Credits
OHP slides
Slides
Lecture
notes
Text
Videotape
Window
Tape ids.
Esta compuesta de
Exercises
#Problems
Description
Pedro Mejia
Solutions
Text
Diagrams
scrollbar
Slider
title 1
Header
body 1
Panel
23
Diagrama de Casos de Uso
Retirar dinero
Cliente
Consultar Extracto
Es una tcnica para capturar

informacin sobre los servicios
que
un sistema proporciona a su
Realizar transferencia
entorno, desde el punto de vista
del
usuario. Es una tcnica para
Pedro Mejia
captura
24
Casos de Uso
Los Casos de Uso describen bajo la forma de

acciones y reacciones el comportamiento de
un sistema desde el p.d.v. del usuario
Permiten definir los lmites del sistema y las

relaciones entre el sistema y el entorno
Los Casos de Uso son descripciones de la

funcionalidad del sistema independientes de
la implementacin
Es posible identificarlos a partir de los puntos

de vista (Metod VORD de Sommerville).
Pedro Mejia
25
Casos de Uso
Ejemplo:
Retirar dinero
Consultar Extracto
Cliente
Realizar transferencia
Pedro Mejia
26
Casos de Uso
Actores:
Principales: personas que usan el sistema

Secundarios: personas que mantienen o administran el
sistema
Material externo: dispositivos materiales imprescindibles
que forman parte del mbito de la aplicacin y deben ser
utilizados
Otros sistemas: sistemas con los que el sistema interacta
La misma persona fsica puede interpretar varios

papeles como actores distintos
El nombre del actor describe el papel desempeado
Pedro Mejia
27
Casos de Uso
Los Casos de Uso se determinan observando y

precisando, actor por actor, las secuencias de
interaccin, los escenarios, desde el punto de
vista del usuario (Metodo VORD).
Un escenario es una instancia de un caso de uso
Los casos de uso intervienen durante todo el ciclo

de vida. El proceso de desarrollo estar dirigido
por los casos de uso
Pedro Mejia
28
Casos de Uso: Ejemplo
Passajero
Usado durante para la obtencion y

analisis de los requerimientos para
representar el comportamiento de
sistema, visible desde el exterior.
Un Actor representa un rol, o un
tipo de usuario en el sistema
Comprarboleto
Un caso de uso representa un tipo
de funcionalidad del sistema
Pedro Mejia
29
Ejemplo: Actores
Pasajeros
Nombre
Pedro Mejia
Un actor es un modelo que permite

representar una entidad externa que
interactua (comunica) con el
sistema:
Usuario
Sistema externo (otro sistema)
Ambiente fisico
Un actor tiene un nombre unico y

una descripcion opcional. Descripcion
Ejemplos:
opcional
Pasajero: Una persona en el tren

Satelite GPS: Sistema externo que
provee coordenadas de ubicacion.
30
Caso de uso
Compraboleto
Los casos de uso pueden ser

descritos textualmente,
describiendo el flujo de eventos
entre el actor y el sistema.
La descripcion textual del caso de
uso incluye 6 partes:
1.
2.
3.
4.
5.
6.
Pedro Mejia
Nombre unico
Actores participantes
Condiciones de entrada
Condiciones de Salida
Flujo de eventos
Requisitos especiales
31
Ejemplo de caso de uso

textual
5. Flujo de eventos:
Pasajero
Compraboleto
1. Nombre: Compra boleto

2. Actor: Pasajero
3. Condicion de entrada:
Elpasajerosedirigeal
laventanilladeboletos
Elpasajerocuentacon
suficientedineropara
comprarelboleto
4. Condicion de salida:
ELpasajerocomproel
boleto
Pedro Mejia
1. El pasajero selecciona la zona

de destinodadondequiere
viajar
2. El vendedor de boletos
despliega el monto del boleto
a ese destino
3. El pasajero entrega al menos el
monto de dinero requerido
4. El vendedor regresa el cambio,
en caso de que sea necesario
5. El vendedor entrega el boleto
6. Requerimientos especiales:
Especificar el tipo de
transporte: Tren o autobus.
32
Casos de Uso: Relaciones
UML define cuatro tipos de relacin en los

Diagramas de Casos de Uso:
Pedro Mejia
Comunicacin
Inclusion
Extension
Herencia
33
Casos de Uso: Relaciones
Pasajero
Comunicacin: permite
comunicar al actor con
su caso de uso.
Compramultiplesboletos
Compraunboleto
<<includes>>
<<includes>>
<<extends>>
Nocambio
Pedro Mejia
Recogeeldinero
<<extends>>
Cancela
<<extends>>
Cambiodemoneda
34
Casos de Uso:
Relaciones
Inclusin : una instancia del Caso de Uso
origen incluye tambin el comportamiento
descrito por el Caso de Uso destino.
La relacin <<include>> pretende evitar
duplicacin de interacciones en distintos casos
de uso
<<include>>
Caso de Uso Origen
Pedro Mejia
Caso de Uso Destino
35
Relacion <<includes>>
Larelacion<<includes>>
Pasajero
representa una funcionalidad
comun necesaria en mas de
un caso de uso
Compramultiplesboletos
Lafuncionalidadde
Compraunboleto
<<includes>> puede
reutilizarse
<<includes>>
La direcion de la relacion
<<includes>>
<<includes>> es hacia el caso
de uso (de forma distinta que
la relacion <<extends>>).
Recogeeldinero
<<extends>>
Nocambio
Pedro Mejia
<<extends>>
Cancela
<<extends>>
Cambiodemoneda
36
Casos de Uso:
Relaciones
Extensin : el Caso de Uso origen extiende el

comportamiento del Caso de Uso destino
La relacin <<extends>> pretende describir una
variacin del comportamiento normal de un caso
de uso, sobre todo cuando dicha variacin pudiera
complicar la legibilidad del caso de uso.
<<extend>>
Caso de Uso Origen
Pedro Mejia
Caso de Uso Destino
37
Relacion <<extends>>
Pasajero
Compraboleto
<<extends>>
<<extends>>
Larelacion<<extends>> modela
casos exceptional, o casos de uso
auto invocados
EL flujo de eventos excepcionales
pueden detallarse para claridad del
caso de uso
La direccion de la relacion
<<extends>> es hacia el caso de
uso
Los casos de uso representando
flujos excepcionales pueden
extender mas de un caso de uso.
<<extends>>
Fueradeservicio
<<extends>>
Cancela
Pedro Mejia
Nohaycambio
Tiempoagotado
38
Casos de Uso:
Relaciones
Otro ejemplo <<include>> y <<extend>>:

Order Product
Supply Customer Data
<<include>>
<<include>>
Arrange Payment
<<include>>
the salesperson asks

for the catalog
1
Salesperson
Pedro Mejia
<<extend>>
*
Place Order
Request Catalog
39
Casos de Uso:
Relaciones
Herencia : el Caso de Uso origen hereda
la especificacin del Caso de Uso destino
y posiblemente la modifica y/o ampla
Caso de Uso Hijo
Pedro Mejia
Caso de Uso Padre
40
Casos de Uso:
Construccin
Un caso de uso debe ser simple, inteligible, claro y

conciso
Generalmente hay pocos actores asociados a cada
Caso de Uso
Preguntas clave:
cules son las tareas del actor?
qu informacin crea, guarda, modifica,
destruye o lee el actor?
debe el actor notificar al sistema los cambios
externos?
debe el sistema informar al actor de los
cambios internos?
Pedro Mejia
41
Casos de Uso:
Construccin
La descripcin del Caso de Uso comprende:
el inicio: cundo y qu actor lo produce?

el fin: cundo se produce y qu valor devuelve?
la interaccin actor-caso de uso: qu mensajes
intercambian ambos?
objetivo del caso de uso: qu lleva a cabo o
intenta?
cronologa y origen de las interacciones
repeticiones de comportamiento: qu
operaciones son iteradas?
situaciones opcionales: qu ejecuciones
alternativas se presentan en el caso de uso?
Pedro Mejia
42
Identificador
CU-<id-requisito>
Nombre
<nombre del requisito funcional>
Descripcin
El sistema deber comportarse tal como se describe en el siguiente caso de uso

{ concreto cuando <evento de activacin> , abstracto durante la realizacin de los
casos de uso <lista de casos de uso>}
Precondicin
<precondicin del caso de uso>
Secuencia
Normal
Paso
Postcondicin
Excepciones
Rendimiento
Accin
{El <actor> , El sistema} <accin realizada por el actor o sistema>, se realiza el

caso de uso
< caso de uso CU-x>
Si <condicin>, {el <actor> , el sistema} <accin realizada por el actor o

sistema>>, se realiza el caso de uso < caso de uso CU-x>
<postcondicin del caso de uso>

Paso
Accin
Si <condicin de excepcin>,{el <actor> , el sistema} }<accin realizada por el

actor o sistema>>, se realiza el caso de uso
< caso de uso CU-x>, a continuacin este caso de uso {continua, aborta}
Paso
Cota de tiempo
n segundos
Frecuencia esperada
<n de veces> veces / <unidad de tiempo>
Importancia
{sin importancia, importante, vital}
Urgencia
{puede esperar, hay presin, inmediatamente}
Comentarios
<comentarios adicionales>
Pedro Mejia
43
Diagrama de Secuencia
: Encargado
:WInPrstamos
:Socio
:Video
:Prstamo
prestar(video, socio)
verificar situacin socio
verificar situacin video
registrar prstamo
entregar recibo
Describe el
comportamiento
dinamico del los
objetos en el
sistema
Pedro Mejia
44
Actor
Mensajes
:WatchUser
Objeto
:Watch
pressButton1()
pressButton1()
pressButton2()
Lifeline
:LCDDisplay
:Time
blinkHours()
blinkMinutes()
return
incrementMinutes()
refresh()
pressButton1and2()
commitNewTime()
Activacion
Pedro Mejia
stopBlinking()
45
Pedro Mejia
46
El Diagrama de Secuencia es ms adecuado para

observar la perspectiva cronolgica de las
interacciones
Muestra la secuencia de mensajes entre objetos
durante un escenario concreto
Cada objeto viene dado por una barra vertical
El tiempo transcurre de arriba abajo
Cuando existe demora entre el envo y la atencin

se puede indicar usando una lnea oblicua
Pedro Mejia
47
Maquinade
Boletos
Pasajero
seleccionadestino()
Usada durante el analisis
Refina la descripcion de casos de us

Util para descubrir objetos
Usada durante el diseo
Para refinar interfaces de subsistem
Las instancias se representan

mediantes rectangulos.
MaquinadeBoletos Actores mediantes figuras

Los flujos de control mediante
zone2price
lineas punteadas
Selec
destino()
Los Mensajes mediante flechas
insertamoneda
Las activaciones mediante
()
rectangulos pequeos.
retiracambio(
)
retiraboleto(
)
48
insertamonedas()
retiracambio()
Retiraboleto()
Pedro Mejia
Diagrama de secuencia
Maquinade
Boletos
Pasajero
seleccionadestino()
insertamonedas()
Lifeline
Activacion
retiracambio()
Retiraboleto()
Pedro Mejia
Mensaje:Flujo
de control
49
Lifeline y Especificacion de la
ejecucion
El lifeline (linea de vida) representa una

participacion de un objeto particular en la
interaccion
Consiste de un rectangulo seguido de una linea
vertical (que puede ser punteada) que
representa el tiempo de vida del participante
La especificacion de la execucion especifica
el comportamiento o la interaccion con la linea
de vida.
Se representa mediante un rectangulo delgado
vertical.
Pedro Mejia
50
Mensajes
Define una comunicacion particular entre los

lifelines de una interaccion.
Ejemplos de comunicacion
Enviar una seal

Invocar una operacion
Crear o destruir una instancia
Es necesario especificar quien envia y quien recibe

(sender y receiver)
Se muestran como una linea que se enviar de
enviador al receptor
Distintas formas de flechas reflejan las propiedades el
mensaje
Pedro Mejia
51
Tipos de mensajes
Asincronos
Sincronos
Llamada(Call) y creacion
de un objeto
Reply
Lost
Found
Asincrono
Pedro Mejia
52
Etiquetas de las flechas
Pedro Mejia
53
Tipos de flechas
Pedro Mejia
54
Flujo de Datos
Pasajero
Botondestinoo
TarifasS
Diespiliegue
Seleccionadestino()
lookupPrice(selection)
precio
Flujo de
Datos
Despliegaprecio(precio)
Los diagramas de secuencia tambien pueden modelar flujo de

datos
El origen de una flecha indica la activacion que envia el
mensaje
Las flechas horizontales punteadas indican flujo de datos.
Pedro Mejia
55
Iteracion y Condicion
Procesadorde
Identif.demonedas
Cambios
Pasajero
Diespliegue
Dispensa
Moneda
*insertacambio(moneda)checamoneda(moneda)
Iteracion
precio
displiegaprecio(precio)
Condicion
[Monto<0]returnCambio(cambio)
La iteracion se denota por un simbolo * seguido de un

nombre de mensaje
La condicion se denota mediante una expresion booleana
en [] antes del nombre del mensaje
Pedro Mejia
56
Creacion y destruccion
Pasajero
Proc.deCambios
Creacion del boleto
creaboletoT(seleccion)
BoletoT
print()
free()
Destruccion del boleto
La creacion se denota mediante un mensaje sobre una flecha

apuntando al objeto
La destruccion se denota mediante una X que marca el fin de
la activacion
Pedro Mejia
57
Propiedades del diagrama de

secuencia
Representa comportamiento en
terminos de interacciones
Util para identificar o encontrar objetos
Complemento al diagrama de flujo de
datos y al diagrama de clases.
Pedro Mejia
58
Diagrama de
Secuencia(ejemplo)
Pedro Mejia
59
Diagrama de
Secuencia(ejemplo)
Caller
Exchange
Receiver
a: lift receiver
{b.receiveTime
- a.sendTime < 1 sec.}
b: dial tone
{c.receiveTime
-b.sendTime < 10 sec.}
c: dial digit
...
The call is routed
through the network
d: route
{d.receiveTime
-d.sendTime < 5 sec.}
ringing tone
phone rings
answer phone
At this point the

parties can talk
Pedro Mejia
stop tone
stop ringing
----< 1 sec
-----
60
Diagrama de Colaboracin
:Socio
Modela la interaccin entre

los objetos de un Caso de
Uso
Los objetos estn
conectados por enlaces
(links) en los cuales se
representan los mensajes
enviados acompaados de
una flecha que indica su
direccin
:Video
2: verificar situacin socio
1: prestar(video, socio)
3: verificar situacin video

:WInPrstamos
5: entregar recibo
: Encargado
Ofrece una mejor visin del

escenario cuando el analista
est intentando comprender
la participacin de un objeto
en el sistema
Pedro Mejia
4: registrar prstamo
:Prstamo
61
Muestran una vista dinamica del sistema.
El diagrama de secuencia muestra el ordenamiento en el tiempo de los
mensajes mientras que el diagrama de colaboracion expone la estructura
organizacional de los mensajes.
Los diagramas de colaboracion muestran el flujo de mensajes entre
objetos en un sistema, y tambien exponen las relaciones (asociaciones)
entre sus clases.
Los diagramas de colaboracion son tambien diagramas de interaccion.
Manejan la misma informacion que los diagramas de secuencia pero se
enfocan mas en los roles de los objetos que en los tiempos en que los
mensajes son enviados.
Pedro Mejia
62
Pedro Mejia
63
Pedro Mejia
64
Notacion del Diagrama de

Colaboracin
Representa una colaboracion o una interaccion.
Colaboracion: conjunto de objetos y su interaccion dentro de un contexto.
Interaccion: conjunto de mensajes intercambiados en una colaboracion para
producir un resultado deseado.
Objetos:
Rectangulos conteniendo una firma del objeto.
Firma del objeto: nombre del objeto : clase del objeto.
nombre de la clase (obligatoria): comienza con letra mayuscula.
Objetos conectados mediante lineas.
Puede existir uno o mas actores.
Mensajes:
Se etiquetan como las llamadas a funciones en Java.
Seguidas de brackets redondeados, pueden tener parametros y valores de
retorno.
Incluyen una flecha que indica direccion.
Los mensajes se numeran, comenzando con el numero 1.
Pedro Mejia
65
Notacion del Diagrama de

Colaboracin
Firma del mensaje
Guardia.
condicion aplicada al mensaje
en brackets redondos al principio del mensaje.
Numeros secuenciales.
numeros separados por puntos, con terminacion en coma.
Valor de retorno
nombre seguido de :=
Nombre de la operacion
Lista de argumentos.
nombres separados por comas, dentro de brackets
redondeados.
Pedro Mejia
66
Tipos de Mensajes
Simple
Indican flujo de control el que envia espera hasta que el

receptor procesa el mensaje.
default: mostrada mediante una flecha:
Sincrono.
indica flujo de control anidado.
usado para asegurar que el estado no pueda ser
interrumpido por factores externos.
mostrado mediante una flecha llena.
Asincrono
muestra una seal de un objeto a otro.
se indica mediante una flecha a la mitad
Pedro Mejia
67
1. Trazado del diagrama: a nivel de instancia y especificacion.
2. Mensajes.
3. Conectores (Links)
Pedro Mejia
68
Diagramas a nivel de instancia: usuados para explorar las
caracteristicas del diseo de los objetos. Estos diagramas muestran
interacciones entre objetos (instancias).
Pedro Mejia
69
Diagramas a nivel de especificacion: se usan para analizar y
explorar los roles de las clases en el sistema.
Pedro Mejia
70
Mensajes en el Diagrama de
Colaboracin
sequenceNumber loopIndicator: returnValue := methodName(parameters)
Pedro Mejia
71
Ligas (links) en el Diagrama de

Colaboracin
Las lineas o ligas entre las clases representan instancias de las

Relaciones, que pueden incluir, asociaciones, agregaciones,
composiciones y dependencias.
Pedro Mejia
72
Diagrama de Estados
alta
baja
nmero_prstamos = 0
sin prstamos
Socio
nmero : int
nombre : char[50]
nmero_prestamos : int = 0
prestar
devolver[ nmero_prstamos = 1 ]
alta()
baja()
prestar(cdigo_libro : int, fecha : date)
devolver(cdigo_libro : int, fecha : date)
nmero_prstamos > 0
con prstamos
prestar
Modela el
comportamiento de
una parte del
sistema
Pedro Mejia
devolver[ nmero_prstamos > 1 ]
73
Diagrama de UML:
Statechart
Estado inicial
Evento
button1&2Pressed
Blink
Hours
Transicion
button1&2Pressed
Estado
button2Pressed
Increment
Hours
button1Pressed
Blink
Minutes
button2Pressed
Increment
Minutes
button1Pressed
Stop
Blinking
Blink
Seconds
button2Pressed
Increment
Seconds
Estado final
Pedro Mejia
74
Diagrama de Actividades
Es un caso especial de un diagrama
de state-chart en donde los estados
son actividades (funciones).
Es util para dibujar los flujos de
trabajo (workflows) en un sistema
Buscar Bebida
[ no hay caf ]
[ hay caf ]
[ hay zumo ]
Poner caf
en filtro
Aadir agua
al depsito
Coger taza
Coger
zumo
Puede especificar:
(1)El comportamiento de los objetos
de una clase
Poner filtro
en mquina
Encender
mquina
(2) Las actividades del sistema
/ cafetera.On
(3) La lgica de una operacin

(mtodo)
Caf en
preparacin
(4) Parte o toda la descripcin de un

Caso de uso
indicador de fin
(5) La descripcin de un Flujo de

Trabajo
Pedro Mejia
[ no zumo ]
Servir caf
Beber
75
Nodos de actividades y
flechas
Un diagrama de actividad consiste de nodos

y flechas (edges)
Hay 3 tipos de nodos de actividades
Nodos de control
Nodos executables: acciones
Nodos de objetos
Una flecha (edge) es una coneccion directa

entre nodos
Control de flujo
Flujo de objetos
Pedro Mejia
76
Notacion delForkDiagrama
Join
node
node
Initial
node
Control
flow
Final
node
Object
node
Pedro Mejia
Merge
node
Action
Object
flow
77
Permite modelar
desiciones
Buscar Bebida
Decision
[ no hay caf ]
[ no zumo ]
[ hay caf ]
[ hay zumo ]
Poner caf
en filtro
Aadir agua
al depsito
Coger taza
Coger
zumo
Poner filtro
en mquina
Encender
mquina
/ cafetera.On
Caf en
preparacin
indicador de fin
Servir caf
Pedro Mejia
Beber
78
Modelacion de concurrencia
Sincronizacion de multiples actividades

Separacion de el flujo de control en
multiples threads
Splitting
Open
Incident
Allocate
Resources
Coordinate
Resources
Synchronization
Archive
Incident
Document
Incident
Pedro Mejia
79
Agrupamiento de
actividades
Las actividades pueden agruparse para

denotar el objeto o el subsistema que
implementa las actividades
Allocate
Resources
Open
Incident
Coordinate
Resources
Dispatcher
Archive
Incident
FieldOfficer
Document
Incident
Pedro Mejia
80
Diagrama de Componentes
Interfaz de Terminal
Gestin de Cuentas
Rutinas de conexin
Control y Anlisis
Acceso a BD
Los diagramas de componentes describen los elementos

fsicos del sistema y sus relaciones
Permite modelar la estructura del software y la
dependencia entre componentes, en donde un
componente es un grupo de clases que trabajan
estrechamente. Los componentes pueden corresponder
cdigo fuente, binario o ejecutable.
Una
relacin de dependencia
indica
que un componente
Pedro
Mejia
Curso de Ingeniera de Software,
CINVESTAV-IPN
81
Diagrama de
Componentes
Los componentes representan todos los

tipos de elementos software que entran
en la fabricacin de aplicaciones
informticas. Pueden ser simples
archivos, paquetes de Ada, bibliotecas
cargadas dinmicamente, etc.
Las relaciones de dependencia se utilizan

en los diagramas de componentes para
indicar que un componente utiliza los
servicios ofrecidos por otro componente
Pedro Mejia
82
Diagrama de
Componentes
Pedro Mejia
83
Diagrama de Despliegue
Los Diagramas de Despliegue muestran

la disposicin fsica de los distintos
nodos que componen un sistema y el
reparto de los componentes sobre
dichos nodos
Nodo
Pedro Mejia
84
Servidor Central
Control y Anlisis
Comment
Acceso a BD
Comment
Rutinas de Coneccion
Comment
Modela la distribucin en
tiempo de ejecucin de
los elementos de
procesamiento y
componentes de
software, junto a los
procesos y objetos
asociados
Se modelan los nodos y
la comunicacin entre
ellos
Cada nodo puede
contiene instancias de
85
componentes
Terminal de Consulta
Comment
Punto de Venta
Comment
Gestin de Cuentas
Comment
Comment
Pedro Mejia
Comment
Los estereotipos permiten precisar la

naturaleza del equipo:
Dispositivos
Procesadores
Memoria
Los nodos se interconectan mediante

soportes bidireccionales que pueden a
su vez estereotiparse
Pedro Mejia
86
Ejemplo de conexin entre nodos:

<<Cliente>>
Terminal Punto
de Venta
<<Servidor>>
<<TCP/IP>>
Base de
Datos
<<RDSI>>
Podemos distinguir
tipos de nodos y
conexiones por
estereotipado
Pedro Mejia
Control
<<RDSI>>
87
Diagramas de
Despliegue
Ejemplo:
Pedro Mejia
88
Diagramas de
Despliegue
Ejemplo:
Component Diagram: videoStoreServer
Client
Component Diagram:
videoStoreApplication /
VideoStoreApplication
Diagram
<<Container>>
Component Diagram:
Client / Client
VideoStoreApplication
Component Diagram:
videoStoreServer /
videoStoreServer
<<browser>>
OpenSourceBrowser
Client
<<AppServer>>
videoStoreServer
<<Session>>
<<Entity>>
ShoppingSession
Catalog
DBServer
<<Entity>>
ShoppingCart
videoStoreApplication
Component Diagram:
DBServer / DBServer
DBServer
VideoStoreDB
Pedro Mejia
89
Diagrama de Despliegue en
Rational
Control y Anlisis
Acceso a BD
Servidor Central
Component Diagram:
Components / Servidor
Central
Rutinas de conexin
Servidor Central
Punto de Venta
Punto de Venta
Terminal de
Consulta
Gestin de Cuentas
Terminal de Consulta
Component Diagram:
Components / Punto de
Venta
Pedro Mejia
Component Diagram:
Components / Terminal
de Consulta
Rutinas de conexin
Rutinas de conexin
90
Paquetes en UML
Los paquetes ofrecen un mecanismo

general para la organizacin de los
modelos/subsistemas agrupando elementos
de modelado
Se representan grficamente como:

Nombre de
paquete
Pedro Mejia
91
Paquetes en UML
Cada paquete corresponde a un submodelo

(subsistema) del modelo (sistema)
Un paquete puede contener otros paquetes,

sin lmite de anidamiento pero cada elemento
pertenece a (est definido en) slo un
paquete
Una clase de un paquete puede aparecer en

otro paquete por la importacin a travs de
una relacin de dependencia entre paquetes
Pedro Mejia
92
Paquetes en UML
Todos los elementos no son

necesariamente visibles desde
el exterior del paquete, es
decir, un paquete encapsula a
la vez que agrupa
El operador :: permite
designar una clase definida en
un contexto distinto del actual
Pedro Mejia
93
...Paquetes en Rational Rose

Customers
Otra Clase
Customers
CheckingAccount
<<access>>
Banking
(f rom Banking)
Banking
CheckingAccount
Pedro Mejia
94
Paquetes en UML
Pedro Mejia
95
Los modelos se usan para

describir al sistema de software
Modelo del sistema: Modelo de objetos

+ modelo funcional + modelo dinamico
Modelo de objetos: Cual es la estructura del sistema?

Cuales son los objetos y cual es su relacion?
Modelo funcional: Cuales son las funciones del sistema?

Como fluyen los datos en el sistema?
Notacion UML: Diagramas de clases
Notacion UML: Diagramas de casos de uso
Modelo dinamico: Como reaccciona el sistema a eventos

externos (e internos) y cual es el flujo de eventos?
Pedro Mejia
Notacion UML: Diagramas de secuencia, state charts y de

actividad.
96
Modos de utilizacion de UML
Ingenieria hacia adelante(Forward Engineering)
Ingenieria en reversa (Reverse Engineering)
Se crea un modelo a partir de algun codigo

Proyectos de interfaces o re-ingenieria
Ingenieria ciclica (Roundtrip Engineering)
Se comienza con un modelo antes de producir codigo
Se mueve constantemente entre ingenieria hacia adelante y

en reversa.
Util en proyectos que utilizan el modelo de procesos
evolutivo, o cuando los requerimientos cambian
frecuentemente.
Se asume que a partir de UML se puede

producir codigo, pero en donde se ubica UML
dentro del proceso de Diseo ?.
97
Pedro Mejia
Proceso de Desarrollo Unificado basado en

UML
Propuesta de Rational Unified Process (RUP)
M. de Casos de Uso del Negocio (Business Use-Case Model)
M. de Objetos del Negocio (Business Object Model)
M. de Casos de Uso (Use-Case Model)
M. de Anlisis (Analysis Model)
M. de Diseo (Design Model)
M. de Despliegue (Deployment Model)
M. de Datos (Data Model)
M. de Implementacin (Implementation Model)
M. de Pruebas (Test Model)
Pedro Mejia
98
Resumen
UML define una notacin que se expresa
como diagramas sirven para representar
modelos/subsistemas o partes de ellos
El modelo de proceso RUP utiliza UML para
el modelado.
Pedro Mejia
99
Tendencias
Nuevas versiones de UML, uff!

Extensiones de UML (SysML, www.sysml.org)
Generacin automtica de cdigo a partir de modelos
Model-Driven Development (MDD), Model-Driven Architecture (MDA),

Compiladores de Modelos
Round-trip engineering. Convergencia entre herramientas CASE e IDEs
Extendiendo UML mediante Profiles (
www.objecteering.com/products_uml_profile_builder.php )
Modelado y generacin de cdigo en dominios especficos

(ms all de UML)
Eclipse Modeling Framework (EMF,

download.eclipse.org/tools/emf/scripts/home.php )
Microsoft Tools for Domain Specific Languagues
Domain-Specific Modeling (DSM, www.dsmforum.org)
Meta CASE Tools (www.metacase.com)
Pedro Mejia
100
Diagramas en UML 2.0
Pedro Mejia
101
Bibliografa Adicional
UML
www.omg.org/uml/
Meta-links www.cetus-links.org/oo_uml.html
Martin Fowler, autor de UML Destilled (UML Gota a Gota)
http://www.martinfowler.com/
Herramientas CASE
Herramientas basadas en UML www.objectsbydesign.com/tools/
umltools_byPrice.html
International Council in SE (INCOSE) www.incose.org/tools/
Otras
Revista IEEE Software, Conferencias: OOPSLA, ECOOP
Patrones http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html,
Foro UML en yahoo: http://groups.yahoo.com/group/uml-forum/
Pedro Mejia
102

Modelado Uml 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelado Uml 2

Uploaded by

Copyright:

Available Formats

Modelado de Software

Orientado a Objetos usando UML

Curso de Ingeniera de Software, CINVESTAV-IPN

Fundamentos del Modelado OO

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

Objeto = unidad atmica que encapsula estado y

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

La clase define el mbito de definicin de un conjunto de

Cada objeto pertenece a una clase

Los objetos se crean por instanciacin de las clases

Para distinguir entre una clase (el tipo) y un objeto (una

Las clases y los objetos forman parte de varios diagramas UML.

Curso de Ingeniera de Software, CINVESTAV-IPN

Clases: Notacin Grfica

Cada clase se representa en un

Curso de Ingeniera de Software, CINVESTAV-IPN

La encapsulacin permite la cohesion y

Los atributos de una clase no deberan ser

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

Permite asociar objetos.

Curso de Ingeniera de Software, CINVESTAV-IPN

Una asociacin se representa mediante una lnea que une las

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

La multiplicidad mnima >= 1 establece

Curso de Ingeniera de Software, CINVESTAV-IPN

Esta es una relacin de

Curso de Ingeniera de Software, CINVESTAV-IPN

Permite gestionar la complejidad mediante un

Se obtiene usando los mecanismos de

La Generalizacin consiste en factorizar las

Curso de Ingeniera de Software, CINVESTAV-IPN

Nombres usados: clase padre - clase hija.

Las subclases heredan propiedades de

Curso de Ingeniera de Software, CINVESTAV-IPN

Relacion de Dependencia entre

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

Diagrama de Casos de Uso

Es una tcnica para capturar

Los Casos de Uso describen bajo la forma de

Permiten definir los lmites del sistema y las

Los Casos de Uso son descripciones de la

Es posible identificarlos a partir de los puntos

Curso de Ingeniera de Software, CINVESTAV-IPN

Curso de Ingeniera de Software, CINVESTAV-IPN

Principales: personas que usan el sistema

La misma persona fsica puede interpretar varios

El nombre del actor describe el papel desempeado

Curso de Ingeniera de Software, CINVESTAV-IPN

Los Casos de Uso se determinan observando y

Un escenario es una instancia de un caso de uso

Los casos de uso intervienen durante todo el ciclo

Curso de Ingeniera de Software, CINVESTAV-IPN

Casos de Uso: Ejemplo

Usado durante para la obtencion y

Curso de Ingeniera de Software, CINVESTAV-IPN