Guía Visual: Josep Vilalta

UML
Gu a Vi sual
C m o c r e a r
f o r m a s d e v i d a
o r g a n i z a t i v a
Vi l a l t a Co n s u l t o r e s 2 0 0 1
i nf o @v i c o . o r g
Re v. 0.17
Josep Vi l al t a
v
i
c
o
.
o
r
g
Proyecto: Presentacin del borrador: UML Gua Visual
Documento: UML Gua Visual
Historial: 03/09/01 9:03
Situacin: Borrador en curso de revisin
Proceso: Evaluacin de contenidos ref.- contacto: jvilalta@vico.org
Autor: Josep Vilalta

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual
Presentacin.doc Equipo: www.vico.org
Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
1 de 9

UML
Gua Visual
Cmo crear formas de vida organizativa

Presentacin
Esta gua describe como definir, organizar y visualizar lo que denominamos formas de
vida organizativa (VIO) con la notacin Unified Modelling Language (UML). Una VIO
representa un ciclo de actividad realizado por uno o varios agentes con un propsito
concreto, en base a una prctica consensuada para utilizar los recursos disponibles y
para tomar las decisiones que caracterizan el comportamiento de una organizacin.

A diferencia de los sistemas biolgicos, las VIO nacen y se desarrollan a partir de una
voluntad compartida, de una idea y de un liderazgo. Pero de la misma manera que la
seleccin natural acta en los sistemas biolgicos, la continuidad de una VIO est
condicionada a la implementacin eficiente de sus procesos esenciales. Conocer estos
procesos, saber como aplicar los recursos y como tomar las decisiones para satisacer la
cadena de valor de todos los agentes son los factores que toda organizacin ha de tener
en cuenta para evolucionar y asegurar su viabilidad.

La notacin UML (no hay que confundir con las metodologas que utilizan dicha
notacin), se ha convertido desde finales de los 90 en un estndar para modelar con
tecnologa orientada a objetos todos aquellos elementos que configuran la arquitectura
de un sistema de informacin y, por extensin, de los procesos de negocio de una
organizacin. De la misma manera que los planos de un arquitecto disponen el esquema
director a partir del cual levantamos un edificio, los diagramas UML suministran un
modelo de referencia para formalizar los procesos, reglas de negocio, objetos y
componentes de una organizacin. La interaccin de todos estos elementos es una
representacin de nuestra realidad.

v
i
c
o
.
o
r
g
Historial: 03/09/01 9:03

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
2 de 9

Nuestros lmites para entender esta realidad estn en nuestro lenguaje. El mundo es la
suma total de lo que podemos definir, organizar y visualizar. Cabe preguntarse de qu
manera un modelo en UML representa nuestra experiencia?. Ensear a utilizar un
lenguaje formal siempre es problemtico. Es necesario mostrar como este lenguaje
puede ser aplicado a la realidad tal como la conocemos y tal como la compartimos con
los dems. Con esta gua visual mostramos de manera precisa las tcnicas bsicas para
usar UML en diferentes contextos. La clave est en discriminar cuales son aquellos
procedimientos esenciales que nos permiten evitar costosas confusiones conceptuales.
No es mediante el descubrimiento de nuevos objetos y de sus mltiples conexiones que
avanzamos en las respuestas a nuestros interrogantes cuando modelamos un dominio,
sino mediante la disolucin de las contradicciones que existen entre los trminos
(conceptos) ya conocidos y, en ltimo caso, mediante la reduccin de su nmero
despejando aquellos conceptos que no aaden valor a la comprensin de dicho dominio.
Reconsiderar lo obvio, desenmascarar presunciones, desambigar conceptos conocidos,
todo en busca de la simplicidad y la usabilidad.

La tecnologa orientada a objetos persigue el antiguo principio del divide y vencers. Su
objetivo es descomponer la complejidad en partes ms manejables y comprensibles. No
parece que esto sea algo novedoso con respecto a la tradicional descomposicin
funcional de los mtodos estructurados. Sin embargo, la gran diferencia reside en
aplicar la dualidad estructura-funcin en pequeas unidades capaces de comunicarse y
reaccionar en base a la aparicin de una serie de eventos. El esquema dominante de la
separacin de estructuras de datos y funciones (bases de datos y programas) est
amenazado pero an se resiste a desaparecer.

v
i
c
o
.
o
r
g
Historial: 03/09/01 9:03

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
3 de 9

Mucha gente cree que la principal utilidad de la orientacin a objetos es la reutilizacin
del cdigo para conseguir un desarrollo ms rpido de las aplicaciones (Rapid
Application Development). No comparto esta opinion. Si hay algo que caracteriza un
entorno de desarrollo actual es la constante del cambio. Todo proyecto que sobrepase
los tres meses est amenazado por la aparicin de nuevas plataformas ms exigentes, la
extincin de herramientas sin previo aviso y, de manera sistemtica, por la rotacin del
personal crtico encargado del proyecto. Tambin est sometido, como no, a los
cambios de requerimientos del cliente que a su vez estn plenamente justificados por la
readaptacin de sus procesos de negocio a un mercado inestable.

Ante este cuadro de incertidumbre, el mayor desafio de una metodologa de desarrollo
es su adaptacin para el cambio. Esto significa crear modelos que faciliten la
comunicacin entre todos los agentes involucrados en el sistema en construccin; que
hagan visible la trazabilidad entre la concepcin de los componentes, su especificacin,
implementacin e instalacin; significa el diseo de arquitecturas que faciliten la
gestin de las dependencias entre estos componentes, que sean en fin, facilmente
reemplazables por otros ms optimizados o bien por componentes que aporten una
mayor funcionalidad y/o facilidad de uso.

La dinmica de cambio no se desarrolla en la ingeniera del software con la misma
velocidad vertiginosa con que nos tiene acostumbrados la tecnologa del hardware. La
clave reside en que a diferencia de la electrnica, en los dominios del desarrollo de
software no existe un vocabulario unificado. Desde la fase de concepcin de un sistema
a la instalacin de sus componentes hay que mapear entre s una gran diversidad de
lenguajes orientados al anlisis, diseo, cdigo ejecutable, esquemas de bases de datos,
componentes de pginas web, entre otros. Esta distancia entre la concepcin y la
usabilidad de un producto o de un proceso de negocio, exige cada vez ms la capacidad
de cooperacin y comunicacin de un equipo interdisciplinar muy especializado. Esta
gua visual de UML est pensada para facilitar este proceso cooperativo y para ayudar a
establecer una buena prctica fundamentada en un lenguaje comn.

v
i
c
o
.
o
r
g
Historial: 03/09/01 9:03

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
4 de 9

A quin va dirigida esta gua visual?
Esta gua ha sido escrita y diseada para los profesionales involucrados en todos los
ciclos de actividad del desarrollo de sistemas de informacin (concepcin, anlisis y
diseo, implementacin, instalacin de aplicaciones, gestin y certificacin de
proyectos); tambin para los que tengan responsabilidades en la especificacin de
procesos de negocio con el propsito de evaluar posibles reingenieras de procesos y/o
diseo de bases de conocimiento; y finalmente, para aquellos equipos que estn
inmersos en la preparacin e implementacin de certificaciones de calidad.

La claridad conceptual y los recursos didcticos utilizados en la exposicin de los
distintos procedimientos sern de utilidad para los estudiantes que sigan programas de
autoaprendizaje y usen esta gua como complemento para sus lecturas de libros sobre
UML. Tambin los centros acadmicos y profesores dispondrn con esta gua de
material interesante para completar sus diseos curriculares y proporcionar ejemplos
prcticos a sus alumnos.

Cmo sacar un mayor provecho a su lectura?
La gua est organizada en unidades didcticas que describen la notacin de los
diagramas y las fuentes de informacin necesarias para definir los elementos de cada
modelo. Puede usarse como consulta puntual de la notacin de un diagrama, o bien,
para revisar como establecer el hilo conductor entre los Casos de Uso (mapa funcional),
las Clases de dominio (mapa conceptual), las Clases de Especifiacin (types e
interfaces) y las Clases de Implementacin (cdigo).

v
i
c
o
.
o
r
g
Historial: 03/09/01 9:03

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
5 de 9

Un plan de estudio para realizar una progresiva asimilacin de los conceptos podra
empezar con los Casos de Uso (CU) y continuar con el anlisis de los flujos de trabajo
de un grupo de CU mediante los diagramas de Actividad; a continuacin, separar los
escenarios que agrupan una serie de actividades y hacer aflorar, a travs de los
diagramas de Interaccin, los objetos que intercambian una serie de mensajes. A partir
de este punto, disponemos del bagaje suficiente como para introducirnos en la
abstraccin de los objetos y comprender la importancia de separar las tres perspectivas
bsicas en nuestra representacin de las clases: concepcin, especificacin e
implementacin. El siguiente paso es identificar alguna clase con un comportamiento
complejo que la haga candidata a revisar todos sus posibles estados y averiguar que
eventos son capaces de provocar un cambio de estado. El diagrama de Estados-
Transicin ser el adecuado para representar esta dinmica de estados. Finalmente,
abordaremos la configuracin de componentes y su despliegue en una arquitectura.

