Guía Visual UML 0.17
-
Upload
rodrigo-m-morel -
Category
Documents
-
view
231 -
download
0
Transcript of Guía Visual UML 0.17
-
8/18/2019 Guía Visual UML 0.17
1/47
UMLGuía Visual
C ó m o c r e a r
f o r m a s d e v i d a
o r g a n i z a t i v a
© V i l a l t a Consu l t o r e s 2001
in fo@v ico .orgRev. 0.17
Josep V i l a l ta Marzo
Reg í s t r a t e e n
vico virtual c@mpus
mailto:[email protected]:[email protected]:[email protected]://www.vico.org/aRecursosPrivats/JosepVilaltaMarzo.pdfhttp://www.vico.org/learning/learning.phphttp://www.vico.org/learning/learning.phpmailto:[email protected]://www.vico.org/aRecursosPrivats/JosepVilaltaMarzo.pdfhttp://www.vico.org/http://www.vico.org/learning/learning.php
-
8/18/2019 Guía Visual UML 0.17
2/47
r g
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
UMLGuí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 nat ral actúa en los sistemas biológicos la contin idad de na VIO está
-
8/18/2019 Guía Visual UML 0.17
3/47
r g
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
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 conlos 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 .
-
8/18/2019 Guía Visual UML 0.17
4/47
r g
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
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, laextinció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
-
8/18/2019 Guía Visual UML 0.17
5/47
r g
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
¿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
-
8/18/2019 Guía Visual UML 0.17
6/47
r g
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
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 partirde 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
-
8/18/2019 Guía Visual UML 0.17
7/47
r g
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
¿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
Ori ented 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 loslibros 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
-
8/18/2019 Guía Visual UML 0.17
8/47
r g
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
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 hemoderivadoso 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
-
8/18/2019 Guía Visual UML 0.17
9/47
r g
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
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
-
8/18/2019 Guía Visual UML 0.17
10/47
r g
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
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
-
8/18/2019 Guía Visual UML 0.17
11/47
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
ó
d
i g o
DinámicaEventos - Estados
CronogramaPlan Director
Iteraciones
FuncionalidadDiagramas de
Casos de Uso
>
>
>
Use Case
>
Use ase
>
>
Actor
Actor
ClasesAná l i s i s
D iseño
I mplementac ión
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
Client ePersonal
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
ClienteCorporat ivo
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]
I t e m
R e c i b i d
o
[ T o d
o s l o s i t e
m s d i s p
o n i b l e
s ]
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]
I t e m
R e c i b i d
o
[ T o d
o s l o s i
t e m s d i s p
o n i b l e
s ]
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
ValidarP ago
SeleccionarPedidos
ValidarRiesgo
PPDI
G
CUCU
EscenariosI nteracció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 stock xxx 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 pedido
Un pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stock xxx línea : Línea de pedido
: I te m de E xp ed ic i ón : I te m de P e di do d e re po si ci ón
1
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D
U M
D_
e s p - R e v .
5 . 2 -
j v i l a l t a @ v i c o . o r g
-
8/18/2019 Guía Visual UML 0.17
12/47
Esfuerzo de desarrolloP D P
ProductoProcesosActividades
Entregables
TiempoFases
I teraciones
M i s i ó n
Concepción Formalización Construcción Transición
I ter a ci ones
I teracionespreliminares Iter #1 Iter #2 Iter #n
I ter#n+1 I ter #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 i l a l t a C o n s u l t o r e s 2 0 0 0 - T R A D
P D P i t e r a c i o n e s_
e s p - R e v .
4 . 2 -
j v i l a l t a @
v i c o . o r g
2
-
8/18/2019 Guía Visual UML 0.17
13/47
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D P D
P m i s i ó n_
e s p 2 - R e v .
5 . 2 -
j v i l a l t a @ v i c o . o
r g
M i s i ó n
Con ce pc ión F or ma li z ac ión Con st ru cc ión T ra ns ic ión
I ter aci ones
Iteracionespreliminares Iter #1 Iter #2 Iter #n
Iter#n+1 Iter #n
Iter#n+2
Iter#n+1
Mo d e l o
C o m p o n e n te 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
Concepc ión
Anteproyecto
Pa t rones de
Anál i sis
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
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
ClienteCorporat ivo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobaciónP
Pa t rones de
Fu n c i o n a l i d a d
>
>
>
Use Case
Actor 2
Actor 1
Use Case
Use Case
Use Case
Use Case
Use Case
P
Procesos
principales
Matrícula
del proyecto
Glosariode Conceptos
CronogramaPlan Director
Iteraciones
PM
PPDIG
Misión
3
-
8/18/2019 Guía Visual UML 0.17
14/47
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D P D
P m o d e l o
_ e s p 2 - R e v .
5 . 3 -
j v i l a l t a @ v i c o . o r g
M i s i ó n
Con ce pc ión F or ma li z ac ión Con st ru cc ión T ra ns ic ión
I ter aci ones
Iteracionespreliminares Iter #1 Iter #2 Iter #n
Iter#n+1 Iter #n
Iter#n+2
Iter#n+1
Mo d e l o
C o m p o n e n te 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 ma l i z ac i ón
Pa t rones de
Anál i sis
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporat ivo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
ClienteP ersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobaciónP
Pa t rones de
Fu n c i o n a l i d a d
>
>
>
Use Case
Actor 2
Actor 1
Use Case
Use Case
Use Case
Use Case
Use Case
P Modelo
FuncionalidadDiagramas de
Casos de Uso
ClasesAná l i s i s
y D i seño
>
>
>
Use Case
>
Use ase
>
>
Actor
Actor
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
Client eCorporat ivo
ClientePersonal
1*
1
*0. .1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
ClientePersonal
1*
1
*0. .1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
EspecificaciónCasos de Uso
Flujos de Trabajo
DinámicaEventosEstados
Verificando Sirviendo
EntregadoEsperando
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&
todos los items disponibles]
I t e m
R e c i b i d
o
[ T o d
o s l o s i
t e m s d i
s p o n i b l e
s ]
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]
I t e m
R e c i b i d
o
[ T o d
o s l o s i t e m
s d i s p
o n i b l e
s ]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
CU * [para cada pedido seleccionado]
Entrar
Reposición
SeleccionarPedidos
Pendientes
AsignarItems
RegularizarStock
ActivarPedido
EntrarReposición
EntrarReposición
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarP ago
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 stock xxx línea : Línea de pedido
: I te m de E xp ed ic ió n : I te m de P ed id o de r ep os ic i ón
tieneStock:( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedido
Un pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stock xxx línea : Línea de pedido
: I te m de E xp ed ic i ón : I te m de P ed id o de r ep os ic ió n
4
-
8/18/2019 Guía Visual UML 0.17
15/47
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D P D
P c o n s t r u c c i ó n_
e s p 2 - R e v .
5 . 3 -
j v i l a l t a @
v i c o . o r g
M i s i ó n
Con ce pc ión F or ma li z ac ión Con st ru cc ión T ra ns ic ión
I ter aci ones
Iteracionespreliminares Iter #1 Iter #2 Iter #n
Iter#n+1 Iter #n
Iter#n+2
Iter#n+1
Mo d e l o
C o m p o n e n te 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
Client e
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
ClienteP ersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Alumno P . Gl o ba l P . E sp . ResultadoSelección Ver
Destino
Versión
Tribunal
Año Académico*
**FechaActa
Alumnos
F ramewo r k de Ap l i c a c i o nes
Pa t rones de
D i seño
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
Client ePersonal
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
ClienteCorporat ivo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
P
Const rucc ión
Alumno P . G lo ba l P . Es p. ResultadoSelección Ver
Destino
Versión
Tribunal
AñoAcadémico*
**
FechaActa
Alumnos
ClasesDiseño
I mplementac ión
Base de DatosEsquema de Persistencia
ArquitecturaComponentes
InterfaceGráfico de Usuario
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
Client eCorporat ivo
ClientePersonal
1*
1
*0. .1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
ClientePersonal
1*
1
*0. .1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Componentes
5
-
8/18/2019 Guía Visual UML 0.17
16/47
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D P D P
_ e s p 2 - R e v .
6 . 2 -
j v i l a l t a @ v i c o . o r g
Fo r ma l i z ac i ón
M i s i ó n
Con ce pc ión F or ma l iz ac ión Con st r ucc ió n T ra ns ic ión
I ter aci ones
Iteracionespreliminares Iter #1 Iter #2 Iter #n Iter#n+1 Iter #nIter#n+2 Iter#n+1
Mo d e l o
C o m p o n e n te 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
ClasesAná l i s i s
y D i seño
>
>
>
Use Case
>
Use ase
>
>
Actor
Actor
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporat ivo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Client e
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
ClienteP ersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
EspecificaciónCasos de Uso
Flujos de Trabajo
DinámicaEventosEstados
Verificando Sirviendo
EntregadoEsperando
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&
todos los items disponibles]
I t e m
R e c i b i d
o
[ T o d
o s l o s i t e
m s d i s p
o n i b l e
s ]
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]
I t e m
R e c i b i d
o
[ T o d
o s l o s i t e
m s d i s p
o n i b l e
s ]
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
Concepc ión
Anteproyecto
Procesosprincipales
Matrículadel proyecto
Glosariode Conceptos
CronogramaPlan Director
I teraciones
PM
PPDIG
Misión
Const rucc ión
Alumno P . G l o ba l P . E s p . ResultadoSelección Ver
Destino
Versión
Tribunal
Año Académico*
**FechaActa
Alumnos
ClasesDiseño
I mplementac ión
Base de DatosEsquema de Persistencia
ArquitecturaComponentes
I nterfaceGráfico de Usuario
Pedido
hacer /comprobaciónitem
Cliente
Línea de Pedido
Producto
Comercial
ClienteCorporat ivo
ClienteP ersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Pedido
hacer /comprobaciónitem
Client e
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
ClienteP ersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Componentes
EscenariosI nteracció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 stock xxx línea : Línea de pedido
: I te m de E xp ed ic i ón : I te m de P ed id o de r ep os ic i ón
tieneStock:( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedido
Un pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stock xxx línea : Línea de pedido
: I te m de E xp ed ic ió n : I te m de P e di do d e re po si ci ón
6
-
8/18/2019 Guía Visual UML 0.17
17/47
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
I nteracció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 Cajero
Automático> Subsistema
de cuentascliente
- Role de subsistema -
Subsitemade cert if icación
de mediosde pago
- Role de subsistema -
A c t i v a r T a r j e t a
R e t i r a r E f e c t i v o
C o n s u l t a r M o v i m i e n t o s
FuncionalidadDiagramas deCasos de Uso
>
Use ase
>
>
Actor
Actor
1
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D
A c t o r e s_
e s p - R e v .
5 . 1 -
j v i l a l t a @ v i c o . o r g
-
8/18/2019 Guía Visual UML 0.17
18/47
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
Exportar movimientos
Piezas de funcionalidad del sistemaque suministran valor a un Actor y son
reutili zables 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
Imprimir documento
Sistema en proceso de modelado
I nteracción de un
Actor con el Sistema
Interacción delSistema con un Actor
Supervisor - Rol de usuario -
Importar nuevaconfiguración
Contabil idad- Sistema externo -
Cajero- Rol de usuario - Cerrar Arqueo
>
>
>
>
>
Relación que indica el uso deuna funcionalidad compartida
por otros Casos de Uso
FuncionalidadDiagramas deCasos de Uso
>
U se ase
>
>
Actor
Actor
2
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D
U C s_
e s p - R e v .
5 . 1 -
j v i l a l t a @ v i c o . o r g
-
8/18/2019 Guía Visual UML 0.17
19/47
Especificaciónde un Caso de Uso
LIMI
T
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 una
situació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 termina
el UC.
2. Sistema comprueba la configuraciónde TPV para identificar tipo de cierre.
3. Sistema calcula los totales teóricos para cad a fo rma de cobr o.
4. Actor introduce totales reales para cadaforma de cobro.
5. Sistema registra el cierre: importesreales para cada forma de cobro y
descuadres.
6. Sistema imprime el documento “Tirade Arqueo”.
a. Cierre de arqueo de tipo abierto:• Actor decide el momento de imprimir eldocumento “Tira de Arqueo”.
a. Si el servidor está off-line, sistema informaal usuario, termina el UC manteniendo el
arqueo 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 con fir mac ión para
continuar.
Hacer unFin de Día
Imprimir documento
Cerrar Arqueo >
>
Caso de Uso principal
Casos de Uso secundarios
Caso de Uso especializadoCaso de Uso genérico
Imprimir
t i ra de arqueo
FuncionalidadDiagramas deCasos de Uso
>
U se ase
>
>
Actor
Actor
3
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D L I M I T U C s_
e s p - R e v .
5 . 1 -
j v i l a l t a @ v i c o . o r
g
-
8/18/2019 Guía Visual UML 0.17
20/47
Ventajas del modeloUse Case
Pi ezas de funcionalidad reutil izablesen 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
Exportar movimientos
Imprimir documento
Importar nuevaconfiguración
Cerrar Arqueo
>
>
>
>
Hacer unFin de Día
>
Imprimir t i ra de arqueo
Abrir Arqueo
FuncionalidadDiagramas deCasos de Uso
>
Use ase
>
>
Actor
Actor
4
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D m o d e l o U C
_ e s p - R e v .
5 . 1 -
j v i l a l t a @ v i c o . o r g
-
8/18/2019 Guía Visual UML 0.17
21/47
Requerimientos y Casos de Uso
Los Casos de Uso son requerimientos funcionales que describende una manera detallada el comportamiento del sistema con
los 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
R e q uer
imie n t o s
M o d e
l
o
A r q u i
t e c t u r a
G e s t i ó
n d e
P r o y e c t o
C e r
t i f
i c a c i ó n
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 prior idades
Funcionalidad,Análisis y Diseño
Implementaciónde código yRefactoring
FuncionalidadDiagramas deCasos de Uso
>
Use ase
>
>
Actor
Actor
5
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D
R e
q y C U s_
e s p - R e v .
1 . 1 -
j v i l a l t a @ v i c o . o r g
Recepción Evento queCU Realizar pedido
-
8/18/2019 Guía Visual UML 0.17
22/47
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
Flu jo Pr inc ipa l Var iac iones
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentación
y cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido .
3. Sistema comprueba cada línea de l pedi do p ara val idar la sit uac ión del
artículo en catálogo y el número de
items del artículo en stock.
4. Sistema comprueba la situación del pedi do .
a. SI se ha realizado el pago y SI todos los itemsdel 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 existensuficientes items del artículo en stock, sistema
aparca 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 ex iste n su fici ente s ite ms de l art ícul o enstock, o la asignación de items deja la
situación del artículo en stock por debajo del
nivel de reposición, sistema genera pedido
de reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente y
muestra artículos alternativos activando el
CU 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 de Trabajo
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarP ago
SeleccionarPedidos
ValidarRiesgo
1
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D
A c
t i v i d a d 1
_ e s p - R e v .
7 . 1 -
j v i l a l t a @ v i c o . o r g
CU A t li i ió
-
8/18/2019 Guía Visual UML 0.17
23/47
Descripciónde un Flujo de Trabajo
Diagrama de ActividadNotación UML 1.3
* [para cada pedido
seleccionado]
Recepciónde una
Reposición
[Todos los items asignados] [Todos las reposiciones entradas]
F lu jo Pr in c ip a l
1. Usuario recepciona albaran es dereposición que ha enviado un proveedor.
2. Sistema localiza los pedidos de clientesaparcados que pueden cumplimentarse
con la nueva entrada de items.
3. Usuario selecciona los pedidos declientes aparcados que decide
cumplimentar.
4. Sistema asigna los items pendientes alos pedidos de cliente seleccionados.
5. Sistema informa que procede a servir el pedido activando el CU Servirpedido..
6. Sistema regulariza la situación de itemsen stock y revisa los umbrales de
reposició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 de Trabajo
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarP ago
SeleccionarPedidos
ValidarRiesgo
2
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D
A c
t i v i d a d 2
_ e s p - R e v .
5 . 2 -
j v i l a l t a @ v i c o . o r g
DescripciónRecepción 3
-
8/18/2019 Guía Visual UML 0.17
24/47
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 responsabil idad(swim-lines)
* [para cada línea de pedido]
Recepciónde un
Pedido
IdentificarCliente
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 pedido
seleccionado]
Seleccionar
Pedido
BuscarPedidos aparcados
[Todos las reposiciones entradas]
RegularizarStock
ComprobarArtículo
AsignarItems
Flujos de Trabajo
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
3
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D A c t i v i d a d 3
_ e s p - R e v .
6 . 1 -
j v i l a l t a @ v i c o . o r
g
Descripción 4
-
8/18/2019 Guía Visual UML 0.17
25/47
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 de Trabajo
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
4
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D A
c t i v i d a d 4
_ e s p - R e v .
5 . 2 -
j v i l a l t a @ v i c o . o r g
óCU Realizar pedido
-
8/18/2019 Guía Visual UML 0.17
26/47
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 en
el flujo de eventos de un Caso de Uso.
Estos mensajes muestran el nivel de colaboración
entre los distintos objetos existentes e indican
cuando se requiere generar nuevos objetos para
cumplir 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 nuevo
objeto
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
Flu jo Pr inc ipa l Var iac ion es
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentación
y cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba ca da línea del ped ido para val ida r la sit uac ión del
artículo en catálogo y el número de
items del artículo en stock.
p
1. Usuario identifica el cliente que haenviado un pedido.
c. NO ex isten sufi cien tes items del a rtíc ulo e nstock, o la asignación de items deja la
situación del artículo en stock por debajo del
nivel de reposición, sistema genera pedido
de reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente y
muestra artículos alternativos activando el
CU Seleccionar artículo.
:Una Cartera
de Items
en Stock
:Un Pedido
de
Reposición
:Una Ventana de
introducción de
Pedidos
:Un Pedido:Una Línea
de Pedido
Escenarios
tieneStock:( )
Una ventana deintroducción de
pedidos
Un itemde stock
Una líneade pedido
Un pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stock xxx línea : Línea de pedido
: Item de Expedición : Item de Pedido de reposición
1
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D S
e c u e n c i a
_ e s p - R e v .
6 . 1 -
j v i l a l t a @ v i c o . o r g
DescripciónCU Realizar pedido 2
-
8/18/2019 Guía Visual UML 0.17
27/47
Descripciónde un Escenario
Diagrama de ColaboraciónNotación UML 1.3
2: generarPedido ( ) 5: comprobarStock ( )
6: asignarItems ( )
7: realizarReposición ( )
Objeto(I nstancia de una Clase)
Auto-mensaje
8: generarReposición ( )
Número de secuencia
Mensajes enviados entre los objetos descritos en
el flujo de eventos de un Caso de Uso.
Estos mensajes muestran el nivel de colaboración
entre los distintos objetos existentes e indican
cuando se requiere generar nuevos objetos para
cumplir con las responsabilidades asignadas.
(1)
Un escenario describe una instancia del flujo de eventos deun Caso de Uso, con sus variaciones o extensiones posibles
y 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
Flu jo Pr inc ipa l Var iac iones
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentación
y cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido .
3. Sistema comprueba cada línea de l pedi do p ara val idar la sit uac ión del
artículo en catálogo y el número de
items del artículo en stock.
CU Realizar pedido
1. Usuario identifica el cliente que haenviado un pedido.
c. NO ex iste n su fici ente s ite ms d el a rtícu lo e nstock, o la asignación de items deja la
situación del artículo en stock por debajo del
nivel de reposición, sistema genera pedido
de reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente y
muestra artículos alternativos activando el
CU 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 pedido
Un pedido
[tieneStock] nuevo
[tieneStock]
nuevo
: Pedido
xxx stock : item de stock xxx 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
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C
o l a b o r a c i ó n_
e s p - R e v .
6 . 1 -
j v i l a l t a @ v i c o
. o r g
1
-
8/18/2019 Guía Visual UML 0.17
28/47
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:• I dentidad ¿Quien soy? = Atributos• P ropósito ¿Cual es mi misión? = J ustificació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 P edido
Producto
Comercial
Client eCorporat ivo
ClientePersonal
1*
1
*0. .1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
1
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C
l a s e s 1
_ e s p - R e v .
6 . 1 -
j v i l a l t a @ v i c o . o r g
Ab t ió 2
-
8/18/2019 Guía Visual UML 0.17
29/47
Abstracción
m é t o d o 4
m é t o d
o 1
Atributos
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
Client ePersonal
1*
1
*0. .1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
m é t o d o 2
m é t o d
o 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 ordenado
y autosuficiente.
vacp 104
2
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C
l a s e s 2
_ e s p - R e v .
3 . 1 -
j v i l a l t a @ v i c o . o r g
Obj t 3
-
8/18/2019 Guía Visual UML 0.17
30/47
Objeto
e l e v a r P l a t a f o r m a
c a r g
a r I t e
m
Atributos
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
Client ePersonal
1*
1
*0. .1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
m o v e r H a c
i a
b a j a
r P l a t a
f o r m
a
Variables.-
• 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 susa t r i bu tos (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 Palets
vacp104¿Qué puedo hacer?
¿Qué conozco?
¿Quien soy?
3
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C
l a s e s 3
_ e s p - R e v .
2 . 2 -
j v i l a l t a @ v i c o . o r g
Mensaje 4
-
8/18/2019 Guía Visual UML 0.17
31/47
Mensaje
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
Client ePersonal
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.
e l e v
a r P l a t a f o r m a
c a r g a r I t e
m
Atributos
m o v e r H a c i a
b a j a
r P l a t a f o
r m a
Objeto Receptor
vacp104 moverHacia: binB7Objeto Emisor
Nomb re d el obje to rec ept or
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
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C
l a s e s 4
_ e s p - R e v .
1 . 2 -
j v i l a l t a @ v i c o . o r g
Encapsulación 5
-
8/18/2019 Guía Visual UML 0.17
32/47
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
Client ePersonal
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
e l e v a r P l a t a f o r m
a
c a r g
a r I t e
m
Atributos
m o v e r H a c i a
b a j a r P
l a t a
f o r m
a
Conjunto de operaciones
externamente visibles que
define el comportamiento
de un objeto
5
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C
l a s e s 5
_ e s p - R e v .
3 . 1 -
j v i l a l t a @ v i c o . o r g
Herencia
6
-
8/18/2019 Guía Visual UML 0.17
33/47
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
Client ePersonal
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 y
atributos. Tambien, pueden redefinir algunos de losheredados (overriding).
Herencia
Vehículo Automático Carga Palets
vac 104
vac 104
vac 103vacp 104
Instancias de
Vehí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 las
especializaciones de una Clase.
Vehículo AutomáticoCarga Palets
SubClase
Vehículo AutomáticoCarga Bobinas
SubClase
Vehículo Automático de Carga
SuperClase
e l e v a r P l a t a f o r m a
c a r g a r I t e
m
Atributos
m o v e r H
a c i a
b a j a
r P l a t a
f o r m
a
vacp 104 © V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C
l a s e s 6
_ e s p - R e v .
1 . 2 -
j v i l a l t a @ v i c o . o r g
Composición 7
-
8/18/2019 Guía Visual UML 0.17
34/47
Composición
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
ClienteP ersonal
1*
1
*0..1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
E n te r t i t l e h e r e
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 MinimizeClose
List box
Grid
Entertitle here
< B ac k N ex t > C an ce l
Ventana Wizard
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C
l a s e s 7
_ e s p - R e v .
2 . 1 -
j v i l a l t a @ v i c o . o r g
Polimorfismo 8
-
8/18/2019 Guía Visual UML 0.17
35/47
Clases
Pedido
hacer /comprobaciónitem
Cliente
Línea de P edido
Producto
Comercial
ClienteCorporat ivo
Client ePersonal
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 un
vehí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 cargarI tem , 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ático
Carga Palets
SubClase
Vehículo Automático
Carga Bobinas
SubClase
e l e v a r P l a t a f o r m a
c a r g
a r I t e
m
Atributos
m o v e r H a c i a
b a j a
r P l a t a
f o r m
a
vacb 117
e l e v a r P l a t a f o r m a
c a r g a r I t e
m
Atributos
m o v e r H a c i a
b a j a
r P l a t a
f o r m
a
vacp 104
Vehículo Automático de Carga
SuperClase
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C
l a s e s 8
_ e s p - R e v .
1 . 1 -
j v i l a l t a @ v i c o . o r g
VisibilidadP didCliente 9
-
8/18/2019 Guía Visual UML 0.17
36/47
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 desarrol lo (C++, Smalltalk, J ava) desarrol la sus propias
reglas 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 P edido
Producto
Comercial
Client eCorporat ivo
ClientePersonal
1*
1
*0. .1
*
* 1
hacer /comprobaciónitem
hacer /comprobación
hacer /comprobación
Visibilidad C++ Smalltalk J ava
+ Publica
- Privada
# P rotegida
Package
Ejemplos
Un elemento siempre es visible en cualquier
pa rt e de l prog ra ma y pued e se r ll am ad o y
modificado por cualquier objeto del
sistema.
Un elemento sólo puede ser usado por la
Clase que lo define.
Un elemento sólo puede ser usado por laClase que lo define, o por las subclases de
dicha Clase.
Consideremos la Clase CLIENTE que disponede una subclase CLIENTE PERSONAL.Consideremos también que el objeto , es una instancia de CLIENTEPERSONAL.
• Puede usar todo elemento público de cualquier
objeto del sistema.
• Puede usar también 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
par a CLIENTE y CLIENTE PERSONAL.
Todas las operaciones son
púb licas p or de fec to.
Todas las variables
instanciadas son privadas.
, puede acceder acualquier variable instanciada dentro
de su propio objeto, si dicha variable
ha sido definida dentro de CLIENTEo CLIENTE PERSONAL. De esta
manera, el concepto de visibilidad priv ada en Smal lta lk e s p are cido al
concepto de visibilidad protegida en
C++.
Consideremos la instancia de CLIENTEPERSONAL, >, este objeto
pued e ac cede r a cual quie r el emen to de , que ha sido definido también como unainstancia de CLIENTE PERSONAL, sea
públ ico , pr iva do o prot egi do. ,a su vez también puede acceder a cualquier
elemento privado, protegido o público de
En C++, podemos acceder a elementos de otros
objetos de la propia Clase, de la misma manera
que podemos acceder a los propios elementos
de un objeto.
En Smalltalk no hay diferencia con
respecto a que un objeto sea de la
misma Clase o no. Podemos acceder
sólo a los elementos públicos de otro
objeto.
En Smalltalk, , n o pued e a cce der a l as vari abl es
instanciadas privadas de , sólo a sus operaciones públicas.
Un elemento siempre es visible en
cualquier parte del programa y puede
ser llamado y modificado por cualquier
objeto del sistema.
Un elemento sólo puede ser usado por
la Clase que lo define.
Un elemento puede ser usado por
subclases y también por cualquier otraClase en el mismo Package como la
Clase propietaria. Esto implica que en
Java, el concepto de visibilidad
prot egida es más públ ico que package .
Un elemento sólo puede ser usado por
otras Clases que compartan el mismo
Package.
Pedido- fechaRecibidoconPrepago- número: Alfanúm.- importe: Núm&2d.- divisa...
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 Clases
como públicas o packages. Los elementos
de una Clase pública pueden ser usados por
cualquier Clase que importe el package a
la que pertenece la Clase.
Los elementos de una Clase package sólo pued en ser usa dos por otra s C las es del
mismo package.
Línea de Pedido
+ hacer /comprobación
9
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D
C l a s e s v i s i b i l i d a d
_ e s p - R e v .
5 . 3 -
j v i l a l t a @ v i c
o . o r g
Descripción1
Flu jo Pr in c ip a l Var iac iones
CU Realizar pedido
-
8/18/2019 Guía Visual UML 0.17
37/47
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 pueden
ocurrir.• 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 disponibles
en stock]
Item Recibido
[algunos items no estan disponibles
en stock]
I t e m
R e c i b i d
o
[ T o d
o s l o s i t e
m s d i s p
o n i b l
e s ]
Pedido Entregado
1
2
3
4
5
6
DinámicaEstados
Verificando Sirviendo
ionar primer item
hacer /comprobación
item
hacer /inicio deentregas
[Todos los items comprobados &&
todos los items disponibles]
I t e m
R e c i b i d
o
[ T o d
o s l o s i t e
m s d i s p
o n i b
l e s ]
Entregadorimer item
rimer item
rimer item
EntregadoEsperando
Flu jo Pr in c ip a l Var iac iones
2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentación
y cantidad.
b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.
3. Sistema comprueba cada línea de l pedi do p ara vali dar la sit uac ión del
artículo en catálogo y el número de
items del artículo en stock.
4. Sistema comprueba la situación del ped ido .
a. SI se ha realizado el pago y SI todos los itemsdel 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 existensuficientes items del artículo en stock, sistema
aparca el pedido del cliente activando el CU
Aparcar pedido.
c. SI no se ha realizado el pago según el plazoconvenido, sistema cancela el pedido.
1. Usuario identifica el cliente que haenviado un pedido.
c. NO ex iste n su ficie ntes items del artíc ulo enstock, o la asignación de items deja la
situación del artículo en stock por debajo del
nivel de reposición, sistema genera pedido
de reposición activando el CU Generarpedido.
a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente y
muestra artículos alternativos activando el
CU Seleccionar artículo .
PedidofechaRecibidoconPrepagonúmero: Alfanúm.importe: Núm&2d.divisa...
*
1
seleccionar ( )comprobar ( )servir ( )
cerrar ( )...
Análisis textualdel Use Case
©
V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D D
i n á m i c a 1
_ e s p - R e v .
5 . 1 -
j v i l a l t a @ v i c o . o
r g
Descripción
2Flu jo Pr inc ipa l Var iac ion es
CU Realizar pedido
-
8/18/2019 Guía Visual UML 0.17
38/47
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 disponibles
en stock]
Item Recibido
[algunos items no estan disponibles
en stock]
I t e m
R e c i b i
d o
[ T o d
o s l o s i t e m
s d i s p
o n i b l e
s ]
Pedido Entregado
PedidofechaRecibidoconPrepagonúmero: Alfanúm.
importe: Núm&2d.divisa...
*
1
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
InicioClase
Atributos
Operaciones
prim era Transición
Estado
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ápida
d