ANLISIS Y DISEO DE

SISTEMAS DE INFORMACIN

2005
Introduccin a UML

Unified Modeling Language - UML

UML es presentado como un lenguage de modelado
para

Visualizar
Especificar
Construir
Documentar

bsicamente los componentes de un sistema

de

informacin computacional.

UML define varios modelos bsicos para la representacin

del modelo del sistema:

el modelo de clases que captura la estructura esttica;

el modelo de estados que expresa el comportamiento
dinmico de los objetos;

el modelo de casos de uso que describe las necesidades
del usuario;

el modelo de interaccin que representa los escenarios y
flujos de mensajes;

el modelo de implementacin que muestra las unidades
de trabajo;

el modelo de despliegue que precisa la forma en que se
distribuyen los procesos.

El modelo del sistema es visto y manipulado por medio de

vistas, que consisten en proyecciones a travs de los elementos
de modelado.
Pueden construirse numerosas vistas a partir de los
modelos bsicos, mostrando la totalidad o parte de los
modelos.
Las vistas son expresadas a travs de los diagramas, que
consisten en representaciones grficas, usualmente grafos que
vinculan los elementos del modelo. UML define nueve tipos de
diagramas:
1. de clases
2. de secuencia
3. de colaboracin
4. de objetos
5. de transicin de estados
6. de casos de uso
7. de actividades
8. de componentes
9. de despliegue

U1
DC
1
DS

DS 3
DC 7

2
DC

vista de
usuarios

DC U

vista de
diseo

diagramas

Modelo
DC
U8

vista ..
........

DC
5

Clase Persona

DC
U9

El vocabulario y las reglas de un lenguaje como UML indican

como crear y leer modelos bien formulados,
aunque no indican que y cuando
los modelos deben ser creados.

El vocabulario de UML est compuesto de tres elementos

bsicos:

entidades

relaciones

diagramas

UML posee cuatro tipos de entidades:

estructurales, que representan la estructura del modelo

comportamiento, que representan aspectos dinmicos

agrupamientos, representan conjuntos de los otros
elementos del lenguaje

descriptores, expresan comentarios asociados a los
componentes del modelo

Entidades Estructurales

Clases

Interfaces

Colaboraciones

Casos de uso

Componentes (representa una parte fsica del
sistema)

Nodos (representan elementos fsicos qu existen en
tiempo de ejecucin, y generalmente poseen
memoria o capacida de procesamiento)

CLASES
son la descripcin de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semntica
<Nombre de Clase>
atributo1:
atributo2:
..........

El nombre de las clases

abstractas se escribe en
tipo cursivo

operacin1:
operacin2:
operacin3:
.....
.....

Cada clase debe tener un nombre nico.

Un atributo expresa una propiedad particular de una clase.

Una operacin refleja un servicio del objeto en el sistema.

Una clase puede implementar una o ms interfaces

INTERFAZ
es un conjutno de operaciones que especifican los servicios que
puede brindar una clase o componente.

<Nombre Interfaz>

Una interfaz describe el comportamiento visible desde el exterior

de una entidad.
Una Interfaz:
debe tener un nombre nico.
puede describir el comportamiento completo o parcial
de una clase.
define un conjunto de especificaciones de
operaciones, nunca sus implementaciones.

COLABORACIN
define una interaccin y una sociedad de roles y otros elementos que
trabajan en conjunto proveyendo un comportamiento cooperativo.

<Nombre Colaboracin>

Una colaboracin se describe a travs de una dimensin esttica y

otra dinmica.
<Nombre Colaboracin>

Diagrama de
Secuencias

Diagrama de
Clases

RELACIONES
Una relacin es la abstraccin de una asociacin entre
instancias de objetos.
La identificacin de relaciones permite reconocer la
manera en que colaboran los distintos objetos en el dominio.
Las relaciones expresan:

un vnculo
clases.

semntico

entre

las

el hecho que las clases estn

vinculadas de alguna manera.
Vendedor

Organizacin

Cliente
1...*

Departamento
confecciona

1...*
compuesto-por
atiende

Cliente

En UML existen cuatro tipo de relaciones:

Asociacin
Dependencia
Generalizacin
Realizacin

Asociacin
Dependencia
Generalizacin
Realizacin

ASOCIACIN

Una asociacin conecta dos

clases y refleja el hecho que
las
mismas
estn
relacionadas en el dominio
de aplicacin.
Empresa

Empleado

Las
relaciones
no
necesariamente deben estar
etiquetadas con un nombre

Empresa

Cliente

trabaja-en

direccin

Gerente

compra

Proveedor

ASOCIACIN
Las asociaciones son inherntemente bidireccionales: el sentido de
lectura lo da el nombre, pero la relacin es vlida en ambos sentidos.
Empresa

Persona
empleado

Empresa

Persona
trabaja-en

