UMLguiaVisual 0 17

UML
Gua Visual
Cmo crear
formas de vida
organizativa
Vi l a l t a C o n s u l t o r e s 2 0 0 1
info@vico.org
R e v. 0 . 1 7
Josep Vilalta
Proyecto:
Documento:
Historial:
Situacin:
Proceso:
Autor:
Presentacin del borrador: UML Gua Visual

UML Gua Visual
03/09/01 9:03
Borrador en curso de revisin
Evaluacin de contenidos ref.- contacto: jvilalta@vico.org
Josep Vilalta
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
vi
co
.o
rg
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.
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
Proyecto:
Documento:
Historial:
Situacin:
Proceso:
Autor:

UML Gua Visual
03/09/01 9:03
Josep Vilalta
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,
vi
co
.o
rg
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.

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
2 de 9
Proyecto:
Documento:
Historial:
Situacin:
Proceso:
Autor:

UML Gua Visual
03/09/01 9:03
Josep Vilalta
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.
vi
co
.o
rg
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.

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
3 de 9
Proyecto:
Documento:
Historial:
Situacin:
Proceso:
Autor:

UML Gua Visual
03/09/01 9:03
Josep Vilalta
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.
vi
co
.o
rg
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).

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
4 de 9
Proyecto:
Documento:
Historial:
Situacin:
Proceso:
Autor:

UML Gua Visual
03/09/01 9:03
Josep Vilalta
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
vi
co
.o
rg
eventos son capaces de provocar un cambio de estado. El diagrama de EstadosTransicin 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/

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
5 de 9
Proyecto:
Documento:
Historial:
Situacin:
Proceso:
Autor:

UML Gua Visual
03/09/01 9:03
Josep Vilalta
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 Journal 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
vi
co
.o
rg
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.

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
6 de 9
Proyecto:
Documento:
Historial:
Situacin:
Proceso:
Autor:

UML Gua Visual
03/09/01 9:03
Josep Vilalta
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
vi
co
.o
rg
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

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
7 de 9
Proyecto:
Documento:
Historial:
Situacin:
Proceso:
Autor:

UML Gua Visual
03/09/01 9:03
Josep Vilalta
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
vi
co
.o
rg
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

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
8 de 9
Proyecto:
Documento:
Historial:
Situacin:
Proceso:
Autor:

UML Gua Visual
03/09/01 9:03
Josep Vilalta
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
vi
co
.o
rg
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.
Josep Vilalta
Badalona, Barcelona (Espaa)
jvilalta@vico.org
http://www.vico.org

Fecha actualizacin:
04/09/01 11:16
Revisin:
18
Pgina:
9 de 9
Niveles de concepcin y formalizacin

de un proyecto
Nivel 1
Nivel 3
Nivel 5
Use Case
Una ventana de
introduccin de
pedidos
Use Case
jvilalta@vico.org
<< Extends >>

<< Extends >>
Una lnea
de pedido
Un pedido
Una ventana de
introduccin de
pedidos
Un item
de stock
Una lnea
de pedido
Un pedido
[tieneStock]
nuevo
Cliente
Pedido
Un item
de stock
tieneStock:= comprobar ( )
hacer /
comprobacin
item
Cliente
*
nuevo
[tieneStock]
nuevo
hacer /
comprobacin
item
<< Communicates >>
tieneStock:( )
Cliente
Personal
Cliente
Corporativo
nuevo
<< Communicates >>
Cliente
Personal
Cliente
Corporativo
[tieneStock]
: Pedido
hacer /
comprobacin
hacer /
comprobacin
item
[tieneStock]
Actor
hacer /
comprobacin
Pedido
hacer /
comprobacin
item
*
0..1
xxx lnea : Lnea de pedido: Pedido
xxx stock : item de stock
<< Uses >>
Comercial
Lnea de Pedido
xxx lnea : Lnea de pedido
: Item de Expedicin
: Item de Pedido de reposicin

