Está en la página 1de 278

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
Modelado del software
Presentacin de UML
Modelado de Casos de Usos
Diagramas de casos de uso

Modelado Estructural
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
Servicio de Mantenimiento

Clase que representa

Mecnicos

Mecnico

Clase que representa

Clientes

Cliente

Ejemplo
Servicio de Mantenimiento

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
Servicio de Mantenimiento

Clase que representa

Mecnicos

Mecnico
Nombre: Jorge Castro
X: 6
Y: 7

Mecnico
Nombre: Luis Diaz
X: 1
Y: 22

Clase que representa

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
Servicio de Mantenimiento

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
Servicio de Mantenimiento

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
Servicio de Mantenimiento
Clase que representa

Mecnicos

Mecnico

Mecnico

Mecnico

Nombre: Jorge Castro


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)

Clase que representa

Clientes

Cliente
Nombre: INETI S.A.
X: 6
Y: 12

Cliente
Nombre: KAOS S.A.
X: 19
Y: 17

Ejemplo
Servicio de Mantenimiento

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
Servicio de Mantenimiento
Clase que representa

Mecnicos

Mecnico

Mecnico

Mecnico

Nombre: Jorge Castro


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)

Clase que representa

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
Servicio de Mantenimiento

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
Servicio de Mantenimiento

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
Servicio de Mantenimiento
Clase que representa

Mecnicos

Mecnico

Mecnico

Mecnico

Nombre: Jorge Castro


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)

Clase que representa

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

Utilidad del modelado

Escribimos cdigo
directamente?

Sera lo ideal pero ....


.... necesitamos escribir modelos

Utilidad del modelado


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.

Utilidad del modelado


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
Modelado del software
Presentacin de UML
Modelado de Casos de Usos
Diagramas de casos de uso

Modelado Estructural
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

Modelado Estructural
Diagrama de Clases

Modelado de Comportamiento
Diagramas de Interaccin
Diagramas de Estados

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


Diagramas de actividades

Modelado Implementacin
Diagrama de Componentes

Modelado de Despliegue
Diagramas de Despliegue

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.

Mecanismos comunes de UML


Dicotoma clasificador /instancia

Persona
nombre
direccion
telefono

Elena

Elena :
Persona

: Persona

Mecanismos comunes de UML


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()

Diagrama de Componentes

HolaMundo.clas
s

hola.html

hola.jpg

hola.java

Contenidos
Modelado del software
Presentacin de UML
Modelado de Casos de Usos
Diagramas de casos de uso

Modelado Estructural
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.

Descripcin de un caso de uso


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.

Descripcin de un caso de uso

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)

Descripcin de un caso de uso

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

Casos de uso y Colaboraciones

caso de uso
colaboracin
Hacer Pedido

Gestin Pedidos

realizacin

Casos de uso y Colaboraciones

El objetivo de la arquitectura del sistema


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

Organizacin de Casos de uso


Tres tipos de relaciones:
Generalizacin
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

Plantilla para casos de uso (D.


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

Plantilla para casos de uso (D.


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

Caso de uso extensin


c.d.u. extends c.d.u.
Cambio
objetivo que debe
conseguirse
Pasos
...
Variaciones
...
No funcional
...
Cuestiones
...

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
Modelado del software
Presentacin de UML
Modelado de Casos de Usos
Diagramas de casos de uso

Modelado Estructural
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)
4: aadirItem(codigo)
2: aadirItem(codigo)

: MostrarProductos

3: [primer producto] crear()

: Aadir

: CarroCompras

6: [!nuevoItem]incrementarUnidades()

10: [nuevoItem]put(codigo,i)

5: i:=getItemCarro(codigo)

: ItemCarro

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

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

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

: Producto

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 casos de uso

Vista de Despliegue

nodos

Vistas UML
Diagramas de clase
Diagramas de interaccin
Diagramas de estado

Vista de Implementacin

Vista de Diseo

Diagramas de casos de uso

Vista de Procesos

Diagramas de clase
Diagramas de interaccin
Diagramas de estado

Diagramas de componentes
Diagrama de interaccin
Diagramas de estado

Vista de casos de uso

Vista de Despliegue

Diagramas 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
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

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
Diagramas de actividades

Diagramas de Interaccin
Describen una interaccin.
Dos tipos: Diagramas de Secuencia y
Colaboracin
Diagramas de Secuencia:
Destacan la ordenacin temporal de los
mensajes

Diagramas de Colaboracin:
Destacan la organizacin estructural de los
objetos participantes.

Equivalencia semntica

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

Diagrama de Secuencia

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

Diagrama de Secuencia
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
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

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.

Diagrama de Componentes
Modelado de ejecutables y bibliotecas
Modelado de cdigo fuente
Modelado de una API

Modelado de ejecutables

v.exe

Vwbas20.dll

vwdev20.dll

vwsrc20.dll

Componentes (UML 2.0)


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)

Componentes (UML 2.0)

Interfaces
proporcionadas

Interfaces
requeridas

Componentes (UML 2.0)

Interfaz
proporcionada

Interfaz
requerida

Componentes (UML 2.0)

Componentes (UML 2.0)

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.

Diagramas de Despliegue
Muestra la configuracin de los nodos que
participan en la ejecucin y de los
componentes que residen en los nodos.
Incluye nodos y arcos que representan
conexiones fsicas entre nodos.
Modelado de sistemas empotrados, sistemas
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
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

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)

Casos de uso y Colaboraciones

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
Modelado del Comportamiento
Diagramas de interaccin
Diagramas de actividades
Mquinas de estado

Modelado de la Implementacin
Diagramas de componentes
Diagramas de despliegue

Colaboraciones

FIN