Otra lectura de la gua puede estar mas centrada en el seguimiento de la metodologa de
desarrollo y la gestin de un proyecto. En este caso, las primeras secciones describen
los niveles de concepcin y formalizacin de un proyecto con la metodologa TRAD
(Taller de Requerimientos, Anlisis y Diseo basado en el Proceso Unificado de
Rational), y se van introduciendo progresivamente los diagramas y actividades que
configuran la unidad mnima de documentacin sostenible para un proyecto concreto.

El estudiante ms avanzado podr sacar tambin provecho con la consulta puntual de
los diagramas en que est ms interesado y la revisin de sus extensiones. Las materias
expuestas en las distintas secciones estn actualizadas constantemente y pueden
descargarse nuevas ediciones desde: http://www.vico.org/UMLguiavisual/

v
i
c
o
.
o
r
g
Historial: 03/09/01 9:03

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
6 de 9

De dnde provienen las ideas expuestas?
El contenido de esta gua ha sido elaborado a partir del trabajo de una serie de
profesionales que el autor ha tenido la oportunidad de estudiar y aplicar en distintos
proyectos. Desde principios de los 90, los artculos publicados en el J ournal of Object
Oriented Programming (JOOP) por James Odell, James Rumbaugh, Grady Booch,
Desmond dSouza, Bertrand Meyer, Steve Cook, John Daniels, Sally Shlaer y
Stephen J. Mellor entre otros, han sido una constante fuente de conocimiento.
Publicaciones pioneras como el Object Oriented Technology, A Managers Guide de
David A. Taylor, en su primera edicin de 1990 y en la segunda ampliada de 1998, han
tenido una gran influencia en como abordar la presentacin didctica. Tambin los
libros de Peter Coad et al, Object Oriented Analysis, Design and Programming, Object
Models y Java Modeling Color with UML, han sido de una ayuda extraordinaria. La
obra enciclopdica The Unified Modeling Language: Reference Manual de Rumbaugh
& Jacobson & Booch, es un punto de referencia constante. Sin duda, uno de los autores
ms influyentes ha sido Martin Fowler. Su primer libro Analysis Patterns continua
siendo una referencia clave. Posteriormente, la primera edicin de UML Distilled en
1997 y su ltima edicin ampliada en 2000, se ha convertido en el libro de cabecera de
UML. Otro clsico por la excelencia de su trabajo es Applying UML and Patterns de
Craig Larman que en su segunda edicin aparecida en verano de 2001 se ha superado
a si mismo. Tambin recientes y con muy buen material que ha sido incorporado a la
gua, tenemos los libros de Wendy & Michael Boggs, Mastering UML with Rational
Rose, de Alistair Cockburn, Writing Effective Use Cases; de Scott W. Ambler, The
Object Primer segunda edicin; y de John Chessman & John Daniels, UML
Components, una de las novedades ms interesantes de 2001. En la bibliografa sobre
UML publicada en http://www.vico.org hay una relacin completa de los libros
consultados que se actualiza peridicamente con las ltimas novedades.

v
i
c
o
.
o
r
g
Historial: 03/09/01 9:03

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
7 de 9

Competencia y actuacin
En los ltimos veinte aos de mi carrera profesional en el desarrollo de sistemas de
informacin he participado en una gran diversidad de proyectos con distintos grados de
responsabilidad e involucracin, pero siempre con un compromiso firme en la calidad y
usabilidad del producto final.

Entorno industrial
o CIM para la extrusin de polietileno y fabricacin de mallas agrcolas y
de embalaje.
o CIM para el fraccionamiento de hemoderivados
o Plan Funcional para la implementacin SAP-Logstica

Entorno sanitario
o Gestin de Bancos de Sangre y Hemoterapia
o Planificacin y gestin de campaas de captacin de donantes
o Gestin mutual de prestaciones asistenciales
o Tarjeta Sanitaria para certificar transacciones asistenciales
o Automatizacin de autoanalizadores de laboratorios de anlisis
o Integracin de peticiones analticas multicentricas y publicacin de
resultados
o Gestin de laboratorios farmacuticos
o Historia Clnica Orientada por Problemas Automatizada
o Libreta de Salud para programacin de citas y exploraciones
o Gestin integrada de servicios de Atencin Primaria
o Plan Funcional para la implementacin SAP-Gestin Clnica y
Asistencial

v
i
c
o
.
o
r
g
Historial: 03/09/01 9:03

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
8 de 9

Entorno de ingeniera del software
o Framework de clases de anlisis para definir mapas conceptuales
o Framework de servicios comunes para la publicacin dinmica de
pginas HTML
o Framework de certificacin de entregables

Entorno administrativo y de gestin
o Plan Funcional para la implementacin SAP-Contabilidad
o Cuadro de control de indicadores de actividad y calidad
o Sistema de informacin Ejecutivo

Entorno comercial
o Merchandising de productos farmacuticos
o Subastas y liquidacin de lotes
o Gestin de redes de puntos de venta con videoconferencia

Entorno de servicios
o Auditoras Informticas
o Plan de Sistemas de Informacin
o Integracin de sistemas de informacin de contabilidad administrativa y
general

Entorno acadmico
o Programa de acceso a la universidad para mayores de 25 aos
o Gestin de ttulos universitarios
o Estudios de tercer cliclo: diseo curricular, publicacin y gestin
acadmica

v
i
c
o
.
o
r
g
Historial: 03/09/01 9:03

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
9 de 9

Entorno docente
o Tutoras de proyectos de fin de carrera con UML
o Cursos de Anlisis, Diseo y Patrones
o Talleres de introduccin a UML
o Talleres avanzados de UML con Rose y Visio
o Talleres monogrficos (Casos de Uso, Mtrica, Metodologa)

Entorno de I+D
o Bases de conocimiento con vocabularios controlados
o Procesador de lenguaje natural dentro del dominio mdico
o Reconocimiento automtico de conceptos clnicos a partir de textos no
estructurados

Agradecimientos
En primer lugar a los clientes que con su confianza han permitido que pueda desarrollar
mi carrera profesional. Tambin a los autores antes mencionados por su valioso trabajo
en el avance de la disciplina de la ingeniera del software y en la consolidacin de UML
como lingua franca.

J osep Vilalta
Badalona, Barcelona (Espaa)
jvilalta@vico.org
http://www.vico.org

Niveles de concepcin y formalizacin
de un proyecto
Nivel
Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5
Procesos
Pri nci pal es
Gl osari o
de Conceptos
Matr cul a
del Proyecto
Code l i ke hel l
Especi fi caci n
Casos de Uso
Fl uj os
de Trabaj o
C
d
i
g
o
Di nmi ca
Eventos - Estados
Cronograma
Pl an Di rector
I teraci ones
Funci onal i dad
Di agramas de
Casos de Uso
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Act or
Act or
Cl ases
Anl i si s
Di seo
I mpl ement aci n
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Verificando Sirviendo
Entregado Esperando
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
[Todos los items comprobados &&
todos los items disponibles]
Item Recibido
[Todos los items disponibles]
Entregado rimer item
rimer item
rimer item
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
Entregado Esperando
P
M
* [para cada pedido seleccionado]
Entrar
Reposicin
Seleccionar
Pedidos
Pendientes
Asignar
Items
Regularizar
Stock
Activar
Pedido
Entrar
Reposicin
Entrar
Reposicin
Activar
Pedido
Regularizar
Stock
Asignar
Items
Entrar
Pedido
Validar
Pago
Seleccionar
Pedidos
Validar
Riesgo
P
PDI
G
CU
CU
Escenari os
I nteracci n
de obj etos
tieneStock:= comprobar ( )
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido Un pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stock xxx lnea : Lnea de pedido
: Item de Expedicin : Item de Pedido de reposicin
tieneStock:( )
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido Un pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
: Pedido
1

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

U
M
D
_
e
s
p

-

R
e
v
.

5
.
2

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Esfuer zo de desar rol l o
P DP
Producto Procesos
Actividades
Entregables
Tiempo
Fases
I teraciones
Mi si n
Concepci n Formali zaci n Construcci n Transi ci n
I t er aci ones
I teraci ones
prel i mi nares I ter #1 I ter #2 I ter #n
I ter
#n+1
I ter #n
I ter
#n+2
I ter
#n+1
Mo del o
C o mpo nent es
C er t i f i c ac i n
P r o t o t i po

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
0

-

T
R
A
D

P
D
P

i
t
e
r
a
c
i
o
n
e
s
_
e
s
p

-

R
e
v
.

4
.
2

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
2

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

P
D
P

m
i
s
i
n
_
e
s
p
2

-

R
e
v
.

5
.
2

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Mi si n
I t er aci ones
I teraci ones
I ter
#n+1 I ter #n
I ter
#n+2
I ter
#n+1
Mo del o
C o mpo nent es
P r o t o t i po
Pl an Di rector de Proyecto
P DP
Concepci n
Anteproyecto
Patrones de
Anl i si s
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
P
Patrones de
Funci onal i dad
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
Act or 2
Act or 1
<<Extiende >>
<<Incluye>>
Use Case
Use Case
Use Case
Use Case
Use Case
<<Incluye>>
<<Generalizacin>>
P
Procesos
pri nci pal es
Matr cul a
del proyecto
Gl osari o
de Conceptos
Cronograma
Pl an Di rector
I teraci ones
P
M
P
PDI
G
Mi si n
3

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