Se puede agregar una punta de flecha que indica en que direccin

debe ser ledo el nombre de la relacin

ASOCIACIN
El sentido de lectura elegido durante esta etapa no implica
decisiones de diseo.
materia prima
Proceso

Compuesto

produce

Una clase puede tener una asociacin a s misma (asociacin

reflexiva).
proveedor
Empresa

Empresa

cliente

ASOCIACIN

Es posible tener ms de una asociacin entre el

mismo par de clases
Persona

Empresa
empleado

entrevista
Avin

Aeropuerto
arriba

despega
Persona

Club
miembro

presidente

ASOCIACIN
La cardinalidad de una asociacin indica el nmero de
instancias de una clase que pueden relacionarse con una nica
instancia de la clase asociada
Cardinalidad

Descripcin

Exactamente uno

Cantidad ilimitada

0 .. *

Cero o ms

1 .. *

Uno o ms

0 .. 1

Cero o uno

2 .. 6

Rango especfico

2 .. 6, 10

Rango especfico o nmero exacto

ASOCIACIN
Cardinalidad

Aeropuerto

Avin

0..*

arriba

0..*

1
despega

Un Avin arriba en exactamente un Aeropuerto. A un

Aeropuerto arriban varios Aviones (cero si est cerrado).

ASOCIACIN
Cardinalidad
1..*

Libro
1

Editorial

1..*

1..*

Autor

1
1..*
1
Captulo

Indice

Un libro tiene varios captulos, un captulo pertenece a un slo

libro.
Cada libro tiene un ndice, el cual pertenece a un nico libro.
Un libro puede tener mltiples personas como autores y, a su vez,
una persona puede ser autor de diferentes libros.

10

ASOCIACIN
La cardinalidad pone de manifiesto suposiciones acerca del
dominio de aplicacin.
Contrato

Empresa

Empleado
*

No interesa que la misma represente una Verdad Universal para los Objetos
Relacionados. Slo debe representar lo que se verifica en el dominio modelado
Estudiante

Matricula

0..*

Curso
1..*

La relacin Matrcula no requiere que un Estudiante est relacionado con un

Curso. Este hecho puede ser diferente en otro contexto en el cual un Estudiante
pierde su condicin si no est registrado en un Curso, lo cual se representara de
la siguiente forma:
Estudiante

Matricula

1..*

Curso
1..*

Roles de un objeto
El rol de un objeto indica el papel que juega un objeto en su relacin
con otros objetos.
Un rol representa un comportamiento de una entidad participando en
un contexto dado.

Empresa

Contrato
+contratado Empleado

+contratante

1..*

Los nombres de roles enriquecen la semntica de una

relacin.
Los nombres de roles son opcionales y aparecen como
sustantivos.
El nombre de un rol es escrito cerca de la clase a la cual
califica.

11

AGREGACIN
Una Asociacin entre dos clases representa una relacin estructural
entre pares.
En ciertos casos es necesario modelar relacin del tipo "todo/parte",
en la cual una clase representa el todo y la otra clase la parte.
Empresa
1

Representa el Todo (contenedor)

*
Departamento

La Agregacin simple es slo conceptual y slo distingue el todo de la

parte.
No realiza ninguna vinculacin acerca del cilo de vida de las clases
vinculadas .

AGREGACIN
(una variacin de Agregacin)

Composicin expresa una relacin de pertenencia y asocia los ciclos de

vida del todo y la parte.
Facultad
1
1..*
Departamento

Las Partes con multiplicidad variable pueden ser creadas luego que el
todo, sin embargo, una vez creadas no podrn persistir si el todo
desaparece.
En una Composicin el todo es responsable de la vida de sus partes, lo
cual quiere decir que deber administrar su creacin y destruccin.

12

Facultad

1..*

Estudiante

0..*
1
1..*
Departamento

Las relaciones entre Facultad y Estudiante, Facultad y Departamento

son claramente diferentes.

Una facultad tiene cero o ms estudiantes, y un estudiante est
registrado en una o ms facultades.

Una facultad posee uno o ms departamentos. Cada departamento
est asociado a exactamente una sola facultad.
Se podra haber modelado el sistema con Asociaciones simples. Sin embargo
el empleo de relaciones Agregacin representan que Facultad es
organizacionalmente superior a Departamento y Estudiante.

ASOCIACIONES COMO CLASES

Surgen cuando las caractersticas a representar se originan como
consecuencia de la relacin entre dos objetos.
Estas propiedades se representan a travs de un nuevo objeto cuya
existencia y significado depende de los dos objetos vinculados.
Una asociacin como clase se representa como una
clase asociada a la relacin a travs de una relacin
con lnea punteada.
Empresa

1..*

Persona

Puesto
Inicio
Salario
Descripcin

13

GENERALIZACIN

Relacin taxonmica entre un elemento ms general y otro

