Curso UML 2010 PDF

Modelamiento de Software con
UML
Contenidos
Modelado del software
Presentacin de UML
Modelado de Casos de Usos
Diagramas de casos de uso
Modelado Estructural
Diagramas de Clases
Contenidos
Modelado del Comportamiento
Diagramas de interaccin
Diagramas de actividades
Mquinas de estado
Modelado de la Implementacin
Diagramas de componentes
Diagramas de despliegue
Colaboraciones
Formalizacin de UML: MOF y metamodelo
Contenidos
Presentacin de UML
Diagramas de Clases
Introduccin
Programas y Modelos
La gran mayora de los programas

modelan algo.
Qu significa modelar?
Un modelo es una representacin
simplificada. Incluye caractersticas
que se consideran importantes para
el que lo usa, a la vez que desecha
otras que no lo son.
Por ejemplo, un modelo de un auto
de plstico para un nio, muestra
los detalles del exterior y las ruedas,
pero obvia por completo el motor y
la transmisin, una versin ms
sofisticada puede incluir un motor
que funcione y unos detalles muy
realistas en el interior. Por
supuesto, mientras ms realista y
detallado sea el modelo, ms
costosa ser su creacin
Introduccin Objetos,
Comportamiento y Clases
Los elementos del modelo en los programas Orientado por
Objetos se llama Objetos.
Los objetos que comparten cierto comportamiento se pueden
agrupar en distintas categoras llamadas clases.
Objetos:
Veamos la siguiente comparacin:
Modelo de la Encargada
Modelo Java
La encargada del
mantenimiento modela cada
uno de los 43 mecnicos con
un alfiler
En Java, los mecnicos se

modelarn por un objeto
Mecnico y se instancian 43
La encargada modela a sus

clientes con chinchetas.
En Java, los clientes sern

modelados por objeto Cliente.
Cuando se produce una

llamada de un cliente, la
encargada pincha una
chincheta en el mapa.
En Java se instancia un objeto

Cliente.
Ejemplo
Servicio de Mantenimiento
1
1
13
Elemento que representa
Mecnicos
17
21
Elemento que representa
Clientes
25
13
17
21
Ejemplo
Clase que representa
Mecnicos
Mecnico
Clientes
Cliente
Ejemplo
Modelo de Mecnicos en el mapa con

alfileres
Jorge Castro
X: 6 , Y: 7
Cada mecnico tiene caracteristicas

propias, como:
Nombre
INETI S.A.
X: 6 , Y: 12
Calle (X)
Carrera (Y)
Pedro Perez
X: 17 , Y: 12
Modelo de Clientes en el mapa con

canchetas
KAOS S.A.
X: 19 , Y: 17
Cada cliente tiene caracteristicas

propias, como:
Razon social
Calle (X)
Carrera (Y)
Luis Diaz
X: 1 , Y: 22
Ejemplo
Mecnicos
Mecnico
Nombre: Jorge Castro
X: 6
Y: 7
Mecnico
Nombre: Luis Diaz
X: 1
Y: 22
Clientes
Cliente
Nombre: INETI S.A.
X: 6
Y: 12
Cliente
Nombre: KAOS S.A.
X: 19
Y: 17
Mecnico
Nombre: Pedro Perez
X: 17
Y: 12
Ejemplo
Jorge Castro
X: 6 , Y: 7
INETI S.A.
X: 6 , Y: 12
Accin externa
Comportamiento asociado
mover()
Pedro Perez
X: 17 , Y: 12
KAOS S.A.
X: 19 , Y: 17
Luis Diaz
X: 1 , Y: 22
Accin externa
Comportamiento asociado
mover()
Ejemplo
Jorge Castro
X: 6 , Y: 12
INETI S.A.
X: 6 , Y: 12
Pedro Perez
X: 19 , Y: 17
KAOS S.A.
X: 19 , Y: 17
Luis Diaz
X: 1 , Y: 22
Ejemplo
Mecnicos
Mecnico
Mecnico
Mecnico

X: 6
Y: 12
Nombre: Luis Diaz

X: 1
Y: 22
Nombre: Pedro Perez

X: 19
Y: 17
mover(6, 12)
mover( , )
mover(19, 17)
Clientes
Cliente
Nombre: INETI S.A.
X: 6
Y: 12
Cliente
Nombre: KAOS S.A.
X: 19
Y: 17
Ejemplo
Jorge Castro
X: 6 , Y: 12
Cuando un cliente llama, se coloca una

chincheta en el mapa.
INETI S.A.
X: 6 , Y: 12
Pedro Perez
X: 19 , Y: 17
NOVA A.G.
X: 10 , Y: 15
KAOS S.A.
X: 19 , Y: 17
Luis Diaz
X: 1 , Y: 22
Ejemplo
Mecnicos
Mecnico
Mecnico
Mecnico

X: 6
Y: 12
Nombre: Luis Diaz

X: 1
Y: 22
Nombre: Pedro Perez

X: 19
Y: 17
mover(6, 12)
mover( , )
mover(19, 17)
Clientes
Cliente
Nombre: INETI S.A.
X: 6
Y: 12
Cliente
Nombre: KAOS S.A.
X: 19
Y: 17
Cliente
Nombre: NOVA A.G.
X: 10
Y: 15
Ejemplo
Una vez se tenga el llamado de un

cliente, se debe ubicar un mecnico y
desplazarlo hasta el cliente para que
este haga su trabajo.
Jorge Castro
X: 6 , Y: 12
INETI S.A.
X: 6 , Y: 12
Pedro Perez
X: 19 , Y: 17
NOVA A.G.
X: 10 , Y: 15
KAOS S.A.
X: 19 , Y: 17
Luis Diaz
X: 1 , Y: 22
Ejemplo
Una vez se tenga la llamada de un

cliente, se debe ubicar un mecnico y
desplazarlo hasta el cliente para que
este haga su trabajo.
Jorge Castro
X: 6 , Y: 12
Luis Diaz
X: 10 , Y: 15
INETI S.A.
X: 6 , Y: 12
Pedro Perez
X: 19 , Y: 17
NOVA A.G.
X: 10 , Y: 15
KAOS S.A.
X: 19 , Y: 17
Ejemplo
Mecnicos
Mecnico
Mecnico
Mecnico

X: 6
Y: 12
Nombre: Luis Diaz

X: 10
Y: 25
Nombre: Pedro Perez

X: 19
Y: 17
mover(6, 12)
mover( 10, 15 )
mover(19, 17)
Clientes
Cliente
Nombre: INETI S.A.
X: 6
Y: 12
Cliente
Nombre: KAOS S.A.
X: 19
Y: 17
Cliente
Nombre: NOVA A.G.
X: 10
Y: 15
Introduccin
Programas y Modelos
Caractersticas de los modelos:
Ya sea un modelo del mundo real o uno hipottico, comparten
las siguientes caractersticas:
Los elementos del modelo representan otras entidades ms complejas;
por ejemplo, alfileres que se utilizan como representacin del personal
de mantenimiento en un mapa.
Estos elementos exhiben un comportamiento consistente;
por ejemplo, los alfileres indican posicin, y se pueden mover
Los elementos del modelo se pueden agrupar en categoras diferentes
basndose en su comportamiento comn;
por ejemplo, las chinchetas aparecen y desaparecen. Una vez que se
han pinchado en el mapa, no se mueven hasta que se quitan. Por el
contrario, los alfileres permanecen todo el tiempo en el mapa pero se
pueden mover. (esto refleja el hecho de que el personal de
mantenimiento viaja, pero las localizaciones de los clientes, bien
necesitan un servicio, o bien no).
Acciones externas sobre los elementos del modelo les hacen exhibir el
comportamiento asociado a los mismos;
por ejemplo, una mano mueve el alfiler.
Objetivos en el diseo de UML

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