P
D
P

m
o
d
e
l
o
_
e
s
p
2

-

R
e
v
.

5
.
3

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Mi si n
I t er aci ones
I teraci ones
I ter
#n+1 I ter #n
I ter
#n+2
I ter
#n+1
Mo del o
C o mpo nent es
P r o t o t i po
P DP
F or mal i zaci n
Patrones de
Anl i si s
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
P
Patrones de
Funci onal i dad
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
Act or 2
Act or 1
<<Extiende >>
<<Incluye>>
Use Case
Use Case
Use Case
Use Case
Use Case
<<Incluye>>
<<Generalizacin>>
P
Model o
Funci onal i dad
Di agramas de
Casos de Uso
Cl ases
Anl i si s
y Di seo
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Act or
Act or
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Especi fi caci n
Casos de Uso
Fl uj os de
Trabaj o
Di nmi ca
Eventos
Estados
Entregado Esperando
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
Entregado Esperando
CU
Entrar
Reposicin
Seleccionar
Pedidos
Pendientes
Asignar
Items
Regularizar
Stock
Activar
Pedido
Entrar
Reposicin
Entrar
Reposicin
Activar
Pedido
Regularizar
Stock
Asignar
Items
Entrar
Pedido
Validar
Pago
Seleccionar
Pedidos
Validar
Riesgo
Escenari os
I nteracci n
de obj etos
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido Un pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
: Pedido
tieneStock:( )
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido Un pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
: Pedido
4

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

P
D
P

c
o
n
s
t
r
u
c
c
i
n
_
e
s
p
2

-

R
e
v
.

5
.
3

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Mi si n
I t er aci ones
I teraci ones
I ter
#n+1 I ter #n
I ter
#n+2
I ter
#n+1
Mo del o
C o mpo nent es
P r o t o t i po
P DP
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Alumno P. Global P. Esp. Resultado Seleccin Ver
Destino
Versin
Tribunal
Ao Acadmico *
**
Fecha Acta
Alumnos
Framework
de Apl i caci ones
Patrones de
Di seo
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
P
Const r ucci n
Destino
Versin
Tribunal
Ao Acadmico *
**
Fecha Acta
Alumnos
Cl ases
Di seo
I mpl ement aci n
Base de Datos
Esquema de Persi stenci a
Arqui tectura
Componentes
I nterface
Grfi co de Usuari o
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Componentes
5

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

P
D
P
_
e
s
p
2

-

R
e
v
.

6
.
2

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
F or mal i zaci n
Mi si n
I t er aci ones
I teraci ones
I ter
#n+1 I ter #n
I ter
#n+2
I ter
#n+1
Mo del o
C o mpo nent es
P r o t o t i po
P DP
Model o
Funci onal i dad
Di agramas de
Casos de Uso
Cl ases
Anl i si s
y Di seo
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Act or
Act or
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Especi fi caci n
Casos de Uso
Fl uj os de
Trabaj o
Di nmi ca
Eventos
Estados
Entregado Esperando
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
Entregado Esperando
CU
Entrar
Reposicin
Seleccionar
Pedidos
Pendientes
Asignar
Items
Regularizar
Stock
Activar
Pedido
Entrar
Reposicin
Entrar
Reposicin
Activar
Pedido
Regularizar
Stock
Asignar
Items
Entrar
Pedido
Validar
Pago
Seleccionar
Pedidos
Validar
Riesgo
Concepci n
Anteproyecto
Procesos
pri nci pal es
Matr cul a
del proyecto
Gl osari o
de Conceptos
Cronograma
Pl an Di rector
I teraci ones
P
M
P
PDI
G
Mi si n
Const r ucci n
Destino
Versin
Tribunal
Ao Acadmico *
**
Fecha Acta
Alumnos
Cl ases
Di seo
I mpl ement aci n
Base de Datos
Esquema de Persi stenci a
Arqui tectura
Componentes
I nterface
Grfi co de Usuari o
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Componentes
Escenari os
I nteracci n
de obj etos
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido Un pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
: Pedido
tieneStock:( )
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido Un pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
: Pedido
6
A la bsqueda de Actores.-
1. Quien est interesado en un requerimiento concreto ?
2. En qu dominios de la organizacin se usar el sistema ?
3. Quien ser beneficiario de la nueva funcionalidad ?
4. Quien proveer, usar y/o retirar, informacin ?
5. Quien dar soporte y administrar el sistema ?
6. Usar el sistema un recurso externo ?
7. Un usuario actuar con diferentes roles ?
8. Diferentes usuarios actuarn con un mismo rol ?
9. I nteraccionar el nuevo sistema con un sistema antiguo ?
Cmo identificar Actores ?
Si st ema en pr oceso de model ado
I nteraccin de un
Actor con el Sistema
I nteraccin del
Sistema con un Actor
Cl i ent e
- Rol e de usuar i o -
Actores
Representan a un agentequeinteracta con el sistema
No son partedel sistema quesedesarrolla
Entran informacin al sistema
Reciben informacin del sistema
Entran y reciben informacin
Relacin que indica la
especializacin a partir de una
funcin genrica
Real i zar una
t r ansacci n
Usar Caj ero
Aut omt i co
<< Incluye >>
Subsi st ema
de cuent as
cl i ent e
- Rol e de subsi st ema -
Subsi t ema
de cer t i f i caci n
de medi os
de pago
- Rol e de subsi st ema -
Ac t i va r
Ta r j e t a
Re t i r a r
Ef e c t i vo
Cons ul t a r
Movi mi e nt os
<<Generaliza>>
<<Generaliza>>
<<Generaliza>>
Funci onal i dad
Di agramas de
Casos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Act or
Act or
1

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
c
t
o
r
e
s
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
A la bsqueda de Casos de Uso.-
1. Cuales son las tareas y responsabilidades de cada actor ?
2. Algn actor crear, almacenar, cambiar, borrar o leer informacin del sistema ?
3. Qu Casos de Uso crearn, almacenarn, cambiarn, borrarn o leern esta informacin ?
4. Es necesario que un Actor informe al sistema sobre cambios externos ?
5. Es necesario que un Actor sea informado sobre ciertas incidencias del sistema ?
6. Qu Casos de Uso darn soporte y mantendrn el sistema ?
7. Pueden ser realizados por los Casos de Uso todos los requerimientos funcionales documentados ?
Cmo identificar Casos de Uso ?
Abri r Arqueo
Hacer un
I ni ci o de D a
Hacer un
Fi n de D a
Expor t ar
movi mi ent os
Piezas de funcionalidad del sistema
que suministran valor a un Actor y son
reutilizables en diferentes procesos
Relacin que describe una variacin
posible del comportamiento normal
de un Use Case
Relacin que permite descomponer
un Use Case con un determinado
nivel de granularidad
I mpr i mi r
document o
Si st ema en pr oceso de model ado
I nteraccin de un
Actor con el Sistema
I nteraccin del
Sistema con un Actor
Super vi sor
- Rol de usuar i o -
Importar nueva
configuracin
Cont abi l i dad
- Si st ema ext er no -
Caj er o
- Rol de usuar i o -
Cerrar Arqueo
<< Incluye >>
<< Extiende >>
<< Incluye >>
<< Incluye >>
<< Extiende >>
Relacin que indica el uso de
una funcionalidad compartida
por otros Casos de Uso
Funci onal i dad
Di agramas de
Casos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Act or
Act or
2

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

U
C
s
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Especificacin
de un Caso de Uso
L
I
M
I
T
Lmites: Cuando empieza y cmo termina el Caso de Uso.
I nteracciones: Comportamiento de Actores y Sistema.
Accin-Reaccin dentro del Caso de Uso.
Masa: Conjunto de Objetos e I nterfaces que requiere
el Caso de Uso.
ndice de escenarios: Flujo principal de eventos y secuencia
de variaciones posibles dentro de un Caso de Uso.
Tribulaciones: Contingencias probables que pueden afectar
al flujo de los eventos y son excepciones del Caso de Uso.
Propsito
- Regla de Negocio - Precondiciones Activacin Flujo Principal Variaciones Excepciones
Cerrar un periodo de
movimientos de caja
para obtener una
situacin real de dinero
en efectivo y en
documentos.
Arqueo abierto
Actor habilitado
TPV abierto
TPV habilitado
A discrecin de un Actor
habilitado
1. Sistema r equier e confir macin de
cier r e de arqueo.
a. Si Actor decide apar car el cierre de arqueo,
sistema activa UC Aparca_arqueo y termina
el UC.
2. Sistema compr ueba la configur acin
de TPV para identificar tipo de cierre.
3. Sistema calcula los totales ter icos
para cada forma de cobro.
4. Actor introduce totales reales para cada
forma de cobro.
5. Sistema r egistr a el cier r e: importes
reales para cada forma de cobro y
descuadres.
6. Sistema impr ime el documento Tira
de Arqueo.
a. Cierre de ar queo de tipo abier to:
Actor decide el momento de imprimir el
documento Tira de Arqueo.
a. Si el servidor est off-line, sistema infor ma
al usuar io, termina el UC manteniendo el
arqueo abierto.
b. Cierre de ar queo de tipo ciego:
Sistema no muestra los totales tericos para
cada forma de cobro.
a. Si impresora est off-line, sistema infor ma
al usuar io y le pide confir macin para
continuar.
Hacer un
Fi n de D a
I mpr i mi r
document o
Cerrar Arqueo << Extiende >>
<< Incluye >>
Caso de Uso principal
Casos de Uso secundarios
Caso de Uso especializado Caso de Uso genrico
<<Generaliza>>
I mpr i mi r
t i r a de ar queo
Funci onal i dad
Di agramas de
Casos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Act or
Act or
3

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