ms especfico. El elemento ms especfico es
completamente consistente con el ms general y contiene
informacin adicional.
Una instancia del elemento ms especfico puede ser empleado
donde el elemento ms general es permitido.
Una relacin de Generalizacin es una relacin dirigida
entre dos elementos del mismo tipo ().
Figura

superclase
generalizacin

subclase

Circulo

Elipse

Linea

GENERALIZACIN

Una Restriccin puede ser aplicada a un conjunto de

relaciones de generalizacin y los hijos que comparten un
padre en comn.
Se pueden especificar las siguientes propiedades:
disjoint: ninguna instancia puede ser simultneamente
instancia de ms de uno de los hijos.
overlapping: una instancia puede ser instancia de uno o
ms hijos
complete: todos los hijos han sido enumerados y no se
pueden adicionar ms
superclase
incomplete: inversa de complete
Figura

{disjoint,incomplete}
Circulo

Elipse

Linea

14

DEPENDENCIA
Dependencia es una relacin utilizada para representar que un
cambio en la especificacin de una de las clases participantes,
puede afectar a la otra clase que hace uso de ella.
Pla n de C u rs o s
C u rs o
a d icio na r(c : C u rs o )
e lim in ar(c : C u rs o )

PlandeCursos depende de Curso, debido a que Curso es

empleado por las operaciones adicionar y eliminar.

REALIZACIN
Relacin entre una especificacin y su implementacin; una
indicacin de la herencia de comportamiento sin la herencia de
estructura.
Especificacin: describe el comportamiento de algo sin determinar
como ser implementado el comportamiento.
Implementacin: provee los detalles acerca de como implementar el
comportamiento (pueden existir mltiples implementaciones para
una especificacin).

Especificacin

<<Interface>>
BloqueElecciones
setDefault()
getChoice()

realizaci

setDefault()
getChoice()

ArregloBotones
setDefault()
getChoice()

Implementaciones

MenuPopUp

15

DIAGRAMA DE CLASES
Representa una vista esttica del sistema
Muestra la existencia de clases y sus relaciones
Especifica los atributos y responsabilidades de las
entidades que proveen el comportamiento de un sistema
Est compuesto por (como mnimo):

Clases.

Interfaces

Colaboraciones

Relaciones entre clases.

Nombre

Clase

Composicin
Expediente

Atributos

Oficina

Perso na

Ubicacin

Titular
Tema
Nmero
Estado
FechaInicio

Nombre
Direccin
Ciudad
FechaNac
DocumentoT ipo
DocumentoNum

Integrante

Generalizacin
Inicio()
Transferir()
Finalizar()
Archivar()

Empleado

Nomnbre
Apellido1 : String
Apellido2 : String
Nombre1 : String
Nombre2 : String
Nombre3 : String

Incorporar()
ActualizarFam()
CalcularHaber()

Trmite
es-un

es-un
es-un
Reclamo

Operaciones
Interno

Otorgamiento

Beneficio
Cliente

Solicitud
Familiar

Asociacin

Diagrama de Clases

16

PAQUETE (Package)
Un paquete encapsula un conjunto de elementos
empleados en el modelo (clases, relaciones, paquetes, etc).
Un paquete es un mecanismo de propsito general empleado
para administrar la complejidad de un modelo, mediante su
descomposicin en grupos de elementos.

Un paquete se emplea para:

agrupar y manipular en conjunto elementos del
modelo
controlar la visibilidad de los elementos contenidos
presentar diferentes vistas de la arquitectura del
sistema
Un paquete bien diseado agrupa elementos con
semnticas relacionadas y que suelen sufrir cambios en
conjunto.

17

PAQUETE

Cliente

Un paquete posee un nombre que lo

distingue del resto de los paquetes.

+ FormOrden
# Orden
- FormSeguimiento

El nombre completo de los elementos incluidos en un paquete,

incluye el nombre del paquete en el cual estn contenido
Cliente::Orden
Un paquete puede contener: clases, interfaces, componentes,
colaboraciones, casos de uso, diagramas y otros paquetes.
Si el paquete se destruye, su contenido tambin.
Todo elemento es posedo por un nico paquete.
Un paquete define un espacio de nombres, es decir, los
elementos dentro del paquete deben poseer nombres nicos.
Pueden existir elementos del mismo tipo, con el mismo nombre, pero
definidos en diferentes paquetes.
Cliente::Port Servidor::Port

VISIBILIDAD
Cliente
+ FormOrden
# Orden
- FormSeguimiento

La visibilidad de los elementos que posee un paquete se puede

establecer de la misma forma que se hace con los atributos y
operaciones de una clase.

pblico

protegido

privado

es visible desde los elementos contenidos de

cualquier paquete que importe los
elementos del paquete contenedor
es visible slo desde los hijos del paquete
contenedor
no es visible desde fuera del paquete en
que fue declarado