Software
El modelado es el diseo de aplicaciones
software antes de escribir el cdigo.
Se crean un conjunto de modelos (planos
del software) que permiten especificar
aspectos del sistema como los requisitos, la
estructura y el comportamiento.
Los modelos
ayudan a razonar sobre el sistema
permiten documentar las decisiones
Permiten una generacin automtica de cdigo
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.
Modelos de Negocio y de
Software
Modelo del Negocio
describe
derivado de
Modelo Software
describe
Empresa
Sistema
software
Sistema de
la empresa
Utilidad del modelado

Una empresa de
software con xito es
aquella que produce
de manera
consistente software
de calidad que
satisface las
necesidades de los
usuarios
El modelado es la
parte esencial de
todas las actividades
que conducen a la
produccin de
software de calidad
Escribimos cdigo
directamente?
Sera lo ideal pero ....

.... necesitamos escribir modelos

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

Visualizar cmo es o queremos que sea el
sistema
Especificar la estructura y comportamiento
del sistema
Proporciona plantillas que guan la
construccin del sistema.
Documentan las decisiones.
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.
Por qu las empresas no hacen

modelado?
Hasta ahora, la mayor parte de las
empresas software no realizan ningn
modelado.
El modelado requiere:
aplicar un proceso de desarrollo
formacin del equipo en la tcnicas
concienciacin de su importancia
Se obtienen beneficios con el modelado?
Construimos software de
calidad?
Retrasos en los plazos

Proyectos cancelados
Rpido deterioro del sistema instalado
Tasa de defectos o fallos
Requisitos mal comprendidos
Cambios frecuentes en el dominio del
problema
Buenos programadores se cansan y dejan el
equipo
Modelado es la solucin?
Conceptos de Programacin
Orientada a Objetos
DEFINICIONES DE OBJETO
Abstraccin de software que modela todos

los aspectos relevantes de una realidad.
Representacin de la realidad que tiene
estructura, estado y comportamiento.
Entidad real o abstracta acerca de la cual
se almacenan datos y operaciones que
operan sobre ellos
OBJETO = ESTADO +
MTODOS
ESTADO
MTODOS
Conjunto de Atributos
Condicin actual del
objeto
Vara dinmicamente
No es accesible desde
afuera
No es directamente
modificable desde afuera
Puertos de entrada del

objeto
Responden a mensajes
Unifica forma de entrada
al objeto
Mecnico
Nombre: Pedro Perez
X: 19
Y: 17
mover(19, 17)
Qu es la Programacin
Orientada a Objetos?
Es la manera standard actual de enfocar la
programacin.
Un programa contiene objetos que
responden a los mensajes que se les envan.
Un Mensaje (llamada a una funcin) es una
peticin a un objeto para que haga algo.
A las acciones que realizan los objetos se les
llama Mtodos.
Todos los objetos son ejemplares de una

categora o Clase. El mtodo invocado
por un objeto en respuesta a un mensaje
queda determinado por la clase del
receptor
Todos los objetos de una clase dada usan
el mismo mtodo de respuesta a
mensajes similares.
Definicin de Clase
Grupo de objetos marcado por

caractersticas comunes que incluyen
estructura y comportamiento
(Booch)
Los objetos son instancias de una clase
Los mtodos del objeto son virtuales:
Solo estn definidos en la clase
Origen de las Clases

Cosas tangibles:
Persona, Vehculo, producto, ...
Papeles que representa:

Agente, profesor, vendedor, ...
Eventos:
Aterrizaje, Suspensin, Venta, Devolucin, ...
Interaccin:
Prstamo, Matrcula, Registro Pblico, ...
Organizaciones:
Financiera, Sindicato, ...
Origen de las Clases

Conceptos:
Proyecto, Materia, ...
Localizaciones:
Punto de Venta, Bodega, Oficina, ...
Visibles en la interfaz:
Icono, Imagen, Ventana, ...
Dispositivos:
Sensor, Lector de Tarjeta, Teclado, Pantalla,
...
Caractersticas Programacin OO
Encapsulacin
Caja Negra
Polimorfismo
Permitir un usar un nombre para especificar
una clase general de acciones
Herencia
Un objeto puede adquirir las propiedades de
otro
Claves en Desarrollo de SI
I. Introduccin: Modelado de SWI
Notacin
Herramientas
Proceso
Abstraccin - Modelado Visual

(MV)
I. Introduccin: Modelado de SW
El modelado captura las

partes esenciales del sistema
Orden
Item
envo
Proceso de Negocios
Sistema Computacional
II. Notacin (Visual) - Beneficios

Manejar la complejidad
Interface de Usuario
(Visual Basic,
Java, ..)
Lgica del Negocio

(C++, Java, ..)
Mltiples Sistemas
Servidor de BDs
(C++ & SQL, ..)
Modelar el sistema
independientemente
del lenguaje de implementacin
Componentes
Reutilizados
Promover la Reutilizacin
Introduccin: UML
Qu es UML?
UML = Unified Modeling Language
Un lenguaje de propsito general para el
modelado orientado a objetos
Documento OMG Unified Modeling
Language Specification
UML combina notaciones provenientes
desde:
Modelado Orientado a Objetos

Modelado de Datos
Modelado de Componentes
Modelado de Flujos de Trabajo (Workflows)
Situacin de Partida
Diversos mtodos y tcnicas OO, con muchos
aspectos en comn pero utilizando distintas
notaciones
Inconvenientes para el aprendizaje, aplicacin,

construccin y uso de herramientas, etc.
Pugna entre distintos enfoques (y
correspondientes gurs)
Establecer una notacin estndar
Historia de UML
Comenz como el Mtodo Unificado, con
la participacin de Grady Booch y Jim
Rumbaugh. Se present en el
OOPSLA95
El mismo ao se uni Ivar Jacobson. Los
Tres Amigos fueron socios en la
compaa Rational Software. Herramienta
CASE Rational Rose
Historia de UML
UML 2.0
2004
2003
UML 1.5
UML 1.4
2000
1999
1998
Nov 97
UML 1.3
UML aprobado por el OMG
UML 1.2
Revisiones menores
Participantes en UML 1.0

Rational Software
(Grady Booch, Jim
Rumbaugh y Ivar
Jacobson)
Digital Equipment
Hewlett-Packard
i-Logix (David Harel)
IBM
ICON Computing
(Desmond DSouza)
Intellicorp and James
Martin & co. (James
Odell)
MCI Systemhouse
Microsoft
ObjecTime
Oracle Corp.
Platinium Technology
Sterling Software
Taskon
Texas Instruments
Unisys
UML aglutina enfoques OO

Rumbaugh
Booch
Jacobson
Odell
Meyer
Pre- and Post-conditions
Shlaer-Mellor
Object life cycles
UML
Harel
State Charts
Gamma et. al.