L
I
M
I
T

U
C
s
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Ventajas del modelo
Use Case
Piezas de funcionalidad reutilizables
en diferentes procesos de negocio
1. Lenguaje de comunicacin entre usuarios
y desarrolladores.
2. Comprensin detallada de la funcionalidad
del sistema.
3. Acotacin precisa de las habilitaciones de
los usuarios.
4. Gestin de riesgo ms eficiente para
gobernar la complejidad.
5. Estimacin ms exacta para determinar
tiempo, recursos y prioridades en la dosificacin
de esfuerzo de desarrollo.
6. Fiel trazabilidad para verificar la traduccin
de requerimientos en cdigo ejecutable.
7. Mayor control para mantener las sucesivas
revisiones de los programas.
8. Certificacin contractual Cliente-
Desarrollador.
9. Documentacin orientada al usuario: Helps
- Manual de Procedimientos - Reglas de Negocio.
10. Documentacin orientada al administrador
del sistema: Soporte de Mantenimiento.
Hacer un
Ini ci o de D a
Expor t ar
movi mi ent os
I mpr i mi r
document o
Importar nueva
configuracin
Cer r ar Ar queo
<< Incluye >>
<< Extiende >>
<< Extiende >>
<< Incluye >>
<<Generaliza>>
Hacer un
Fi n de D a
<< Incluye >>
I mpr i mi r
t i r a de ar queo
Abr i r Ar queo
Funci onal i dad
Di agramas de
Casos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Act or
Act or
4

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

m
o
d
e
l
o

U
C
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Requerimientos y Casos de Uso
Los Casos de Uso son requerimientos funcionales que describen
de una manera detallada el comportamiento del sistema con
los distintos Actores que interactan con l.
No definen todos los requerimientos (por ej. los tipos de
datos, interfaces externas, niveles de rendimiento esperado,
etc.), pero representan el hilo conductor que vincula a todos
los requerimientos posibles (actuales y futuros) de una
aplicacin.
Caso de Uso
R
e
q
u
e
rimie
n
t
o
s
M
o
d
e
l
o
A
r
q
u
i
t
e
c
t
u
r
a
G
e
s
t
i
n
d
e
P
r
o
y
e
c
t
o
C
e
r
t
i
f
i
c
a
c
i
n
Reglas
de Negocio
y protocolos de
intercambio de
informacin
Funcionales,
no funcionales
e interfaces de
usuario
Mapa conceptual:
Clases de anlisis
Dinmica de
Clases complejas
Mapa funcional:
Flujos de trabajo
principales y
variaciones
Escenarios de
interaccin
de objetos:
Clases de diseo
Mtrica:
Escandallo de
recursos
y actividades
Plan Director
de I teraciones:
Cronograma
y prioridades
Funcionalidad,
Anlisis y Diseo
I mplementacin
de cdigo y
Refactoring
Funci onal i dad
Di agramas de
Casos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Act or
Act or
5

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

R
e
q

y

C
U
s
_
e
s
p

-

R
e
v
.

1
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
de un Flujo de Trabajo
Un flujo de trabajo muestra la secuencia de actividades
que se desarrollan dentro de uno o varios Casos de
Uso, como una pieza de funcionalidad concreta que
satisface los requerimientos de un Actor.
Diagrama de Actividad
Notacin UML 1.3
* [para cada lnea de pedido]
Concurrencia dinmica de actividades
Recepcin
de un
Pedido
[SI vigente]
[NO]
Barra de sincronizacin
Actividad
Punto de decisin
Barra de fusin
Condicin lgica: verdadera o falsa,
que permite la transicin
a otra actividad
Evento que
desencadena
la secuencia de
actividades
Anlisis textual
del Caso de Uso
Fl uj o Pr i nci pal Var i aci ones
2. Usuario entra lineas de pedido, con su
cdigo de artculo, tipo de presentacin
y cantidad.
b. SI existen suficientes items del artculo en
el stock, sistema asigna items al pedido.
3. Sistema compr ueba cada lnea del
pedido para validar la situacin del
artculo en catlogo y el nmero de
items del artculo en stock.
4. Sistema compr ueba la situacin del
pedido .
a. SI se ha realizado el pago y SI todos los items
del pedido han sido asignados, sistema
informa que procede a ser vir el pedido
activando el CU Servir pedido.
b. SI se ha realizado el pago y NO existen
suficientes items del artculo en stock, sistema
aparca el pedido del cliente activando el CU
Aparcar pedido.
c. SI no se ha realizado el pago segn el plazo
convenido, sistema cancela el pedido.
CU Realizar pedido
1. Usuario identifica el cliente que ha
enviado un pedido.
c. NO existen suficientes items del artculo en
stock, o la asignacin de items deja la
situacin del artculo en stock por debajo del
nivel de reposicin, sistema gener a pedido
de r eposicin activando el CU Generar
pedido.
a. Artculo NO est vigente en catlogo, sistema
informa que ar ticulo no est vigente y
muestra artculos alternativos activando el
CU Seleccionar artculo.
[NO vigente]
[NO Stock] o
[SI umbral reposicin]
[SI]
[Todos los items asignados] [Faltan items por asignar]
Cancelar
Pedido
Identificar
Cliente
Entrar
lneas pedido
Comprobar
Artculo
Comprobar
Pago
Servir
Pedido
Generar
reposicin
Seleccionar
Artculo alternativo
Asignar
Items
Comprobar
situacin Pedido
Aparcar
Pedido
Fl uj os de
Trabaj o
Activar
Pedido
Regularizar
Stock
Asignar
Items
Entrar
Pedido
Validar
Pago
Seleccionar
Pedidos
Validar
Riesgo
1

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
c
t
i
v
i
d
a
d

1
_
e
s
p

-

R
e
v
.

7
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
Notacin UML 1.3
* [para cada pedido
seleccionado]
Recepcin
de una
Reposicin
[Todos los items asignados] [Todos las reposiciones entradas]
Fl uj o Pr i nci pal
1. Usuario r ecepciona albar anes de
reposicin que ha enviado un proveedor.
2. Sistema localiza los pedidos de clientes
aparcados que pueden cumplimentarse
con la nueva entrada de items.
3. Usuario selecciona los pedidos de
clientes aparcados que decide
cumplimentar.
4. Sistema asigna los items pendientes a
los pedidos de cliente seleccionados.
5. Sistema informa que procede a ser vir
el pedido activando el CU Servir
pedido..
6. Sistema regulariza la situacin de items
en stock y revisa los umbrales de
reposicin automtica.
Una diagrama de actividad describe una secuencia de
actividades que pueden exhibir un comportamiento en
paralelo o estar sujetas a condiciones lgicas.
Los procesos de negocio no muestran siempre una secuencia
fija en su desarrollo, es una ventaja as poder modelar
bloques de actividades sin restricciones de concurrencia.
Transicin de una actividad a otra sujeta
a una condicin lgica.
Sincronizacin de actividades que
pueden ocurrir en paralelo.
CU Actualizar reposicin
Servir
Pedido
Seleccionar
Pedido
Asignar
Items
Fin de la secuencia de
actividades
Anlisis textual
del Caso de Uso
Entrar
Reposicin
Buscar
Pedidos aparcados
Regularizar
Stock
Fl uj os de
Trabaj o
Activar
Pedido
Regularizar
Stock
Asignar
Items
Entrar
Pedido
Validar
Pago
Seleccionar
Pedidos
Validar
Riesgo
2

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
c
t
i
v
i
d
a
d

2
_
e
s
p

-

R
e
v
.

5
.
2

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
Notacin UML 1.3
Un diagrama de actividad puede mostrar la secuencia de
actividades que se desarrolla en un paquete de Casos de
Uso que define un proceso de negocio y sus reas de
responsabilidad.
[SI xito]
[NO xito]
Contabilidad Comercial Almacn
Lneas para acotar
reas de responsabilidad
(swim-lines)
Recepcin
de un
Pedido
Identificar
Cliente
Entrar
lneas pedido
Comprobar
Pago
Cancelar
Pedido
[NO Stock]
o [SI umbral reposicin]
Generar
reposicin
Entrar
Reposicin
[Recepcin de Reposicin]
[SI vigente]
[NO vigente]
Seleccionar
Artculo alternativo
[Todos los items asignados] [Faltan items por asignar]
Servir
Pedido
Comprobar
situacin Pedido
Aparcar
Pedido
* [para cada pedido
seleccionado]
Seleccionar
Pedido
Buscar
Pedidos aparcados
[Todos las reposiciones entradas]
Regularizar
Stock
Comprobar
Artculo
Asignar
Items
Fl uj os de
Trabaj o
Activar
Pedido
Regularizar
Stock
Asignar
Items
Entrar
Pedido
Validar
Pago
Seleccionar
Pedidos
Validar
Riesgo
3

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
c
t
i
v
i
d
a
d