La parte pblica del package constituye su interface.

18

IMPORTACIN Y EXPORTACIN ENTRE PAQUETES

La importacin brinda permiso en un sentido para que elementos

de un paquete puedan acceder elementos de otro paquete.
Servidor

Elementos exportables
Cliente

+ BasedeDatos
+ ServiciosdeLogging

+ FormOrden
+ FormSeguimiento
Orden

Polticas
+ ReglasOrden

<<import>>

GUI
+ Window
+ Form
EventHandler

<<import>>

En UML la relacin de importacin entre paquetes se modela como una

dependencia, etiquetada con <<import>>

IMPORTACIN Y EXPORTACIN ENTRE PAQUETES

Agrupando las abstracciones del modelo en conjuntos
significativos (mediante paquetes), y controlando luego el
acceso a los mismos mediante la importacin, es posible
controlar la complejidad de modelos de gran dimensin
Exportacin
Los elementos pblicos de un paquete constituyen su parte
exportable. Es decir, accesibles mediante relaciones
<<import>>.
Los elementos que un paquete exporta son visibles
solamente a aquellos paquetes vinculados mediante una
relacin <<import>>.
La relacin <<import>> no es transitiva

19

VISIBILIDAD ENTRE PAQUETES CONTENIDOS

Manejo de Ordenes
Orden

UI

Procesamiento
de Ordenes
Almacenamiento
Externo

Calculo de
Precios

1. Los paquetes contenidos tiene acceso directo a cualquier

elemento del paquete contenedor, sin necesidad de relacin
<<import>> o restriccin de visibilidad. Esto vale para cualquier
nivel de contenido.
2. El paquete contenedor requiere una relacin <<import>> con el
paquete contenido.

Manejo de Ordenes solo ve UI

Todos los paquetes ven Orden

GENERALIZACION
La generalizacin entre paquetes es semejante a la
generalizacin entre clases.
El paquete especializado:

hereda los elementos pblicos y protegidos del
paquete ms general

puede reemplazar y agregar nuevos elementos
Almacenamiento
Externo

DiscosFijos

Paquete general

Removibles

Paquete
especializado

20

EMPLEO DE PAQUETES
El empleo ms usual del concepto de paquete, es para agrupar un
cierto nmero de elementos del modelo, de forma tal que puedan
ser manipulados y referenciados como un conjunto.
Por que usar un paquete y no una clase?
La razn es que las Clases son abstracciones de cosas
que existen en el problema o la solucin; mientras que
un paquete es un mecanismo para organizar los
elementos en el modelo.
Los paquetes no tendrn existencia en el sistema; las
clases existirn en el sistema (las clases poseen
instancias que son elementos del sistema ejecutable).

Los paquetes se pueden emplear para agrupar elementos

del modelo de acuerdo a diferentes criterios: similaridad,
relacin funcional, representacin de vistas, etc.

Servicios al
Usuario

Servicios de
Negocios

Servicios de
Datos

Proveen la interfase visual para

presentar e ingresar datos
Proveen la comunicacin entre la
presentacin y los datos, y las reglas
del negocio que restringen a los
mismos
Los elementos de este paquete
permiten mantener, acceder y
actualizar los datos.

21

AWT

UI Captura
Ordenes

UI Mailing

Aplicacion de
Mailing

Aplicacion de Captura
de Ordenes

Ordenes

Clientes

Si hay una modificacin en una clase de Ordenes, se

deben revizar las clases de UICapturaOrdenes?

AWT

UI Captura
Ordenes

UI Mailing

Aplicacion de
Mailing

Aplicacion de Captura
de Ordenes

Dominio
Ordenes

Clientes

En este caso se ha generado un paquete Dominio, lo cual

permite especificar dependencias referenciando el paquete
contenedor, en lugar de hacerlo individualmente.

22

AWT

UI Captura
Ordenes

UI Mailing

Aplicacion de
Mailing

Aplicacion de Captura
de Ordenes

Dominio
Ordenes

Implementan la
interfase de del
paquete general

Clientes

Interfase
Oracle
Interfase a
Base de Datos
Interfase
Sybase

Paquete abstracto

Los paquetes poseen una finalidad primaria que es la de

convertirse en un mecanismo de control de configuacin
y acceso, que permita a los desarrolladores organizar
modelos de gran dimensin y administrar su evolucin.
Los paquetes como herramientas para el control de
configuracin debern contener aquellos elementos que
evolucionarn conjuntamente.
Los paquetes debern contener aquellos elementos que se
compilan en forma conjunta.

23

ESTABILIDAD vs. GENERALIDAD DE PAQUETES