Frameworks, patterns,
notes
Embly
Singleton classes
Wirfs-Brock
Fusion
Operation descriptions,
message numbering
Responsabilities
Aspectos Novedosos
Definicin semi-formal del Metamodelo de
UML
Mecanismos de Extensin en UML:

Stereotypes
Constraints
Tagged Values
Permiten adaptar los elementos de modelado,
asignndoles una semntica particular
Inconvenientes en UML
Definicin del proceso de desarrollo usando
UML.
UML no es una metodologa
Falta integracin con respecto de otras

tcnicas tales como patrones de diseo,
interfaces de usuario, documentacin, etc.
Ejemplos aislados
Monopolio de conceptos, tcnicas y mtodos en
torno a UML
Perspectivas de UML
UML es el lenguaje de modelado orientado a
objetos estndar predominante los prximos
aos
Razones:
Participacin de metodlogos influyentes
Participacin de importantes empresas
Aceptacin del OMG como notacin estndar
Evidencias:
Herramientas que proveen la notacin UML
Edicin de libros
Congresos, cursos, camisetas, etc.
Contenidos
Presentacin de UML
Diagramas de Clases
UML y el modelado
UML es un lenguaje para visualizar, especificar,
construir y documentar los artefactos (modelos) de
un sistema que involucra una gran cantidad de
software, desde una perspectiva orientada a objetos.
UML es una notacin, no es un proceso

Se han definido muchos procesos para UML.
Rational ha ideado RUP, elproceso unificado.
Utilizable para sistemas que no sean software
Marco Conceptual de UML

Bloques bsicos de construccin
Elementos
Estructurales, Comportamiento, Agrupacin, Anotacin
Relaciones
Diagramas
Reglas para combinar bloques

Establecen qu es un modelo bien formado
Mecanismos comunes
Especificaciones, Extensibilidad, Dicotoma
clase-instancia, Dicotoma interfaz-realizacin
Elementos Estructurales
Partes estticas de un modelo
Ventana
origen
tamao
abrir()
cerrar()
mover()
dibujar()
clase
<<Interface>>
IAvisable
IAvisable
Interface
ValidarTransaccion
caso de uso
Elementos Estructurales
Gestor Eventos
Hola
Mundo.class
clase activa
suspender()
vaciarCola()
componente
colaboracin
Gestin Pedidos
Servidor
nodo
Elementos de Comportamiento
Son las partes dinmicas de UML.

Interaccin
Conjunto de mensajes intercambiados entre un
conjunto
de objetos con un propsito particular.
dibujar
mensaje
Elementos de Comportamiento
Son las partes dinmicas de UML.
Mquina de estados
Secuencia de estados por las que pasa un objeto
durante su vida en respuesta a eventos.
activado
estado
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
IteradorCuenta
Cuenta
Domiciliacion
1
Ahorro
0..n
Corriente
Operacion
Periodica
Diagramas de UML
Diagramas de Casos de Uso

Diagramas de Clases
Diagramas
Diagramas de Objetos
no son
Diagramas de Interaccin
modelos
Diagrama Secuencia
Diagrama Colaboracin
Diagramas de Estados
Diagramas de Actividades
Diagramas de Componentes
Diagramas de Despliegue
Modelos en UML
Modelado de Casos de Uso
Diagrama de Casos de Uso
Diagrama de Clases
Modelado de Comportamiento
Diagramas de Estados
Modelado de flujos de actividades (p.e. Modelo del Negocio)

Modelado Implementacin
Diagrama de Componentes
Modelado de Despliegue
Modelo del Negocio

Responsable
Serv icio PE
Alumno
Sistema
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 de 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
Modelo
Estructural
Diagrama
de clases
Modelo de Comportamiento
1. cerrarEdicionSubasta(es)
Diagrama
de
colaboracin
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
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

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

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

Dicotoma interfaz / implementacin
asistente
Ortografico.dll
IOrtografia
Mecanismos de extensibilidad de
UML
Estereotipos
Extienden el vocabulario de UML, permiten definir
nuevos tipos elementos y relaciones a partir de los
existentes.
Algunos son predefinidos en UML
Valores etiquetados
Extienden las propiedades de un elemento,
aadiendo nueva informacin.
Par etiqueta/valor: { etiqueta = valor }
Restricciones
Restricciones semnticas a elementos o relaciones.
Definidos por el modelador o incluidos en UML.
Ejemplo: { emp.vacaciones < 28 }
Ejemplo Estereotipo predefinido
Cliente
<<Actor>>
Cliente
Cliente
Clase
Clase
estereotipada
Ejemplo Estereotipo Predefinido
IComparator
Clase
estereotipada
Mecanismos de extensibilidad de
UML
valor etiquetado
estereotipo
ColaEventos {version 3.2; autor: jgm}
<<Exception>>
Overflow
aadir()
quitar()
vaciar()
{ordenado}
restriccin
Hola, Mundo!
import java.awt.Graphics;
class HolaMundo extends java.applet.Applet {
public void paint (Graphics g) {
g.drawString (Hola, Mundo!,10,10);
}
}
HolaMundo
g.drawString
("Hola, mundo)
paint()
Diagrama de Clases
Organizacin en Paquetes
Organizacin en Paquetes
java
HolaMundo
Applet
awt
lang
Diagrama de Secuencia
: Thread
: Toolkit
1. run()
: ComponentPeer
target : HolaMundo
1.1. callbackLoop()
1.1.1. handleExpose()
1.1.1.1. paint()
HolaMundo.clas
s
hola.html
hola.jpg
hola.java
Contenidos
Presentacin de UML
Diagramas de Clases
Modelado de Casos de Uso

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

noventa
Se inspira en los escenarios utilizados para describir
procesos
Otras definiciones de caso de uso

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

el sistema en discusin y sus actores externos, relacionado
con un objetivo particular.
[A. Cockburn]
Es una coleccin de escenarios de xito y fracaso relacionados
que describe a los actores que usan un sistema para
conseguir un objetivo
[C. Larman]
Ejemplo Caso de Uso
actor
caso de uso
Gestionar Prstamos
Responsable
Prestamos
asociacion
Actores
Un actor representa un conjunto
coherente de roles que juegan los
usuarios de los casos de uso al
interaccionar con el sistema.
Roles jugados por personas, dispositivos, u
otros sistemas.
El tiempo puede ser un actor (procesos
iniciados por el sistema)
No forman parte del sistema
Actores
Un usuario puede jugar diferentes roles.
En la realizacin de un caso de uso pueden
intervenir diferentes actores.
Un actor puede intervenir en varios casos de
uso.
Identificar casos de uso mediante actores y
eventos externos.
Un actor necesita el caso de uso y/o participa
en l.
Actores
A. Cockburn distingue dos tipos de
actores:
Primarios:
Requieren al sistema el cumplimiento de un
objetivo
Secundarios:
El sistema necesita de ellos para satisfacer un
objetivo
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.
Escenarios y Casos de Uso

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

Describir el flujo de eventos
Texto estructurado informal

Texto estructurado formal (plantillas)
Pseudocdigo
Notaciones grficas: diagramas de secuencia
Debe ser legible y comprensible para un

usuario no experto.
Debe indicarse: inicio y final, actores, objetos
que fluyen, flujo principal y flujos
excepcionales.

Comprar artculos (en un terminal de punto de venta)
Flujo Principal: Un cliente llega al TPV con un conjunto de
articulos. El Cajero registra los artculos y se genera un ticket.
El cliente paga en efectivo y recoge los artculos.
1.
2.
3.
4.
5.
El cliente llega al TPV con los artculos.

El cajero registra el identificador de cada artculo.
El sistema obtiene el precio de cada artculo y aade la
informacin a la transaccin de venta.
Al acabar el cajero indica la finalizacin de la introduccin
de artculos.
El sistema calcula el total de la compra y lo muestra.
Comprar artculos (en un terminal de punto de venta)
6.
7.
8.
9.
El Cajero le dice al cliente el total.

El cliente realiza el pago.
El cajero registra la cantidad de dinero recibida.
El sistema muestra la cantidad a retornar al cliente y genera
un recibo.
10. El cajero deposita el dinero recibido y saca la cantidad a
devolver que entrega al cliente junto al ticket de compra.
11. El sistema almacena la compra completada.
12. El cliente recoge los artculos comprados.
Cajero
Comprar Articulos
Cliente
:Sistema
: Cajero
introducirItem(upc,cantidad)
finalizarVenta()
hacerPago(cantidad)
Validar Usuario (contexto de un cajero automtico)
Flujo Principal: El sistema pide el NIP. El cliente lo introduce

a travs del teclado y pulsa Enter. El sistema comprueba la
validez del NIP. Si es vlido el sistema acepta la entrada y
finaliza el caso de uso.
Flujo Excepcional: El cliente puede cancelar la transaccin

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

se reinicia el caso de uso. Si esto ocurre tres veces, el
sistema cancela la transaccin completa y se queda con la
tarjeta.
Ejemplo diagrama de casos de

uso
Registrar curso
Rebajar Mnimo
Aprobar curso
Servicio CPE
Responsable
Cerrar curso
Crear proyecto
Servicio Contabilidad
Fin matriculacion
Realizar preinscripcin
Sistema
Avisar admitidos
Alumno
Matriculacin
Cancelar curso
Ejemplo diagrama de casos de

uso
Actores
Secundario
Alumno
Realizar preinscripcin
Gestin Expedientes
Actor
Principal
Matriculacin
Entidad Bancaria
Ejemplo diagrama de casos de uso
Reservar Libro
Prestamo revista
Profesor
Prestamo Libro
Devolver revista
Devolver libro
Actualizar catalogo
Socio
Extender Prestamo
Consultar
Bibliotecario
Socio
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).
caso de uso
colaboracin
Hacer Pedido
Gestin Pedidos
realizacin
El objetivo de la arquitectura del sistema

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