3
_
e
s
p

-

R
e
v
.

6
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
Notacin UML 1.3
Su objetivo no es relacionar actividad con objetos, slo
comprender qu actividades son necesarias y cuales son sus
relaciones de dependencia.
El diagrama de actividad nos permite definir en qu orden
se van a realizar distintas tareas. Los diagramas de flujo
(flowchart) slo nos permiten modelar procesos secuenciales,
mientras que los diagramas de actividad nos permiten
establecer procesos en paralelo.
Comprobar
Cliente habitual
Importe
> 150.000
Comprobar
Crdito
Pre-Pago
requerido
[Tarjeta de Crdito]
NO xito
[NO xito]
[Cheque]
[SI xito]
[SI xito]
SI xito
[SI xito]
[SI xito]
[NO xito]
[NO]
[NO]
[SI]
[SI]
[Factura]
[NO xito]
[NO recibido]
NO xito
[NO xito]
Autorizacin
[Efectivo]
Descomposicin
de la actividad
Comprobar
Pago
Comprobar
Pago
Comprobar
Cheque
Comprobar
historial pagos
Abrir
Cuenta Cliente
Pueden procesarse distintas
modalidades de pago de
manera simultanea
Fl uj os de
Trabaj o
Activar
Pedido
Regularizar
Stock
Asignar
Items
Entrar
Pedido
Validar
Pago
Seleccionar
Pedidos
Validar
Riesgo
4

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
c
t
i
v
i
d
a
d

4
_
e
s
p

-

R
e
v
.

5
.
2

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
de un Escenario
Diagrama de Secuencia
Notacin UML 1.3
2:generarPedido ( )
4:generarLneaPedido ( )
5:comprobarStock ( )
6:asignarItems ( )
7:realizarReposicin ( )
Objetos que
interactan
Mensaje
Auto-mensaje
Lnea de vida
de un objeto
durante la interaccin
(1)
Mensajes enviados entre los objetos descritos en
el flujo de eventos de un Caso de Uso.
Estos mensajes muestran el nivel de colaboracin
entre los distintos objetos existentes e indican
cuando se requiere generar nuevos objetos para
cumplir con las responsabilidades asignadas.
(1)
Utilizamos dos diagramas de interaccin:
a/. Secuencia
b/. Colaboracin
Su finalidad es describir los mensajes que intercambian los
distintos objetos para cumplir con las responsabilidades
definidas en un escenario concreto de un Caso de Uso.
Diagrama de Secuencia.- Representa las
interacciones de objetos ordenadas en una serie temporal
que muestra su ciclo de vida.
1:indentificarCliente ( )
8:generarReposicin ( )
Creacin de
un nuevo
objeto
Un escenario muestra de que manera interactan los distintos
objetos dentro del flujo principal de eventos de un Caso de
Uso con alguna variacin o extensin concreta del mismo.
: Comer ci al
3:entrarLneaPedido ( )
Anlisis textual
del Use Case
y cantidad.
CU Realizar pedido
enviado un pedido.
pedido.
:Una Cartera
de Items
en Stock
:Un Pedido
de
Reposicin
:Una Ventana de
introduccin de
Pedidos
:Un Pedido
:Una Lnea
de Pedido
Escenari os
tieneStock:( )
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido Un pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
: Pedido
1

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

S
e
c
u
e
n
c
i
a
_
e
s
p

-

R
e
v
.

6
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
de un Escenario
Diagrama de Colaboracin
Notacin UML 1.3
2: generarPedido ( )
5: comprobarStock ( )
6: asignarItems ( )
7: realizarReposicin ( )
Objeto
(I nstancia de una Clase)
Auto-mensaje
8: generarReposicin ( )
Nmero de secuencia
Mensajes enviados entre los objetos descritos en
el flujo de eventos de un Caso de Uso.
Estos mensajes muestran el nivel de colaboracin
entre los distintos objetos existentes e indican
cuando se requiere generar nuevos objetos para
cumplir con las responsabilidades asignadas.
(1)
Un escenario describe una instancia del flujo de eventos de
un Caso de Uso, con sus variaciones o extensiones posibles
y las excepciones probables.
Diagrama de colaboracin.- Representa una
posible interaccin de los obj etos ordenados a partir
de la topologa que muestra el envio de sus mensaj es.
Con un escenario representamos el conjunto de eventos que
configura el comportamiento de un Caso de Uso.
Enlace entre
dos objetos
Direccin del mensaje
Utilizamos dos diagramas de interaccin:
a/. Secuencia
b/. Colaboracin
Su finalidad es describir los mensajes que intercambian los
distintos objetos para cumplir con las responsabilidades
definidas en un escenario concreto de un Caso de Uso.
Anlisis textual
del Use Case
y cantidad.
CU Realizar pedido
enviado un pedido.
pedido.
: Comercial
: Una Ventana de introduccin de Pedidos
: Un Pedido
: Una Lnea de Pedido
:Una Cartera de Items en Stock
: Un Pedido de Reposicin
Escenari os
tieneStock:( )
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido Un pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
: Pedido
1: identificarCliente ( )
3: entrarLneaPedido ( )
4: generarLneaPedido ( )
Mensaje (1)
2

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
o
l
a
b
o
r
a
c
i
n
_
e
s
p

-

R
e
v
.

6
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Clases
Desde una perspectiva conceptual, una Clase representa un
conjunto de Objetos que comparten:
Las mismas propiedades (Atributos)
El mismo comportamiento (Mtodos)
Las mismas relaciones con otros Objetos (Mensajes)
La misma semntica dentro del sistema
Un Objeto representa una entidad del mundo real o inventada.
Es un concepto, una abstraccin o algo que dispone de unos
lmites bien definidos y tiene una significacin para el sistema
que se pretende modelar.
Estructura y funcin:
I dentidad Quien soy? = Atributos
Propsito Cual es mi misin? = J ustificacin
Responsabilidades Qu debo hacer? = Mtodos
Procedencia De qu Clase provengo? = Origen
Relaciones Qu mensajes entiendo? = Comportamiento
Objetos
Desde una perspectiva fsica, una Clase es una pieza de software
que actua como un molde para fabricar tipos particulares de
objetos que disponen de los mismos atributos y mtodos.
Estos elementos que configuran cada tipo de objeto slo se
definen una vez, cuando especificamos la estructura de la Clase
a la que pertenecen.
Los objetos que se han creado a partir de una Clase concreta,
se llaman instancias de esta Clase y se diferencian entre ellos
nicamente por los valores de sus atributos (variables).
Diagrama de Clases
Notacin UML 1.3
Pedido
FechaRecibido
ConPrepago
Nmero
Importe
Divisa
...
Cliente
Lnea de Pedido
Producto
Representante
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
*
1
facturarMes( )
recordar( )
aceptar ( )
valorarCredito( ): string
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
Nombre
Direccion
NombreContacto
ValoracionCredito
LimiteCredito
NumTargetaCredito
Cantidad
Importe
Cumplimentada
Obj etos Cl ases
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
1

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
l
a
s
e
s

1
_
e
s
p

-

R
e
v
.

6
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Abstraccin
m
t
o
d
o

4
m
t
o
d
o

1
Atributos
Cl ases
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
m
t
o
d
o

2
m
t
o
d
o

3
A partir de una abstraccin del mundo real, definimos
objetos que representan micromdulos de software ideales.
Desde su creacin, se mantienen de manera independiente
unos de otros, slo interaccionan con otros objetos a travs
de sus mensajes. Cada objeto configura un universo ordenado
y autosuficiente.
vacp 104
2

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
l
a
s
e
s

2
_
e
s
p

-

R
e
v
.

3
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Objeto
e
l
e
v
a
r
P
l
a
t
a
f
o
r
m
a
c
a
r
g
a
r
I
t
e
m
Atributos
Cl ases
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
m
o
v
e
r
H
a
c
i
a
b
a
j
a
r
P
l
a
t
a
f
o
r
m
a
Variables.-
Identificacin
Medidas de la carga
Capacidad de carga
Velocidad mxima
Tipo de carga
Estado.-
Localizacin
Orientacin
Velocidad
Todo lo que un objeto conoce est representado en sus
atributos (variables y estado actual), y todo lo que puede
realizar est definido en sus mtodos (comportamiento),
y en sus interacciones con otros objetos a travs del
intercambio de mensajes (dinmica del ciclo de vida).
Vehculo Automtico Carga Palets
vacp104
Qu puedo hacer ?
Qu conozco?
Quien soy?
3

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
l
a
s
e
s

3
_
e
s
p

-

R
e
v
.