Los paquetes que importan son dependientes de
aquellos que exportan.
Si un paquete no es importado por ningn paquete (no posee
dependientes) lo clasificamos como irresponsable. Ningn
elemento depende de l y sus cambios no tienen impacto.
Los paquetes importados por muchos paquetes, posee
muchos dependientes, lo clasificamos como responsables.
Muchos elementos depende de ellos.
paquete
irresponsable

paquete
responsable

B
<<import>>

A
<<import>>

<<import>>

paquete
irresponsable

<<import>>

D
C

ESTABILIDAD vs. GENERALIDAD DE PAQUETES

Los paquetes que no importan son independientes.
Ningn paquete puede inducir cambios en un
paquete independiente
paquete
independiente

paquete
irresponsable

<<import>>

A
<<import>>

<<import>>

<<import>>

paquete
irresponsable

Sera aconsejable que:

Las decisiones arquitectnicas se encuentren en
paquetes independientes

Los detalles de implementacin se encuentren en
paquetes irresponsables

24

Es deseable que los paquetes

independientes y reponsables
sean estables.

Estable

Dependientes

Irresponsable

Responsable

ESTABILIDAD vs. GENERALIDAD DE PAQUETES

Es
pa
cio

fre
cu
e

nt

pa

ra

pa
qu
et
es

Inestable

Dependencias
Independiente

Dependiente

Generalidad , Abstraccin

ESTABILIDAD vs. GENERALIDAD DE PAQUETES

Estructura
arquitectnica

Se
cu

en

ci
a

Pr
in

ci
p

al

Detalles de
implementacin

Inestabilidad
independiente
responsable

dependiente
irresponsable

Los paquetes ms generales y que constituyen las bases del

sistemas deben ser los ms estables. Los cambios en los
mismos poseen un alto grado de propagacin.

25

CASOS DE USO
Los casos de uso describen bajo la forma de accciones
y reacciones el comportamiento de un sistema desde
el punto de vista de un usuario; permiten definir los
lmites del sistema y las relaciones entre el sistema y el
entorno.
El modelo de Casos de Uso emplea dos conceptos
bsicos
Actor y Caso de Uso
Estos conceptos permiten definir:

que elementos externos al sistema interactuan
con l (Actor) y

qu funciones deben ser realizadas por el sistema
(Caso de Uso)

26

CASOS DE USO

cliente
caso de uso

otro sistema

empleado

actor

CASOS DE USO
La definicin de un caso de uso incluye la descripcin
de todos los comportamientos que representa:

la secuencia principal

diferentes variaciones del comportamiento
normal

todas las condiciones de excepcin que pueden
ocurrir
La dinmica de un caso de uso puede ser especificada
en forma textual o mediante diversos diagramas UML
(secuencia, mquina de estados o colaboracin)

27

CASO DE USO: Validar Cliente en un Cajero

Flujo de eventos principal: El caso de uso comienza cuando el sistema le
solicita al cliente el nmero de PIN. El cliente puede ahora digitar su
PIN por medio del teclado. El cliente confirma lo ingresado por medio de
la tecla Enter. El sistema luego verifica si el PIN es vlido. Si el PIN es
vlido, el sistema comunica la aceptacin, y termina el caso de uso.
Flujo de eventos exepcional (Cancelacin): El cliente puede cancelar la
transaccin en cualquier momento presionando la tecla Cancel, y por lo
tanto se reinicia el caso de uso. No se realiza ningun cambio en la
cuenta del cliente.
Flujo de eventos exepcional (Re-digitacin del PIN): El cliente puede
borrar el PIN en cualquier momento antes confirmar lo ingresado y
reingresar un nuevo PIN.
Flujo de eventos exepcional (PIN no vlido): Si el cliente ingresa un
nmero de PIN invlido, el caso de uso comienza nuevamente. Si esto
ocurre tres veces seguidas, el sistema cancela la transaccin,
indicndole al cliente que por 60 segundos no podr interactuar con la
mquina.

Cuando se posee suficiente conocimiento, usualmente se

emplea un diagrama de secuencia para describir cada flujo
de eventos incluido en el caso de uso.

1. Flujo de eventos principal

2. Cancelacin
3. Re-digitacin del PIN
4. PIN no vlido

Validar Cliente

Cliente

28

ACTOR
Los actores no forman parte del sistema.

Un actor puede:

solamente ingresar informacin al sistema

solamente recibir informacin del sistema

ingresar y recibir informacin del sistema

Usualmente estos actores aparecen en la descripcin del dominio,

en las entrevistas con los usuarios y/o con los expertos.
Por ejemplo:

sistema de alumnado: alumno, profesor, etc.

sistema de stock: sist. facturacin, vendedor

IDENTIFICACIN DE ACTORES
Las siguientes preguntas usualmente colaboran en la deteccin de actores:

Quin est interesado en ciertos requerimientos?

En qu lugar de la organizacin el sistema ser usado?
Quin se beneficiar con el uso del sistema?
Quin suministrar al sistema esta informacin, usar esta
informacin, y eliminar esta informacin?