Tres tipos de relaciones:
Generalizacin
Un cdu hereda el comportamiento y significado de otro
Inclusin
Un cdu base incorpora explcitamente el
comportamiento de otro en algn lugar de su
secuencia.
Extensin
Un cdu base incorpora implcitamente el
comportamiento de otro cdu en el lugar especificado
indirectamente por este otro cdu
Ejemplo
Relacin de extensin
extend
Hacer Pedido
(establecer
prioridad)
include
Relacin de
inclusin
Hacer Pedido
Urgente
Comprobar clave
Validar Usuario
Generalizacin
Seguir Pedido
include
Examinar retina
Relacin de inclusin
Permite factorizar un comportamiento en
un caso de uso aparte y evitar repetir un
mismo flujo en diferentes casos de uso.
Ejemplo caso de uso Hacer Pedido:
Obtener y verificar el nmero de pedido.
Include (Validar usuario). Examinar el estado
de cada parte del pedido y preparar un
informe para el usuario.
Relacin de extensin
El caso de uso base incluye una serie de
puntos de extensin.
Sirve para modelar
la parte opcional del sistema
un subflujo que slo se ejecuta bajo ciertas
condiciones
varios flujos que se pueden insertar en un punto
Ejemplo caso de uso Hacer Pedido:

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

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

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

Coleman)
Relacin de uso:
PERFORM c.d.u.
Relacin de extensin:
Caso de uso extensin

c.d.u. extends c.d.u.
Cambio
objetivo que debe
conseguirse
Pasos
...
Variaciones
...
No funcional
...
Cuestiones
...
Plantilla usecases.org (Larman)
Actor Principal
Personas involucradas e Intereses
Precondiciones
Postcondiciones
Escenario Principal (Flujo Bsico)
Extensiones (Flujos Alternativos)
Requisitos especiales
Tecnologa y Lista Variaciones de datos
Frecuencia
Cuestiones abiertas
Por qu casos de uso?

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

(B.Meyer)
Los casos de uso no son adecuados en el
modelado orientado a objetos porque:
I.
Favorecen un enfoque funcional, basado en

procesos
II. Se centran en secuencias de acciones
III. Se basan en los escenarios actuales del sistema
Solo deben ser usados por equipos expertos en

desarrollo OO
tiles para validacin
Utilidad de los casos de uso

Hay consenso en considerar casos de uso
como esenciales para capturar requisitos y
guiar el modelado.
Pero existe (ha existido?) mucha confusin
sobre cmo usarlos.
Diferentes opiniones sobre el nmero de
casos de uso conveniente:
20 para un proyecto 10 personas/ao (Jacobson)
depende de la granularidad
Granularidad
Diferente granularidad
Un caso de uso puede describir:
Un objetivo o propsito del usuario
Una interaccin con el sistema
Un objetivo implica una o ms

interacciones.
Construir un caso de uso por cada
objetivo del usuario.
Granularidad
(A. Cockburn)
mbito
Caso de
uso
Sistema
Funcionalidad requerida del sistema
Organizacin
Caso de
uso del
negocio
Objetivo estratgico para la empresa, de mucho valor
Especificidad
Objetivo del usuario
cdu
Colecciones de objetivos de usuario
cdu
negocio
Subfunciones
inclusin de cdu
Granularidad
(A. Cockburn)
Especificidad
Objetivo del usuario
Tarea del usuario o proceso de negocio elemental
Colecciones de objetivos de usuario

Recoge casos de uso de usuario relacionados
Subfunciones
Un paso en la descripcin de un caso de uso (validar,
buscar, log on)
Detalle de la interaccin
Interfaz de dialogo o Interfaz semntica
Tipos de casos de uso

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

Esencial : Qu hace el sistema?
Concreto : Se contemplan detalles de
implementacin (GUI y tecnologa)
Recomendaciones
Especificar casos de uso no es una actividad de
dibujar diagramas sino de escribir con el detalle
necesario el flujo principal y los flujos alternativos:
centrado en la escritura en vez del dibujo
No hay que preocuparse demasiado por las
relaciones entre casos de uso ni entre actores.
El objetivo inicial es identificar los actores y a
partir de sus objetivos encontrar los casos de uso,
el diagrama de casos de uso es una ayuda visual.
Los actores deben interactuar con el sistema
Recomendaciones
Qu granularidad es apropiada para un
caso de uso?
En un sistema de venta por internet,
Aadir producto al carro de la compra
Introducir datos facturacin
son casos de uso?
Deben ser objetivos del usuario

Error comn: no identificar como casos de
uso las tareas que inicia el propio sistema
Anular reservas pasados quince das
Recomendaciones
No incluir como caso de uso las operaciones CRUD
sobre un objeto de negocio (alta, consulta, borrado,
actualizacin) funcin del sistema aparte, excepto si
se trata de operaciones relevantes para el sistema,
como registrar cliente en un sistema de venta por
internet
Cuidado con el empleo de la relacin include
NO HACER UNA DESCOMPOSICION FUNCIONAL!
Escribir casos de uso independientes de la interfaz o