2
.
2

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Mensaje
Cl ases
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Una aplicacin orientada a objetos consiste en un nmero
determinado de objetos que interactuan entre si envindose
mensajes unos a otros para invocar sus mtodos. Este
intercambio de mensajes facilita su comportamiento, cambios
de estado, destruccin o almacenamiento.
Ya que todo lo que un objeto puede realizar est expresado
en sus mtodos, este simple mecanismo de mensajes soporta
todas las posibles interacciones entre ellos.
e
l
e
v
a
r
P
l
a
t
a
f
o
r
m
a
c
a
r
g
a
r
I
t
e
m
Atributos
m
o
v
e
r
H
a
c
i
a
b
a
j
a
r
P
l
a
t
a
f
o
r
m
a
Objeto Receptor
vacp104 moverHacia: binB7
Objeto Emisor
Nombre del objeto receptor
Mtodo que se invoca para que lo ejecute el objeto receptor
Parmetro enviado para especificar el mtodo
Signatura del mensaje
vacp104
4

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
l
a
s
e
s

4
_
e
s
p

-

R
e
v
.

1
.
2

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Cl ases
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
El empaquetado de mtodos y atributos dentro de un objeto
mediante una interface de mensajes, es lo que denominamos
encapsulacin.
La clave est precisamente en este envoltorio del objeto.
La interface que rodea por completo al objeto acta como
punto de contacto para todos los mensajes que llegan desde
cualquier objeto emisor.
La interface de mensajes tiene la misma funcin que la
membrana de una clula, disponer de una barrera esencial
entre la estructura interna de un objeto y el exterior.
Su propsito es garantizar que todas las interacciones del
objeto tengan lugar a travs de un sistema de mensajera
predefinido con el que es capaz de entenderse y reaccionar
adecuadamente.
No existe ninguna otra manera con la que un objeto externo
pueda acceder a los atributos y mtodos escondidos dentro
de la interface de mensajes de otro objeto.
Encapsulacin
M e n s a j e
I nter face de mensajes
vacp104 moverHacia: binB7
vacp104
e
l
e
v
a
r
P
l
a
t
a
f
o
r
m
a
c
a
r
g
a
r
I
t
e
m
Atributos
m
o
v
e
r
H
a
c
i
a
b
a
j
a
r
P
l
a
t
a
f
o
r
m
a
Conjunto de oper aciones
exter namente visibles que
define el compor tamiento
de un objeto
5

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
l
a
s
e
s

5
_
e
s
p

-

R
e
v
.

3
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Cl ases
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Es el mecanismo por el cual una clase de objetos puede ser
definida como un caso especial de otra clase ms genrica.
Los casos especiales de una clase se denominan Subclases.
La clase ms genrica, se conoce como la Superclase de
todos sus casos especiales. Adems de los mtodos y atributos
que heredan, las Subclases definen sus propios mtodos y
atributos. Tambien, pueden redefinir algunos de los
heredados (overriding).
Herencia
Vehculo Automtico Carga Palets
vac 104
vac 104
vac 103
vacp 104
I nstancias de
Vehculo Automtico Car ga Palets
I nter face de mensajes
I dentificador del objeto
Mtodos
Atr ibutos
La interface de mensajes definida para una Superclase
tambin es heredada por las subclases. Esto implica que
todas las Subclases de una Superclase estan preparadas
para responder correctamente a los mismos mensajes que
la Clase padre. Esta propiedad es extremadamente til
porque nos permite tratar de la misma manera a todas las
especializaciones de una Clase.
Vehculo Automtico
Carga Palets
SubClase
Vehculo Automtico
Carga Bobinas
SubClase
Vehculo Automtico de Carga
SuperClase
e
le
v
a
rP
la
ta
fo
rm
a
c
a
rg
a
rIte
m
Atributos
m
o
v
e
rH
a
c
ia
b
a
ja
rP
la
ta
fo
rm
a
vacp 104
6

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
l
a
s
e
s

6
_
e
s
p

-

R
e
v
.

1
.
2

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Composicin
Cl ases
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
E nter title h ere
Los objetos que contienen a otros objetos se denominan
Objetos Compuestos. Los atributos de un objeto pueden
utilizarse de dos maneras. Podemos usarlos para almacenar
valores como el nmero 15, o bien, el texto Autorizado.
Panel de ventana
Tambin pueden contener referencias de otros objetos. Las
referencias almacenadas en los atributos de un objeto
compuesto, permite a este objeto enviar los mensajes
apropiados a todos los objetos contenidos.
Tab Tab control
Scroll
Combo box
Slider
Trackbar
67%
Progress
Campo simple
Botones de ventana
Restore
Maximize
?
Help
Minimize
Close
List box
Grid
E nter title h ere
< Back Next > Cancel
Ventana Wizard
7

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
l
a
s
e
s

7
_
e
s
p

-

R
e
v
.

2
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Cl ases
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Diferentes objetos pueden responder a un mismo mensaje
de diferentes maneras. El polimorfismo permite a los objetos
interactuar entre ellos sin necesidad de conocer previamente
a que tipo pertenecen.
Un objeto puede ser de diferentes tipos. Por ejemplo un
vehculo automtico de carga puede especializarse para
cargar bobinas, palets u otro tipo de items. Los dems
objetos del sistema no tienen porque saber cuantos tipos
de vehculos disponemos.
El mismo mensaje cargarI tem, acompaado del parmetro
que identifica dicho item, ser intrepretado de distinta
manera por cada objeto receptor, el cual ya conoce
previamente como tiene que tratar la naturaleza de su
carga: bobinas, palets, etc.
Hay una reduccin de esfuerzo muy significativa por el
hecho de que cualquier objeto del sistema puede enviar
mensajes a los vehculos automticos de carga sin necesidad
de saber de antemano qu tipo de vehculos estan en
circulacin.
No hay necesidad as de picar un cdigo especfico para
cada tipo de vehculo, con lo cual, nos ahorramos prolijas
sentencias I F o CASE que son complejas de mantener y de
actualizar cuando se incorporan nuevos tipos de objetos.
Polimorfismo
M e n s a j e
cargarItem: #A234C19FZ
Vehculo Automtico
Carga Palets
SubClase
Vehculo Automtico
Carga Bobinas
SubClase
e
le
v
a
rP
la
ta
fo
rm
a
c
a
rg
a
rIte
m
Atributos
m
o
v
e
rH
a
c
ia
b
a
ja
rP
la
ta
fo
rm
a
vacb 117
e
le
v
a
rP
la
ta
fo
rm
a
c
a
rg
a
rIte
m
Atributos
m
o
v
e
rH
a
c
ia
b
a
ja
rP
la
ta
fo
rm
a
vacp 104
Vehculo Automtico de Carga
SuperClase
8

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
l
a
s
e
s

8
_
e
s
p

-

R
e
v
.

1
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Visibilidad
Toda Clase encapsula unos elementos (atributos y operaciones) que disponen
de ciertos criterios de visibilidad y manipulacin para otras Clases.
Los elementos pblicos pueden ser usados por cualquier otra Clase.
Los elementos privados pueden ser usados slo por la Clase propietaria.
Cada plataforma de desarrollo (C++, Smalltalk, J ava) desarrolla sus propias
reglas con respecto a la visibilidad y manipulacin de atributos y operaciones.
La notacin UML especifica que todo atributo y operacin de una Clase ha
de disponer de un indicador de visibilidad.
Cl ases
Pedido
hacer /
comprobacin
item
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1 *
1
*
0..1
*
* 1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Visibilidad C++ Smalltalk J ava
+ Publica
- Privada
# Protegida
Package
Ejemplos
Un elemento siempre es visible en cualquier
parte del programa y puede ser llamado y
modificado por cualquier objeto del
sistema.
Un elemento slo puede ser usado por la
Clase que lo define.
Un elemento slo puede ser usado por la
Clase que lo define, o por las subclases de
dicha Clase.
Consideremos la Clase CLIENTE que dispone
de una subclase CLIENTE PERSONAL.
Consideremos tambin que el objeto <<Josep
V.>>, es una instancia de CLIENTE
PERSONAL.
<<Josep V.>>
Puede usar todo elemento pblico de cualquier
objeto del sistema.
Puede usar tambin todo elemento privado de
la Clase CLIENTE PERSONAL.
No puede usar los elementos privados definidos
en la Clase CLIENTE.
Puede usar los elementos protegidos definidos
para CLIENTE y CLIENTE PERSONAL.
Todas las operaciones son
pblicas por defecto.
Todas las variables
instanciadas son privadas.
<<Josep V.>>, puede acceder a
cualquier variable instanciada dentro
de su propio objeto, si dicha variable
ha sido definida dentro de CLIENTE
o CLIENTE PERSONAL. De esta
manera, el concepto de visibilidad
privada en Smalltalk es parecido al
concepto de visibilidad protegida en
C++.
Consideremos la instancia de CLIENTE
PERSONAL, <<Miquel M.>>, este objeto
puede acceder a cualquier elemento de <<Josep
V.>>, que ha sido definido tambin como una
instancia de CLIENTE PERSONAL, sea
pblico, privado o protegido. <<Miquel M.>>,
a su vez tambin puede acceder a cualquier
elemento privado, protegido o pblico de
<<Josep V.>>
En C++, podemos acceder a elementos de otros
objetos de la propia Clase, de la misma manera
que podemos acceder a los propios elementos
de un objeto.
En Smalltalk no hay diferencia con
respecto a que un objeto sea de la
misma Clase o no. Podemos acceder
slo a los elementos pblicos de otro
objeto.
En Smalltalk, <<Miquel M.>>, no
puede acceder a las variables
instanciadas privadas de <<Josep
V.>>, slo a sus operaciones pblicas.
Un elemento siempre es visible en
cualquier parte del programa y puede
ser llamado y modificado por cualquier
objeto del sistema.
Un elemento slo puede ser usado por
la Clase que lo define.
Un elemento puede ser usado por
subclases y tambin por cualquier otra
Clase en el mismo Package como la
Clase propietaria. Esto implica que en
Java, el concepto de visibilidad
protegida es ms pblico que package.
Un elemento slo puede ser usado por
otras Clases que compartan el mismo
Package.
Pedido
- fechaRecibido
conPrepago
- nmero: Alfanm.
- importe: Nm&2d.
- divisa
...
Cliente
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1
*
1
*
0..1
*
*
1
+ hacer /
comprobacin
item
+ hacer /
comprobacin
+ crear ()
+ seleccionar ( )
+ comprobar ( )
+ servir ( )
+ cerrar ( )
Java permite marcar tambin las Clases
como pblicas o packages. Los elementos
de una Clase pblica pueden ser usados por
cualquier Clase que importe el package a
la que pertenece la Clase.
Los elementos de una Clase package slo
pueden ser usados por otras Clases del
mismo package.
Lnea de Pedido
+ hacer /
comprobacin
9

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