Quin mantendr el sistema?

El sistema usar recursos externos?
Una misma persona desarrollar diferentes roles?
El mismo rol ser desempeado por varias personas?
El sistema interactuar con un sistema preexistente?

29

IDENTIFICACIN DE CASOS DE USO

Un Caso de Uso modela el dilogo entre un actor y el sistema.

El conjunto de todos los casos de uso de un sistema constituye
todas las formas en que el sistema puede ser empleado.
Las siguientes consultas pueden ayudar a identificar casos de uso:
Cules son las tareas de cada actor?
Algn actor crear, almacenar, modificar, eliminar o leer
informacin del sistema?
Qu caso de uso crea, almacena, modifica, elimina o lee
informacin del sistema?
Existe algn actor que requiera informar al sistema de algn
cambio externo?
Algn actor necesita que el sistema lo informe de algn cambio
en l?
Qu casos de uso soportarn y mantendrn el sistema?
Todos los requerimientos funcionales son realizados por los casos
de uso.

Casos de Uso para un Sistema de Stock

Recepcin de mercadera
Dar de baja un item
Consulta sobre existencia

Mantener informacin de usuarios

Mantener informacin de proveedores
Mantener informacin de mercaderas

Sistema de Planificaci
n de Compras

Recepcionista
Recepcin de mercadera
Dar de Baja un Item

Sistema de
Facturacin
Consulta de Existencia
Vendedor

Mantener Informacin de Usuarios

Mantener Informacin de
Mercadera
Administrador de
Sistema

Mantiene Informacin de
Proveedores

30

RELACIONES ENTRE CASOS DE USO

Utiliza: Una relacin de este tipo entre casos de uso

significa que una instancia del caso de uso origen
incluye tambin el comportamiento del caso de uso
destino
B

<<utiliza>>

Extiende: Una relacin de este tipo entre casos de uso

significa que una instancia del caso de uso origen es
una extensin o variante del comportamiento
representado por el caso de uso destino
B

<<extiende>>

RELACIONES ENTRE CASOS DE USO

Cliente Remoto
Giro por Internet
<<Extiende>>

Colocar orden de venta

<<Utiliza>>

<<Utiliza>>

Giro

Cliente Local

<<Utiliza>>
Seguir orden

Validacin cliente

Validacin cliente
<<Utiliza>>

<<extiende>>
Despachar orden

Despachar orden parcialmente

31

DIAGRAMA DE SECUENCIA

Los Diagramas de Secuencia

representan explcitamente
la secuencia ordenada de interacciones (mediante el envo de
mensajes) descriptas en el Caso de Uso.
IDENTIFICACIN DE LAS CARACTERSTICAS DE LAS CLASES

Los Diagramas de Secuencia pueden ser empleados

para conocer las responsabilidades de las clases y
objetos.
Los Diagramas de Secuencia permiten identificar los
objetos e interacciones necesarias para brindar algn
servicio.

DIAGRAMA DE SECUENCIA
Un Diagrama de Interaccin (DI) o Secuencia se
compone de:
Un conjunto de objetos (clase o instancia).
Un conjunto de mensajes que comunican pares
de objetos.
Secuencias de comportamiento de los objetos.
Informacin de control (Condicional, Repeticin,
etc.)

32

DIAGRAMA DE SECUENCIA
Actividad: Controlar Temperatura
Objeto

Borde del sistema

Controlador

SensorT ValvulaVapor

Controlar Temperatura
entre 60 y 70 C
Obtener la Temperatura Actual.

obtenerT

Si T < 60 Luego
Abrir Vlvula de Vapor

Actividad
abrir
cerrar

Si T> 70 Luego
Cerrar Vlvula de Vapor

Descripcin de las
interacciones entre los
objetos, estructuras
condicionales, etc.

DIAGRAMA DE SECUENCIA
Actividad: Actualizar Ventana
Objeto

Borde del sistema

Ventana
El usuario elige del
men la opcin
Actualizar Ventana

rea de
mensaje

Men

actualizarVentana

rea
de
trabajo

Circulo

actualizar

Retngulo

Tiempo que
est activo un
mtodo

redibujar
limpiar

Descripcin de
las interacciones
entre los objetos

dibujar
dibujar
actualizar
actualizar

33

DIAGRAMA DE SECUENCIA

a
while X loop

Empleo
de
pseudocdigo
para representar
estructuras
de
control

Creacin de
instancias

mensaje 1

end loop

2: crear

If X
else
end if

mensaje 2

mensaje 3
destruir

Destruccin
de instancias

Preguntas que se deben realizar continuamente al

revisar un escenario

1. Qu objeto debe ser responsable de una accin

determinada?
2. Posee el objeto suficiente conocimiento para realizar la
accin, o debe delegar ese comportamiento a otro
objeto?
3. No se le estn asignando demasiadas acciones al
objeto?
4. Qu podra fallar?