: Item de Expedicin
Diagramas de
Casos de Uso
Interaccin
de objetos
Clases
Anlisis
Diseo
Implementacin
Dinmica
Eventos - Estados
Entrar
Reposicin
Entrar
Entrar
Pedido
ionar primer item
Asignar
Items
* [para cada pedido seleccionado]
[Todos los items

comprobados &&
Sirviendo
todos los items disponibles]
hacer /
rimer item
hacer /
comprobacin
item
rimer item
rimer item
Esperando
rimer item
Activar
Pedido Activar
Pedido
Regularizar
StockRegularizar
Stock
inicio de
entregasSirviendo
Verificando
hacer /
inicio de
entregas
s]
Pago
[Todos los items comprobados &&

hacer /
comprobacin
item
rimer item
le
Validar
ionar primer item

rimer item Verificando
n ib
*Seleccionar
[para cada pedido seleccionado]
Pedidos
Reposicin
Entregado
Esperando
s]
Riesgo
Entrar
po
Validar
Seleccionar
Pedidos
Pendientes
d is
Reposicin
Asignar
Items
Cronograma
Plan Director
Iteraciones
Producto
le
CU
CU
Flujos
de Trabajo
Comercial
n ib
Especificacin
Casos de Uso
po
Escenarios
Producto
hacer /
comprobacin
Entregado
d is
PDI
P
Procesos
Principales
Funcionalidad
0..1
*
1
*
Lnea de Pedido
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Code like hell
Glosario
de Conceptos
hacer /
comprobacin
[T
Matrcula
del Proyecto
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
<< Uses >>

Actor
Entregado
[T
Vilalta Consultores 2001 - TRAD UMD_esp - Rev. 5.2 -
Nivel 4
C d i g o
Nivel
Nivel 2
Entregado
Tiempo
Iteraciones
Procesos
PDP
Fases
E s f u e r z o d e d e s a r ro l l o
Producto
Actividades
Entregables
Concepcin
Formalizacin
Construccin
Transicin
Vilalta Consultores 2000 - TRAD PDP iteraciones_esp - Rev. 4.2 -
jvilalta@vico.org
Misin
Modelo
Prototipo
Componentes
Certificacin
Iteraciones
preliminares
Iter #1
Iter #2
Iter #n
Iter
#n+1
Iteraciones
Iter
#n+2
Iter #n
Iter
#n+1
PDP
Concepcin
Formalizacin
Construccin
Transicin
Misin
P l a n D i re c t o r d e P ro y e c t o
Modelo
Prototipo
Componentes
Certificacin
Iteraciones
preliminares
Iter #1
Iter #2
Concepcin
Vilalta Consultores 2001 - TRAD PDP misin_esp2 - Rev. 5.2 -
jvilalta@vico.org
Pedido
hacer /
comprobacin
item
Pedido
Matrcula
del proyecto
Procesos
principales
<<Incluye>>
Cliente
hacer /
comprobacin
Cliente
Corporativo
Misin
Cliente
Personal
hacer /
comprobacin
item
0..1
Comercial
Lnea de Pedido
0..1
*
1
*
Lnea de Pedido
hacer /
comprobacin
Producto
Use Case
<< Extends >>
<<Extiende >>
Use Case
Cliente
Personal
Cliente
Corporativo
hacer /
comprobacin
item
Use Case
Use Case
Cliente
hacer /
comprobacin
item
hacer /
comprobacin
hacer /
comprobacin
Iter #n
Comercial
Actor 1
<< Communicates >>
<<Generalizacin>>
Actor 2
Use Case
<< Uses >>
<<Incluye>>
Use Case
Producto
Patrones de
Anlisis
PDI
P
G
Glosario
de Conceptos
Iter
#n+1
Iteraciones
Cronograma
Plan Director
Iteraciones
Anteproyecto
Patrones de
Funcionalidad
Iter
#n+2
Iter #n
Iter
#n+1
PDP
Concepcin
Formalizacin
Construccin
Transicin
Misin
Modelo
Prototipo
Componentes
Certificacin
Iteraciones
preliminares
Iter #1
Iter #2
Iter #n
Iter
#n+1
Iteraciones
Fo r m a l i z a c i n
Una ventana de
introduccin de
pedidos
Use Case
Use Case
Una lnea
de pedido
Un pedido
<< Extends >>
Un item
de stock
Cliente
Pedido
Una ventana de
introduccin de
pedidos
Una lnea
de pedido
Un pedido
[tieneStock]
nuevo
Un item
de stock
<< Extends >>
hacer /
comprobacin
item
hacer /
comprobacin
Cliente
Pedido
[tieneStock]
nuevo
[tieneStock]
nuevo
hacer /
comprobacin
item
tieneStock:( )
<< Communicates >>
hacer /
comprobacin
item
*
0..1
<< Uses >>
Cliente
Personal
Cliente
Corporativo
nuevo
Cliente
Personal
Cliente
Corporativo
[tieneStock]
: Pedido
Actor
<< Communicates >>
hacer /
comprobacin
hacer /
comprobacin
item
Comercial
Lnea de Pedido
: Item de Expedicin
Actor
Use Case
Use Case
<<Incluye>>
Use Case

: Item de Expedicin
hacer /
comprobacin
0..1
*
1
*
Lnea de Pedido
hacer /
comprobacin
Producto
Comercial
Producto
Funcionalidad
Escenarios
Clases
Diagramas de
Casos de Uso
Interaccin
de objetos
Anlisis
y Diseo
Pedido
<<Extiende >>
Use Case
Modelo
<<Incluye>>
Use Case
Patrones de
Funcionalidad
hacer /
comprobacin
Pedido
ionar primer item
[Todos los items

comprobados &&
Sirviendo
hacer /
hacer /
comprobacin
rimer item
rimer item
rimer item
Esperando
rimer item
Activar
Pedido Activar
Pedido
Especificacin
Casos de Uso
Regularizar
StockRegularizar
inicio de
entregasSirviendo
s]
hacer /
inicio de
entregas
n ib
le
hacer /
comprobacin
item
po
Asignar
Items
item
rimer item
Verificando
Entregado
Esperando
s]
le
Pago
Asignar
Items
d is
Validar

ionar primer item

Pedidos
n ib
Reposicin
po
*Seleccionar
Entregado
d is
CU
Comercial
*
0..1
*
1
*
Lnea de Pedido
hacer /
comprobacin
Entrar
Riesgo
Cliente
Personal
Lnea de Pedido
Entrar
Validar
Cliente
Corporativo
hacer /
comprobacin
item
Producto
Comercial
Producto
Patrones de
Anlisis
Seleccionar
Pedidos
Pendientes
Entrar
Cliente
Personal
Cliente
Corporativo
0..1
Reposicin
Entrar
Reposicin
hacer /
comprobacin
hacer /
comprobacin
item
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Actor 2
<< Uses >>
[T
<<Generalizacin>>
Cliente
hacer /
comprobacin
item
Use Case
Cliente
hacer /
comprobacin
Pedido
<< Communicates >>
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Actor 1
hacer /
comprobacin
item
<< Extends >>
Entregado
[T
Vilalta Consultores 2001 - TRAD PDP modelo_esp2 - Rev. 5.3 -
jvilalta@vico.org
<< Uses >>
Entregado
Stock
Flujos de
Trabajo
Dinmica
Eventos
Estados
Iter
#n+2
Iter #n
Iter
#n+1
PDP
Concepcin
Formalizacin
Construccin
Transicin
Misin
Modelo
Prototipo
Componentes
Certificacin
Iteraciones
preliminares
Iter #1
Iter #2
Iter #n
Iter
#n+1
Iter
#n+2
Iteraciones
Construccin
Cliente
Pedido
hacer /
comprobacin
item
*Acta
*Acta
Versin
Fecha
Destino
Ao Acadmico
Versin
Fecha
Destino
** Tribunal
Alumnos
Cliente
*
** Tribunal
jvilalta@vico.org
Alumno
P. Global
P. Esp.
Resultado
P. Global
P. Esp.
Resultado
Ver
Cliente
Corporativo
Cliente
Personal
hacer /
comprobacin
item
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
Cliente
Pedido
hacer /
comprobacin
0..1
*
1
*
Lnea de Pedido
hacer /
comprobacin
hacer /
comprobacin
item
Producto
Comercial
Producto
1
Cliente
Corporativo
Cliente
Personal
hacer /
comprobacin
item
*
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
Vilalta Consultores 2001 - TRAD PDP construccin_esp2 - Rev. 5.3 -
Alumno
Ver
Cliente
Personal
Cliente
Corporativo
hacer /
comprobacin
item
*
Seleccin
Seleccin
hacer /
comprobacin
hacer /
comprobacin
item
Ao Acadmico
Alumnos
hacer /
comprobacin
Pedido
Interface
Grfico de Usuario
Producto
Clases
Diseo
Implementacin
Cliente
Pedido
hacer /
comprobacin
item
Cliente
*
hacer /
comprobacin
hacer /
comprobacin
item
Componentes
hacer /
comprobacin
Pedido
P
Cliente
Personal
Cliente
Corporativo
hacer /
comprobacin
item
Cliente
Corporativo
Cliente
Personal
hacer /
comprobacin
item
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
0..1
*
1
*
Lnea de Pedido
hacer /
comprobacin
Producto
Comercial
Producto
Patrones de
Diseo
Framework
de Aplicaciones
Base de Datos
Arquitectura
Esquema de Persistencia
Componentes
Iter #n
Iter
#n+1
PDP
Concepcin
Formalizacin
Construccin
Transicin
Misin
Modelo
Prototipo
Componentes
Certificacin
Iteraciones
preliminares
Iter #1
Iter #2
Iter
#n+2
Iter
#n+1
Iter #n
Iter #n
Iter
#n+1
Iteraciones
Concepcin
Fo r m a l i z a c i n
Use Case
Una ventana de
introduccin de
pedidos
Use Case
Una lnea
de pedido
Un pedido
Un item
de stock
Una lnea
de pedido
Un pedido
[tieneStock]
nuevo
Un item
de stock
<< Extends >>
hacer /
comprobacin
item
Pedido
hacer /
comprobacin
hacer /
comprobacin
hacer /
comprobacin
item
[tieneStock]
hacer /
comprobacin
item
<< Communicates >>

<< Uses >>
Seleccin

: Item de Expedicin
Procesos
principales
: Item de Expedicin
hacer /
comprobacin
Comercial
P. Esp.
Resultado
Ver
Cliente
Corporativo
Producto
0..1
Comercial
hacer /
comprobacin
Lnea de Pedido
Comercial
0..1
*
1
*
Lnea de Pedido
hacer /
comprobacin
Cliente
Personal
hacer /
comprobacin
item
hacer /
comprobacin
Producto
Funcionalidad
Escenarios
Clases
Diagramas de
Casos de Uso
Interaccin
de objetos
Anlisis
y Diseo
Misin
P. Global
Cliente
Personal
Cliente
Corporativo
hacer /
comprobacin
item
0..1
*
1
*
Lnea de Pedido
Interface
Grfico de Usuario
Modelo
Producto
Comercial
Producto
Clases
Diseo
Implementacin
Componentes
Entrar
Reposicin
ionar primer item
rimer item
rimer item
rimer item
Esperando
rimer item
Glosario
de Conceptos
Cronograma
Plan Director
Iteraciones
Anteproyecto
Activar
Pedido Activar
Pedido
Especificacin
Casos de Uso
Regularizar
StockRegularizar
inicio de
entregasSirviendo
s]
hacer /
inicio de
entregas
n ib
le
hacer /
comprobacin
item
po
Asignar
Items
[Todos los items

comprobados &&
Sirviendo
hacer /
Verificando
Entregado
d is
Esperando
s]
Asignar
Items
le
Pago
hacer /
comprobacin
item
rimer item
n ib
Validar

ionar primer item

po
Reposicin
Entregado
d is
*Seleccionar
Pedidos
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
CU
Pedido
Riesgo
Entrar
[T
Entrar
Validar
Seleccionar
Pedidos
Pendientes
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
PDI
P
Entrar
Reposicin
Entregado
[T
jvilalta@vico.org
Vilalta Consultores 2001 - TRAD PDP_esp2 - Rev. 6.2 -
Matrcula
del proyecto

** Tribunal
Lnea de Pedido
<< Uses >>
Alumno
hacer /
comprobacin
hacer /
comprobacin
item
Ao Acadmico
Alumnos
0..1
Actor
Fecha
Cliente
*
hacer /
comprobacin
item
*
Versin
Destino
hacer /
comprobacin
Pedido
Cliente
Personal
Cliente
Corporativo
nuevo
tieneStock:( )
*Acta
Cliente
Personal
Cliente
Corporativo
1
[tieneStock]
hacer /
comprobacin
item
Cliente
Pedido
nuevo
[tieneStock]
nuevo
: Pedido
Actor
<< Communicates >>
Cliente
Cliente
Pedido
Una ventana de
introduccin de
pedidos
<< Extends >>
Construccin
Entregado
Stock
Flujos de
Trabajo
Dinmica
Eventos
Estados
Base de Datos
Arquitectura
Esquema de Persistencia
Componentes
Cmo identificar Actores ?

Interaccin de un
Actor con el Sistema
Us ar Caje ro
Automtic o
S u b sistema
d e cu en tas
clien te
<< Incluye >>
C lien te
Relacin que indica la

especializacin a partir de una
funcin genrica
<<Generaliza>>
- Role de us ua rio -
- Ro le d e su b sistema -
R e a l i z a r una
t ra nsa c c i n
Interaccin del
Sistema con un Actor
<<Generaliza>>
<<Generaliza>>
jvilalta@vico.org
Vilalta Consultores 2001 - TRAD Actores_esp - Rev. 5.1 -
Activar
Ta r j e t a
Retirar
Efectivo
Consultar
Movimientos
S is te ma e n proc e s o de mode la do
Actores
S u b sitema
d e certificaci n
d e med io s
d e p ag o
- Ro le d e su b sistema -
Representan a un agente que interacta con el sistema
No son parte del sistema que se desarrolla
Entran informacin al sistema
Reciben informacin del sistema
Entran y reciben informacin
Use Case
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.
Interaccionar el nuevo sistema con un sistema antiguo ?
<< Extends >>
Actor
<< Communicates >>
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
Cmo identificar Casos de Uso ?

Hacer un
Ini ci o de D a
<< Extiende >>
Abr ir Arque o
Relacin que describe una variacin

posible del comportamiento normal
de un Use Case
Interaccin de un
Actor con el Sistema
<< Incluye >>

Piezas de funcionalidad del sistema
que suministran valor a un Actor y son
reutilizables en diferentes procesos
C ajero
- Rol de us ua rio -
C e r r ar Arque o
<< Extiende >>
Ha c e r un
Fi n de D a
jvilalta@vico.org
Vilalta Consultores 2001 - TRAD UCs_esp - Rev. 5.1 -
- Ro l d e u su ario -
Relacin que permite descomponer

un Use Case con un determinado
nivel de granularidad
<< Incluye >>
<< Incluye >>

Relacin que indica el uso de
una funcionalidad compartida
por otros Casos de Uso
S u p erv iso r
Importar nueva
configuracin
Im pri m i r
doc um e nt o
E xport ar
m ovi m i ent os
Co n tab ilid ad
S is te ma e n proc e s o de mode la do
- S istema ex tern o Interaccin del

Sistema con un Actor
A la bsqueda de Casos de Uso.-
Use Case
<< Extends >>
Actor
<< Communicates >>
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 ?
<< Uses >>

Actor
Funcionalidad
Diagramas de
Casos de Uso
Use Case
<< Extends >>
Especificacin
de un Caso de Uso
Actor
<< Communicates >>
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
Caso de Uso principal
<< Extiende >>
Vilalta Consultores 2001 - TRAD LIMIT UCs_esp - Rev. 5.1 -
jvilalta@vico.org
C e r r ar A rque o
Ha c e r un
Fin de Da
<< Incluye >>
Casos de Uso secundarios
Imprimir
doc ume nto
Imprimir
tira de a rque o
<<Generaliza>>
Caso de Uso genrico
Caso de Uso especializado
L
I
M
I
T
Lmites: Cuando empieza y cmo termina el Caso de Uso.

Interacciones: Comportamiento de Actores y Sistema.
Accin-Reaccin dentro del Caso de Uso.
Masa: Conjunto de Objetos e Interfaces 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
Precondiciones
- Regla de Negocio -
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
Activacin
A discrecin de un Actor
habilitado
Flujo Principal
Variaciones
1. Sistema requiere confirmacin de

cierre de arqueo.
a. Si Actor decide aparcar el cierre de arqueo,

sistema activa UC Aparca_arqueo y termina
el UC.
2. Sistema comprueba la configuracin

de TPV para identificar tipo de cierre.
a. Cierre de arqueo de tipo abierto:

Actor decide el momento de imprimir el
documento Tira de Arqueo.
b. Cierre de arqueo de tipo ciego:
Sistema no muestra los totales tericos para
cada forma de cobro.
3. Sistema calcula los totales tericos

para cada forma de cobro.
4. Actor introduce totales reales para cada
forma de cobro.
5. Sistema registra el cierre: importes
reales para cada forma de cobro y
descuadres.
6. Sistema imprime el documento Tira
de Arqueo.
Excepciones
a. Si el servidor est off-line, sistema informa

al usuario, termina el UC manteniendo el
arqueo abierto.
a. Si impresora est off-line, sistema informa
al usuario y le pide confirmacin para
continuar.
Ventajas del modelo

Use Case
1. Lenguaje de comunicacin entre usuarios

y desarrolladores.
2. Comprensin detallada de la funcionalidad
del sistema.
A brir A rque o
<< Extiende >>
H ac e r un
Ini c i o de D a
<< Incluye >>

Hac e r un
Fin de Da
Vilalta Consultores 2001 - TRAD modelo UC_esp - Rev. 5.1 -
jvilalta@vico.org
<< Extiende >>
Importar nueva
configuracin
<< Incluye >>

Export a r
movimient os
C e rra r A rque o
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.
<< Incluye >>
Imprimir
doc ume nto
3. Acotacin precisa de las habilitaciones de

los usuarios.
<<Generaliza>>
Imprim i r
tira de arque o
8. Certificacin contractual ClienteDesarrollador.

9. Documentacin orientada al usuario: Helps
- Manual de Procedimientos - Reglas de Negocio.
Use Case
<< Extends >>
Actor
<< Communicates >>
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
Piezas de funcionalidad reutilizables

en diferentes procesos de negocio
10. Documentacin orientada al administrador

del sistema: Soporte de Mantenimiento.
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.
Funcionalidad,
Anlisis y Diseo
Implementacin
de cdigo y
Refactoring
Reglas
de Negocio
y protocolos de
intercambio de
informacin
Mapa conceptual:
Clases de anlisis
Caso de Uso
Plan Director
de Iteraciones:
Cronograma
y prioridades
Dinmica de
Clases complejas
Mapa funcional:
Flujos de trabajo
principales y
variaciones
de
Pr
oye
cto
A rq
ur
Use Case
Mtrica:
Escenarios de
Escandallo de
interaccin
recursos
de objetos:
y actividades Clases de diseo
sti
delo
Cer tif ic ac
in
Funcionales,
no funcionales
e interfaces de
usuario
Ge
Vilalta Consultores 2001 - TRAD Req y CUs_esp - Rev. 1.1 -
erimiento
Mo
jvilalta@vico.org
qu
Re
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.
e
ui t
ct
<< Extends >>
Actor
<< Communicates >>
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
Recepcin
de un
Pedido
Evento que
desencadena
la secuencia de
actividades
Identificar
Cliente
Actividad
CU Realizar pedido
Flujo Principal
Va r i a c i o n e s
1. Usuario identifica el cliente que ha

enviado un pedido.
Diagrama de Actividad
Notacin UML 1.3
2. Usuario entra lineas de pedido, con su

cdigo de artculo, tipo de presentacin
y cantidad.
3. Sistema comprueba cada lnea del
pedido para validar la situacin del
artculo en catlogo y el nmero de
items del artculo en stock.
a. Artculo NO est vigente en catlogo, sistema

informa que articulo no est vigente y
muestra artculos alternativos activando el
CU Seleccionar artculo.
Anlisis textual
del Caso de Uso
b. SI existen suficientes items del artculo en

el stock, sistema asigna items al 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 genera pedido
de reposicin activando el CU Generar
pedido.
4. Sistema comprueba la situacin del

pedido .
Concurrencia dinmica de actividades
Barra de sincronizacin
* [para cada lnea de pedido]
a. SI se ha realizado el pago y SI todos los items

del pedido han sido asignados, sistema
informa que procede a servir 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.
jvilalta@vico.org
Vilalta Consultores 2001 - TRAD Actividad 1_esp - Rev. 7.1 -
Entrar
lneas pedido
[NO vigente]
Punto de decisin
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.
Seleccionar
Artculo alternativo
[SI vigente]
c. SI no se ha realizado el pago segn el plazo

convenido, sistema cancela el pedido.
Comprobar
Artculo
Comprobar
Pago
[NO]
Cancelar
Pedido
Asignar
Items
[SI]
[NO Stock] o
[SI umbral reposicin]
Barra de fusin
Generar
reposicin
Condicin lgica: verdadera o falsa,

que permite la transicin
a otra actividad
Comprobar
situacin Pedido
Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
[Todos los items asignados]
[Faltan items por asignar]
Validar
Pago
Asignar
Items
Servir
Pedido
Aparcar
Pedido
Activar
Pedido
Regularizar
Stock
Flujos de
Trabajo
CU Actualizar reposicin
Descripcin
Flujo Principal
1. Usuario recepciona albaranes de
reposicin que ha enviado un proveedor.
2. Sistema localiza los pedidos de clientes
aparcados que pueden cumplimentarse
con la nueva entrada de items.
Recepcin
de una
Reposicin
Anlisis textual
del Caso de Uso
Una diagrama de actividad describe una secuencia de

actividades que pueden exhibir un comportamiento en
paralelo o estar sujetas a condiciones lgicas.
3. Usuario selecciona los pedidos de

clientes aparcados que decide
cumplimentar.
4. Sistema asigna los items pendientes a
los pedidos de cliente seleccionados.
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.
Entrar
Reposicin
5. Sistema informa que procede a servir

el pedido activando el CU Servir
pedido..
Buscar
Pedidos aparcados
6. Sistema regulariza la situacin de items

en stock y revisa los umbrales de
reposicin automtica.
jvilalta@vico.org
Notacin UML 1.3
Seleccionar
Pedido
* [para cada pedido
seleccionado]
Transicin de una actividad a otra sujeta
a una condicin lgica.
Asignar
Items
Sincronizacin de actividades que

pueden ocurrir en paralelo.
[Todos las reposiciones entradas]

Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
Servir
Pedido
Validar
Regularizar
Stock
Pago
Asignar
Items
Activar
Pedido
Fin de la secuencia de
actividades
Regularizar
Stock
Flujos de
Trabajo
Descripcin
Recepcin
de un
Pedido
Identificar
Cliente
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.
Entrar
lneas pedido
Notacin UML 1.3
[Recepcin de Reposicin]
Comprobar
Artculo
Seleccionar
Artculo alternativo
[NO vigente]
[SI vigente]
Comprobar
Pago
Seleccionar
Pedido
jvilalta@vico.org
Entrar
Reposicin
Buscar
Pedidos aparcados
Lneas para acotar
reas de responsabilidad
(swim-lines)
* [para cada pedido

seleccionado]
Asignar
Items
[NO xito]
Cancelar
Pedido
[SI xito]
Generar
reposicin
[NO Stock]
o [SI umbral reposicin]
Comprobar
situacin Pedido
Contabilidad
Comercial
Regularizar
Stock
Almacn
Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
Validar
Pago
[Todos las reposiciones entradas]

Servir
Pedido
[Faltan items por asignar]
Aparcar
Pedido
Asignar
Items
Activar
Pedido
Regularizar
Stock
Flujos de
Trabajo
Descripcin
Descomposicin
de la actividad
Comprobar
Pago
Su objetivo no es relacionar actividad con objetos, slo

comprender qu actividades son necesarias y cuales son sus
relaciones de dependencia.
Notacin UML 1.3
Pueden procesarse distintas

modalidades de pago de
manera simultanea
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
Pago
[Tarjeta de Crdito]
jvilalta@vico.org
[Factura]
Comprobar
Cheque
Autorizacin
[Cheque]
Comprobar
Cliente habitual
Importe
> 150.000
NO xito
[SI]
[NO]
[Efectivo]
[NO xito]
[NO xito]
[SI]
Comprobar
historial pagos
[SI xito]
[SI xito]
[NO xito]
Pre-Pago
requerido
[NO recibido]
[NO]
Comprobar
Crdito
[NO xito]
NO xito
[SI xito]
Entrar
Pedido
Validar
[SI xito]
Riesgo
Seleccionar
Pedidos
Validar
Pago
Abrir
Cuenta Cliente
SI xito
Asignar
Items
Activar
Pedido
Regularizar
Stock
Flujos de
Trabajo
CU Realizar pedido
Flujo Principal
Descripcin
de un Escenario

enviado un pedido.
y cantidad.
Anlisis textual
del Use Case
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.

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.

pedido.
Objetos que
interactan
Vilalta Consultores 2001 - TRAD Secuencia_esp - Rev. 6.1 -
jvilalta@vico.org
Diagrama de Secuencia.- Representa las
: C o m erci al
:Una Ventana de
introduccin de
Pedidos
:Un Pedido
:Una Lnea
de Pedido
:Una Cartera
de Items
en Stock
interacciones de objetos ordenadas en una serie temporal

que muestra su ciclo de vida.
(1) Mensajes enviados entre los objetos descritos en
el flujo de eventos de un Caso de Uso.
1:indentificarCliente ( )
2:generarPedido ( )
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.
3:entrarLneaPedido ( )
4:generarLneaPedido ( )
5:comprobarStock ( )
Auto-mensaje
6:asignarItems ( )
(1)
Mensaje
7:realizarReposicin ( )
Lnea de vida
de un objeto
durante la interaccin
8:generarReposicin ( )
Creacin de
un nuevo
objeto
:Un Pedido
de
Reposicin
Una ventana de
introduccin de
pedidos
Un pedido
Una lnea
de pedido
Un item
de stock
[tieneStock]
nuevo
[tieneStock]
nuevo
tieneStock:( )
: Pedido

Diagrama de Secuencia
Notacin UML 1.3
: Item de Expedicin
Escenarios
CU Realizar pedido
Flujo Principal

enviado un pedido.
Anlisis textual
del Use Case
Con un escenario representamos el conjunto de eventos que

configura el comportamiento de un Caso de Uso.

y cantidad.
Descripcin
de un Escenario

pedido.
Un escenario describe una instancia del flujo de eventos de

un Caso de Uso, con sus variaciones o extensiones posibles
y las excepciones probables.
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.
Objeto
Vilalta Consultores 2001 - TRAD Colaboracin_esp - Rev. 6.1 -
jvilalta@vico.org
(Instancia de una Clase)
Diagrama de colaboracin.- Representa una

: Comercial
Nmero de secuencia
posible interaccin de los objetos ordenados a partir

de la topologa que muestra el envio de sus mensajes.
1: identificarCliente ( )
(1) Mensajes enviados entre los objetos descritos en

el flujo de eventos de un Caso de Uso.
3: entrarLneaPedido ( )
4: generarLneaPedido ( )
: Una Ventana de introduccin de Pedidos

Enlace entre
dos objetos
Mensaje (1)
2: generarPedido ( )
: Una Lnea de Pedido
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.
5: comprobarStock ( )
6: asignarItems ( )
Auto-mensaje
: Un Pedido
7: realizarReposicin ( )
Direccin del mensaje
:Una Cartera de Items en Stock

Una ventana de
introduccin de
pedidos
Un pedido
Una lnea
de pedido
Un item
de stock
[tieneStock]
nuevo
[tieneStock]
nuevo
8: generarReposicin ( )
tieneStock:( )
: Pedido

Diagrama de Colaboracin
Notacin UML 1.3
: Item de Expedicin
: Un Pedido de Reposicin
Escenarios
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
Pedido
FechaRecibido
ConPrepago
Nmero
Importe
Divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
jvilalta@vico.org
Vilalta Consultores 2001 - TRAD Clases 1_esp - Rev. 6.1 -
Nombre
Direccion
valorarCredito( ): string
1
Cliente
Corporativo
Cliente
Personal
NumTargetaCredito
NombreContacto
ValoracionCredito
LimiteCredito
facturarMes( )
recordar( )
Estos elementos que configuran cada tipo de objeto slo se

definen una vez, cuando especificamos la estructura de la Clase
a la que pertenecen.
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.
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).
Cliente
0..1
*
Representante
Lnea de Pedido
Cantidad
Importe
Cumplimentada
Producto
aceptar ( )
Diagrama de Clases
Notacin UML 1.3
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:
Identidad Quien soy? = Atributos
Propsito Cual es mi misin? = Justificacin
Responsabilidades Qu debo hacer? = Mtodos
Procedencia De qu Clase provengo? = Origen
Relaciones Qu mensajes entiendo? = Comportamiento
Cliente
Pedido
hacer /
comprobacin
hacer /
comprobacin
item
1
Cliente
Corporativo
Cliente
Personal
hacer /
comprobacin
item
*
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
Objetos
Producto
Clases
Abstraccin
vacp 104
t
m
o
od
2
do
o
t
Atributos
m
o
od
t
4
jvilalta@vico.org
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.
o
od
t
Cliente
Pedido
hacer /
comprobacin
hacer /
comprobacin
item
1
Cliente
Corporativo
hacer /
comprobacin
item
*
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
Producto
Clases
Cliente
Personal
Objeto
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).
Quien soy?
Vehculo Automtico Carga Palets
vacp104
Qu puedo hacer?
ia
Atributos
m
or
af
at
Pl
jvilalta@vico.org
ac
H
rg
ar
ev
el
a
er
ca
em
ov
m
It
ar
a
Pl
r
a
aj
m
or
f
ta
Qu conozco?
Variables.
Identificacin
Medidas de la carga
Capacidad de carga
Velocidad mxima
Tipo de carga
Cliente
Pedido
hacer /
comprobacin
hacer /
comprobacin
item
Estado.-
1
Cliente
Corporativo
hacer /
comprobacin
item
Localizacin
Orientacin
Velocidad
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
Producto
Clases
Cliente
Personal
Mensaje
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.
Mtodo que se invoca para que lo ejecute el objeto receptor

Parmetro enviado para especificar el mtodo
Nombre del objeto receptor
vacp104
moverHacia: binB7
Objeto Emisor
ia
Atributos
a
rm
ar
ev
el
m
or
af
at
Pl
a
rg
ac
H
ca
em
er
It
ar
ov
m
jvilalta@vico.org
vacp104
ba
ja
a
at
l
rP
Signatura del mensaje
fo
Cliente
Pedido
hacer /
comprobacin
hacer /
comprobacin
item
1
Cliente
Corporativo
hacer /
comprobacin
item
Objeto Receptor
*
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
Producto
Clases
Cliente
Personal
Encapsulacin
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.
Interface de mensajes
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.
m
ac
H
er
ia
ca
a
rg
e
rIt
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.
Atributos
ar
ev
el
m
or
af
at
Pl
a
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.
ov
m
jvilalta@vico.org
Conjunto de operaciones
externamente visibles que
define el comportamiento
de un objeto
ba
ja
t
la
P
r
af
a
m
r
o
vacp104
moverHacia: binB7
Cliente
Pedido
hacer /
comprobacin
hacer /
comprobacin
item
Mensaje
1
Cliente
Corporativo
hacer /
comprobacin
item
*
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
vacp104
Producto
Clases
Cliente
Personal
Herencia
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).
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 de Carga
Vehculo Automtico
Carga Palets
Vehculo Automtico
Carga Bobinas
vac 104
vac 104
SubClase
SubClase
vac 103
vacp 104
Interface de mensajes
H
er
ov
Mtodos
ia
ac
rg
ca
em
r It
or
af
at
Pl
ar
Instancias de
ba
ja
l
rP
or
af
at
Cliente
Pedido
hacer /
comprobacin
hacer /
comprobacin
item
Atributos
ev
el
jvilalta@vico.org
SuperClase
Atributos
1
Cliente
Corporativo
hacer /
comprobacin
item
*
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
vacp 104
Identificador del objeto
Producto
Clases
Cliente
Personal
Composicin
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.
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.
Ventana Wizard
Progress
Enter title here
Tab
67%
Tab control
Trackbar
jvilalta@vico.org
< Back
Next >
Panel de ventana
Grid
Cancel
Slider
Enter title here
Campo simple
Scroll
Botones de ventana
Restore
Maximize
Cliente
Combo box
Pedido
hacer /
comprobacin
hacer /
comprobacin
item
1
Cliente
Corporativo
Help
?
Close
Minimize
hacer /
comprobacin
item
List box
*
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
Producto
Clases
Cliente
Personal
Polimorfismo
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.
Vehculo Automtico de Carga
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.
SubClase
Vehculo Automtico
Carga Palets
SubClase
El mismo mensaje cargarItem, 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 IF o CASE que son complejas de mantener y de
actualizar cuando se incorporan nuevos tipos de objetos.
Cliente
Atributos
a
or
af
at
Pl
ar
r
fo
ta
la
ev
el
or
af
at
Pl
ar
rP
ja
ba
ia
ac
ia
ac
rg
ca
Atributos
cargarItem: #A234C19FZ
H
er
ov
H
er
ov
m
Ite
ar
m
Ite
ar
rg
ca
ev
el
jvilalta@vico.org
SuperClase
Vehculo Automtico
Carga Bobinas
rP
ja
ba
Pedido
rm
fo
ta
la
hacer /
comprobacin
hacer /
comprobacin
item
Mensaje
1
Cliente
Corporativo
hacer /
comprobacin
item
*
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
vacb 117
vacp 104
Producto
Clases
Cliente
Personal
Visibilidad
Cliente
Pedido
- fechaRecibido
conPrepago
- nmero: Alfanm.
- importe: Nm&2d.
- divisa
...
+ crear ()
+ seleccionar ( )
+ comprobar ( )
+ servir ( )
+ cerrar ( )
1
+ hacer /
comprobacin
1
Cliente
Corporativo
+ hacer /
comprobacin
item
Cliente
Personal
Visibilidad
jvilalta@vico.org
Vilalta Consultores 2001 - TRAD Clases visibilidad_esp - Rev. 5.3 -
Comercial
Producto
C++
Smalltalk
+ Publica
- Privada
Un elemento slo puede ser usado por la

Clase que lo define.
# Protegida
Un elemento slo puede ser usado por la

Clase que lo define, o por las subclases de
dicha Clase.
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.
Todas las variables

instanciadas son privadas.
Un elemento slo puede ser usado por

otras Clases que compartan el mismo
Package.
Package
Cliente
Pedido
Ejemplos
hacer /
comprobacin
hacer /
comprobacin
item
1
Cliente
Corporativo
Cliente
Personal
hacer /
comprobacin
item
*
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
Producto
Clases
Java
Un elemento siempre es visible en
cualquier parte del programa y puede
ser llamado y modificado por cualquier
objeto del sistema.
Lnea de Pedido
+ hacer /
comprobacin
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, Java) 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.
Un elemento siempre es visible en cualquier Todas las operaciones son
parte del programa y puede ser llamado y pblicas por defecto.
modificado por cualquier objeto del
sistema.
0..1
*
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.>>
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.
<<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++.
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 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, <<Miquel M.>>, no