de detalles de implementacin, escribirlos a nivel
esencial.
A qu nivel de detalle se describe un caso de uso?
Primero informal, luego expandido
Recomendaciones
Hay que comprobar que los casos de uso
incluyen toda la funcionalidad del sistema.
Preocupacin por mantener la validez y
consistencia del conjunto de casos de uso.
Cada compaa debe tener un manual sobre
uso de los casos de uso.
Los casos de uso slo consideran los
requisitos funcionales del proyecto, hay que
aadir los no-funcionales.
Referencias
http://alistair.cockburn.us/usecases/usecases.html
Writing effective uses case, Alistair Cockburn, Addison-Wesley,
2000
C. Larman, UML y Patrones: Una introduccin al anlisis y diseo
orientado a objetos y al proceso unificado, Prentice-Hall, 2003.
Contenidos
Presentacin de UML
Diagramas de Clases
Modelado estructural
Se describen los tipos de objetos de un sistema y
las relaciones estticas que existen entre ellos.
Clases
Interfaces
Relaciones de dependencia, realizacin,
generalizacin y asociacin (agregacin,
composicin)
Tambin pueden incluir paquetes y colaboraciones
Un diagrama de clase es una representacin

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

Clases que corresponden a conceptos del dominio
Atributos y mtodos
Modelo de Diseo
Incluye clases que corresponden a decisiones del diseo
Modelo de Implementacin
Clases que corresponden a un lenguaje de programacin
Modelo Conceptual
Del Modelo Conceptual a las

clases
Los modelos de anlisis se obtienen a
partir del modelo conceptual:
Conceptos a clases
Atributos de un concepto a atributos de la
clase
Aadir comportamiento (mtodos)
Modelo de diseo
IteradorCuenta
Cuenta
Domiciliacion
1
Ahorro
0..n
Corriente
Operacion
Periodica
Modelo Conceptual
o de Anlisis?
Modelo de
Comportamiento
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
Se crean tantas adjudicaciones
como pujas ganadoras haya.
Cada adjudicacin se asocia
con un ArticuloConcreto, una
puja adjudicataria y con la
subasta.
Colaboracin (parte esttica)
Colaboracin (parte dinmica)
: Usuario
11: recalcularTotal()
1: 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
Patrn de diseo (Parte Esttica)

Subject
subjectState
Attach()
Observer
+observers
1..*
1..1
Detach()
Update()
Notify()
for all o in observers
{o.update()}
ConcreteSubject
subjectState
getState()
setState()
ConcreteObserver
+subject
observerState
observerState=
update()
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.
Atributos
[visibilidad] nombre [: tipo] [= valor_inicial ] [{propiedades}]
visibilidad
+ = pblica
# = protegida
- = privada
nombre: nombre del atributo

tipo:
tipo del atributo
valor_inicial: valor inicial o por defecto

propiedades: {frozen} {addOnly}
Atributos
Nivel Conceptual:
Los clientes tienen un
nombre
Nivel de Especificacin:
El cliente puede almacenar y
consultar su nombre
Nivel de Implementacin:
Una instancia de Cliente tiene
un campo de tipo String que
almacena su nombre y un
mtodo que lo devuelve
Operaciones
[visibilidad] nombre [(lista_parametros)] [: tipo_retorno]
[{propiedades}]
visibilidad
+ = pblica
# = protegida
- = privada
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
Atributos
Operaciones
Clases Parametrizadas
Clase
Parametrizada
Tabla
count
capacity
put(G)
item() : G
bind <Empleado>
Empleados
Instanciacin
Tabla<Cliente>
Otras propiedades
Clases y mtodos diferidos
Multiplicidad
Variables y mtodos de clase
<<abstract>>
Figura
rotar()
trasladar()
visualizar()
Clases Estereotipadas
<<metaclass>>
MetaclaseCuenta
Clases y valores etiquetados
<<exception>>
FueraRango
Relaciones
Dependencia
Un cambio en la especificacin de un elemento
afecta a otro
PlanDelCurso
Window
position
parent
children
size
open()
close()
move()
resize()
Curso
aadir(c : Curso)
eliminar(c : Curso)
Clock
Nodo
Lista
<<friend>>
Estereotipos para dependencias