34

Cmo se interpreta un Diagrama de Secuencia?

Las interacciones comienzan con la ocurrencia de
algn requerimiento externo al sistema.
Las interacciones se llevan a cabo a medida que los
objetos se envan mensajes.
El orden de las barras que representan a los objetos
es indistinto.
Si es necesario representar ms de una instancia de
una clase dada, pueden dibujarse una o ms barras,
segn resulte ms claro.

DIAGRAMA DE SECUENCIA
El eje temporal se mueve en forma descendente. No
es lineal sino controlado por eventos.

La barra (sobre la lnea de un objeto), que representa

a una secuencia de comportamientos, permite
identificar el conjunto de actividades que se llevan a
cabo como consecuencia de un evento dado.

A la izquierda de la Barra de Borde del Sistema, se

pueden documentar las actividades (en aquello casos
que sea necesario).

35

Cliente

Vendedor

Inventario

Responsable
Planificacin

Plan de
Produccin

Responsable
Manufactura

Producto

1: pedido
2: HayStock?
Si no hay
stock
suficiente

3: Requerimientos
4: Crear

5: Plan

6: Elaborar
7:

8: NuevoProducto

CASOS DE USO
DIAGRAMA DE SECUENCIA

Los Casos de Uso

constituyen una tcnica centrada en el usuario para
relevar los requerimientos del sistemas desde su
enfoque

son un medio apropiado de comunicacin con los

usuarios, ya que esencialmente se expresan en
lenguaje natural, que si bien se representan mediante
DI con el soporte de CASE, los mismos requieren
muy poca asistencia por parte de la CASE.

36

CASOS DE USO
DIAGRAMA DE SECUENCIA

Los Casos de Uso

son una herramienta adecuada para relevar la
manera en que se llevan a cabo las actividades.

facilitan la identificacin de los objetos de un dominio.

son de gran ayuda para manejar la complejidad de los

proyectos, ya que permiten descomponerlo en sus
principales funcionalidades, especificadas desde el
punto de vista del usuario.

CASOS DE USO
DIAGRAMA DE SECUENCIA
usualmente involucran la colaboracin de varias clases
y objetos, por lo cual contribuyen a descubrir y
proponer

los

mensajes

que

los

comunican.

Proveen una alternativa al enfoque tradicional en las

metodologas

orientadas

objetos,

que

ponen

demasiado nfasis en los aspectos estticos del

modelo (herencia, y estructuras de clases y objetos).

son una buena base para la verificacin de los

modelos de alto nivel de abstraccin.

37

DIAGRAMA DE SECUENCIA
Se origina de manera forward.

Puede ser empleado para verificar los requerimientos

de un sistema.

Tiene una naturaleza funcional.

No siempre se dispone de informacin acerca de la

manera en que deben interactuar un conjunto de
objetos para cumplir un objetivo.

CASOS DE USO
DIAGRAMA DE SECUENCIA
Precauciones:
Los Casos de Uso son de naturaleza Funcional,
por lo tanto, se debe ser cuidadoso en su empleo
en un proyecto que emplea el Modelo de Objetos.
El concepto clave a remarcar es que

Las Funciones no son Objetos

y
Los Objetos no son Funciones

38

PELIGROS EN EL EMPLEO DE CASOS DE USO

En general existe una relacin N-M entre Casos de
Usos y Clases-Objetos, ya que seguramente ocurrir
que:
1. Cada Caso de Uso emplea las caractersticas
de varios objetos y clases, y
2. Cada objeto y clase individual participa de
varios Casos de Uso
Por lo tanto cualquier descomposicin realizada en
base a Casos de Uso,distribuir Caractersticas de
Clases-Objetos, y las mismas Clases-Objetos en los
distintos Casos de Uso .

CASOS DE USO
Qu puede ocurrir con el empleo de Casos de Uso en un
proyecto ?
Si en el proyecto se asigna cada Caso de Uso a un
equipo de desarrolladores distinto, lo usual es que los
distintos equipos produzcan
varias veces la misma clase,
en forma redundante y
con variaciones parciales
Esto obviamente producir la consiguiente prdida de
productividad,

pues

el

proceso

de

integracin

de

resultados no ser trivial.

39

VISTA DE INTERACCIONES
Los objetos interactuan para implementar un comportamiento.
Esta interaccin se puede describir en dos formas
complementarias, focalizandose:
1. en una coleccin de objetos cooperantes - Colaboracin
2. en objetos individuales Mquinas de Estados
Una colaboracin tiene aspectos:

esttico (define el contexto del comportamiento)

de comportamiento (el conjunto de mensajes que se
intercambian los objetos - Interaccin)
Una Interaccin puede representarse con dos tipos de
diagramas:

de secuencia

de colaboracin

