UMLGuía Visual
C ó m o c r e a rf 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 C o n s u l t o r e s 2 0 0 1
i n f o @ v i c o . o r gR e v. 0 . 1 7 Josep V i la l ta
vico.o
rg
Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org
Fecha actualización:
04/09/01 11:16 Revisión:
18 Página:
1 de 9
UML Guía Visual
Cómo crear formas de vida organizativa
Presentación Esta guía describe como definir, organizar y visualizar lo que denominamos formas de
vida organizativa (VIO) con la notación Unified Modelling Language (UML). Una VIO
representa un ciclo de actividad realizado por uno o varios agentes con un propósito
concreto, en base a una práctica consensuada para utilizar los recursos disponibles y
para tomar las decisiones que caracterizan el comportamiento de una organización.
A diferencia de los sistemas biológicos, 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
selección natural actúa en los sistemas biológicos, la continuidad de una VIO está
condicionada a la implementación 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 organización ha de tener
en cuenta para evolucionar y asegurar su viabilidad.
La notación UML (no hay que confundir con las metodologías que utilizan dicha
notación), se ha convertido desde finales de los 90 en un estándar para modelar con
tecnología orientada a objetos todos aquellos elementos que configuran la arquitectura
de un sistema de información y, por extensión, de los procesos de negocio de una
organización. 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 organización. La interacción de todos estos elementos es una
representación de nuestra realidad.
vico.o
rg
Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org
Fecha actualización:
04/09/01 11:16 Revisión:
18 Página:
2 de 9
Nuestros límites para entender esta realidad están 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?. Enseñar a utilizar un
lenguaje formal siempre es problemático. Es necesario mostrar como este lenguaje
puede ser aplicado a la realidad tal como la conocemos y tal como la compartimos con
los demás. Con esta guía visual mostramos de manera precisa las técnicas básicas 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 múltiples conexiones que
avanzamos en las respuestas a nuestros interrogantes cuando modelamos un dominio,
sino mediante la disolución de las contradicciones que existen entre los términos
(conceptos) ya conocidos y, en último caso, mediante la reducción de su número
despejando aquellos conceptos que no añaden valor a la comprensión de dicho dominio.
Reconsiderar lo obvio, desenmascarar presunciones, desambigüar conceptos conocidos,
todo en busca de la simplicidad y la usabilidad.
La tecnología orientada a objetos persigue el antiguo principio del divide y vencerás. Su
objetivo es descomponer la complejidad en partes más manejables y comprensibles. No
parece que esto sea algo novedoso con respecto a la tradicional descomposición
funcional de los métodos estructurados. Sin embargo, la gran diferencia reside en
aplicar la dualidad estructura-función en pequeñas unidades capaces de comunicarse y
reaccionar en base a la aparición de una serie de eventos. El esquema dominante de la
separación de estructuras de datos y funciones (bases de datos y programas) está
amenazado pero aún se resiste a desaparecer.
vico.o
rg
Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org
Fecha actualización:
04/09/01 11:16 Revisión:
18 Página:
3 de 9
Mucha gente cree que la principal utilidad de la orientación a objetos es la reutilización
del código para conseguir un desarrollo más rápido 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 aparición de nuevas plataformas más exigentes, la
extinción de herramientas sin previo aviso y, de manera sistemática, por la rotación del
personal crítico encargado del proyecto. También está sometido, como no, a los
cambios de requerimientos del cliente que a su vez están plenamente justificados por la
readaptación de sus procesos de negocio a un mercado inestable.
Ante este cuadro de incertidumbre, el mayor desafio de una metodología de desarrollo
es su adaptación para el cambio. Esto significa crear modelos que faciliten la
comunicación entre todos los agentes involucrados en el sistema en construcción; que
hagan visible la trazabilidad entre la concepción de los componentes, su especificación,
implementación e instalación; significa el diseño de arquitecturas que faciliten la
gestión de las dependencias entre estos componentes, que sean en fin, facilmente
reemplazables por otros más optimizados o bien por componentes que aporten una
mayor funcionalidad y/o facilidad de uso.
La dinámica de cambio no se desarrolla en la ingeniería del software con la misma
velocidad vertiginosa con que nos tiene acostumbrados la tecnología del hardware. La
clave reside en que a diferencia de la electrónica, en los dominios del desarrollo de
software no existe un vocabulario unificado. Desde la fase de concepción de un sistema
a la instalación de sus componentes hay que mapear entre sí una gran diversidad de
lenguajes orientados al análisis, diseño, código ejecutable, esquemas de bases de datos,
componentes de páginas web, entre otros. Esta distancia entre la concepción y la
usabilidad de un producto o de un proceso de negocio, exige cada vez más la capacidad
de cooperación y comunicación de un equipo interdisciplinar muy especializado. Esta
guía visual de UML está pensada para facilitar este proceso cooperativo y para ayudar a
establecer una buena práctica fundamentada en un lenguaje común.
vico.o
rg
Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org
Fecha actualización:
04/09/01 11:16 Revisión:
18 Página:
4 de 9
¿A quién va dirigida esta guía visual? Esta guía ha sido escrita y diseñada para los profesionales involucrados en todos los
ciclos de actividad del desarrollo de sistemas de información (concepción, análisis y
diseño, implementación, instalación de aplicaciones, gestión y certificación de
proyectos); también para los que tengan responsabilidades en la especificación de
procesos de negocio con el propósito de evaluar posibles reingenierías de procesos y/o
diseño de bases de conocimiento; y finalmente, para aquellos equipos que estén
inmersos en la preparación e implementación de certificaciones de calidad.
La claridad conceptual y los recursos didácticos utilizados en la exposición de los
distintos procedimientos serán de utilidad para los estudiantes que sigan programas de
autoaprendizaje y usen esta guía como complemento para sus lecturas de libros sobre
UML. También los centros académicos y profesores dispondrán con esta guía de
material interesante para completar sus diseños curriculares y proporcionar ejemplos
prácticos a sus alumnos.
¿Cómo sacar un mayor provecho a su lectura? La guía está organizada en unidades didácticas que describen la notación de los
diagramas y las fuentes de información necesarias para definir los elementos de cada
modelo. Puede usarse como consulta puntual de la notación 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 Especifiación (types e
interfaces) y las Clases de Implementación (código).
vico.o
rg
Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org
Fecha actualización:
04/09/01 11:16 Revisión:
18 Página:
5 de 9
Un plan de estudio para realizar una progresiva asimilación de los conceptos podría
empezar con los Casos de Uso (CU) y continuar con el análisis de los flujos de trabajo
de un grupo de CU mediante los diagramas de Actividad; a continuación, separar los
escenarios que agrupan una serie de actividades y hacer aflorar, a través de los
diagramas de Interacción, los objetos que intercambian una serie de mensajes. A partir
de este punto, disponemos del bagaje suficiente como para introducirnos en la
abstracción de los objetos y comprender la importancia de separar las tres perspectivas
básicas en nuestra representación de las clases: concepción, especificación e
implementación. 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-
Transición será el adecuado para representar esta dinámica de estados. Finalmente,
abordaremos la configuración de componentes y su despliegue en una arquitectura.
Otra lectura de la guía puede estar mas centrada en el seguimiento de la metodología de
desarrollo y la gestión de un proyecto. En este caso, las primeras secciones describen
los niveles de concepción y formalización de un proyecto con la metodología TRAD
(Taller de Requerimientos, Análisis y Diseño basado en el Proceso Unificado de
Rational), y se van introduciendo progresivamente los diagramas y actividades que
configuran la unidad mínima de documentación sostenible para un proyecto concreto.
El estudiante más avanzado podrá sacar también provecho con la consulta puntual de
los diagramas en que esté más interesado y la revisión de sus extensiones. Las materias
expuestas en las distintas secciones están actualizadas constantemente y pueden
descargarse nuevas ediciones desde: http://www.vico.org/UMLguiavisual/
vico.o
rg
Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org
Fecha actualización:
04/09/01 11:16 Revisión:
18 Página:
6 de 9
¿De dónde provienen las ideas expuestas? El contenido de esta guía 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 artículos publicados en el Journal of Object
Oriented Programming (JOOP) por James Odell, James Rumbaugh, Grady Booch,
Desmond d’Souza, 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 Manager’s Guide de
David A. Taylor, en su primera edición de 1990 y en la segunda ampliada de 1998, han
tenido una gran influencia en como abordar la presentación didáctica. También 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 enciclopédica The Unified Modeling Language: Reference Manual de Rumbaugh
& Jacobson & Booch, es un punto de referencia constante. Sin duda, uno de los autores
más influyentes ha sido Martin Fowler. Su primer libro Analysis Patterns continua
siendo una referencia clave. Posteriormente, la primera edición de UML Distilled en
1997 y su última edición ampliada en 2000, se ha convertido en el libro de cabecera de
UML. Otro clásico por la excelencia de su trabajo es Applying UML and Patterns de
Craig Larman que en su segunda edición aparecida en verano de 2001 se ha superado
a si mismo. También recientes y con muy buen material que ha sido incorporado a la
guía, 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 edición; y de John Chessman & John Daniels, UML
Components, una de las novedades más interesantes de 2001. En la bibliografía sobre
UML publicada en http://www.vico.org hay una relación completa de los libros
consultados que se actualiza periódicamente con las últimas novedades.
vico.o
rg
Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org
Fecha actualización:
04/09/01 11:16 Revisión:
18 Página:
7 de 9
Competencia y actuación En los últimos veinte años de mi carrera profesional en el desarrollo de sistemas de
información he participado en una gran diversidad de proyectos con distintos grados de
responsabilidad e involucración, pero siempre con un compromiso firme en la calidad y
usabilidad del producto final.
Entorno industrial
o CIM para la extrusión de polietileno y fabricación de mallas agrícolas y
de embalaje.
o CIM para el fraccionamiento de hemoderivados
o Plan Funcional para la implementación SAP-Logística
Entorno sanitario
o Gestión de Bancos de Sangre y Hemoterapia
o Planificación y gestión de campañas de captación de donantes
o Gestión mutual de prestaciones asistenciales
o Tarjeta Sanitaria para certificar transacciones asistenciales
o Automatización de autoanalizadores de laboratorios de análisis
o Integración de peticiones analíticas multicentricas y publicación de
resultados
o Gestión de laboratorios farmacéuticos
o Historia Clínica Orientada por Problemas Automatizada
o Libreta de Salud para programación de citas y exploraciones
o Gestión integrada de servicios de Atención Primaria
o Plan Funcional para la implementación SAP-Gestión Clínica y
Asistencial
vico.o
rg
Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org
Fecha actualización:
04/09/01 11:16 Revisión:
18 Página:
8 de 9
Entorno de ingeniería del software
o Framework de clases de análisis para definir mapas conceptuales
o Framework de servicios comunes para la publicación dinámica de
páginas HTML
o Framework de certificación de entregables
Entorno administrativo y de gestión
o Plan Funcional para la implementación SAP-Contabilidad
o Cuadro de control de indicadores de actividad y calidad
o Sistema de información Ejecutivo
Entorno comercial
o Merchandising de productos farmacéuticos
o Subastas y liquidación de lotes
o Gestión de redes de puntos de venta con videoconferencia
Entorno de servicios
o Auditorías Informáticas
o Plan de Sistemas de Información
o Integración de sistemas de información de contabilidad administrativa y
general
Entorno académico
o Programa de acceso a la universidad para mayores de 25 años
o Gestión de títulos universitarios
o Estudios de tercer cliclo: diseño curricular, publicación y gestión
académica
vico.o
rg
Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org
Fecha actualización:
04/09/01 11:16 Revisión:
18 Página:
9 de 9
Entorno docente
o Tutorías de proyectos de fin de carrera con UML
o Cursos de Análisis, Diseño y Patrones
o Talleres de introducción a UML
o Talleres avanzados de UML con Rose y Visio
o Talleres monográficos (Casos de Uso, Métrica, Metodología)
Entorno de I+D
o Bases de conocimiento con vocabularios controlados
o Procesador de lenguaje natural dentro del dominio médico
o Reconocimiento automático de conceptos clínicos 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. También a los autores antes mencionados por su valioso trabajo
en el avance de la disciplina de la ingeniería del software y en la consolidación de UML
como lingua franca.
Josep Vilalta
Badalona, Barcelona (España)
http://www.vico.org
Niveles de concepción y formalizaciónde un proyecto
Nivel ø
Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5
ProcesosPrincipales
Glosariode Conceptos
Matrículadel Proyecto
“Code like hell”
EspecificaciónCasos de Uso
Flujosde Trabajo
Có
di
go
DinámicaEventos - Estados
CronogramaPlan Director
Iteraciones
FuncionalidadDiagramas de
Casos de Uso
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Actor
Actor
C l a s e sA n á l i s i s
D i s e ñ o
I m p l e m e n t a c i ó n
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Verificando Sirviendo
EntregadoEsperando
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
Verificando Sirviendo
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
P
M
* [para cada pedido seleccionado]
EntrarReposición
SeleccionarPedidos
Pendientes
AsignarItems
RegularizarStock
ActivarPedido
EntrarReposición
EntrarReposición
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
PPDI
G
CUCU
EscenariosInteracción
de objetos
tieneStock:= comprobar ( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stockxxx línea : Línea de pedido
: Item de Expedición : Item de Pedido de reposición
tieneStock:( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stockxxx línea : Línea de pedido
: Item de Expedición : Item de Pedido de reposición
1©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D U
MD
_es
p -
Rev
. 5
.2 -
j
vila
lta@
vico
.org
Esfuerzo de desarrol loP D P
ProductoProcesosActividadesEntregables
TiempoFases
Iteraciones
M i s i ó n
Concepción Formalización Construcción Transición
I t e r a c i o n e s
Iteracionespreliminares Iter #1 Iter #2 Iter #n
Iter#n+1 Iter #n
Iter#n+2
Iter#n+1
M o d e l o
C o m p o n e n t e s
C e r t i f i c a c i ó n
P r o t o t i p o
© V
ilal
ta C
on
sult
ore
s 2
00
0 -
TR
AD
PD
P i
tera
cio
nes
_es
p -
Rev
. 4
.2 -
j
vila
lta@
vico
.org
2
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
PD
P m
isió
n_
esp
2 -
Rev
. 5
.2 -
j
vila
lta@
vico
.org
M i s i ó n
Concepción Formalización Construcción Transición
I t e r a c i o n e s
Iteracionespreliminares Iter #1 Iter #2 Iter #n
Iter#n+1 Iter #n
Iter#n+2
Iter#n+1
M o d e l o
C o m p o n e n t e s
C e r t i f i c a c i ó n
P r o t o t i p oPlan Director de ProyectoP D P
C o n c e p c i ó n
Anteproyecto
Patrones deAnálisis
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobaciónP
Patrones deFuncionalidad
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
Actor 2
Actor 1
<<Extiende >>
<<Incluye>>
Use Case
Use Case
Use Case
Use Case
Use Case
<<Incluye>>
<<Generalización>>
PProcesos
principalesMatrícula
del proyecto
Glosariode Conceptos
CronogramaPlan Director
Iteraciones
PM
PPDIG
Misión
3
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
PD
P m
od
elo
_es
p2
- R
ev.
5.3
-
jvi
lalt
a@vi
co.o
rg
M i s i ó n
Concepción Formalización Construcción Transición
I t e r a c i o n e s
Iteracionespreliminares Iter #1 Iter #2 Iter #n
Iter#n+1 Iter #n
Iter#n+2
Iter#n+1
M o d e l o
C o m p o n e n t e s
C e r t i f i c a c i ó n
P r o t o t i p oPlan Director de Proyecto
P D P
Fo r m a l i z a c i ó n
Patrones deAnálisis
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobaciónP
Patrones deFuncionalidad
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
Actor 2
Actor 1
<<Extiende >>
<<Incluye>>
Use Case
Use Case
Use Case
Use Case
Use Case
<<Incluye>>
<<Generalización>>
PModelo
FuncionalidadDiagramas de
Casos de Uso
C l a s e sA n á l i s i s
y D i s e ñ o
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Actor
Actor
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
EspecificaciónCasos de Uso
Flujos deTrabajo
DinámicaEventosEstados
Verificando Sirviendo
EntregadoEsperando
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
Verificando Sirviendo
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
CU * [para cada pedido seleccionado]
EntrarReposición
SeleccionarPedidos
Pendientes
AsignarItems
RegularizarStock
ActivarPedido
EntrarReposición
EntrarReposición
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
EscenariosInteracción
de objetos
tieneStock:= comprobar ( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stockxxx línea : Línea de pedido
: Item de Expedición : Item de Pedido de reposición
tieneStock:( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stockxxx línea : Línea de pedido
: Item de Expedición : Item de Pedido de reposición
4
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
PD
P c
on
stru
cció
n_
esp
2 -
Rev
. 5
.3 -
j
vila
lta@
vico
.org
M i s i ó n
Concepción Formalización Construcción Transición
I t e r a c i o n e s
Iteracionespreliminares Iter #1 Iter #2 Iter #n
Iter#n+1 Iter #n
Iter#n+2
Iter#n+1
M o d e l o
C o m p o n e n t e s
C e r t i f i c a c i ó n
P r o t o t i p oPlan Director de ProyectoP D P
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Alumno P. Global P. Esp. ResultadoSelección Ver
✔
✔
Destino
Versión
Tribunal
Año Académico*
**FechaActa
Alumnos
Frameworkde Aplicaciones
Patrones deDiseño
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
P
C o n s t r u c c i ó n
Alumno P. Global P. Esp. ResultadoSelección Ver
✔
✔
Destino
Versión
Tribunal
Año Académico*
**FechaActa
Alumnos
C l a s e sD i s e ñ o
I m p l e m e n t a c i ó n
Base de DatosEsquema de Persistencia
ArquitecturaComponentes
InterfaceGráfico de Usuario
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Componentes
5
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
PD
P_
esp
2 -
Rev
. 6
.2 -
j
vila
lta@
vico
.org
Fo r m a l i z a c i ó n
M i s i ó n
Concepción Formalización Construcción Transición
I t e r a c i o n e s
Iteracionespreliminares Iter #1 Iter #2 Iter #n
Iter#n+1 Iter #n
Iter#n+2
Iter#n+1
M o d e l o
C o m p o n e n t e s
C e r t i f i c a c i ó n
P r o t o t i p oPlan Director de ProyectoP D P
Modelo
FuncionalidadDiagramas de
Casos de Uso
C l a s e sA n á l i s i s
y D i s e ñ o
<< Extends >>
<< Uses >>
<< Communicates >>
Use Case
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Actor
Actor
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
EspecificaciónCasos de Uso
Flujos deTrabajo
DinámicaEventosEstados
Verificando Sirviendo
EntregadoEsperando
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
Verificando Sirviendo
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
CU * [para cada pedido seleccionado]
EntrarReposición
SeleccionarPedidos
Pendientes
AsignarItems
RegularizarStock
ActivarPedido
EntrarReposición
EntrarReposición
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
C o n c e p c i ó n
Anteproyecto
Procesosprincipales
Matrículadel proyecto
Glosariode Conceptos
CronogramaPlan Director
Iteraciones
PM
PPDIG
Misión
C o n s t r u c c i ó n
Alumno P. Global P. Esp. ResultadoSelección Ver
✔
✔
Destino
Versión
Tribunal
Año Académico*
**FechaActa
Alumnos
C l a s e sD i s e ñ o
I m p l e m e n t a c i ó n
Base de DatosEsquema de Persistencia
ArquitecturaComponentes
InterfaceGráfico de Usuario
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Componentes
EscenariosInteracción
de objetos
tieneStock:= comprobar ( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stockxxx línea : Línea de pedido
: Item de Expedición : Item de Pedido de reposición
tieneStock:( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stockxxx línea : Línea de pedido
: Item de Expedición : Item de Pedido de reposición
6
A la búsqueda de Actores.-
1. ¿ Quien está interesado en un requerimiento concreto ?
2. ¿ En qué dominios de la organización se usará el sistema ?
3. ¿ Quien será beneficiario de la nueva funcionalidad ?
4. ¿ Quien proveerá, usará y/o retirará, información ?
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 actuarán con un mismo rol ?
9. ¿ Interaccionará el nuevo sistema con un sistema antiguo ?
¿ Cómo identificar Actores ?
Sistema en proceso de modelado
Interacción de unActor con el Sistema
Interacción delSistema con un ActorCliente
- Role de usuario -
Actores
• Representan a un agente que interactúa con el sistema• No son parte del sistema que se desarrolla• Entran información al sistema• Reciben información del sistema• Entran y reciben información
Relación que indica laespecialización a partir de una
función genérica
Realizar unatransacción
Usar CajeroAutomático
<< Incluye >> Subsis temade cuentas
cl iente- Role de subsis tema -
Subsi temade cer t i f icación
de mediosde pago
- Role de subsis tema -
A c t i v a rTa r j e t a
R e t i r a rE f e c t i v o
C o n s u l t a rM o v i m i e n t o s
<<Generaliza>>
<<Generaliza>>
<<Generaliza>>
FuncionalidadDiagramas deCasos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Actor
Actor
1©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D A
cto
res_
esp
- R
ev.
5.1
-
jvi
lalt
a@vi
co.o
rg
A la búsqueda de Casos de Uso.-
1. ¿ Cuales son las tareas y responsabilidades de cada actor ?
2. ¿ Algún actor creará, almacenará, cambiará, borrará o leerá información del sistema ?
3. ¿ Qué Casos de Uso crearán, almacenarán, cambiarán, borrarán o leerán esta información ?
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 darán soporte y mantendrán el sistema ?
7. ¿ Pueden ser realizados por los Casos de Uso todos los requerimientos funcionales documentados ?
¿ Cómo identificar Casos de Uso ?
Abrir ArqueoHacer un
Inicio de Día
Hacer unFin de Día
Exportarmovimientos
Piezas de funcionalidad del sistemaque suministran valor a un Actor y son
reutilizables en diferentes procesos
Relación que describe una variaciónposible del comportamiento normal
de un Use Case
Relación que permite descomponerun Use Case con un determinado
nivel de granularidad
Imprimirdocumento
Sistema en proceso de modelado
Interacción de unActor con el Sistema
Interacción delSistema con un Actor
Supervisor- Rol de usuario -
Importar nuevaconfiguración
Contabi l idad- Sis tema externo -
Cajero- Rol de usuario - Cerrar Arqueo
<< Incluye >>
<< Extiende >>
<< Incluye >>
<< Incluye >>
<< Extiende >>
Relación que indica el uso deuna funcionalidad compartida
por otros Casos de Uso
FuncionalidadDiagramas deCasos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Actor
Actor
2©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D U
Cs_
esp
- R
ev.
5.1
-
jvi
lalt
a@vi
co.o
rg
Especificaciónde un Caso de Uso
LIMIT
Límites: Cuando empieza y cómo termina el Caso de Uso.
Interacciones: Comportamiento de Actores y Sistema.Acción-Reacción dentro del Caso de Uso.
Masa: Conjunto de Objetos e Interfaces que requiereel Caso de Uso.
Índice de escenarios: Flujo principal de eventos y secuenciade variaciones posibles dentro de un Caso de Uso.
Tribulaciones: Contingencias probables que pueden afectaral flujo de los eventos y son excepciones del Caso de Uso.
Propósito- Regla de Negocio - Precondiciones Activación Flujo Principal Variaciones Excepciones
Cerrar un periodo demovimientos de cajapara obtener unasituación real de dineroen efectivo y endocumentos.
• Arqueo abierto• Actor habilitado• TPV abierto• TPV habilitado
• A discreción de un Actorhabilitado
1. Sistema requiere confirmación decierre de arqueo.
a. Si Actor decide aparcar el cierre de arqueo,sistema activa UC Aparca_arqueo y terminael UC.
2. Sistema comprueba la configuraciónde TPV para identificar tipo de cierre.
3. Sistema calcula los totales teóricospara cada forma de cobro.
4. Actor introduce totales reales para cadaforma de cobro.
5. Sistema registra el cierre: importesreales para cada forma de cobro ydescuadres.
6. Sistema imprime el documento “Tirade Arqueo”.
a. Cierre de arqueo de tipo abierto:• Actor decide el momento de imprimir el
documento “Tira de Arqueo”.
a. Si el servidor está off-line, sistema informaal usuario, termina el UC manteniendo elarqueo abierto.
b. Cierre de arqueo de tipo ciego:• Sistema no muestra los totales teóricos para
cada forma de cobro.
a. Si impresora está off-line, sistema informaal usuario y le pide confirmación paracontinuar.
Hacer unFin de Día
Imprimirdocumento
Cerrar Arqueo << Extiende >>
<< Incluye >>
Caso de Uso principal
Casos de Uso secundarios
Caso de Uso especializadoCaso de Uso genérico
<<Generaliza>>Imprimir
t i ra de arqueo
FuncionalidadDiagramas deCasos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Actor
Actor
3©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D L
IMIT
UC
s_es
p -
Rev
. 5
.1 -
j
vila
lta@
vico
.org
Ventajas del modeloUse Case
Piezas de funcionalidad reutilizablesen diferentes procesos de negocio
1. Lenguaje de comunicación entre usuariosy desarrolladores.
2. Comprensión detallada de la funcionalidaddel sistema.
3. Acotación precisa de las habilitaciones delos usuarios.
4. Gestión de riesgo más eficiente paragobernar la complejidad.
5. Estimación más exacta para determinartiempo, recursos y prioridades en la dosificaciónde esfuerzo de desarrollo.
6. Fiel trazabilidad para verificar la traducciónde requerimientos en código ejecutable.
7. Mayor control para mantener las sucesivasrevisiones de los programas.
8. Certificación contractual Cliente-Desarrollador.
9. Documentación orientada al usuario: Helps- Manual de Procedimientos - Reglas de Negocio.
10. Documentación orientada al administradordel sistema: Soporte de Mantenimiento.
Hacer unInicio de Día
Exportarmovimientos
Imprimirdocumento
Importar nuevaconfiguración
Cerrar Arqueo
<< Incluye >>
<< Extiende >>
<< Extiende >>
<< Incluye >>
<<Generaliza>>
Hacer unFin de Día
<< Incluye >>
Imprimirt i ra de arqueo
Abrir Arqueo
FuncionalidadDiagramas deCasos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Actor
Actor
4©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D m
od
elo
UC
_es
p -
Rev
. 5
.1 -
j
vila
lta@
vico
.org
Requerimientos y Casos de UsoLos Casos de Uso son requerimientos funcionales que describende una manera detallada el comportamiento del sistema conlos distintos Actores que interactúan con él.
No definen todos los requerimientos (por ej. los tipos dedatos, interfaces externas, niveles de rendimiento esperado,etc.), pero representan el hilo conductor que vincula a todoslos requerimientos posibles (actuales y futuros) de unaaplicación.
Caso de Uso
Requerimientos
Mod
elo
Arquitectu
ra
Gestión
de Proyecto
Cer
tif i
caci
ón
Reglasde Negocio
y protocolos deintercambio de
información
Funcionales,no funcionalese interfaces de
usuario
Mapa conceptual:Clases de análisis
Dinámica deClases complejas
Mapa funcional:Flujos de trabajo
principales yvariaciones
Escenarios deinteracciónde objetos:
Clases de diseño
Métrica:Escandallo de
recursosy actividades
Plan Directorde Iteraciones:
Cronogramay prioridades
Funcionalidad,Análisis y Diseño
Implementaciónde código yRefactoring
FuncionalidadDiagramas deCasos de Uso
<< Extends >>
Use Case
<< Uses >>
<< Communicates >>
Actor
Actor
5©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D R
eq y
CU
s_es
p -
Rev
. 1
.1 -
j
vila
lta@
vico
.org
Descripciónde un Flujo de Trabajo
Un flujo de trabajo muestra la secuencia de actividadesque se desarrollan dentro de uno o varios Casos deUso, como una pieza de funcionalidad concreta quesatisface los requerimientos de un Actor.
Diagrama de ActividadNotación UML 1.3
* [para cada línea de pedido]
Concurrencia dinámica de actividades
Recepciónde un
Pedido
[SI vigente]
[NO]
Barra de sincronización
Actividad
Punto de decisión
Barra de fusión
Condición lógica: verdadera o falsa,que permite la transicióna otra actividad
Evento quedesencadenala secuencia deactividades
Análisis textualdel Caso de Uso
F l u j o P r i n c i p a l Va r i a c i o n e s
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba cada línea delpedido para validar la situación delartículo en catálogo y el número deitems del artículo en stock.
4. Sistema comprueba la situación delpedido .
a. SI se ha realizado el pago y SI todos los itemsdel pedido han sido asignados, sistemainforma que procede a servir el pedidoactivando el CU Servir pedido.
b. SI se ha realizado el pago y NO existensuficientes items del artículo en stock, sistemaaparca el pedido del cliente activando el CUAparcar pedido.
c. SI no se ha realizado el pago según el plazoconvenido, sistema cancela el pedido.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO existen suficientes items del artículo enstock, o la asignación de items deja lasituación del artículo en stock por debajo delnivel de reposición, sistema genera pedidode reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra artículos alternativos activando elCU Seleccionar artículo.
[NO vigente]
[NO Stock] o[SI umbral reposición]
[SI]
[Todos los items asignados] [Faltan items por asignar]
CancelarPedido
IdentificarCliente
Entrarlíneas pedido
ComprobarArtículo
ComprobarPago
ServirPedido
Generarreposición
SeleccionarArtículo alternativo
AsignarItems
Comprobarsituación Pedido
AparcarPedido
Flujos deTrabajo
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
1
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
Act
ivid
ad 1
_es
p -
Rev
. 7
.1 -
j
vila
lta@
vico
.org
Descripciónde un Flujo de Trabajo
Diagrama de ActividadNotación UML 1.3
* [para cada pedidoseleccionado]
Recepciónde una
Reposición
[Todos los items asignados] [Todos las reposiciones entradas]
F l u j o P r i n c i p a l
1. Usuario recepciona albaranes dereposición que ha enviado un proveedor.
2. Sistema localiza los pedidos de clientesaparcados que pueden cumplimentarsecon la nueva entrada de items.
3. Usuario selecciona los pedidos declientes aparcados que decidecumplimentar.
4. Sistema asigna los items pendientes alos pedidos de cliente seleccionados.
5. Sistema informa que procede a servirel pedido activando el CU Servirpedido..
6. Sistema regulariza la situación de itemsen stock y revisa los umbrales dereposición automática.
Una diagrama de actividad describe una secuencia deactividades que pueden exhibir un comportamiento enparalelo o estar sujetas a condiciones lógicas.
Los procesos de negocio no muestran siempre una secuenciafija en su desarrollo, es una ventaja así poder modelarbloques de actividades sin restricciones de concurrencia.
Transición de una actividad a otra sujetaa una condición lógica.
Sincronización de actividades quepueden ocurrir en paralelo.
CU Actualizar reposición
ServirPedido
SeleccionarPedido
AsignarItems
Fin de la secuencia deactividades
Análisis textualdel Caso de Uso
EntrarReposición
BuscarPedidos aparcados
RegularizarStock
Flujos deTrabajo
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
2©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D A
ctiv
idad
2_
esp
- R
ev.
5.2
-
jvi
lalt
a@vi
co.o
rg
Descripciónde un Flujo de Trabajo
Diagrama de ActividadNotación UML 1.3
Un diagrama de actividad puede mostrar la secuencia deactividades que se desarrolla en un paquete de Casos deUso que define un proceso de negocio y sus áreas deresponsabilidad.
[SI éxito]
[NO éxito]
Contabilidad Comercial Almacén
Líneas para acotaráreas de responsabilidad(swim-lines)
* [para cada línea de pedido]
Recepciónde un
PedidoIdentificar
Cliente
Entrarlíneas pedido
ComprobarPago
CancelarPedido
[NO Stock]o [SI umbral reposición]
Generarreposición
EntrarReposición
[Recepción de Reposición]
[SI vigente]
[NO vigente]Seleccionar
Artículo alternativo
[Todos los items asignados] [Faltan items por asignar]
ServirPedido
Comprobarsituación Pedido
AparcarPedido
* [para cada pedidoseleccionado]
SeleccionarPedido
BuscarPedidos aparcados
[Todos las reposiciones entradas]
RegularizarStock
ComprobarArtículo
AsignarItems
Flujos deTrabajo
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
3©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D A
ctiv
idad
3_
esp
- R
ev.
6.1
-
jvi
lalt
a@vi
co.o
rg
Descripciónde un Flujo de Trabajo
Diagrama de ActividadNotación UML 1.3
Su objetivo no es relacionar actividad con objetos, sólocomprender qué actividades son necesarias y cuales son susrelaciones de dependencia.
El diagrama de actividad nos permite definir en qué ordense van a realizar distintas tareas. Los diagramas de flujo(flowchart) sólo nos permiten modelar procesos secuenciales,mientras que los diagramas de actividad nos permitenestablecer procesos en paralelo.
ComprobarCliente habitual
Importe> 150.000
ComprobarCrédito
Pre-Pagorequerido
[Tarjeta de Crédito]
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]
Autorización
[Efectivo]
Descomposiciónde la actividad
ComprobarPago
ComprobarPago
ComprobarCheque
Comprobarhistorial pagos
AbrirCuenta Cliente
Pueden procesarse distintasmodalidades de pago demanera simultanea
Flujos deTrabajo
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
4©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D A
ctiv
idad
4_
esp
- R
ev.
5.2
-
jvi
lalt
a@vi
co.o
rg
Descripciónde un Escenario
Diagrama de SecuenciaNotación UML 1.3
2:generarPedido ( )
4:generarLíneaPedido ( )
5:comprobarStock ( )
6:asignarItems ( )
7:realizarReposición ( )
Objetos queinteractúan
Mensaje
Auto-mensaje
Línea de vidade un objetodurante la interacción
(1)
Mensajes enviados entre los objetos descritos enel flujo de eventos de un Caso de Uso.
Estos mensajes muestran el nivel de colaboraciónentre los distintos objetos existentes e indicancuando se requiere generar nuevos objetos paracumplir con las responsabilidades asignadas.
(1)
Utilizamos dos diagramas de interacción:a/. Secuenciab/. Colaboración
Su finalidad es describir los mensajes que intercambian losdistintos objetos para cumplir con las responsabilidadesdefinidas en un escenario concreto de un Caso de Uso.
• Diagrama de Secuencia.- Representa lasinteracciones de objetos ordenadas en una serie temporalque muestra su ciclo de vida.
1:indentificarCliente ( )
8:generarReposición ( )
Creación deun nuevoobjeto
Un escenario muestra de que manera interactúan los distintosobjetos dentro del flujo principal de eventos de un Caso deUso con alguna variación o extensión concreta del mismo.
:Comercial
3:entrarLíneaPedido ( )
Análisis textualdel Use Case
F l u j o P r i n c i p a l Va r i a c i o n e s
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba cada línea delpedido para validar la situación delartículo en catálogo y el número deitems del artículo en stock.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO existen suficientes items del artículo enstock, o la asignación de items deja lasituación del artículo en stock por debajo delnivel de reposición, sistema genera pedidode reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra artículos alternativos activando elCU Seleccionar artículo.
:Una Carterade Itemsen Stock
:Un Pedidode
Reposición
:Una Ventana deintroducción de
Pedidos:Un Pedido
:Una Líneade Pedido
Escenarios
tieneStock:( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stockxxx línea : Línea de pedido
: Item de Expedición : Item de Pedido de reposición
1©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D S
ecu
enci
a_es
p -
Rev
. 6
.1 -
j
vila
lta@
vico
.org
Descripciónde un Escenario
Diagrama de ColaboraciónNotación UML 1.3
2: generarPedido ( ) 5: comprobarStock ( )
6: asignarItems ( )
7: realizarReposición ( )
Objeto(Instancia de una Clase)
Auto-mensaje
8: generarReposición ( )
Número de secuencia
Mensajes enviados entre los objetos descritos enel flujo de eventos de un Caso de Uso.
Estos mensajes muestran el nivel de colaboraciónentre los distintos objetos existentes e indicancuando se requiere generar nuevos objetos paracumplir con las responsabilidades asignadas.
(1)
Un escenario describe una instancia del flujo de eventos deun Caso de Uso, con sus variaciones o extensiones posiblesy las excepciones probables.
• Diagrama de colaboración.- Representa unaposible interacción de los objetos ordenados a partirde la topología que muestra el envio de sus mensajes.
Con un escenario representamos el conjunto de eventos queconfigura el comportamiento de un Caso de Uso.
Enlace entredos objetos
Dirección del mensaje
Utilizamos dos diagramas de interacción:a/. Secuenciab/. Colaboración
Su finalidad es describir los mensajes que intercambian losdistintos objetos para cumplir con las responsabilidadesdefinidas en un escenario concreto de un Caso de Uso.
Análisis textualdel Use Case
F l u j o P r i n c i p a l Va r i a c i o n e s
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba cada línea delpedido para validar la situación delartículo en catálogo y el número deitems del artículo en stock.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO existen suficientes items del artículo enstock, o la asignación de items deja lasituación del artículo en stock por debajo delnivel de reposición, sistema genera pedidode reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra artículos alternativos activando elCU Seleccionar artículo.
: Comercial
: Una Ventana de introducción de Pedidos
: Un Pedido
: Una Línea de Pedido
:Una Cartera de Items en Stock
: Un Pedido de ReposiciónEscenarios
tieneStock:( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stockxxx línea : Línea de pedido
: Item de Expedición : Item de Pedido de reposición
1: identificarCliente ( )
3: entrarLíneaPedido ( )4: generarLíneaPedido ( )
Mensaje (1)
2©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
ola
bo
raci
ón
_es
p -
Rev
. 6
.1 -
j
vila
lta@
vico
.org
ClasesDesde una perspectiva conceptual, una Clase representa unconjunto de Objetos que comparten:
• Las mismas propiedades (Atributos)• El mismo comportamiento (Métodos)• Las mismas relaciones con otros Objetos (Mensajes)• La misma semántica dentro del sistema
Un Objeto representa una entidad del mundo real o inventada.Es un concepto, una abstracción o algo que dispone de unoslímites bien definidos y tiene una significación para el sistemaque se pretende modelar.
Estructura y función:• Identidad ¿Quien soy? = Atributos• Propósito ¿Cual es mi misión? = Justificación• Responsabilidades ¿Qué debo hacer? = Métodos• Procedencia ¿De qué Clase provengo? = Origen• Relaciones ¿Qué mensajes entiendo? = Comportamiento
Objetos
Desde una perspectiva física, una Clase es una pieza de softwareque actua como un molde para fabricar tipos particulares deobjetos que disponen de los mismos atributos y métodos.
Estos elementos que configuran cada tipo de objeto sólo sedefinen una vez, cuando especificamos la estructura de la Clasea 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 ClasesNotación UML 1.3
PedidoFechaRecibidoConPrepagoNúmeroImporteDivisa...
Cliente
Línea de Pedido
Producto
Representante
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
facturarMes( )recordar( )
aceptar ( )
valorarCredito( ): string
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
NombreDireccion
NombreContactoValoracionCreditoLimiteCredito
NumTargetaCredito
CantidadImporteCumplimentada
Objetos Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
1©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
lase
s 1
_es
p -
Rev
. 6
.1 -
j
vila
lta@
vico
.org
Abstracción
método 4
mét
odo 1
Atributos
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
método 2
mét
odo 3
A partir de una abstracción del mundo real, definimosobjetos que representan micromódulos de software ideales.Desde su creación, se mantienen de manera independienteunos de otros, sólo interaccionan con otros objetos a travésde sus mensajes. Cada objeto configura un universo ordenadoy autosuficiente.
vacp 104
2©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
lase
s 2
_es
p -
Rev
. 3
.1 -
j
vila
lta@
vico
.org
Objeto
elevarPlataforma
carg
arIte
m
Atributos
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
moverHacia
bajarP
lataf
orma
Variables.-
• Identificación• Medidas de la carga• Capacidad de carga• Velocidad máxima• Tipo de carga
Estado.-
• Localización• Orientación• Velocidad
Todo lo que un objeto “conoce” está representado en susatributos (variables y estado actual), y todo lo que puede“realizar” está definido en sus métodos (comportamiento),y en sus “interacciones” con otros objetos a través delintercambio de mensajes (dinámica del ciclo de vida).
Vehículo Automático Carga Paletsvacp104
¿Qué puedo hacer?
¿Qué conozco?
¿Quien soy?
3©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
lase
s 3
_es
p -
Rev
. 2
.2 -
j
vila
lta@
vico
.org
Mensaje
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Una aplicación orientada a objetos consiste en un númerodeterminado de objetos que interactuan entre si enviándosemensajes unos a otros para invocar sus métodos. Esteintercambio de mensajes facilita su comportamiento, cambiosde estado, destrucción o almacenamiento.
Ya que todo lo que un objeto puede realizar está expresadoen sus métodos, este simple mecanismo de mensajes soportatodas las posibles interacciones entre ellos.
elevarPlataforma
carg
arIte
m
Atributos
moverHacia
bajarP
lataf
orma
Objeto Receptor
vacp104 moverHacia: binB7Objeto Emisor
Nombre del objeto receptor
Método que se invoca para que lo ejecute el objeto receptor
Parámetro enviado para especificar el método
Signatura del mensaje
vacp104
4©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
lase
s 4
_es
p -
Rev
. 1
.2 -
j
vila
lta@
vico
.org
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
El empaquetado de métodos y atributos dentro de un objetomediante una interface de mensajes, es lo que denominamosencapsulación.
La clave está precisamente en este envoltorio del objeto.La interface que rodea por completo al objeto actúa comopunto de contacto para todos los mensajes que llegan desdecualquier objeto emisor.
La interface de mensajes tiene la misma función que lamembrana de una célula, disponer de una barrera esencialentre la estructura interna de un objeto y el exterior.
Su propósito es garantizar que todas las interacciones delobjeto tengan lugar a través de un sistema de mensajeríapredefinido con el que es capaz de entenderse y reaccionaradecuadamente.
No existe ninguna otra manera con la que un objeto externopueda acceder a los atributos y métodos escondidos dentrode la interface de mensajes de otro objeto.
Encapsulación
M e n s a j e
Interface de mensajes
vacp104 moverHacia: binB7
vacp104
elevarPlataforma
carg
arIte
m
Atributos
moverHacia
bajarP
lataf
orma
Conjunto de operacionesexternamente visibles quedefine el comportamiento
de un objeto
5©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
lase
s 5
_es
p -
Rev
. 3
.1 -
j
vila
lta@
vico
.org
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Es el mecanismo por el cual una clase de objetos puede serdefinida como un caso especial de otra clase más genérica.Los casos especiales de una clase se denominan Subclases.La clase más genérica, se conoce como la Superclase detodos sus casos especiales. Además de los métodos y atributosque heredan, las Subclases definen sus propios métodos yatributos. Tambien, pueden redefinir algunos de losheredados (overriding).
Herencia
Vehículo Automático Carga Palets
vac 104
vac 104
vac 103
vacp 104
Instancias deVehículo Automático Carga Palets
Interface de mensajes
Identificador del objeto
Métodos
Atributos
La interface de mensajes definida para una Superclasetambién es heredada por las subclases. Esto implica quetodas las Subclases de una Superclase estan preparadaspara responder correctamente a los mismos mensajes quela Clase padre. Esta propiedad es extremadamente útilporque nos permite tratar de la misma manera a todas lasespecializaciones de una Clase.
Vehículo AutomáticoCarga Palets
SubClase
Vehículo AutomáticoCarga Bobinas
SubClase
Vehículo Automático de Carga
SuperClase
elevarPlataforma
carg
arIte
m
Atributos
moverHacia
bajarP
lataf
orma
vacp 104
6©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
lase
s 6
_es
p -
Rev
. 1
.2 -
j
vila
lta@
vico
.org
Composición
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Enter title here
Los objetos que contienen a otros objetos se denominanObjetos Compuestos. Los atributos de un objeto puedenutilizarse de dos maneras. Podemos usarlos para almacenarvalores como el número 15, o bien, el texto “Autorizado”.
Panel de ventana
También pueden contener referencias de otros objetos. Lasreferencias almacenadas en los atributos de un objetocompuesto, permite a este objeto enviar los mensajesapropiados a todos los objetos contenidos.
Tab Tab control
Scroll
Combo box
Slider
Trackbar
67%
Progress
Campo simple
Botones de ventanaRestore Maximize
?Help Minimize
CloseList box
Grid
Enter title here
< Back Next > Cancel
Ventana Wizard
7©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
lase
s 7
_es
p -
Rev
. 2
.1 -
j
vila
lta@
vico
.org
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Diferentes objetos pueden responder a un mismo mensajede diferentes maneras. El polimorfismo permite a los objetosinteractuar entre ellos sin necesidad de conocer previamentea que tipo pertenecen.
Un objeto puede ser de diferentes tipos. Por ejemplo unvehículo automático de carga puede especializarse paracargar bobinas, palets u otro tipo de items. Los demásobjetos del sistema no tienen porque saber cuantos tiposde vehículos disponemos.
El mismo mensaje cargarItem, acompañado del parámetroque identifica dicho item, será intrepretado de distintamanera por cada objeto receptor, el cual ya conocepreviamente como tiene que tratar la naturaleza de sucarga: bobinas, palets, etc.
Hay una reducción de esfuerzo muy significativa por elhecho de que cualquier objeto del sistema puede enviarmensajes a los vehículos automáticos de carga sin necesidadde saber de antemano qué tipo de vehículos estan encirculación.
No hay necesidad así de picar un código específico paracada tipo de vehículo, con lo cual, nos ahorramos prolijassentencias IF o CASE que son complejas de mantener y deactualizar cuando se incorporan nuevos tipos de objetos.
Polimorfismo
M e n s a j e
cargarItem: #A234C19FZ
Vehículo AutomáticoCarga Palets
SubClase
Vehículo AutomáticoCarga Bobinas
SubClase
elevarPlataforma
carg
arIte
m
Atributos
moverHacia
bajarP
lataf
orma
vacb 117elevarPlataform
a
carg
arIte
m
Atributos
moverHacia
bajarP
lataf
orma
vacp 104
Vehículo Automático de Carga
SuperClase
8©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
lase
s 8
_es
p -
Rev
. 1
.1 -
j
vila
lta@
vico
.org
Visibilidad•Toda Clase encapsula unos elementos (atributos y operaciones) que disponende ciertos criterios de visibilidad y manipulación para otras Clases.•Los elementos públicos pueden ser usados por cualquier otra Clase.•Los elementos privados pueden ser usados sólo por la Clase propietaria.•Cada plataforma de desarrollo (C++, Smalltalk, Java) desarrolla sus propiasreglas con respecto a la visibilidad y manipulación de atributos y operaciones.•La notación UML especifica que todo atributo y operación de una Clase hade disponer de un indicador de visibilidad.
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Visibilidad C++ Smalltalk Java
+ Publica
- Privada
# Protegida
Package
Ejemplos
Un elemento siempre es visible en cualquierparte del programa y puede ser llamado ymodificado por cualquier objeto delsistema.
Un elemento sólo puede ser usado por laClase que lo define.
Un elemento sólo puede ser usado por laClase que lo define, o por las subclases dedicha Clase.
Consideremos la Clase CLIENTE que disponede una subclase CLIENTE PERSONAL.Consideremos también que el objeto <<JosepV.>>, es una instancia de CLIENTEPERSONAL.<<Josep V.>>• Puede usar todo elemento público de cualquierobjeto del sistema.• Puede usar también todo elemento privado dela Clase CLIENTE PERSONAL.• No puede usar los elementos privados definidosen la Clase CLIENTE.• Puede usar los elementos protegidos definidospara CLIENTE y CLIENTE PERSONAL.
Todas las operaciones sonpúblicas por defecto.
Todas las variablesinstanciadas son privadas.
<<Josep V.>>, puede acceder acualquier variable instanciada dentrode su propio objeto, si dicha variableha sido definida dentro de CLIENTEo CLIENTE PERSONAL. De estamanera, el concepto de visibilidadprivada en Smalltalk es parecido alconcepto de visibilidad protegida enC++.
Consideremos la instancia de CLIENTEPERSONAL, <<Miquel M.>>, este objetopuede acceder a cualquier elemento de <<JosepV.>>, que ha sido definido también como unainstancia de CLIENTE PERSONAL, seapúblico, privado o protegido. <<Miquel M.>>,a su vez también puede acceder a cualquierelemento privado, protegido o público de<<Josep V.>>
En C++, podemos acceder a elementos de otrosobjetos de la propia Clase, de la misma maneraque podemos acceder a los propios elementosde un objeto.
En Smalltalk no hay diferencia conrespecto a que un objeto sea de lamisma Clase o no. Podemos accedersólo a los elementos públicos de otroobjeto.
En Smalltalk, <<Miquel M.>>, nopuede acceder a las variablesinstanciadas privadas de <<JosepV.>>, sólo a sus operaciones públicas.
Un elemento siempre es visible encualquier parte del programa y puedeser llamado y modificado por cualquierobjeto del sistema.
Un elemento sólo puede ser usado porla Clase que lo define.
Un elemento puede ser usado porsubclases y también por cualquier otraClase en el mismo Package como laClase propietaria. Esto implica que enJava, el concepto de visibilidadprotegida es más público que package.
Un elemento sólo puede ser usado porotras Clases que compartan el mismoPackage.
Pedido- fechaRecibidoconPrepago- número: Alfanúm.- importe: Núm&2d.- divisa...
Cliente
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*
0..1
*
* 1
+ hacer /comprobaciónitem
+ hacer /comprobación
+ crear ()+ seleccionar ( )+ comprobar ( )+ servir ( )+ cerrar ( )
Java permite marcar también las Clasescomo públicas o packages. Los elementosde una Clase pública pueden ser usados porcualquier Clase que importe el package ala que pertenece la Clase.Los elementos de una Clase package sólopueden ser usados por otras Clases delmismo package.
Línea de Pedido
+ hacer /comprobación
9©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D C
lase
s v
isib
ilid
ad_
esp
- R
ev.
5.3
-
jvi
lalt
a@vi
co.o
rg
Descripciónde la Dinámica del Sistema
La dinámica de un sistema está determinada por:
• Todos los posibles estados que sus objetos pueden tener.
• Todas las posibles secuencias de eventos que puedenocurrir.
• Todas las transiciones posibles, de un estado a otro,como consecuencia de los eventos que afectan a los objetos.
Diagrama de Estadosde un PedidoNotación UML 1.3
Comprobando Sirviendo
EntregadoEsperando
/seleccionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles][No todos los items comprobados]
/seleccionar siguiente item
[Todos los items comprobados &&algunos items no estan disponiblesen stock]
Item Recibido[algunos items no estan disponiblesen stock]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Pedido Entregado
1
2
3
4
5
6
1
DinámicaEstados
Verificando Sirviendo
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
F l u j o P r i n c i p a l Va r i a c i o n e s
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba cada línea delpedido para validar la situación delartículo en catálogo y el número deitems del artículo en stock.
4. Sistema comprueba la situación delpedido .
a. SI se ha realizado el pago y SI todos los itemsdel pedido han sido asignados, sistemainforma que procede a servir el pedidoactivando el CU Servir pedido.
b. SI se ha realizado el pago y NO existensuficientes items del artículo en stock, sistemaaparca el pedido del cliente activando el CUAparcar pedido.
c. SI no se ha realizado el pago según el plazoconvenido, sistema cancela el pedido.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO existen suficientes items del artículo enstock, o la asignación de items deja lasituación del artículo en stock por debajo delnivel de reposición, sistema genera pedidode reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra artículos alternativos activando elCU Seleccionar artículo.
PedidofechaRecibidoconPrepagonúmero: Alfanúm.importe: Núm&2d.divisa...
*
1
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
Análisis textualdel Use Case
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
Din
ámic
a 1
_es
p -
Rev
. 5
.1 -
j
vila
lta@
vico
.org
Descripciónde la Dinámica del Sistema
Diagrama de Estadosde un PedidoNotación UML 1.3
Comprobando Sirviendo
EntregadoEsperando
/seleccionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[No todos los items comprobados]/seleccionar siguiente item
[Todos los items comprobados &&algunos items no estan disponiblesen stock]
Item Recibido[algunos items no estan disponiblesen stock]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Pedido Entregado
PedidofechaRecibidoconPrepagonúmero: Alfanúm.importe: Núm&2d.divisa...
*
1
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
InicioClase
Atributos
Operaciones
primera Transición
E s t a d o
Actividad
Acción
Acción
Indicador
Auto-Transición
Transición
12
Evento3
Utilizamos el diagrama de estados para describir elcomportamiento de una Clase dentro de una serie temporal.
4
5
6
Procesos que ocurren de manera rápidadentro de un ciclo contínuo sin interrupción.
/ Acción Transición
Desencadenasiempre
la Transición
[Indicador] TransiciónCondición lógica con dos categorias: “verdadero” o “falso”.Una Transición con [Indicador] sólo ocurre si este es “verdadero”.Sólo podemos extraer una Transición para un Estado concreto.
[Todos los items comprobados &&todos los items disponibles]
2
DinámicaEstados
Verificando Sirviendo
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
Sintaxis para etiquetar una transición
Evento [Indicador] / Acción
Los tres elementos son opcionales
Análisis textualdel Use Case
F l u j o P r i n c i p a l Va r i a c i o n e s
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba cada línea delpedido para validar la situación delartículo en catálogo y el número deitems del artículo en stock.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO existen suficientes items del artículo enstock, o la asignación de items deja lasituación del artículo en stock por debajo delnivel de reposición, sistema genera pedidode reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra artículos alternativos activando elCU Seleccionar artículo.
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
Din
ámic
a 2
_es
p -
Rev
.- 5
.1 -
j
vila
lta@
vico
.org
Descripciónde la Dinámica del Sistema
Diagrama de Estadosde un PedidoNotación UML 1.3
Comprobando Sirviendo
EntregadoEsperando
/seleccionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles][No todos los items comprobados]
/seleccionar siguiente item
[Todos los items comprobados &&algunos items no estan disponiblesen stock]
Item Recibido[algunos items no estan disponiblesen stock]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Pedido Entregado
Construimos el diagrama de estados a partir de una claseconcreta para mostrar el comportamiento de un objetodurante su ciclo de vida.
Inicio
primera Transición
E s t a d o
Actividad
Acción
Acción
Indicador
Auto-Transición
Transición
Impl
emen
taci
ón
Cuando una Transición no dispone de un Eventoen su etiqueta, significa que la Transición serealiza tan pronto como la Actividad asociadacon un Estado es finalizada
Procesos que ocurren de manera rápidadentro de un ciclo contínuo sin interrupción.
/ Acción Transición
/ Actividad EstadoProcesos que ocurren dentro de un ciclo discontínuoy pueden ser interrumpidospor algun evento.
[Indicador] TransiciónCondición lógica con dos categorias: “verdadero” o “falso”.Una Transición con [Indicador] sólo ocurre si este es “verdadero”.Sólo podemos extraer una Transición para un Estado concreto.
12
Evento3
No hay Actividades para este Estado, por loque el Pedido permanecerá a la espera deun Evento.
Desencadenasiempre
la Transición
Aunque finalize la Actividadel Pedido permanecerá eneste Estado hasta que ocurreel Evento que desencadenasu Transición
4
5
6
3
DinámicaEstados
Verificando Sirviendo
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
Análisis textualdel Use Case
F l u j o P r i n c i p a l Va r i a c i o n e s
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba cada línea delpedido para validar la situación delartículo en catálogo y el número deitems del artículo en stock.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO existen suficientes items del artículo enstock, o la asignación de items deja lasituación del artículo en stock por debajo delnivel de reposición, sistema genera pedidode reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra artículos alternativos activando elCU Seleccionar artículo.
PedidofechaRecibidoconPrepagonúmero: Alfanúm.importe: Núm&2d.divisa...
*
1
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
Clase
Atributos
Operaciones
Sintaxis para etiquetar una transición
Evento [Indicador] / Acción
Los tres elementos son opcionales
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
Din
ámic
a 3
_es
p -
Rev
. 5
.1 -
j
vila
lta@
vico
.org
Descripciónde la Dinámica del Sistema
Diagrama de EstadosNotación UML 1.3
Un Evento no es un objeto. Un Evento es la “causa” quejustifica la existencia de una información.
Sólo podemos conocer que un Evento ha ocurrido,detectando sus “efectos” en nuestro modelo.
Sólo nos interesan aquellos Eventos que provocan un cambiode estado en los objetos de nuestro modelo.
Hay que distinguir un Evento como tal, del objeto querepresenta el registro de los efectos de dicho Evento.
Comprobando Sirviendo
Esperando
/seleccionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[No todos los itemscomprobados]/seleccionarsiguiente item
[Todos los itemscomprobados &&algunos items no estandisponibles en stock]
Item Recibido[algunos itemsno estandisponibles en stock]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
PedidoEntregado
1
2
3
4 5
6
[Todos los items comprobados &&todos los items disponibles]
sin Superestados
Comprobando Sirviendo
EntregadoEsperando
/seleccionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[No todos los itemscomprobados]/seleccionarsiguiente item
[Todos los itemscomprobados &&algunos items no estandisponibles en stock]
Item Recibido[algunos itemsno estandisponibles en stock]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
PedidoEntregado
1
2
3
4
5
6
[Todos los items comprobados &&todos los items disponibles]
CanceladoPedidoCancelado
PedidoCancelado
PedidoCancelado
Activo
Cancelado Entregado
PedidoCancelado
Nombre del Superestado
con Superestados
4
DinámicaEstados
Verificando Sirviendo
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
Análisis textualdel Use Case
F l u j o P r i n c i p a l Va r i a c i o n e s
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba cada línea delpedido para validar la situación delartículo en catálogo y el número deitems del artículo en stock.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO existen suficientes items del artículo enstock, o la asignación de items deja lasituación del artículo en stock por debajo delnivel de reposición, sistema genera pedidode reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra artículos alternativos activando elCU Seleccionar artículo.
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
Din
ámic
a 4
_es
p -
Rev
. 5
.1 -
j
vila
lta@
vico
.org
Descripciónde la Dinámica del Sistema
Diagrama de EstadosConcurrentesNotación UML 1.3
Autorizandohacer /
comprobacióndel pago
[pago NO correcto]
Entregado
[pago SI correcto]
RechazadoAutorizado
Rechazado
Cancelado
Entregado
Comprobando
Esperando
Sirviendo
Autorizando AutorizadoPedido Entregado
Pedido Cancelado
Pedido Rechazado
Los diagramas de estados son muy útiles para describir elcomportamiento de un objeto a través de múltiples Casosde Uso.
5F l u j o P r i n c i p a l Va r i a c i o n e s
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.
b. SI existen suficientes items...
3. Sistema comprueba cada línea delpedido para validar la situación delartículo...
4. Sistema comprueba la situación delpedido .
a. SI se ha realizado el pago y SI todos los itemsdel pedido han sido asignados, sistemainforma que procede a servir el pedidoactivando el CU Servir pedido.
b. SI se ha realizado el pago y NO existensuficientes items del artículo en stock, sistemaaparca el pedido del cliente activando el CUAparcar pedido.
c. SI no se ha realizado el pago según el plazoconvenido, sistema cancela el pedido.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO existen suficientes items...
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra...
Análisis textualdel Use Case
DinámicaEstados
Verificando Sirviendo
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
Din
ámic
a 5
_es
p -
Rev
. 5
.1 -
j
vila
lta@
vico
.org
Vista deDistribución Física
Elementos
Vista deImplementación
Ejecutables
Arquitectura del sistema
Una Arquitectura es un conjunto organizado de elementos.Se utiliza para especificar las decisiones estratégicas acercade la estructura y funcionalidad del sistema, las colaboracionesentre sus distintos elementos y su despliegue físico paracumplir unas responsabilidades bien definidas.
Vista de la Arquitectura 4+1Notación UML 1.3 Arquitectura
Vista delModelo de Referencia
Vista de la
FuncionalidadUse Cases
Vista deComponentes
Modulares
1©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D A
rqu
itec
tura
1_
esp
- R
ev.
5.1
-
jvi
lalt
a@vi
co.o
rg
Arquitectura del sistemaLa vista del Modelo de Referencia (Reference InformationModel), está determinada por la arquitectura lógica.
La arquitectura lógica es capturada por los diagramas deClases que contienen las Clases y relaciones que representanlas abstracciones esenciales del sistema a desarrollar.
• Clases
• Asociaciones
• Agregaciones
• Generalización
• Packages
Arquitectura
Vista delModelo de Referencia
Vista delModelo de Referencia
El Modelo de Referencia se construye en sucesivasiteraciones durante la fase de Formalización.
Pedidos Clientes
ArtículosLas Clases y Packages del modelo reflejan lasdecisiones tomadas con respecto a los “mecanismosclave” del sistema.
Una eficiente implementación de los “mecanismosclave” requiere seleccionar Patrones (Patterns) quese ajusten a los requerimientos esenciales delproyecto.
La implementación de “mecanismos clave” requiereseleccionar también:
• Lenguaje de programación
• Motor de Base de Datos
• Interface gráfico de usuario “look and feel”
• Tratamiento de errores
• Mecanismos de comunicación
• Migración y distribución de objetos
• Networking
PedidofechaRecibidoconPrepagonúmero: Alfanúm.importe: Núm&2d.divisa...
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
2©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D A
rqu
itec
tura
2_
esp
- R
ev.
5.1
-
jvi
lalt
a@vi
co.o
rg
Vista deComponentes
Modulares
Arquitectura del sistemaLa vista de Componentes Modulares refleja la organizaciónde módulos de software dentro del entorno de desarrollo.
Esta vista de arquitectura toma en cuenta los requerimientosque facilitan la programación, los niveles de reutilización,y las limitaciones impuestas por el entorno de desarrollo.
Disponemos de dos elementos para modelizar esta vista:
• Packages: En esta vista representan una partición físicadel sistema.
• Componentes: En esta vista representan la organizaciónde módulos de código fuente.
Arquitectura
Los Packages estan organizados en una jerarquíade capas que disponen de una interface bien definida:
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
I n t e r f a c e d e U s u a r i o
Pa c k a g e s r e u t i l i z a b l e s
M e c a n i s m o s c l a v e C O R E
Pa c k a g e s d e p l a t a f o r m a ( O S - H a r d w a r e )
4
3
2
1
ø
Vista deComponentes
Modulares
Vista delModelo de Referencia
Los Packages de la vista lógica del modelo estanmapeados con los Packages físicos y los componentesde software (subsistemas).
InformaciónArtículos
Pe d i d o
Dominio
Clientes
Artículos
Pedidos
MailingInterface Usuario
AWTJava GUI toolkit
EntradaPedidos
Interface Usuario
3©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D A
rqu
itec
tura
3_
esp
- R
ev.
5.1
-
jvi
lalt
a@vi
co.o
rg
Vista deImplementación
Ejecutables
Vista deImplementación
Ejecutables
Arquitectura del sistema
Arquitectura
Los componentes run-time muestran los mappingsde las Clases a librerías de tipo ActiveX, Applets deJava y librerías dinámicas.
Vista deComponentes
Modulares
Vista delModelo de Referencia
Los componentes ejecutables muestran sus interfacesy niveles de dependencia dentro de la aplicación.
Clientes.dll
Expedición.dll
Artículos.dll
Pe d i d o s . exe
MailingInterface Usuario
AWTJava GUI toolkit
EntradaPedidos
Interface Usuario
Dominio
Clientes
Artículos
Pedidos
EntradaPedidosAplicación
MailingAplicación
Base deDatos
Interface global
OracleInterface
IngresInterface
Esta vista se centra en la estructura de los componentes“run-time”, los ejecutables del sistema.
Esta arquitectura tiene muy en cuenta los siguientesrequerimientos no funcionales:
• Rendimiento
• Fiabilidad
• Escalabilidad
• Integridad
• Seguridad
• Sincronización
• Administración del sistema
4©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D A
rqu
itec
tura
4_
esp
- R
ev.
5.1
-
jvi
lalt
a@vi
co.o
rg
Vista deDistribución Física
Elementos
Vista deImplementación
Ejecutables
Arquitectura del sistema
Un Nodo es un objeto físico run-time que representaun recurso informático. Este recurso, generalmentedispone de datos persistentes y capacidad de proceso.
En la mayoría de los casos un Nodo puede representaruna pieza de hardware, desde un periférico a unservidor.
Las Conexiones entre Nodos muestran las líneas decomunicación con las que el sistema tendrá queinteractuar.
Los Componentes, en un diagrama de distribución,representan los módulos físicos de código, los cuales,se corresponden con los Packages de ejecutables.De esta manera, el diagrama muestra donde correcada Package en el sistema.
Las Dependencias muestran cómo los componentesse comunican con otros componentes. La direcciónde una Dependencia concreta, indica el conocimientoen la comunicación.
Vista deComponentes
Modulares
Vista delModelo de Referencia
Esta vista presenta el mapping de componentes de softwareejecutables con los nodos de procesamiento (hardware).
Esta arquitectura tiene en cuenta los siguientesrequerimientos:
• Disponibilidad del sistema
• Rendimiento
• Escalabilidad
Los diagramas de distribución muestran el despliegue denodos (locales y remotos), en la organización de la empresa.
Permite al equipo de desarrollo comprender mejor latopología de un sistema distribuido.
Vista deDistribución Física
Elementos
Componente
Arquitectura
Interface
Nodos
Conexión
TCP/IP
TCP/IP
Servidor Área Comercial
Cliente Win95
Servidor Contabilidad
:GUIComercial
:ClienteComercial
Configuración
:Usuarios
:Contabilidad
:Base deDatos
:Base deDatos
:Comercial
:ServidorAplicaciones
5©
Vil
alta
Co
nsu
lto
res
20
01
- T
RA
D A
rqu
itec
tura
5_
esp
- R
ev.
5.1
-
jvi
lalt
a@vi
co.o
rg
Vista deImplementación
Ejecutables
Arquitectura del sistemaVista de
ComponentesModulares
Vista delModelo de Referencia Esta vista certifica la validez de:
• Modelo de Referencia
• Componentes modulares de software
• Ejecutables
• Distribución de recursos informáticos
Con la funcionalidad requerida del sistema.
Utilizamos los siguientes elementos para describir lafuncionalidad:
• Diagramas de Casos de Uso
• Especificación de Casos de Uso
• Diagramas de Interacción (Escenarios)
• Diagramas de Actividad (Flujos de Trabajo)
• Diagramas de Estados (Dinámica)
Vista deDistribución Física
Elementos
Vista de la
FuncionalidadUse Cases
Arquitectura
tieneStock:= comprobar ( )
[tieneStock] asignar ( )
[tieneStock] nuevo
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
* [para cada línea de pedido]
PrepararPedido
Recepciónde un
Pedido
ComprobarItems
ComprobarPago
CancelarPedido
AsignarItems
ReponerItems
ServirPedido
[en stock]
[SI éxito]
[NO éxito]
[Requiere reposición]
Verificando Sirviendo
EntregadoEsperando
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&todos los items disponibles]
Item
Rec
ibid
o
[Todos l
os ite
ms d
isponib
les]
Entregadorimer item
rimer item
rimer item
<< Ext >>
<< Inclu >> << Inclu >>
<< Ext >>
<< Inclu >>
Abrir Arqueo Hacer unInicio de Día
Hacer unFin de Día
Exportarmovimientos
Imprimirdocumento
SupervisorImportar nuevaconfiguración
Contabi l idad
CajeroCerrar Arqueo
6
F l u j o P r i n c i p a l Va r i a c i o n e s
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba cada línea delpedido para validar la situación delartículo en catálogo y el número deitems del artículo en stock.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO existen suficientes items del artículo enstock, o la asignación de items deja lasituación del artículo en stock por debajo delnivel de reposición, sistema genera pedidode reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra artículos alternativos activando elCU Seleccionar artículo.
© V
ilal
ta C
on
sult
ore
s 2
00
1 -
TR
AD
Arq
uit
ectu
ra 6
_es
p -
Rev
. 5
.1 -
j
vila
lta@
vico
.org