puede acceder a las variables
instanciadas privadas de <<Josep
V.>>, slo a sus operaciones pblicas.
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.
CU Realizar pedido
Flujo Principal
Descripcin
de la Dinmica del Sistema

enviado un pedido.
y cantidad.


pedido.

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

Aparcar pedido.
jvilalta@vico.org
Notacin UML 1.3

/seleccionar primer item
2
1
ionar primer item
hacer /
inicio de
entregas
le
ib
on
sp
di
le
n ib
po
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
d is
rimer item
rimer item
Esperando
Entregado
Dinmica
Estados
hacer /
inicio de
entregas
6
Pedido Entregado
s]
Sirviendo
hacer /
comprobacin
item
hacer /
comprobacin
item

algunos items no estan disponibles
en stock]

Verificando

Sirviendo
1
rimer item
Comprobando
s]
[No todos los items comprobados]

/seleccionar siguiente item
It
[T em
od R
os eci
lo bid
s
ite o
m
s
Pedido
fechaRecibido
conPrepago
nmero: Alfanm.
importe: Nm&2d.
divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
[T
Vilalta Consultores 2001 - TRAD Dinmica 1_esp - Rev. 5.1 -
La dinmica de un sistema est determinada por:

Anlisis textual
del Use Case
Item Recibido
[algunos items no estan disponibles
en stock]
Esperando
Entregado
CU Realizar pedido
Flujo Principal

enviado un pedido.
y cantidad.
Anlisis textual
del Use Case
Descripcin

Utilizamos el diagrama de estados para describir el

comportamiento de una Clase dentro de una serie temporal.

pedido.
Notacin UML 1.3
Indicador
Accin
1
Comprobando
Estado
2

Sirviendo
hacer /
comprobacin
item
hacer /
inicio de
entregas
Transicin
di
sp

en stock]
Desencadena
siempre
la Transicin
Evento
Pedido Entregado
Item Recibido
en stock]
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.
Esperando
ionar primer item
Entregado
rimer item