DIAGRAMA DE COLABORACIN
El Diagrama de Colaboracin modela los objetos y los enlaces
(links) que son significativos para una interaccin
determinada.
El Diagrama de Colaboracin muestra las interacciones entre
los objetos, representando adems las relaciones estructurales que
permiten la colaboracin del grupos de objetos.
: Ascensor
1: Subir

mensajes

: Cabina

links

2: Encender
: Luz

3: Cerrar
: Puerta

40

En el diagrama de colaboracin se muestan los enlaces

que representan instancias de las asociaciones, as como
los vnculos temporarios (representando argumentos de
mtodos, variables locales y referencias a s mismo).
Ascensor

componente

Cabina

es-instancia-de
iluminacin

parte

Luz

Puerta
1 : S u b ir

: A s c en s or

r1 : c om p o n e nte

3: C e rra r

: C a bina

: P ue rt a
t ra n si e n t

i1 : ilum ina c in2 : E n c e n de r

es-instancia-de

: L uz

DIAGRAMA DE COLABORACIN
Los objetos que participan pueden ser especificados a
travs de:
I Slo el nombre de la instancia
:C Slo el nombre de la clase
I:C Los nombres de la instancia y clase
Los enlaces se representan por lneas entre los objetos:
Los mensajes se representan a travs de flechas sobre el enlace.
Un mensaje se compone de:
Un nmero de secuencia
Un smbolo de sincronizacin
Una etiqueta que identifica al mensaje

41

Se trabaja sobre el SI de una biblioteca, en la cual se manejara

por separado el concepto de ttulo y los distintos ejemplares que
de un determinado ttulo existen en el inventario
Titulo

volumen

Ejemplar

crearEjemplar()

catalogo

Biblioteca

Libro
reserva

prestamo

prestamo

Usuario
inventario

Se desea representar la incorporacin de un nuevo ejemplar al

inventario de la biblioteca. Se utiliza un diagrama de
colaboracin para representar el caso de uso.

El empleado interactua con el SI, ingresando el nuevo
ejemplar.

Por razones de eficiencia se requiere que se pueda acceder
directamente a cada ejemplar, sin recurrir a ttulo.
2: crearEjemplar( )
1: Ingresar( )

: Libro
3: crear(Bibloteca)

:
Biblioteca
empleado :
actor
4: incorporarInventario(Ejemplar)

:
Ejemplar

42

En los diagramas de colaboracin es posible especificar el

tipo de link que vincula a los objetos en la colaboracin. Si se
trata de un link transitorio (argumento, variable local,
autoreferencia) o un link permanente (asocciacin).
Instancia
de
la
agregacin :catalogo

2: crearEjemplar( )

: Libro
F

1: Ingresar( )

3: crear( )

: catalogo
:
Biblioteca

4: iniciar(datos, Biblioteca)

: actor
L

5: incorporarInventario(Ejemplar)

:
Ejemplar

Indica de que forma :Ejemplar

ubica la identidad de :Biblioteca
<<parameter>>

Indica de que forma :Libro ubica

la identidad de :Ejemplar
<<local>>

:B

:A
P

cliente

6:

servidor

NOTACIN
SIGNIFICADO
<<parametro>> El servidor est asociado a un
parmetro del mtodo que se
P
est ejecutando en el cliente
<<local>>
El servidor est asociado a una
variable local del mtodo que se
L
est ejecutando en el cliente
El servidor est vinculado por
una asociacin al cliente
F

43

En el diagrama de colaboracin se puede especificar si durante

la ejecucin el objeto:

se crea {new}

se crea y destruye {transient}

se destruye {destroyed}
2: crearEjemplar( )

: Libro
F

1: Ingresar( )

3: crear( )

: catalogo
:
Biblioteca

4: iniciar(datos, Biblioteca)

: actor
L

5: incorporarInventario(Ejemplar)

:
Ejemplar

{new}

El objeto :Ejemplar no exista cuando comenzaba la colaboracin,

y se crea durante la misma

Diagramas de Secuencia y de Colaboracin

Ambos diagramas muestran interacciones, aunque enfatizan
aspectos diferentes.
Los Diagramas de Cola2: crearEjemplar( )

: Libro

libro :

3: crear( )

:
Biblioteca P

4: incorporarInventario(Ejemplar)

1: Ingresar( )

{new}

: actor

: actor

:
Ejemplar

: Biblioteca

: Ejemplar

: Libro

1: Ingresar( )
2: crearEjemplar( )
3: crear( )
4: incorporarInventario(Ejemplar)

boracin muestran explcitamente las relaciones

entre los objetos, y la
secuencia temporal debe
ser inducida a partir de la
numeracin
de
los
mensajes.
Los Diagramas de Secuencia
muestran
claramente
la
secuencia temporal y aunque
no las relaciones entre los
objetos.

44