bind:
entre una clase genrica y una instanciacin
friend:
dependencia de clase amiga
refine:
relacin de refinamiento
use:
relacin de uso
import:
un paquete importa los elementos de otro.
extend:
para casos de uso
include:
para casos de uso
Relaciones
Generalizacin
Es-un-tipo-de
Cuenta
CuentaAhorro
Window
CuentaCorriente
TextWindow
BoxDialog
Generalizacin
Nivel Conceptual
Todas las instancias de CuentaCorriente son
instancias de Cuenta
Nivel Especificacin
La interfaz de CuentaCorriente incluye la
interfaz de Cuenta
Principio Sustitucin
Nivel Implementacin
Herencia
Asociacin
Asociacin
Relacin estructural que especifica que los
objetos de un tipo estn conectados con los
de otro.
Persona
+empleado
+patron
1..*
Empresa
impartido
Curso
*
Profesor
1..*
Asociaciones
Agregacin
Caso especial de asociacin
Relacin estructural parte-de
Empresa
1..1
*
Departamento
Asociaciones
Nivel Conceptual
Muestran la relacin conceptual entre dos clases.
Un cliente tiene varios pedidos
Nivel de Especificacin
Representan responsabilidades
Detectamos los mensajes del protocolo de una
clase con respecto a la otra
Nivel de Implementacin
Establecer atributos: navegabilidad
Asociaciones
Especificacin:
class Pedido {
public Cliente getCliente();
public Set
getLineaPedido();... }
Implementacin
class Pedido {
private Cliente
private HashSet
_cliente;
_lineasPedido;
Navegacin
Posibilidad de limitar la navegacin a una
sola direccin
Determina si una clase de la asociacin
tiene conocimiento de la otra.
Nivel de especificacin o implementacin
impartido
Curso
*
Profesor
1..*
Visibilidad
Pblica:
Protegida:
Privada:
+propietario
#propietario
-propietario
GrupoUsuarios
Usuario
*
+propietario
1..1
-clave
*
Clave
Asociaciones calificadas
Nivel Conceptual:
Dentro del mismo pedido no pueden existir dos lneas con
el mismo producto
Nivel Especificacin:
El acceso a ItemPedido es indexado por productos
Nivel Implementacin:
Se usa una tabla para almacenar las lneas de pedido
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?
Cuatro posibles tipos de agregacin
Composicin
Es un caso particular de agregacin:
exclusiva y dependiente
Las partes pueden crearse despus del agregado
compuesta al que pertenecen, pero una vez
creadas viven y mueren con ella.
La parte slo puede formar parte de un
agregado.
El agregado gestiona la creacin y destruccin
de las partes.
Las partes se pueden eliminar antes de eliminar
el agregado.
Composicin
Ventana
agregado /todo
1..1
composicin
*
Marco
parte
Composicin
POLIGONO
1
Relleno:Diseo
{ordered}
{ordered} 3..*
Punto
Clases Asociacin
Una asociacin que tambin es una clase
Una clase asociacin aade una restriccin:
Slo puede existir una instancia de la asociacin
entre cualquiera par de objetos participantes
No podramos modelar que una persona

tiene diferentes contratos para una misma
compaa a lo largo del tiempo.
Ejemplo de clase asociacin
Ejemplo de clase asociacin
Asociaciones derivadas
Asociacin
Derivada
Asociaciones derivadas
recibe
Estudiante
Asignatura
/ensea
imparte
Profesor
Asociacin
Derivada
Restricciones para Asociaciones
Empresa
Cuenta
{or}
Persona
Departamento
*
{subconjunto}
+miembro
1..*
Persona
+Director
1..1
Restricciones para Asociaciones
operario
*
0..1
empleado
Persona
patrn
0..1
jefe
{Persona.patrn=
Persona.jefe.patrn }
Compaia
Realizacin
Relacin entre clasificadores:
un clasificador especifica un contrato que otro
clasificador garantiza que cumplir.
<<Interface>>
IPila
Pila
push()
pop()
top()
Pila
IPila
Clases Abstractas e Interfaces
Interfaz
InputStream
(from io)
InputStreamReader
(from io)
DataInput
(from io)
Clase
Abstracta
FilterInputStream
(from io)
DataInputStream
(from io)
Clases Abstractas e Interfaces
InputStream
<<Interface>>
DataInput
(from io)
(from io)
Interfaz
FilterInputStream
(from io)
DataInputStream
(from io)
InputStreamReader
(from io)
Paquetes
Elemento organizativo
Puede agrupar elementos de cualquier tipo.
Un elemento es exclusivo a un paquete.
Establece un espacio de nombres
Posibilidad de anidar paquetes.
Modelo
Modelo
+ Producto
+ CarroCompra
+ Comercio
Importacin/Exportacin en
paquetes
Los paquetes permiten controlar la complejidad del
manejo de un gran nmero de abstracciones,
controlando los accesos mediante la importacin.
Relaciones de importacin, acceso y
generalizacin
La parte pblica de un paquete son sus
exportaciones.
Las partes pblicas son visibles en los paquetes
que importan al paquete contenedor.
La importacin no es transitiva.
Los paquetes anidados pueden ver todo lo que
ven los paquetes que los contienen.
Cliente
+ FormularioPedido
+ FormularioDeSeguimiento
- Pedido
Servidor
+ BaseDeDatos
+ ServicioDeRegistro
<<import>>
Politicas
+ ReglasPedidos
+ GUI:Ventana
GUI
+ Ventana
+ Formulario
# GestorEventos
<<import>>
Generalizacin de Paquetes
GUI
+ Ventana
+ Formulario
# GestorEventos
WindowsGUI
+ GUI:Ventana
+ Formulario
# GUI:GestorEventos
+ VBForm
MacGUI
Paquetes
Un paquete bien estructurado debe:
ser cohesivo
estar poco acoplado
pocos anidamientos
conjunto equilibrado de elementos
Uso de los paquetes
<<subsystem>>
Pedidos
<<model>>
Diseo
<<layer>>
Servicios
Bsicos
<<framework>>
Struts
Uso de los paquetes

Agrupar elementos relacionados para
manejarlo en conjunto.
Paquete Clases e interfaces del modelo

Paquete Interfaces de usuario
Paquete Servicios base de datos
Paquete Modelo del anlisis
Un modelo es un paquete incluyendo todos

los elementos que constituyen una particular
vista del sistema modelado.
Sistema, modelo, vista, diagrama

Un sistema es aquello que se est
desarrollando y para lo que se crean
modelos.
Un sistema debe ser modelado desde dos
puntos de vista:
Modelar el problema: comprender el problema
Modelar el producto a crear: disear la solucin
Modelado OO ofrece una correspondencia

directa entre los dos puntos de vista, a travs
del concepto de objeto
Sistema, modelo, vista, diagrama

Un modelo captura una vista de un sistema fsico:
Es una abstraccin de ese sistema con cierto propsito,
por ejemplo modelar su comportamiento en relacin a
unas personas que tienen determinado inters.
Un modelo contiene todos los elementos de modelado

necesarios:
Organizados en una jerarqua de paquetes/ subsistemas.
Un modelo y sus elementos tienen una especificacin.

Un modelo y sus elementos se representan mediante
diagramas, que expresan una vista del modelo.
Subsistema
Un subsistema es una unidad de
comportamiento en el sistema.
Permite descomponer el sistema
Un subsistema ofrece interfaces, tiene
operaciones, y distingue entre especificacin
e implementacin.
Vistas UML
vocabulario
funcionalidad
ensamblado
gestion conf.
Vista de Implementacion
Vista de Diseo
comportamiento
Vista de Procesos
Funcionamiento
escalabilidad
rendimiento
Vista de casos de uso
Vista de Despliegue
topologa
entrega
distribucin
instalacin
Vistas UML
clases
interfaces
colaboraciones
componentes
Vista de Implementacion
Vista de Diseo
casos de uso
Vista de Procesos
clases activas
Vista de Despliegue
nodos
Vistas UML
Diagramas de clase
Diagramas de estado
Vista de Implementacin
Vista de Diseo
Vista de Procesos
Diagramas de clase
Diagramas de estado
Diagrama de interaccin
Diagramas de estado
Vista de Despliegue
Diagrama de interaccin
Diagramas de estado
Diagrama de Objetos
: Cuenta
: Cliente
: Perfil
: CodigoCuenta
: Tarjeta
: Transaccion
Diagrama de Objetos
: Curso
: Alumno
: Profesor
: Tarjeta
: Expediente
: Departamento
director : Profesor
: GrupoInvestigacion
: Tarjeta
Contenidos
Mquinas de estado
Colaboraciones
Enlaces y Asociaciones
Un enlace es :
una conexin semntica entre objetos.
una instancia de una asociacin.
un camino por el cual enviar un mensaje
enlace
p:Persona
:Empresa
1: asignar(desarrollo)
mensaje
Interacciones y Mensajes
Interaccin:
Comportamiento que comprende un conjunto
de mensajes intercambiados entre un
conjunto de objetos dentro de un contexto
para lograr un propsito.
Mensaje:
Especificacin de una comunicacin entre
objetos que transmite informacin, con la
expectativa de desencadenar una actividad.
Modelado del comportamiento

Se describe cmo los objetos colaboran
entre s para realizar cierta actividad.
Se expresan mediante los diagramas de
interaccin:
Diagramas de Secuencia y Diagramas de
Colaboracin.
Tambin se describe las mquinas de estado

que caracterizan a los objetos
Diagramas de estado
Describen una interaccin.
Dos tipos: Diagramas de Secuencia y
Colaboracin
Diagramas de Secuencia:
Destacan la ordenacin temporal de los
mensajes
Diagramas de Colaboracin:
Destacan la organizacin estructural de los
objetos participantes.
Equivalencia semntica
Diagramas de Secuencia
Incluye:
Objetos y su lnea de tiempo

Focos de control o activacin
Mensajes: a instancias o de creacin
Mensaje self
Informacin de control: condiciones y marcas de
iteracin
Indicar el objeto devuelto por el mensaje: return
(aadirlos slo cuando ayuden a clarificar la
interaccin)
Mensajes
Simple:
Creacin de objetos:
Condicin:
Iteracin:
Asignacin:
metodo(arg)
<<create>>
[cond] metodo()
* metodo()
v:= getObjeto()
Numeracin jerrquica o secuencial o

ninguna
Diagramas de Secuencia
:
:
: Pedido
: LineaPedido
: Item
InterfacePedido
ControladorPedido
1: preparar()
2: preparar()
3: * preparar()
4: hayStock:=check()
5: [hayStock] eliminar()
6: pedir?:= necesarioPedir()
7: [pedir?] <<create>>
: ItemPedido
8:
9: [hayStock] <<create>>
: ItemEntregado
Diagramas de Colaboracin
1: preparar()
:
InterfacePedido
2: preparar()
: ControladorPedido
6: pedir?:= necesarioPedir()
3: * preparar()
4: hayStock:=check()
5: [hayStock] eliminar()
: Item
7: [pedir?] <<create>>
: ItemPedido
: Pedido
:
LineaPedido
8: [hayStock] <<create>>
:
ItemEntregado
c:Cliente
p:ProxyODBC
<<create>>
:Transaccion
establecerAcciones
establecerValores
Lnea de vida
establecerValores
tiempo
exito
<<destroy>>
Foco de
control
Diagrama de Colaboracin
1: <<create>>
2: establecerAcciones
6: <<destroy>>
c:Cliente
:Transac
cion
5: exito
3: establecerValores
4: establecerValores
p:Proxy
ODBC
c:Cliente
a:Ayuda
Planificacion
<<create>>
:AgenteBilletes
establecerItinerario(i)
calcularRuta
ruta
<<destroy>>
notificar
Diagrama de Colaboracin
3: calcularRuta
1: <<create>>
2: establecerItinerario(i)
5: <<destroy>>
c:Cliente
:Agente
Billetes
4: ruta
6: notificar
a:Ayuda
Planificacion
Numeracin secuencial
2: m2()
1: m1()
:A
3: m3()
:B
:C
4: m4()
:D
Confusin en el flujo de ejecucin
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
Numeracin jerrquica
1.1. m2()
1. m1()
:A
1.2. m3()
:B
:C
1.3. m4()
:D
Tipos de mensajes
Simple
Llamada de operacin o flujo anidado de
control
Sncrono
El emisor espera hasta recibir el resultado
Asncrono
El emisor no espera a recibir el resultado
Retorno
Indica el retorno de una llamada
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
Caso de Uso (Escenario)
: Cliente
:ReceptorPedidos
:AgenteTarjeta
Credito
:GestionPedido
:AgenteFacturacion
enviarPedido
procesarTarjeta
tramitarPedido
confirmarPedido
emitirFactura
Caso de uso (Colaboracin)
: Technical
Responsible
: Launch
Manufacturing GUI
:OrderManager
:EvaluatedOrders
o : Order
: OrderLine
: Product
selectOrder()
selectOrder(cod)
o:=find(cod)
launchManufacturing()
launchManufacturing(cod)
launch manufacturing()
*generateWO()
tpl:=getTemplate()
createWO(tpl)
: WorkOrder
Caso de uso de negocio
viajero: Empleado
encargado: Empleado
contable : Empleado
pagador : Empleado
solicitudPermisoViaje()
PermisoViaje()
informeGastos(unInforme)
OKgastos(unInforme)
solicitudPago(viajero)
Caso de uso de negocio

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

Diagramas de Colaboracin
Equivalencia semntica
Simples para comportamientos simples.
Si hay mucho comportamiento
condicional, usar diferentes escenarios.
Diagramas de secuencia muestran mejor
el orden en que se ejecutan los mensajes
Diagramas de colaboracin muestran
claramente los objetos con que interacta
un determinado objeto.
Diagramas de Actividades
Muestran un flujo de actividades.
Es un caso especial de mquina de estados.
Incluye:
estados actividad y estados accin
transiciones
objetos
Una actividad produce alguna accin que

produce algn cambio en el sistema o
retorna un valor.
Estados Accin y Estados

Actividad
Procesar
Pedido
Un estado accin no se puede

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

actividades
Modelado de flujos de trabajo (workflow)
como son los procesos de negocio
(business process).
Se puede asociar a cualquier elemento de
modelado, pero lo ms normal es
asociarlo a una operacin:
diagrama de flujo de las acciones.
Eventos
Un evento es un acontecimiento que ocupa
un lugar en el tiempo y espacio.
Un evento es un estmulo que dispara una
transicin en una mquina de estados.
Eventos externos vs. Eventos internos.
Tipos de eventos:
Seales (excepciones)
Llamadas
Paso de tiempo
Cambio de estado
Seales
Modelado Excepciones
<<exception>>
Excepcion
establecerManejador()
primerManejador()
ultimoManejador()
<<exception>>
Duplicado
Conjunto
aadir()
eliminar()
<<send>>
<<exception>>
Overflow
<<send>>
<<send>>
<<exception>>
Underflow
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
Estados
Rastreando
accin entrada
transicin interna
evento diferido
entry/ activarModo(enRastreo)
exit / activarModo(noRastreo)
nuevoObjetivo/rastreador.adquirir
do / seguirObjetivo
autotest / defer
accin salida
actividad
Transiciones
Una transicin de un estado A a un estado B, se
produce cuando se origina el evento asociado y
se satisface la condicin especificada, en cuyo
caso se ejecuta la accin de salida de A, la accin
de entrada a B y la accin asociada a la
transicin.
Elementos de una transicin:
Estados origen y destino

Evento de disparo
Condicin de guarda
Accin
Mquina de estados
Especifica la secuencia de estados por las que
pasa un objeto a lo largo de su vida en respuesta
a eventos, junto con sus respuestas a esos
eventos.
til si las instancias de una clase tienen un
comportamiento que depende de su historia o que
deben responder a eventos externos: objetos
reactivos.
Se representa mediante un diagrama de estados.
After (2 sec) send c.estaActivo
ruido
Inactivo
objetivoEn(p)
[representaAmenaza]
/ t.aadirObjetivo(p)
Buscando
Configuracin
Acoplamiento
Rastreando
contactar
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 secuenciales
introducirTarjeta
Activo
entry/leerTarjeta
exit/expulsarTarjeta
Inactivo
Validacin
cancelar
[continuar]
mantener
Seleccin
Mantenimiento
Procesando
[no continuar]
Impresin
Subestados concurrentes
Mantenimiento
mantener
Inactivo
Pruebas
Probar
perifericos
Manejo Ordenes
AutoDiagnosis
[continuar]
Orden
Espera
Pulsar tecla
[no continuar]
Subestados Concurrentes
Contenidos
Mquinas de estado
Colaboraciones
Componentes
Un componente es una parte fsica y
reemplazable de un sistema, que conforma con un
conjunto de interfaces y proporciona su
implementacin.
Modela artefactos tales como:
ejecutables, bibliotecas, tablas, archivos,
documentos,..
Representa el empaquetamiento fsico

de elementos lgicos tales como clases, interfaces,..
Residirn en los nodos del sistema

Estereotipos: executable, library, file, table, document
Componentes (UML 1.5)

Es una parte de un sistema reemplazable,
modular y desplegable que encapsula una
implementacin y expone un conjunto de
interfaces. Normalmente especificado por
uno o ms clasificadores (clases, interfaces,
tipo de dato,..) que residen en el
componente, y un conjunto de ellos define su
interfaz externa. Conforma a las interfaces
que expone al exterior, y puede ser
implementado por un archivo binario,
ejecutable o script. Puede ser desplegado
sobre un nodo
Propiedades de un componente
Es una unidad de despliegue independiente.

Puede ser conectado con otros componentes
En una aplicacin dada existir una nica copia
Es una parte sustituible de un sistema
(conforma con una interfaz)
Realiza una funcin bien definida

(cohesin fsica y lgica)
Abarca ms de una colaboracin de clases

Existe en el contexto de una arquitectura bien
definida.
Presupone una infraestructura tecnolgica en la que
se piensa utilizar
Propiedades de un componente
Interfaz
Componente
Interfaz soportada Especificacin
1..*
Componente
1
*
realizacin
Implementacin
Componente
1
*
Instancia
Componente
instancia
instalacin
Instalacin
Componente
Componentes
<<EXE>>
Explorador
agenteFraudes.dll
Realiza
agenteFraudes
politicaFraudes
busquedaPatrones
Componentes
explorador.java
JerarquaElementos
arbol.java
El componente
arbol.java
puede ser reemplazado por otro que

proporcione la interfaz
JerarquaElementos.
Componentes
AsignacionAula.exe
AsignaturaUSP
Asignacion
AulaUSP
Reserva
Tipos de componentes
Despliegue
Necesarios y suficientes para formar un sistema
ejecutable: libreras dinmicas (dll), ejecutables
(exe),..
Productos del trabajo

Permanecen al final del proceso de desarrollo:
archivos cdigo fuentes, archivos de datos,..
Con ellos se crean los componentes de
despliegue
De ejecucin
Se crean durante la ejecucin: objeto COM,
instanciado a partir de una dll.
Modelado de ejecutables y bibliotecas
Modelado de cdigo fuente
Modelado de una API
Modelado de ejecutables
v.exe
Vwbas20.dll
vwdev20.dll
vwsrc20.dll

Es una parte modular de un sistema que
encapsula su contenido y cuya manifestacin
se puede reemplazar en su entorno
Define su comportamiento en trminos de las
interfaces que requiere y proporciona.
Puede actuar como un tipo.
Es una unidad auto-contenida que encapsula
el estado y comportamiento de clasificadores
(cdu, clases, interfaces)
Interfaces
proporcionadas
Interfaces
requeridas
Interfaz
proporcionada
Interfaz
requerida
Nodos
Un nodo es un elemento fsico que existe
en tiempo de ejecucin y representa un
recurso computacional que puede tener
memoria y capacidad de procesamiento.
Los componentes se ejecutan en nodos
Los nodos representan el despliegue
fsico de los componentes.
Muestra la configuracin de los nodos que
participan en la ejecucin y de los
componentes que residen en los nodos.
Incluye nodos y arcos que representan
conexiones fsicas entre nodos.
Modelado de sistemas empotrados, sistemas
cliente-servidor, sistemas distribuidos.
Diagrama de Despliegue
terminal
<<10-T-Ethernet>>
servidor
<<RS-232>>
Consola
Unidad
RAID
Modem
<<procesador>>
servidor cache
<<procesador>
servidor cache
internet
<<red>> red local
<<procesador>
servidor
principal
<<procesador>
servidor
<<procesador>>
servidor
<<procesador>>
servidor
Deployment Diagram
Contenidos
Mquinas de estado
Colaboraciones
Formalizacin de UML:
MOF y metamodelo
Colaboraciones
Sociedad de clases, interfaces y otros
elementos que colaboran para
proporcionar un comportamiento
cooperativo mayor que la suma de los
comportamientos de los elementos.
Parte estructural (diagrama de clases) y

parte de comportamiento (diagrama de
secuencia).
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)
caso de uso
colaboracin
Hacer Pedido
Gestin Pedidos
realizacin
Ejercicio
Disea una colaboracin de un mecanismo Object
Trading que separa la representacin de una
informacin de su presentacin y edicin; las clases
que representan a los objetos informacin no conocen
a las clases que representan editores y viceversa. Un
mismo editor puede editar diferentes tipos de
informacin y una misma informacin puede ser
editada por diferentes editores.
El propsito del mecanismo es seleccionar un editor
que colaborar adecuadamente con el objeto
informacin, crear un objeto editor y lo ligar con el
objeto informacin.
Un objeto cliente solicitar a un objeto Trader editar
cierta informacin.
Mecanismo trading (Parte esttica)
ClienteDeGestor
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
: FactoriaEditor
info :
ObjetoInformacion
editar(info)
* i:= getInterfaz()
p:= soportaInterfaz(i)
[p] crearEditor(info)
<<create>>
: Editor
Clases Cliente, Editor y ObjetoInformacion?
Mecanismo trading
(Comportamiento)
2: * i:= getInterfaz()
4: [p] crearEditor(info)
1: editar(info)
:
Cliente...
: Trader
3: p:= soportaInterfaz(i)
info :
ObjetoInformacion
: FactoriaEditor
5: <<create>>
: Editor
Clases Cliente, Editor y ObjetoInformacion?
Colaboraciones Parametrizadas
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)
: Subject
one : Observer
another : Observer
SetState( )
Notify( )
Update( )
GetState( )
Update( )
GetState( )
Contenidos
Mquinas de estado
Colaboraciones
FIN