Verificando
Sirviendo
hacer /
comprobacin
item
hacer /
inicio de
entregas
s]
le
Auto-Transicin
n ib
Procesos que ocurren de manera rpida

dentro de un ciclo contnuo sin interrupcin.
[Indicador]
on
ib
Los tres elementos son opcionales
/ Accin
le
s]
Evento [Indicador] / Accin
Actividad
po
Sintaxis para etiquetar una transicin

Accin
rimer item
d is
primera Transicin
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Operaciones
fechaRecibido
conPrepago
nmero: Alfanm.
importe: Nm&2d.
divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
Inicio
rimer item
Esperando
[T
Atributos
Pedido
It
[T em
od R
os eci
lo bid
s
ite o
m
s
Vilalta Consultores 2001 - TRAD Dinmica 2_esp - Rev.- 5.1 -
jvilalta@vico.org
Clase
Diagrama de Estados
de un Pedido
Entregado
Transicin
Dinmica
Estados
CU Realizar pedido
Flujo Principal

enviado un pedido.
y cantidad.
Anlisis textual
del Use Case

Construimos el diagrama de estados a partir de una clase

concreta para mostrar el comportamiento de un objeto
durante su ciclo de vida.

pedido.
Diagrama de Estados
de un Pedido
Notacin UML 1.3
[Indicador]
hacer /
inicio de
entregas
Actividad
le
5
Auto-Transicin
ionar primer item
Entregado
rimer item

Verificando
Sirviendo
hacer /
comprobacin
item
hacer /
inicio de
entregas
po
n ib
le
s]
Esperando
rimer item
rimer item
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.
Evento
Pedido Entregado
Transicin
No hay Actividades para este Estado, por lo
que el Pedido permanecer a la espera de
un Evento.
d is
Item Recibido
en stock]
Desencadena
siempre
la Transicin
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Procesos que ocurren dentro de un ciclo discontnuo