C
l
a
s
e
s

v
i
s
i
b
i
l
i
d
a
d
_
e
s
p

-

R
e
v
.

5
.
3

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
de la Dinmica del Sistema
La dinmica de un sistema est determinada por:
Todos los posibles estados que sus objetos pueden tener.
Todas las posibles secuencias de eventos que pueden
ocurrir.
Todas las transiciones posibles, de un estado a otro,
como consecuencia de los eventos que afectan a los objetos.
Diagrama de Estados
de un Pedido
Notacin UML 1.3
Comprobando Sirviendo
Entregado Esperando
/seleccionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
todos los items disponibles] [No todos los items comprobados]
/seleccionar siguiente item
algunos items no estan disponibles
en stock]
Item Recibido
[algunos items no estan disponibles
en stock]
I
t
e
m

R
e
c
i
b
i
d
o
[
T
o
d
o
s

l
o
s

i
t
e
m
s

d
i
s
p
o
n
i
b
l
e
s
]
Pedido Entregado
1
2
3
4
5
6
1
Di nmi ca
Estados
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
Entregado Esperando
y cantidad.
pedido .
Aparcar pedido.
CU Realizar pedido
enviado un pedido.
pedido.
Pedido
fechaRecibido
conPrepago
nmero: Alfanm.
importe: Nm&2d.
divisa
...
*
1
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
Anlisis textual
del Use Case

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

D
i
n
m
i
c
a

1
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
Diagrama de Estados
de un Pedido
Notacin UML 1.3
Entregado Esperando
hacer /
comprobacin
item
hacer /
inicio de
entregas
[No todos los items comprobados]
en stock]
Item Recibido
en stock]
I
t
e
m

R
e
c
i
b
i
d
o
[
T
o
d
o
s

l
o
s

i
t
e
m
s

d
i
s
p
o
n
i
b
l
e
s
]
Pedido Entregado
Pedido
fechaRecibido
conPrepago
nmero: Alfanm.
importe: Nm&2d.
divisa
...
*
1
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
I nicio
Clase
Atributos
Operaciones
primera Transicin
E st ado
Actividad
Accin
Accin
I ndicador
Auto-Transicin
Transicin
1
2
Evento
3
Utilizamos el diagrama de estados para describir el
comportamiento de una Clase dentro de una serie temporal.
4
5
6
Procesos que ocurren de manera rpida
dentro de un ciclo contnuo sin interrupcin.
/ Accin Transicin
Desencadena
siempre
la Transicin
[I ndicador] Transicin
Condicin lgica con dos categorias: verdadero o falso.
Una Transicin con [Indicador] slo ocurre si este es verdadero.
Slo podemos extraer una Transicin para un Estado concreto.
2
Di nmi ca
Estados
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
Entregado Esperando
Sintaxis para etiquetar una transicin
Evento [I ndicador ] / Accin
Los tres elementos son opcionales
Anlisis textual
del Use Case
y cantidad.
CU Realizar pedido
enviado un pedido.
pedido.

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

D
i
n
m
i
c
a

2
_
e
s
p

-

R
e
v
.
-

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
Diagrama de Estados
de un Pedido
Notacin UML 1.3
Entregado Esperando
hacer /
comprobacin
item
hacer /
inicio de
entregas
todos los items disponibles] [No todos los items comprobados]
en stock]
Item Recibido
en stock]
I
t
e
m

R
e
c
i
b
i
d
o
[
T
o
d
o
s

l
o
s

i
t
e
m
s

d
i
s
p
o
n
i
b
l
e
s
]
Pedido Entregado
Construimos el diagrama de estados a partir de una clase
concreta para mostrar el comportamiento de un objeto
durante su ciclo de vida.
I nicio
primera Transicin
E st ado
Actividad
Accin
Accin
I ndicador
Auto-Transicin
Transicin
I
m
p
l
e
m
e
n
t
a
c
i
n
Cuando una Transicin no dispone de un Evento
en su etiqueta, significa que la Transicin se
realiza tan pronto como la Actividad asociada
con un Estado es finalizada
Procesos que ocurren de manera rpida
dentro de un ciclo contnuo sin interrupcin.
/ Accin Transicin
/ Actividad Estado
Procesos que ocurren dentro de un ciclo discontnuo
y pueden ser interrumpidospor algun evento.
[I ndicador] Transicin
Condicin lgica con dos categorias: verdadero o falso.
Una Transicin con [Indicador] slo ocurre si este es verdadero.
Slo podemos extraer una Transicin para un Estado concreto.
1
2
Evento
3
No hay Actividades para este Estado, por lo
que el Pedido permanecer a la espera de
un Evento.
Desencadena
siempre
la Transicin
Aunque finalize la Actividad
el Pedido permanecer en
este Estado hasta que ocurre
el Evento que desencadena
su Transicin
4
5
6
3
Di nmi ca
Estados
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
Entregado Esperando
Anlisis textual
del Use Case
y cantidad.
CU Realizar pedido
enviado un pedido.
pedido.
Pedido
fechaRecibido
conPrepago
nmero: Alfanm.
importe: Nm&2d.
divisa
...
*
1
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
Clase
Atributos
Operaciones
Sintaxis para etiquetar una transicin
Evento [I ndicador ] / Accin
Los tres elementos son opcionales

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

D
i
n
m
i
c
a