Curso UML 2010 PDF

Uploaded by

Document Information

Original Title

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

Curso UML 2010 PDF

Uploaded by

Copyright:

Available Formats

Modelamiento de Software con

La gran mayora de los programas

En Java, los mecnicos se

La encargada modela a sus

En Java, los clientes sern

Cuando se produce una

En Java se instancia un objeto

Elemento que representa

Elemento que representa

Clase que representa

Clase que representa

Modelo de Mecnicos en el mapa con

Cada mecnico tiene caracteristicas

Modelo de Clientes en el mapa con

Cada cliente tiene caracteristicas

Clase que representa

Clase que representa

Nombre: Jorge Castro

Nombre: Luis Diaz

Nombre: Pedro Perez

Clase que representa

Cuando un cliente llama, se coloca una

Nombre: Jorge Castro

Nombre: Luis Diaz

Nombre: Pedro Perez

Clase que representa

Una vez se tenga el llamado de un

Una vez se tenga la llamada de un

Nombre: Jorge Castro

Nombre: Luis Diaz

Nombre: Pedro Perez

Clase que representa

Objetivos en el diseo de UML

Resumiendo modelado del

Utilidad del modelado

Utilidad del modelado

Sera lo ideal pero ....

Utilidad del modelado

Utilidad del modelado

Propiedades del modelado

Por qu las empresas no hacen

Se obtienen beneficios con el modelado?

Retrasos en los plazos

Abstraccin de software que modela todos

Puertos de entrada del

Todos los objetos son ejemplares de una

Grupo de objetos marcado por

Origen de las Clases

Papeles que representa:

Origen de las Clases

Abstraccin - Modelado Visual

El modelado captura las

II. Notacin (Visual) - Beneficios

Lgica del Negocio

Modelado Orientado a Objetos

Inconvenientes para el aprendizaje, aplicacin,

Participantes en UML 1.0

UML aglutina enfoques OO

Gamma et. al.

Mecanismos de Extensin en UML:

Falta integracin con respecto de otras

UML es una notacin, no es un proceso

Utilizable para sistemas que no sean software