y pueden ser interrumpidospor algun evento.
hacer /
comprobacin
item

en stock]
Transicin
Estado
Comprobando
Los tres elementos son opcionales
Procesos que ocurren de manera rpida

dentro de un ciclo contnuo sin interrupcin.
/ Actividad

Sirviendo
s]
Evento [Indicador] / Accin
Aunque finalize la Actividad

el Pedido permanecer en
este Estado hasta que ocurre
el Evento que desencadena
su Transicin
Esperando
[T
/ Accin
Indicador
Accin
1
ib
Sintaxis para etiquetar una transicin
Estado

Accin
on
primera Transicin
sp
fechaRecibido
conPrepago
nmero: Alfanm.
importe: Nm&2d.
divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
Inicio
di
Pedido
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
It
[T em
od R
os eci
lo bid
s
ite o
m
s
Operaciones
Implementacin
jvilalta@vico.org
Clase
Atributos
Descripcin
Entregado
Dinmica
Estados
CU Realizar pedido
Flujo Principal

enviado un pedido.

pedido.

Sirviendo
hacer /
comprobacin
item
hacer /
inicio de
entregas
s]
ib
on
Pedido
Entregado
Pedido
Cancelado
Entregado
sp
on
ib
Pedido
Cancelado
Cancelado
sin Superestados
Pedido
Cancelado
hacer /
inicio de
entregas
le
s]
Sirviendo
hacer /
comprobacin
item
n ib
Notacin UML 1.3
rimer item
rimer item
Esperando
Cancelado
Entregado