3
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
Diagrama de Estados
Notacin UML 1.3
Un Evento no es un objeto. Un Evento es la causa que
justifica la existencia de una informacin.
Slo podemos conocer que un Evento ha ocurrido,
detectando sus efectos en nuestro modelo.
Slo nos interesan aquellos Eventos que provocan un cambio
de estado en los objetos de nuestro modelo.
Hay que distinguir un Evento como tal, del objeto que
representa el registro de los efectos de dicho Evento.
Esperando
hacer /
comprobacin
item
hacer /
inicio de
entregas
[No todos los items
comprobados]
/seleccionar
siguiente item
[Todos los items
comprobados &&
algunos items no estan
disponibles en stock]
Item Recibido
[algunos items
no estan
I
t
e
m

R
e
c
i
b
i
d
o
[
T
o
d
o
s

l
o
s

i
t
e
m
s

d
i
s
p
o
n
i
b
l
e
s
]
Pedido
Entregado
1
2
3
4 5
6
sin Superestados
Entregado Esperando
hacer /
comprobacin
item
hacer /
inicio de
entregas
[No todos los items
comprobados]
/seleccionar
siguiente item
[Todos los items
comprobados &&
algunos items no estan
Item Recibido
[algunos items
no estan
I
t
e
m

R
e
c
i
b
i
d
o
[
T
o
d
o
s

l
o
s

i
t
e
m
s

d
i
s
p
o
n
i
b
l
e
s
]
Pedido
Entregado
1
2
3
4
5
6
Cancelado
Pedido
Cancelado
Pedido
Cancelado
Pedido
Cancelado
Activo
Cancelado Entregado
Pedido
Cancelado
Nombre del Superestado
con Superestados
4
Di nmi ca
Estados
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
Entregado Esperando
Anlisis textual
del Use Case
y cantidad.
CU Realizar pedido
enviado un pedido.
pedido.

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

D
i
n
m
i
c
a

4
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Descripcin
Diagrama de Estados
Concurrentes
Notacin UML 1.3
Autorizando
hacer /
comprobacin
del pago
[pago NO correcto]
Entregado
[pago SI correcto]
Rechazado Autorizado
Rechazado
Cancelado
Entregado
Comprobando
Esperando
Sirviendo
Autorizando Autorizado
Pedido Entregado
Pedido Cancelado
Pedido Rechazado
Los diagramas de estados son muy tiles para describir el
comportamiento de un objeto a travs de mltiples Casos
de Uso.
5
y cantidad.
b. SI existen suficientes items...
artculo...
pedido .
Aparcar pedido.
CU Realizar pedido
enviado un pedido.
c. NO existen suficientes items...
muestra...
Anlisis textual
del Use Case
Di nmi ca
Estados
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item Recibido
rimer item
rimer item
Entregado Esperando

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

D
i
n
m
i
c
a

5
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Vista de
Distribucin Fsica
Elementos
Vista de
I mplementacin
Ejecutables
Arquitectura del sistema
Una Arquitectura es un conjunto organizado de elementos.
Se utiliza para especificar las decisiones estratgicas acerca
de la estructura y funcionalidad del sistema, las colaboraciones
entre sus distintos elementos y su despliegue fsico para
cumplir unas responsabilidades bien definidas.
Vista de la Arquitectura 4+1
Notacin UML 1.3
Arqui tectura
Vista del
Modelo de Referencia
Vista de la
Funcionalidad
Use Cases
Vista de
Componentes
Modulares
1

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
r
q
u
i
t
e
c
t
u
r
a

1
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
La vista del Modelo de Referencia (Reference I nformation
Model), est determinada por la arquitectura lgica.
La arquitectura lgica es capturada por los diagramas de
Clases que contienen las Clases y relaciones que representan
las abstracciones esenciales del sistema a desarrollar.
Clases
Asociaciones
Agregaciones
Generalizacin
Packages
Arqui tectura
Vista del
Vista del
El Modelo de Referencia se construye en sucesivas
iteraciones durante la fase de Formalizacin.
Pedidos Clientes
Artculos
Las Clases y Packages del modelo reflejan las
decisiones tomadas con respecto a los mecanismos
clave del sistema.
Una eficiente implementacin de los mecanismos
clave requiere seleccionar Patrones (Patterns) que
se ajusten a los requerimientos esenciales del
proyecto.
La implementacin de mecanismos clave requiere
seleccionar tambin:
Lenguaje de programacin
Motor de Base de Datos
I nterface grfico de usuario look and feel
Tratamiento de errores
Mecanismos de comunicacin
Migracin y distribucin de objetos
Networking
Pedido
fechaRecibido
conPrepago
nmero: Alfanm.
importe: Nm&2d.
divisa
...
Cliente
Lnea de Pedido
Producto
Comercial
Cliente
Corporativo
Cliente
Personal
1
*
1
*
0..1
*
*
1
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
2

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
r
q
u
i
t
e
c
t
u
r
a

2
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Vista de
Componentes
Modulares
La vista de Componentes Modulares refleja la organizacin
de mdulos de software dentro del entorno de desarrollo.
Esta vista de arquitectura toma en cuenta los requerimientos
que facilitan la programacin, los niveles de reutilizacin,
y las limitaciones impuestas por el entorno de desarrollo.
Disponemos de dos elementos para modelizar esta vista:
Packages: En esta vista representan una particin fsica
del sistema.
Componentes: En esta vista representan la organizacin
de mdulos de cdigo fuente.
Arqui tectura
Los Packages estan organizados en una jerarqua
de capas que disponen de una interface bien definida:
Pack ages espec f i cos del domi ni o
I nt er f ace de Usuar i o
Pack ages r eut i l i zabl es
Mecani smos cl ave COR E
Packages de pl at af or ma ( OS- Har dwar e)
4
3
2
1
Vista de
Componentes
Modulares
Vista del
Los Packages de la vista lgica del modelo estan
mapeados con los Packages fsicos y los componentes
de software (subsistemas).
I nformacin
Artculos
Pedi do
Dominio
Clientes
Artculos
Pedidos
Mailing
Interface Usuario
AWT
Java GUI toolkit
Entrada
Pedidos
Interface Usuario
3

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
r
q
u
i
t
e
c
t
u
r
a

3
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Vista de
I mplementacin
Ejecutables
Vista de
I mplementacin
Ejecutables
Arqui tectura
Los componentes run-time muestran los mappings
de las Clases a libreras de tipo ActiveX, Applets de
J ava y libreras dinmicas.
Vista de
Componentes
Modulares
Vista del
Los componentes ejecutables muestran sus interfaces
y niveles de dependencia dentro de la aplicacin.
Clientes.dll
Expedicin.dll
Artculos.dll
Pedi dos. exe
Mailing
Interface Usuario
AWT
Java GUI toolkit
Entrada
Pedidos
Interface Usuario
Dominio
Clientes
Artculos
Pedidos
Entrada
Pedidos
Aplicacin
Mailing
Aplicacin
Base de
Datos
Interface global
Oracle
Interface
I ngres
Interface
Esta vista se centra en la estructura de los componentes
run-time, los ejecutables del sistema.
Esta arquitectura tiene muy en cuenta los siguientes
requerimientos no funcionales:
Rendimiento
Fiabilidad
Escalabilidad
I ntegridad
Seguridad
Sincronizacin
Administracin del sistema
4

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
r
q
u
i
t
e
c
t
u
r
a

4
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Vista de
Distribucin Fsica
Elementos
Vista de
I mplementacin
Ejecutables
Un Nodo es un objeto fsico run-time que representa
un recurso informtico. Este recurso, generalmente
dispone de datos persistentes y capacidad de proceso.
En la mayora de los casos un Nodo puede representar
una pieza de hardware, desde un perifrico a un
servidor.
Las Conexiones entre Nodos muestran las lneas de
comunicacin con las que el sistema tendr que
interactuar.
Los Componentes, en un diagrama de distribucin,
representan los mdulos fsicos de cdigo, los cuales,
se corresponden con los Packages de ejecutables.
De esta manera, el diagrama muestra donde corre
cada Package en el sistema.
Las Dependencias muestran cmo los componentes
se comunican con otros componentes. La direccin
de una Dependencia concreta, indica el conocimiento
en la comunicacin.
Vista de
Componentes
Modulares
Vista del
Esta vista presenta el mapping de componentes de software
ejecutables con los nodos de procesamiento (hardware).
Esta arquitectura tiene en cuenta los siguientes
requerimientos:
Disponibilidad del sistema
Rendimiento
Escalabilidad
Los diagramas de distribucin muestran el despliegue de
nodos (locales y remotos), en la organizacin de la empresa.
Permite al equipo de desarrollo comprender mejor la
topologa de un sistema distribuido.
Vista de
Distribucin Fsica
Elementos
Componente
Arqui tectura
I nterface
Nodos
Conexi n
TCP/ IP
TCP/ IP
Servi dor rea Comerci al
Cl i ente Wi n95
Servi dor Contabi l i dad
: GUI
Comerci al
: Cl i ent e
Comerci al
Confi guraci n
: Usuari os
: Cont abi l i dad
: Base de
Dat os
: Base de
Dat os
: Comerci al
: Servi dor
Apl i caci ones
5

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
r
q
u
i
t
e
c
t
u
r
a

5
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g
Vista de
I mplementacin
Ejecutables
Vista de
Componentes
Modulares
Vista del
Modelo de Referencia Esta vista certifica la validez de:
Componentes modulares de software
Ejecutables
Distribucin de recursos informticos
Con la funcionalidad requerida del sistema.
Utilizamos los siguientes elementos para describir la
funcionalidad:
Diagramas de Casos de Uso
Especificacin de Casos de Uso
Diagramas de I nteraccin (Escenarios)
Diagramas de Actividad (Flujos de Trabajo)
Diagramas de Estados (Dinmica)
Vista de
Distribucin Fsica
Elementos
Vista de la
Funcionalidad
Use Cases
Arqui tectura
[tieneStock]
asignar ( )
[tieneStock]
nuevo
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido
Un pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
Preparar
Pedido
Recepcin
de un
Pedido
Comprobar
Items
Comprobar
Pago
Cancelar
Pedido
Asignar
Items
Reponer
Items
Servir
Pedido
[en stock]
[SI xito]
[NO xito]
[Requiere reposicin]
Entregado Esperando
ionar primer item
hacer /
comprobacin
item
hacer /
inicio de
entregas
Item
R
ecib
id
o
[T
o
d
o
s lo
s item
s d
isp
o
n
ib
les]
Entregado
rimer item
rimer item
rimer item
<< Ext >>
<< Inclu >>
<< Inclu >>
<< Ext >>
<< Inclu >>
Abr i r Ar queo
Hacer un
I ni ci o de D a
Hacer un
Fi n de D a
Expor t ar
movi mi ent os
I mpr i mi r
document o
Super vi sor
Importar nueva
configuracin
Cont abi l i dad
Caj er o
Cer r ar Ar queo
6
y cantidad.
CU Realizar pedido
enviado un pedido.
pedido.

V
i
l
a
l
t
a

C
o
n
s
u
l
t
o
r
e
s

2
0
0
1

-

T
R
A
D

A
r
q
u
i
t
e
c
t
u
r
a

6
_
e
s
p

-

R
e
v
.

5
.
1

-

j
v
i
l
a
l
t
a
@
v
i
c
o
.
o
r
g

Guía Visual: Josep Vilalta

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guía Visual: Josep Vilalta

Cargado por

Copyright:

Formatos disponibles

UML

También podría gustarte