Verificando
po
con Superestados
ionar primer item
rimer item
d is
Diagrama de Estados
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Pedido
Entregado
[T
Item Recibido
[algunos items
Esperando
no estan
disponibles en stock]
Pedido
Cancelado
Item Recibido
[algunos items
Esperando
no estan
di
[Todos los items

comprobados &&
algunos items no estan
le
s]
le
[Todos los items

comprobados &&
algunos items no estan
hacer /
inicio de
entregas
sp
[No todos los items

comprobados]
/seleccionar
Comprobando
siguiente item
1
[No todos los items
2
comprobados]
/seleccionar
Comprobando todos los items disponibles]
Sirviendo
siguiente item
hacer /
comprobacin
item
Activo
Hay que distinguir un Evento como tal, del objeto que

representa el registro de los efectos de dicho Evento.
di
Slo nos interesan aquellos Eventos que provocan un cambio

de estado en los objetos de nuestro modelo.
It
[T em
od R
os eci
lo bid
s
ite o
m
s
jvilalta@vico.org
Nombre del Superestado
Slo podemos conocer que un Evento ha ocurrido,

detectando sus efectos en nuestro modelo.
It
[T em
od R
os eci
lo bid
s
ite o
m
s
Anlisis textual
del Use Case
Un Evento no es un objeto. Un Evento es la causa que

justifica la existencia de una informacin.

y cantidad.
Descripcin
Entregado
Dinmica
Estados
CU Realizar pedido
Flujo Principal

enviado un pedido.
y cantidad.
artculo...
Descripcin

muestra...
Los diagramas de estados son muy tiles para describir el

comportamiento de un objeto a travs de mltiples Casos
de Uso.
b. SI existen suficientes items...

c. NO existen suficientes items...
Aparcar pedido.
Autorizando
hacer /
comprobacin
del pago
[pago NO correcto]
[pago SI correcto]
Esperando
Cancelado
Autorizado
Rechazado
Pedido Cancelado
Sirviendo
Entregado
Pedido Entregado
ionar primer item

Verificando
Sirviendo
hacer /
comprobacin
item
hacer /
inicio de
entregas
le
s]
rimer item
n ib
Autorizado
po
Autorizando
Entregado
rimer item
Rechazado
Pedido Rechazado
Diagrama de Estados
Concurrentes
Notacin UML 1.3
d is
Comprobando
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
jvilalta@vico.org

rimer item
Esperando
[T
Anlisis textual
del Use Case

pedido .
Entregado
Dinmica
Estados
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
Vilalta Consultores 2001 - TRAD Arquitectura 1_esp - Rev. 5.1 -
jvilalta@vico.org
Vista del
Componentes
Modulares
Modelo de Referencia
Vista de la
Funcionalidad
Use Cases
Vista de
Vista de
Implementacin
Ejecutables
Distribucin Fsica
Elementos
Vista de la Arquitectura 4+1

Notacin UML 1.3
Arquitectura
Vista del
La vista del Modelo de Referencia (Reference Information

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
Vista del
Agregaciones
Generalizacin
Packages
Pedidos
jvilalta@vico.org
Cliente
El Modelo de Referencia se construye en sucesivas
iteraciones durante la fase de Formalizacin.
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.
Pedido
fechaRecibido
conPrepago
nmero: Alfanm.
importe: Nm&2d.
divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
1
hacer /
comprobacin
Artculos
1
Cliente
Corporativo
La implementacin de mecanismos clave requiere

seleccionar tambin:
Motor de Base de Datos

Tratamiento de errores
Mecanismos de comunicacin
Migracin y distribucin de objetos
Networking
Cliente
Personal
hacer /
comprobacin
item
Lenguaje de programacin
Interface grfico de usuario look and feel
Clientes
0..1
*
Comercial
Lnea de Pedido
hacer /
comprobacin
Producto
Arquitectura
Vista de
Vista del
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.
Vista de
Componentes: En esta vista representan la organizacin

de mdulos de cdigo fuente.
jvilalta@vico.org
Componentes
Modulares
Pe d i d o
Los Packages estan organizados en una jerarqua

de capas que disponen de una interface bien definida:
Interface de Usuario
Pa c k a g e s e s p e c f i c o s d e l d o m i n i o
Pa c k a g e s r e u t i l i z a b l e s
Mecanismos clave CORE
Pa c k a g e s d e p l a t a f o r m a
Entrada
Pedidos
AWT
Mailing
Interface Usuario
Java GUI toolkit
Interface Usuario
Informacin
Artculos
Dominio
(OS -Hardware)
Pedidos
Los Packages de la vista lgica del modelo estan
mapeados con los Packages fsicos y los componentes
de software (subsistemas).
Clientes
Artculos
Arquitectura

Vista de
Vista del
Componentes
Modulares
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:
Vista de
Implementacin
Ejecutables
jvilalta@vico.org
Implementacin
Ejecutables
Los componentes run-time muestran los mappings

de las Clases a libreras de tipo ActiveX, Applets de
Java y libreras dinmicas.
Los componentes ejecutables muestran sus interfaces
y niveles de dependencia dentro de la aplicacin.
Rendimiento
Integridad
Fiabilidad
Seguridad
Escalabilidad
Sincronizacin
Administracin del sistema
Vista de
Entrada
Pedidos
AWT
Mailing
Interface Usuario
Java GUI toolkit
Interface Usuario
Entrada
Pedidos
Mailing
Aplicacin
Aplicacin
Dominio
Pedidos
P e d i d o s . exe
Clientes
Artculos
Artculos.dll
Oracle
Expedicin.dll
Base de
Datos
Interface
Interface global
Ingres
Clientes.dll
Interface
Arquitectura

Vista de
Vista del
Componentes
Modulares
Vista de
Implementacin
Ejecutables
Esta vista presenta el mapping de componentes de software

ejecutables con los nodos de procesamiento (hardware).
Esta arquitectura tiene en cuenta los siguientes
requerimientos:
Vista de
Distribucin Fsica
Elementos
Disponibilidad del sistema

Rendimiento
Escalabilidad
Los diagramas de distribucin muestran el despliegue de
nodos (locales y remotos), en la organizacin de la empresa.
Vista de
jvilalta@vico.org
Distribucin Fsica
Elementos
Permite al equipo de desarrollo comprender mejor la

topologa de un sistema distribuido.
TCP/IP
Servidor Contabilidad
Un Nodo es un objeto fsico run-time que representa

un recurso informtico. Este recurso, generalmente
dispone de datos persistentes y capacidad de proceso.
:Base de
Datos
En la mayora de los casos un Nodo puede representar

una pieza de hardware, desde un perifrico a un
servidor.
:Base de
Datos
Las Conexiones entre Nodos muestran las lneas de

comunicacin con las que el sistema tendr que
interactuar.
Servidor rea Comercial

:Contabilidad
:Comercial
Configuracin
:Servidor
Aplicaciones
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.
Nodos
:Usuarios
TCP/IP
Las Dependencias muestran cmo los componentes

se comunican con otros componentes. La direccin
de una Dependencia concreta, indica el conocimiento
en la comunicacin.
Cliente Win95
:Cliente
Comercial
Interface
:GUI
Comercial
Componente
Conexin
Arquitectura

Vista de
Vista del
Esta vista certifica la validez de:
Componentes
Modulares
Vista de la
Funcionalidad
Componentes modulares de software
Use Cases
Vista de
Vista de
Implementacin
Ejecutables
Distribucin Fsica
Elementos
Ejecutables
Distribucin de recursos informticos
Con la funcionalidad requerida del sistema.
Utilizamos los siguientes elementos para describir la
funcionalidad:
Abrir Arqueo
<< Ext >>
Diagramas de Casos de Uso
Hacer un
Inicio de Da
Especificacin de Casos de Uso
<< Inclu >>
Cajero
Cerrar Arqueo
Supervisor
Diagramas de Interaccin (Escenarios)

Diagramas de Actividad (Flujos de Trabajo)
Hacer un
Fin de Da
<< Ext >>
<< Inclu >>
<< Inclu >>
Imprimir
documento
Exportar
movimientos
Diagramas de Estados (Dinmica)

Contabilidad
Recepcin
de un
Pedido
Preparar
Pedido
CU Realizar pedido
Flujo Principal
[NO xito]
Cancelar
Pedido

enviado un pedido.
Comprobar
Comprobar
Pago
Items
[en stock]
[SI xito]
Asignar
Items

y cantidad.
Una ventana de
introduccin de
pedidos
Un pedido
Una lnea
de pedido
Un item
de stock

[Requiere reposicin]
Reponer
Items

Servir
Pedido

[tieneStock]
nuevo
ionar primer item
rimer item

Verificando
Sirviendo
hacer /
comprobacin
item
hacer /
inicio de
entregas
on
ib
le
s]
[tieneStock]
asignar ( )

pedido.
rimer item
di
sp
[tieneStock]
nuevo
rimer item
[tieneStock]
nuevo
Esperando
It
[T em
od R
os eci
lo bid
s
ite o
m
s
jvilalta@vico.org
Importar nueva
configuracin
Entregado
Entregado
Arquitectura

UMLguiaVisual 0 17

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

UMLguiaVisual 0 17

Cargado por

Copyright:

Formatos disponibles

UML

Presentacin del borrador: UML Gua Visual

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual

Presentacin del borrador: UML Gua Visual

La tecnologa orientada a objetos persigue el antiguo principio del divide y vencers. Su

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual

Presentacin del borrador: UML Gua Visual

Mucha gente cree que la principal utilidad de la orientacin a objetos es la reutilizacin

Ante este cuadro de incertidumbre, el mayor desafio de una metodologa de desarrollo

La dinmica de cambio no se desarrolla en la ingeniera del software con la misma

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual

Presentacin del borrador: UML Gua Visual

A quin va dirigida esta gua visual?

La claridad conceptual y los recursos didcticos utilizados en la exposicin de los

Cmo sacar un mayor provecho a su lectura?

La gua est organizada en unidades didcticas que describen la notacin de los

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual

Presentacin del borrador: UML Gua Visual

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual

Presentacin del borrador: UML Gua Visual

De dnde provienen las ideas expuestas?

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual

Presentacin del borrador: UML Gua Visual

o Plan Funcional para la implementacin SAP-Logstica

o Gestin de Bancos de Sangre y Hemoterapia

o Planificacin y gestin de campaas de captacin de donantes

o Tarjeta Sanitaria para certificar transacciones asistenciales

o Gestin de laboratorios farmacuticos

o Historia Clnica Orientada por Problemas Automatizada

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual

Presentacin del borrador: UML Gua Visual

Entorno de ingeniera del software

o Sistema de informacin Ejecutivo

o Merchandising de productos farmacuticos

o Gestin de redes de puntos de venta con videoconferencia

o Plan de Sistemas de Informacin

o Integracin de sistemas de informacin de contabilidad administrativa y

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual

Presentacin del borrador: UML Gua Visual

o Reconocimiento automtico de conceptos clnicos a partir de textos no

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual

Niveles de concepcin y formalizacin

<< Extends >>

<< Communicates >>

<< Communicates >>

xxx lnea : Lnea de pedido: Pedido

xxx stock : item de stock

<< Uses >>

: Item de Pedido de reposicin

ionar primer item

* [para cada pedido seleccionado]

[Todos los items

[Todos los items comprobados &&

ionar primer item

Code like hell

: Item de Pedido de reposicin

<< Uses >>

Vilalta Consultores 2001 - TRAD UMD_esp - Rev. 5.2 -

Vilalta Consultores 2000 - TRAD PDP iteraciones_esp - Rev. 4.2 -

Vilalta Consultores 2001 - TRAD PDP misin_esp2 - Rev. 5.2 -

<< Communicates >>

<< Extends >>

<< Extends >>