UML Guía Visual

Transcripción

UML Guía Visual

UML
Guía Visual
Cómo crear
formas de vida
organizativa
© Vi l a l t a C o n s u l t o r e s 2 0 0 1
[email protected]
R e v. 0 . 1 7
Josep Vilalta
Proyecto:
Documento:
Historial:
Situación:
Proceso:
Autor:
Presentación del borrador: UML Guía Visual
UML Guía Visual
03/09/01 9:03
Borrador en curso de revisión
Evaluación de contenidos ref.- contacto: [email protected]
Josep Vilalta
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
vi
co
.o
rg
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.
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
Proyecto:
Documento:
Historial:
Situación:
Proceso:
Autor:
UML Guía Visual
03/09/01 9:03
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 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,
vi
co
.o
rg
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.
04/09/01 11:16
Revisión:
18
Página:
2 de 9
Proyecto:
Documento:
Historial:
Situación:
Proceso:
Autor:
UML Guía Visual
03/09/01 9:03
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, 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.
vi
co
.o
rg
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.
04/09/01 11:16
Revisión:
18
Página:
3 de 9
Proyecto:
Documento:
Historial:
Situación:
Proceso:
Autor:
UML Guía Visual
03/09/01 9:03
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.
vi
co
.o
rg
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).
04/09/01 11:16
Revisión:
18
Página:
4 de 9
Proyecto:
Documento:
Historial:
Situación:
Proceso:
Autor:
UML Guía Visual
03/09/01 9:03
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 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
vi
co
.o
rg
eventos son capaces de provocar un cambio de estado. El diagrama de EstadosTransició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/
04/09/01 11:16
Revisión:
18
Página:
5 de 9
Proyecto:
Documento:
Historial:
Situación:
Proceso:
Autor:
UML Guía Visual
03/09/01 9:03
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
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
vi
co
.o
rg
libros de Peter Coad et al, Object Oriented Analysis, Design and Programming, Object
Models y Java Modeling Color with UML, han sido de una ayuda extraordinaria. La
obra 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.
04/09/01 11:16
Revisión:
18
Página:
6 de 9
Proyecto:
Documento:
Historial:
Situación:
Proceso:
Autor:
UML Guía Visual
03/09/01 9:03
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 hemoderivados
vi
co
.o
rg
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
04/09/01 11:16
Revisión:
18
Página:
7 de 9
Proyecto:
Documento:
Historial:
Situación:
Proceso:
Autor:
UML Guía Visual
03/09/01 9:03
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
vi
co
.o
rg
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
04/09/01 11:16
Revisión:
18
Página:
8 de 9
Proyecto:
Documento:
Historial:
Situación:
Proceso:
Autor:
UML Guía Visual
03/09/01 9:03
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
vi
co
.o
rg
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)
[email protected]
http://www.vico.org
04/09/01 11:16
Revisión:
18
Página:
9 de 9
1
Niveles de concepción y formalización
de un proyecto
Nivel 1
Nivel 3
Nivel 5
ø
Use Case
Una ventana de
introducción de
pedidos
Use Case
[email protected]
M
G
<< Extends >>
<< Extends >>
Una línea
de pedido
Un pedido
Una ventana de
introducción de
pedidos
Un item
de stock
Una línea
de pedido
Un pedido
[tieneStock]
nuevo
Cliente
Pedido
Un item
de stock
tieneStock:= comprobar ( )
*
hacer /
comprobación
item
Cliente
*
nuevo
[tieneStock]
nuevo
1
hacer /
comprobación
item
<< Communicates >>
tieneStock:( )
Cliente
Personal
Cliente
Corporativo
nuevo
<< Communicates >>
Cliente
Personal
Cliente
Corporativo
[tieneStock]
: Pedido
hacer /
comprobación
1
hacer /
comprobación
item
1
[tieneStock]
Actor
hacer /
comprobación
1
Pedido
hacer /
comprobación
item
*
0..1
xxx línea : Línea de pedido: Pedido
xxx stock : item de stock
<< Uses >>
*
Comercial
*
Línea de Pedido
xxx línea : Línea de pedido
: Item de Expedición
: Item de Pedido de reposición
Diagramas de
Casos de Uso
Interacción
de objetos
Clases
Análisis
Diseño
Implementación
Dinámica
Eventos - Estados
Entrar
Reposición
Entrar
Entrar
Pedido
ionar primer item
Asignar
Items
* [para cada pedido seleccionado]
[Todos los items
comprobados &&
Sirviendo
todos los items disponibles]
hacer /
rimer item
hacer /
comprobación
item
rimer item
rimer item
Esperando
rimer item
Activar
Pedido Activar
Pedido
Regularizar
StockRegularizar
Stock
inicio de
entregasSirviendo
Verificando
hacer /
inicio de
entregas
s]
Pago
[Todos los items comprobados &&
hacer /
comprobación
item
rimer item
le
Validar
ionar primer item
rimer item Verificando
n ib
*Seleccionar
[para cada pedido seleccionado]
Pedidos
Reposición
Entregado
Esperando
s]
Riesgo
Entrar
po
Validar
Seleccionar
Pedidos
Pendientes
d is
Reposición
Asignar
Items
Cronograma
Plan Director
Iteraciones
Producto
le
CU
CU
Flujos
de Trabajo
Comercial
n ib
Especificación
Casos de Uso
1
*
po
P
Escenarios
Producto
hacer /
comprobación
Entregado
d is
PDI
P
Procesos
Principales
Funcionalidad
0..1
*
1
*
Línea de Pedido
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
“Code like hell”
Glosario
de Conceptos
hacer /
comprobación
[T
Matrícula
del Proyecto
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
<< Uses >>
Actor
Entregado
[T
© Vilalta Consultores 2001 - TRAD UMD_esp - Rev. 5.2 -
Nivel 4
C ó d i g o
Nivel
Nivel 2
Entregado
Tiempo
Iteraciones
Procesos
PDP
Fases
2
E s f u e r z o d e d e s a r ro l l o
Producto
Actividades
Entregables
Concepción
Formalización
Construcción
Transición
© Vilalta Consultores 2000 - TRAD PDP iteraciones_esp - Rev. 4.2 -
[email protected]
Misión
Modelo
Prototipo
Componentes
Certificación
Iteraciones
preliminares
Iter #1
Iter #2
Iter #n
Iter
#n+1
Iteraciones
Iter
#n+2
Iter #n
Iter
#n+1
3
PDP
Concepción
Formalización
Construcción
Transición
Misión
P l a n D i re c t o r d e P ro y e c t o
Modelo
Prototipo
Componentes
Certificación
Iteraciones
preliminares
Iter #1
Iter #2
Concepción
© Vilalta Consultores 2001 - TRAD PDP misión_esp2 - Rev. 5.2 -
[email protected]
M
P
Pedido
*
hacer /
comprobación
item
1
Pedido
Matrícula
del proyecto
Procesos
principales
<<Incluye>>
Cliente
*
hacer /
comprobación
1
Cliente
Corporativo
Misión
Cliente
Personal
hacer /
comprobación
item
*
0..1
*
Comercial
*
Línea de Pedido
0..1
*
1
*
Línea de Pedido
hacer /
comprobación
Producto
*
1
Use Case
<< Extends >>
<<Extiende >>
Use Case
Cliente
Personal
Cliente
Corporativo
hacer /
comprobación
item
P
Use Case
Use Case
Cliente
hacer /
comprobación
item
1
hacer /
comprobación
P
hacer /
comprobación
1
Iter #n
Comercial
Actor 1
<< Communicates >>
<<Generalización>>
Actor 2
Use Case
<< Uses >>
<<Incluye>>
Use Case
Producto
Patrones de
Análisis
PDI
P
G
Glosario
de Conceptos
Iter
#n+1
Iteraciones
Cronograma
Plan Director
Iteraciones
Anteproyecto
Patrones de
Funcionalidad
Iter
#n+2
Iter #n
Iter
#n+1
4
PDP
Concepción
Formalización
Construcción
Transición
Misión
Modelo
Prototipo
Componentes
Certificación
Iteraciones
preliminares
Iter #1
Iter #2
Iter #n
Iter
#n+1
Iteraciones
Fo r m a l i z a c i ó n
Una ventana de
introducción de
pedidos
Use Case
Use Case
Una línea
de pedido
Un pedido
<< Extends >>
Un item
de stock
Cliente
Pedido
Una ventana de
introducción de
pedidos
Una línea
de pedido
Un pedido
[tieneStock]
nuevo
Un item
de stock
1
<< Extends >>
*
hacer /
comprobación
item
hacer /
comprobación
1
Cliente
Pedido
*
[tieneStock]
nuevo
[tieneStock]
nuevo
1
hacer /
comprobación
item
tieneStock:( )
<< Communicates >>
hacer /
comprobación
item
*
0..1
*
<< Uses >>
Cliente
Personal
Cliente
Corporativo
nuevo
Cliente
Personal
Cliente
Corporativo
[tieneStock]
: Pedido
Actor
<< Communicates >>
hacer /
comprobación
1
hacer /
comprobación
item
Comercial
*
Línea de Pedido
Actor
P
Use Case
Use Case
<<Incluye>>
Use Case
hacer /
comprobación
0..1
*
1
*
Línea de Pedido
hacer /
comprobación
Producto
*
Comercial
1
Producto
Funcionalidad
Escenarios
Clases
Diagramas de
Casos de Uso
Interacción
de objetos
Análisis
y Diseño
P
Pedido
<<Extiende >>
1
Use Case
Modelo
<<Incluye>>
Use Case
Patrones de
Funcionalidad
*
hacer /
comprobación
Pedido
ionar primer item
[Todos los items
comprobados &&
Sirviendo
hacer /
hacer /
comprobación
rimer item
rimer item
rimer item
Esperando
rimer item
Activar
Pedido Activar
Pedido
Especificación
Casos de Uso
Regularizar
StockRegularizar
inicio de
entregasSirviendo
s]
hacer /
inicio de
entregas
n ib
le
hacer /
comprobación
item
po
Asignar
Items
item
rimer item
Verificando
Entregado
Esperando
s]
le
Pago
Asignar
Items
d is
Validar
ionar primer item
Pedidos
n ib
Reposición
po
*Seleccionar
Entregado
d is
CU
Comercial
*
0..1
*
1
*
Línea de Pedido
hacer /
comprobación
Entrar
Riesgo
Cliente
Personal
Línea de Pedido
Entrar
Validar
Cliente
Corporativo
hacer /
comprobación
item
Producto
*
1
Comercial
Producto
Patrones de
Análisis
Seleccionar
Pedidos
Pendientes
Entrar
Cliente
Personal
Cliente
Corporativo
0..1
Reposición
Entrar
Reposición
hacer /
comprobación
1
hacer /
comprobación
item
*
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Actor 2
<< Uses >>
[T
<<Generalización>>
Cliente
*
hacer /
comprobación
item
Use Case
Cliente
hacer /
comprobación
1
Pedido
1
<< Communicates >>
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Actor 1
*
hacer /
comprobación
item
<< Extends >>
Entregado
[T
© Vilalta Consultores 2001 - TRAD PDP modelo_esp2 - Rev. 5.3 -
[email protected]
<< Uses >>
Entregado
Stock
Flujos de
Trabajo
Dinámica
Eventos
Estados
Iter
#n+2
Iter #n
Iter
#n+1
5
PDP
Concepción
Formalización
Construcción
Transición
Misión
Modelo
Prototipo
Componentes
Certificación
Iteraciones
preliminares
Iter #1
Iter #2
Iter #n
Iter
#n+1
Iter
#n+2
Iteraciones
Construcción
Cliente
Pedido
*
hacer /
comprobación
item
1
*Acta
*Acta
Versión
Fecha
Destino
Año Académico
Versión
Fecha
Destino
** Tribunal
Alumnos
Cliente
*
1
** Tribunal
[email protected]
Alumno
P. Global
P. Esp.
Resultado
P. Global
P. Esp.
Resultado
Ver
Cliente
Corporativo
Cliente
Personal
hacer /
comprobación
item
0..1
*
Comercial
*
Línea de Pedido
✔
hacer /
comprobación
✔
Cliente
Pedido
✔
*
hacer /
comprobación
1
✔
0..1
*
1
*
Línea de Pedido
hacer /
comprobación
hacer /
comprobación
item
Producto
*
1
Comercial
Producto
1
Cliente
Corporativo
Cliente
Personal
hacer /
comprobación
item
*
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
© Vilalta Consultores 2001 - TRAD PDP construcción_esp2 - Rev. 5.3 -
Alumno
Ver
Cliente
Personal
Cliente
Corporativo
hacer /
comprobación
item
*
Selección
Selección
hacer /
comprobación
1
hacer /
comprobación
item
Año Académico
Alumnos
hacer /
comprobación
1
Pedido
*
1
Interface
Gráfico de Usuario
Producto
Clases
Diseño
Implementación
Cliente
Pedido
*
hacer /
comprobación
item
1
Cliente
*
hacer /
comprobación
1
hacer /
comprobación
item
1
Componentes
hacer /
comprobación
1
Pedido
P
Cliente
Personal
Cliente
Corporativo
hacer /
comprobación
item
*
Cliente
Corporativo
Cliente
Personal
hacer /
comprobación
item
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
*
0..1
*
1
*
Línea de Pedido
hacer /
comprobación
Producto
*
1
Comercial
Producto
Patrones de
Diseño
Framework
de Aplicaciones
Base de Datos
Arquitectura
Esquema de Persistencia
Componentes
Iter #n
Iter
#n+1
6
PDP
Concepción
Formalización
Construcción
Transición
Misión
Modelo
Prototipo
Componentes
Certificación
Iteraciones
preliminares
Iter #1
Iter #2
Iter
#n+2
Iter
#n+1
Iter #n
Iter #n
Iter
#n+1
Iteraciones
Concepción
Fo r m a l i z a c i ó n
Use Case
M
Una ventana de
introducción de
pedidos
Use Case
P
Una línea
de pedido
Un pedido
Un item
de stock
Una línea
de pedido
Un pedido
[tieneStock]
nuevo
Un item
de stock
<< Extends >>
*
hacer /
comprobación
item
1
Pedido
hacer /
comprobación
1
*
hacer /
comprobación
1
hacer /
comprobación
item
1
[tieneStock]
hacer /
comprobación
item
<< Communicates >>
<< Uses >>
Selección
Procesos
principales
hacer /
comprobación
Comercial
P. Esp.
Resultado
Ver
*
Cliente
Corporativo
Producto
0..1
Comercial
hacer /
comprobación
✔
1
*
Línea de Pedido
Comercial
0..1
*
1
*
Línea de Pedido
hacer /
comprobación
*
Cliente
Personal
hacer /
comprobación
item
✔
hacer /
comprobación
Producto
Funcionalidad
Escenarios
Clases
Diagramas de
Casos de Uso
Interacción
de objetos
Análisis
y Diseño
Misión
P. Global
Cliente
Personal
Cliente
Corporativo
hacer /
comprobación
item
0..1
*
1
*
Línea de Pedido
Interface
Gráfico de Usuario
Modelo
Producto
*
1
Comercial
Producto
Clases
Diseño
Implementación
Componentes
Entrar
Reposición
ionar primer item
rimer item
rimer item
rimer item
Esperando
rimer item
Glosario
de Conceptos
Cronograma
Plan Director
Iteraciones
Anteproyecto
Activar
Pedido Activar
Pedido
Especificación
Casos de Uso
Regularizar
StockRegularizar
inicio de
entregasSirviendo
s]
hacer /
inicio de
entregas
n ib
le
hacer /
comprobación
item
po
Asignar
Items
[Todos los items
comprobados &&
Sirviendo
hacer /
Verificando
Entregado
d is
Esperando
s]
Asignar
Items
le
Pago
hacer /
comprobación
item
rimer item
n ib
Validar
ionar primer item
po
Reposición
Entregado
d is
*Seleccionar
Pedidos
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
CU
Pedido
Riesgo
Entrar
[T
G
Entrar
Validar
Seleccionar
Pedidos
Pendientes
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
PDI
P
Entrar
Reposición
Entregado
[T
[email protected]
© Vilalta Consultores 2001 - TRAD PDP_esp2 - Rev. 6.2 -
Matrícula
del proyecto
1
** Tribunal
*
Línea de Pedido
<< Uses >>
Alumno
hacer /
comprobación
1
hacer /
comprobación
item
Año Académico
Alumnos
0..1
*
Actor
Fecha
Cliente
*
*
hacer /
comprobación
item
*
Versión
Destino
hacer /
comprobación
1
Pedido
Cliente
Personal
Cliente
Corporativo
nuevo
tieneStock:( )
*Acta
Cliente
Personal
Cliente
Corporativo
1
[tieneStock]
*
hacer /
comprobación
item
Cliente
Pedido
nuevo
[tieneStock]
nuevo
: Pedido
Actor
<< Communicates >>
Cliente
Cliente
Pedido
Una ventana de
introducción de
pedidos
<< Extends >>
Construcción
Entregado
Stock
Flujos de
Trabajo
Dinámica
Eventos
Estados
Base de Datos
Arquitectura
Esquema de Persistencia
Componentes
1
¿ Cómo identificar Actores ?
Interacción de un
Actor con el Sistema
Us ar Caje ro
Automátic o
S u b sistema
d e cu en tas
clien te
<< Incluye >>
C lien te
Relación que indica la
especialización a partir de una
función genérica
<<Generaliza>>
- Role de us ua rio -
- Ro le d e su b sistema -
R e a l i z a r una
t ra nsa c c i ón
Interacción del
Sistema con un Actor
<<Generaliza>>
<<Generaliza>>
[email protected]
© Vilalta Consultores 2001 - TRAD Actores_esp - Rev. 5.1 -
Activar
Ta r j e t a
Retirar
Efectivo
Consultar
Movimientos
S is te ma e n proc e s o de mode la do
Actores
S u b sitema
d e certificació n
d e med io s
d e p ag o
- Ro le d e su b sistema -
•
Representan a un agente que 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
Use Case
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 ?
<< Extends >>
Actor
<< Communicates >>
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
2
¿ Cómo identificar Casos de Uso ?
Hacer un
Ini ci o de Dí a
<< Extiende >>
Abr ir Arque o
Relación que describe una variación
posible del comportamiento normal
de un Use Case
Interacción de un
Actor con el Sistema
<< Incluye >>
Piezas de funcionalidad del sistema
que suministran valor a un Actor y son
reutilizables en diferentes procesos
C ajero
- Rol de us ua rio -
C e r r ar Arque o
<< Extiende >>
Ha c e r un
Fi n de Dí a
[email protected]
© Vilalta Consultores 2001 - TRAD UCs_esp - Rev. 5.1 -
- Ro l d e u su ario -
Relación que permite descomponer
un Use Case con un determinado
nivel de granularidad
<< Incluye >>
<< Incluye >>
Relación que indica el uso de
una funcionalidad compartida
por otros Casos de Uso
S u p erv iso r
Importar nueva
configuración
Im pri m i r
doc um e nt o
E xport ar
m ovi m i ent os
Co n tab ilid ad
S is te ma e n proc e s o de mode la do
- S istema ex tern o Interacción del
Sistema con un Actor
A la búsqueda de Casos de Uso.-
Use Case
<< Extends >>
Actor
<< Communicates >>
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 ?
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
3
Use Case
<< Extends >>
Especificación
de un Caso de Uso
Actor
<< Communicates >>
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
Caso de Uso principal
<< Extiende >>
© Vilalta Consultores 2001 - TRAD LIMIT UCs_esp - Rev. 5.1 -
[email protected]
C e r r ar A rque o
Ha c e r un
Fin de Día
<< Incluye >>
Casos de Uso secundarios
Imprimir
doc ume nto
Imprimir
tira de a rque o
<<Generaliza>>
Caso de Uso genérico
Caso de Uso especializado
L
I
M
I
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 requiere
el Caso de Uso.
Índice de escenarios: Flujo principal de eventos y secuencia
de variaciones posibles dentro de un Caso de Uso.
Tribulaciones: Contingencias probables que pueden afectar
al flujo de los eventos y son excepciones del Caso de Uso.
Propósito
Precondiciones
- Regla de Negocio -
Cerrar un periodo de
movimientos de caja
para obtener una
situación real de dinero
en efectivo y en
documentos.
•
•
•
•
Arqueo abierto
Actor habilitado
TPV abierto
TPV habilitado
Activación
• A discreción de un Actor
habilitado
Flujo Principal
Variaciones
1. Sistema requiere confirmación de
cierre de arqueo.
a. Si Actor decide aparcar el cierre de arqueo,
sistema activa UC Aparca_arqueo y termina
el UC.
2. Sistema comprueba la configuración
de TPV para identificar tipo de cierre.
a. Cierre de arqueo de tipo abierto:
• Actor decide el momento de imprimir el
documento “Tira de Arqueo”.
b. Cierre de arqueo de tipo ciego:
• Sistema no muestra los totales teóricos para
cada forma de cobro.
3. Sistema calcula los totales teóricos
para cada forma de cobro.
4. Actor introduce totales reales para cada
forma de cobro.
5. Sistema registra el cierre: importes
reales para cada forma de cobro y
descuadres.
6. Sistema imprime el documento “Tira
de Arqueo”.
Excepciones
a. Si el servidor está off-line, sistema informa
al usuario, termina el UC manteniendo el
arqueo abierto.
a. Si impresora está off-line, sistema informa
al usuario y le pide confirmación para
continuar.
4
Ventajas del modelo
Use Case
1. Lenguaje de comunicación entre usuarios
y desarrolladores.
2. Comprensión detallada de la funcionalidad
del sistema.
A brir A rque o
<< Extiende >>
H ac e r un
Ini c i o de Dí a
<< Incluye >>
Hac e r un
Fin de Día
© Vilalta Consultores 2001 - TRAD modelo UC_esp - Rev. 5.1 -
[email protected]
<< Extiende >>
Importar nueva
configuración
<< Incluye >>
Export a r
movimient os
C e rra r A rque o
4. Gestión de riesgo más eficiente para
gobernar la complejidad.
5. Estimación más exacta para determinar
tiempo, recursos y prioridades en la dosificación
de esfuerzo de desarrollo.
6. Fiel trazabilidad para verificar la traducción
de requerimientos en código ejecutable.
7. Mayor control para mantener las sucesivas
revisiones de los programas.
<< Incluye >>
Imprimir
doc ume nto
3. Acotación precisa de las habilitaciones de
los usuarios.
<<Generaliza>>
Imprim i r
tira de arque o
8. Certificación contractual ClienteDesarrollador.
9. Documentación orientada al usuario: Helps
- Manual de Procedimientos - Reglas de Negocio.
Use Case
<< Extends >>
Actor
<< Communicates >>
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
Piezas de funcionalidad reutilizables
en diferentes procesos de negocio
10. Documentación orientada al administrador
del sistema: Soporte de Mantenimiento.
5
Requerimientos y Casos de Uso
Los Casos de Uso son requerimientos funcionales que describen
de una manera detallada el comportamiento del sistema con
los distintos Actores que interactúan con él.
Funcionalidad,
Análisis y Diseño
Implementación
de código y
Refactoring
Reglas
de Negocio
y protocolos de
intercambio de
información
Mapa conceptual:
Clases de análisis
Caso de Uso
Plan Director
de Iteraciones:
Cronograma
y prioridades
Dinámica de
Clases complejas
Mapa funcional:
Flujos de trabajo
principales y
variaciones
ó
de
Pr
oye
cto
A rq
ur
Use Case
a
Métrica:
Escenarios de
Escandallo de
interacción
recursos
de objetos:
y actividades Clases de diseño
sti
n
s
delo
Cer tif ic ac
ión
Funcionales,
no funcionales
e interfaces de
usuario
Ge
© Vilalta Consultores 2001 - TRAD Req y CUs_esp - Rev. 1.1 -
erimiento
Mo
[email protected]
qu
Re
No definen todos los requerimientos (por ej. los tipos de
datos, interfaces externas, niveles de rendimiento esperado,
etc.), pero representan el hilo conductor que vincula a todos
los requerimientos posibles (actuales y futuros) de una
aplicación.
e
ui t
ct
<< Extends >>
Actor
<< Communicates >>
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
Recepción
de un
Pedido
Evento que
desencadena
la secuencia de
actividades
Identificar
Cliente
Actividad
CU Realizar pedido
Flujo Principal
Va r i a c i o n e s
1. Usuario identifica el cliente que ha
enviado un pedido.
Diagrama de Actividad
Notación UML 1.3
2. Usuario entra lineas de pedido, con su
código de artículo, tipo de presentación
y cantidad.
3. Sistema comprueba cada línea del
pedido para validar la situación del
artículo en catálogo y el número de
items del artículo en stock.
a. Artículo NO está vigente en catálogo, sistema
informa que articulo no está vigente y
muestra artículos alternativos activando el
CU Seleccionar artículo.
Análisis textual
del Caso de Uso
b. SI existen suficientes items del artículo en
el stock, sistema asigna items al pedido.
c. NO existen suficientes items del artículo en
stock, 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 Generar
pedido.
4. Sistema comprueba la situación del
pedido .
Concurrencia dinámica de actividades
Barra de sincronización
* [para cada línea de pedido]
a. SI se ha realizado el pago y SI todos los items
del pedido han sido asignados, sistema
informa que procede a servir el pedido
activando el CU Servir pedido.
b. SI se ha realizado el pago y NO existen
suficientes items del artículo en stock, sistema
aparca el pedido del cliente activando el CU
Aparcar pedido.
[email protected]
© Vilalta Consultores 2001 - TRAD Actividad 1_esp - Rev. 7.1 -
Entrar
líneas pedido
[NO vigente]
Punto de decisión
Descripción
de un Flujo de Trabajo
Un flujo de trabajo muestra la secuencia de actividades
que se desarrollan dentro de uno o varios Casos de
Uso, como una pieza de funcionalidad concreta que
satisface los requerimientos de un Actor.
Seleccionar
Artículo alternativo
[SI vigente]
c. SI no se ha realizado el pago según el plazo
convenido, sistema cancela el pedido.
1
Comprobar
Artículo
Comprobar
Pago
[NO]
Cancelar
Pedido
Asignar
Items
[SI]
[NO Stock] o
[SI umbral reposición]
Barra de fusión
Generar
reposición
Condición lógica: verdadera o falsa,
que permite la transición
a otra actividad
Comprobar
situación Pedido
Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
[Todos los items asignados]
[Faltan items por asignar]
Validar
Pago
Asignar
Items
Servir
Pedido
Aparcar
Pedido
Activar
Pedido
Regularizar
Stock
Flujos de
Trabajo
CU Actualizar reposición
Descripción
Flujo Principal
1. Usuario recepciona albaranes de
reposición que ha enviado un proveedor.
2. Sistema localiza los pedidos de clientes
aparcados que pueden cumplimentarse
con la nueva entrada de items.
Recepción
de una
Reposición
Análisis textual
del Caso de Uso
Una diagrama de actividad describe una secuencia de
actividades que pueden exhibir un comportamiento en
paralelo o estar sujetas a condiciones lógicas.
3. Usuario selecciona los pedidos de
clientes aparcados que decide
cumplimentar.
4. Sistema asigna los items pendientes a
los pedidos de cliente seleccionados.
2
Los procesos de negocio no muestran siempre una secuencia
fija en su desarrollo, es una ventaja así poder modelar
bloques de actividades sin restricciones de concurrencia.
Entrar
Reposición
5. Sistema informa que procede a servir
el pedido activando el CU Servir
pedido..
Buscar
Pedidos aparcados
6. Sistema regulariza la situación de items
en stock y revisa los umbrales de
reposición automática.
[email protected]
Notación UML 1.3
Seleccionar
Pedido
* [para cada pedido
seleccionado]
Transición de una actividad a otra sujeta
a una condición lógica.
Asignar
Items
Sincronización de actividades que
pueden ocurrir en paralelo.
[Todos las reposiciones entradas]
Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
Servir
Pedido
Validar
Regularizar
Stock
Pago
Asignar
Items
Activar
Pedido
Fin de la secuencia de
actividades
Regularizar
Stock
Flujos de
Trabajo
Descripción
Recepción
de un
Pedido
Identificar
Cliente
Un diagrama de actividad puede mostrar la secuencia de
actividades que se desarrolla en un paquete de Casos de
Uso que define un proceso de negocio y sus áreas de
responsabilidad.
Entrar
líneas pedido
3
Notación UML 1.3
[Recepción de Reposición]
Comprobar
Artículo
Seleccionar
Artículo alternativo
[NO vigente]
[SI vigente]
Comprobar
Pago
Seleccionar
Pedido
[email protected]
Entrar
Reposición
Buscar
Pedidos aparcados
Líneas para acotar
áreas de responsabilidad
(swim-lines)
* [para cada pedido
seleccionado]
Asignar
Items
[NO éxito]
Cancelar
Pedido
[SI éxito]
Generar
reposición
[NO Stock]
o [SI umbral reposición]
Comprobar
situación Pedido
Contabilidad
Comercial
Regularizar
Stock
Almacén
Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
Validar
Pago
[Todos las reposiciones entradas]
Servir
Pedido
[Faltan items por asignar]
Aparcar
Pedido
Asignar
Items
Activar
Pedido
Regularizar
Stock
Flujos de
Trabajo
Descripción
Descomposición
de la actividad
Comprobar
Pago
Su objetivo no es relacionar actividad con objetos, sólo
comprender qué actividades son necesarias y cuales son sus
relaciones de dependencia.
Notación UML 1.3
Pueden procesarse distintas
modalidades de pago de
manera simultanea
4
El diagrama de actividad nos permite definir en qué orden
se van a realizar distintas tareas. Los diagramas de flujo
(flowchart) sólo nos permiten modelar procesos secuenciales,
mientras que los diagramas de actividad nos permiten
establecer procesos en paralelo.
Comprobar
Pago
[Tarjeta de Crédito]
[email protected]
[Factura]
Comprobar
Cheque
Autorización
[Cheque]
Comprobar
Cliente habitual
Importe
> 150.000
NO éxito
[SI]
[NO]
[Efectivo]
[NO éxito]
[NO éxito]
[SI]
Comprobar
historial pagos
[SI éxito]
[SI éxito]
[NO éxito]
Pre-Pago
requerido
[NO recibido]
[NO]
Comprobar
Crédito
[NO éxito]
NO éxito
[SI éxito]
Entrar
Pedido
Validar
[SI éxito]
Riesgo
Seleccionar
Pedidos
Validar
Pago
Abrir
Cuenta Cliente
SI éxito
Asignar
Items
Activar
Pedido
Regularizar
Stock
Flujos de
Trabajo
CU Realizar pedido
Flujo Principal
Descripción
de un Escenario
enviado un pedido.
y cantidad.
Análisis textual
del Use Case
Un escenario muestra de que manera interactúan los distintos
objetos dentro del flujo principal de eventos de un Caso de
Uso con alguna variación o extensión concreta del mismo.
Utilizamos dos diagramas de interacción:
a/. Secuencia
b/. Colaboración
Su finalidad es describir los mensajes que intercambian los
distintos objetos para cumplir con las responsabilidades
definidas en un escenario concreto de un Caso de Uso.
pedido.
Objetos que
interactúan
1
© Vilalta Consultores 2001 - TRAD Secuencia_esp - Rev. 6.1 -
[email protected]
• Diagrama de Secuencia.- Representa las
: C o m erci al
:Una Ventana de
introducción de
Pedidos
:Un Pedido
:Una Línea
de Pedido
:Una Cartera
de Items
en Stock
interacciones de objetos ordenadas en una serie temporal
que muestra su ciclo de vida.
(1) Mensajes enviados entre los objetos descritos en
el flujo de eventos de un Caso de Uso.
1:indentificarCliente ( )
2:generarPedido ( )
Estos mensajes muestran el nivel de colaboración
entre los distintos objetos existentes e indican
cuando se requiere generar nuevos objetos para
cumplir con las responsabilidades asignadas.
3:entrarLíneaPedido ( )
4:generarLíneaPedido ( )
5:comprobarStock ( )
Auto-mensaje
6:asignarItems ( )
(1)
Mensaje
7:realizarReposición ( )
Línea de vida
de un objeto
durante la interacción
8:generarReposición ( )
Creación de
un nuevo
objeto
:Un Pedido
de
Reposición
Una ventana de
introducción de
pedidos
Un pedido
Una línea
de pedido
Un item
de stock
[tieneStock]
nuevo
[tieneStock]
nuevo
tieneStock:( )
: Pedido
Diagrama de Secuencia
Notación UML 1.3
Escenarios
CU Realizar pedido
Flujo Principal
enviado un pedido.
Análisis textual
del Use Case
2
Con un escenario representamos el conjunto de eventos que
configura el comportamiento de un Caso de Uso.
y cantidad.
Descripción
de un Escenario
pedido.
Un escenario describe una instancia del flujo de eventos de
un Caso de Uso, con sus variaciones o extensiones posibles
y las excepciones probables.
Utilizamos dos diagramas de interacción:
a/. Secuencia
b/. Colaboración
Su finalidad es describir los mensajes que intercambian los
distintos objetos para cumplir con las responsabilidades
definidas en un escenario concreto de un Caso de Uso.
Objeto
© Vilalta Consultores 2001 - TRAD Colaboración_esp - Rev. 6.1 -
[email protected]
(Instancia de una Clase)
• Diagrama de colaboración.- Representa una
: Comercial
Número de secuencia
posible interacción de los objetos ordenados a partir
de la topología que muestra el envio de sus mensajes.
1: identificarCliente ( )
(1) Mensajes enviados entre los objetos descritos en
el flujo de eventos de un Caso de Uso.
3: entrarLíneaPedido ( )
4: generarLíneaPedido ( )
: Una Ventana de introducción de Pedidos
Enlace entre
dos objetos
Mensaje (1)
2: generarPedido ( )
: Una Línea de Pedido
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.
5: comprobarStock ( )
6: asignarItems ( )
Auto-mensaje
: Un Pedido
7: realizarReposición ( )
Dirección del mensaje
:Una Cartera de Items en Stock
Una ventana de
introducción de
pedidos
Un pedido
Una línea
de pedido
Un item
de stock
[tieneStock]
nuevo
[tieneStock]
nuevo
8: generarReposición ( )
tieneStock:( )
: Pedido
Diagrama de Colaboración
Notación UML 1.3
: Un Pedido de Reposición
Escenarios
Clases
Desde una perspectiva conceptual, una Clase representa un
conjunto 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
Pedido
FechaRecibido
ConPrepago
Número
Importe
Divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
[email protected]
© Vilalta Consultores 2001 - TRAD Clases 1_esp - Rev. 6.1 -
Nombre
Direccion
valorarCredito( ): string
1
Cliente
Corporativo
Cliente
Personal
NumTargetaCredito
NombreContacto
ValoracionCredito
LimiteCredito
facturarMes( )
recordar( )
*
Estos elementos que configuran cada tipo de objeto sólo se
definen una vez, cuando especificamos la estructura de la Clase
a la que pertenecen.
Objetos
1
*
Desde una perspectiva física, una Clase es una pieza de software
que actua como un molde para fabricar tipos particulares de
objetos que disponen de los mismos atributos y métodos.
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).
1
Cliente
0..1
*
Representante
Línea de Pedido
Cantidad
Importe
Cumplimentada
*
1
Producto
aceptar ( )
Diagrama de Clases
Notación UML 1.3
Un Objeto representa una entidad del mundo real o inventada.
Es un concepto, una abstracción o algo que dispone de unos
límites bien definidos y tiene una significación para el sistema
que 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
Cliente
Pedido
*
hacer /
comprobación
1
hacer /
comprobación
item
1
Cliente
Corporativo
Cliente
Personal
hacer /
comprobación
item
*
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
Objetos
*
1
Producto
Clases
Abstracción
2
vacp 104
1
ét
m
o
od
2
m
do
o
ét
Atributos
m
o
od
ét
4
[email protected]
A partir de una abstracción del mundo real, definimos
objetos que representan micromódulos de software ideales.
Desde su creación, se mantienen de manera independiente
unos de otros, sólo interaccionan con otros objetos a través
de sus mensajes. Cada objeto configura un universo ordenado
y autosuficiente.
m
o
od
t
é
3
Cliente
Pedido
*
hacer /
comprobación
1
hacer /
comprobación
item
1
Cliente
Corporativo
hacer /
comprobación
item
*
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
*
1
Producto
Clases
Cliente
Personal
Objeto
3
Todo lo que un objeto “conoce” está representado en sus
atributos (variables y estado actual), y todo lo que puede
“realizar” está definido en sus métodos (comportamiento),
y en sus “interacciones” con otros objetos a través del
intercambio de mensajes (dinámica del ciclo de vida).
¿Quien soy?
Vehículo Automático Carga Palets
vacp104
¿Qué puedo hacer?
ia
Atributos
m
or
af
at
Pl
[email protected]
ac
H
rg
ar
ev
el
a
er
ca
em
ov
m
It
ar
a
Pl
r
a
aj
m
or
f
ta
a
¿Qué conozco?
b
Variables.•
•
•
•
•
Identificación
Medidas de la carga
Capacidad de carga
Velocidad máxima
Tipo de carga
Cliente
Pedido
*
hacer /
comprobación
1
hacer /
comprobación
item
Estado.-
1
Cliente
Corporativo
hacer /
comprobación
item
*
• Localización
• Orientación
• Velocidad
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
*
1
Producto
Clases
Cliente
Personal
Mensaje
4
Una aplicación orientada a objetos consiste en un número
determinado de objetos que interactuan entre si enviándose
mensajes unos a otros para invocar sus métodos. Este
intercambio de mensajes facilita su comportamiento, cambios
de estado, destrucción o almacenamiento.
Ya que todo lo que un objeto puede realizar está expresado
en sus métodos, este simple mecanismo de mensajes soporta
todas las posibles interacciones entre ellos.
Método que se invoca para que lo ejecute el objeto receptor
Parámetro enviado para especificar el método
Nombre del objeto receptor
vacp104
moverHacia: binB7
Objeto Emisor
ia
Atributos
a
rm
ar
ev
el
m
or
af
at
Pl
a
rg
ac
H
ca
em
er
It
ar
ov
m
[email protected]
vacp104
ba
ja
a
at
l
rP
Signatura del mensaje
fo
Cliente
Pedido
*
hacer /
comprobación
1
hacer /
comprobación
item
1
Cliente
Corporativo
hacer /
comprobación
item
Objeto Receptor
*
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
*
1
Producto
Clases
Cliente
Personal
Encapsulación
5
El empaquetado de métodos y atributos dentro de un objeto
mediante una interface de mensajes, es lo que denominamos
encapsulación.
La clave está precisamente en este envoltorio del objeto.
La interface que rodea por completo al objeto actúa como
punto de contacto para todos los mensajes que llegan desde
cualquier objeto emisor.
Interface de mensajes
Su propósito es garantizar que todas las interacciones del
objeto tengan lugar a través de un sistema de mensajería
predefinido con el que es capaz de entenderse y reaccionar
adecuadamente.
m
ac
H
er
ia
ca
a
rg
e
rIt
No existe ninguna otra manera con la que un objeto externo
pueda acceder a los atributos y métodos escondidos dentro
de la interface de mensajes de otro objeto.
Atributos
ar
ev
el
m
or
af
at
Pl
a
La interface de mensajes tiene la misma función que la
membrana de una célula, disponer de una barrera esencial
entre la estructura interna de un objeto y el exterior.
ov
m
[email protected]
Conjunto de operaciones
externamente visibles que
define el comportamiento
de un objeto
ba
ja
t
la
P
r
af
a
m
r
o
vacp104
moverHacia: binB7
Cliente
Pedido
*
hacer /
comprobación
1
hacer /
comprobación
item
Mensaje
1
Cliente
Corporativo
hacer /
comprobación
item
*
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
vacp104
*
1
Producto
Clases
Cliente
Personal
Herencia
6
Es el mecanismo por el cual una clase de objetos puede ser
definida 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 de
todos sus casos especiales. Además de los métodos y atributos
que heredan, las Subclases definen sus propios métodos y
atributos. Tambien, pueden redefinir algunos de los
heredados (overriding).
La interface de mensajes definida para una Superclase
también es heredada por las subclases. Esto implica que
todas las Subclases de una Superclase estan preparadas
para responder correctamente a los mismos mensajes que
la Clase padre. Esta propiedad es extremadamente útil
porque nos permite tratar de la misma manera a todas las
especializaciones de una Clase.
Vehículo Automático de Carga
Vehículo Automático
Carga Palets
Carga Bobinas
vac 104
vac 104
SubClase
SubClase
vac 103
vacp 104
Interface de mensajes
H
er
ov
Métodos
ia
ac
rg
m
a
ca
em
r It
a
m
or
af
at
Pl
ar
Instancias de
ba
ja
l
rP
or
af
at
m
Cliente
Pedido
*
hacer /
comprobación
1
hacer /
comprobación
item
Atributos
ev
el
[email protected]
SuperClase
a
Atributos
1
Cliente
Corporativo
hacer /
comprobación
item
*
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
vacp 104
Identificador del objeto
*
1
Producto
Clases
Cliente
Personal
Composición
7
Los objetos que contienen a otros objetos se denominan
Objetos Compuestos. Los atributos de un objeto pueden
utilizarse de dos maneras. Podemos usarlos para almacenar
valores como el número 15, o bien, el texto “Autorizado”.
También pueden contener referencias de otros objetos. Las
referencias almacenadas en los atributos de un objeto
compuesto, permite a este objeto enviar los mensajes
apropiados a todos los objetos contenidos.
Ventana Wizard
Progress
Enter title here
Tab
67%
Tab control
Trackbar
[email protected]
< Back
Next >
Panel de ventana
Grid
Cancel
Slider
Enter title here
Campo simple
Scroll
Botones de ventana
Restore
Maximize
Cliente
Combo box
Pedido
*
hacer /
comprobación
1
hacer /
comprobación
item
1
Cliente
Corporativo
Help
?
Close
Minimize
hacer /
comprobación
item
List box
*
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
*
1
Producto
Clases
Cliente
Personal
Polimorfismo
Diferentes objetos pueden responder a un mismo mensaje
de diferentes maneras. El polimorfismo permite a los objetos
interactuar entre ellos sin necesidad de conocer previamente
a que tipo pertenecen.
Vehículo Automático de Carga
Un objeto puede ser de diferentes tipos. Por ejemplo un
vehículo automático de carga puede especializarse para
cargar bobinas, palets u otro tipo de items. Los demás
objetos del sistema no tienen porque saber cuantos tipos
de vehículos disponemos.
SubClase
Carga Palets
SubClase
El mismo mensaje cargarItem, acompañado del parámetro
que identifica dicho item, será intrepretado de distinta
manera por cada objeto receptor, el cual ya conoce
previamente como tiene que tratar la naturaleza de su
carga: bobinas, palets, etc.
Hay una reducción de esfuerzo muy significativa por el
hecho de que cualquier objeto del sistema puede enviar
mensajes a los vehículos automáticos de carga sin necesidad
de saber de antemano qué tipo de vehículos estan en
circulación.
No hay necesidad así de picar un código específico para
cada tipo de vehículo, con lo cual, nos ahorramos prolijas
sentencias IF o CASE que son complejas de mantener y de
actualizar cuando se incorporan nuevos tipos de objetos.
m
Cliente
Atributos
a
a
m
or
af
at
Pl
ar
r
fo
ta
la
ev
el
a
m
or
af
at
Pl
ar
m
rP
ja
ba
ia
ac
ia
ac
rg
ca
Atributos
cargarItem: #A234C19FZ
H
er
ov
H
er
ov
m
Ite
ar
m
m
Ite
ar
rg
ca
ev
el
[email protected]
SuperClase
Carga Bobinas
8
rP
ja
ba
Pedido
rm
fo
ta
la
*
hacer /
comprobación
1
hacer /
comprobación
item
a
Mensaje
1
Cliente
Corporativo
hacer /
comprobación
item
*
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
vacb 117
vacp 104
*
1
Producto
Clases
Cliente
Personal
Visibilidad
Cliente
Pedido
- fechaRecibido
conPrepago
- número: Alfanúm.
- importe: Núm&2d.
- divisa
...
+ crear ()
+ seleccionar ( )
+ comprobar ( )
+ servir ( )
+ cerrar ( )
*
1
+ hacer /
comprobación
1
Cliente
Corporativo
+ hacer /
comprobación
item
*
Cliente
Personal
Visibilidad
[email protected]
© Vilalta Consultores 2001 - TRAD Clases visibilidad_esp - Rev. 5.3 -
Comercial
*
1
Producto
C++
Smalltalk
+ Publica
- Privada
Un elemento sólo puede ser usado por la
Clase que lo define.
# Protegida
Un elemento sólo puede ser usado por la
Clase que lo define, o por las subclases de
dicha Clase.
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 otra
Clase en el mismo Package como la
Clase propietaria. Esto implica que en
Java, el concepto de visibilidad
protegida es más público que package.
Todas las variables
instanciadas son privadas.
Un elemento sólo puede ser usado por
otras Clases que compartan el mismo
Package.
Package
Cliente
Pedido
*
Ejemplos
hacer /
comprobación
1
hacer /
comprobación
item
1
Cliente
Corporativo
Cliente
Personal
hacer /
comprobación
item
*
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
*
1
Producto
Clases
Java
Un elemento siempre es visible en
cualquier parte del programa y puede
ser llamado y modificado por cualquier
objeto del sistema.
Línea de Pedido
+ hacer /
comprobación
•Toda Clase encapsula unos elementos (atributos y operaciones) que disponen
de 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 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 ha
de disponer de un indicador de visibilidad.
Un elemento siempre es visible en cualquier Todas las operaciones son
parte del programa y puede ser llamado y públicas por defecto.
modificado por cualquier objeto del
sistema.
0..1
*
9
Consideremos la instancia de CLIENTE
PERSONAL, <<Miquel M.>>, este objeto
puede acceder a cualquier elemento de <<Josep
V.>>, que ha sido definido también como una
instancia de CLIENTE PERSONAL, sea
público, privado o protegido. <<Miquel M.>>,
a su vez también puede acceder a cualquier
elemento privado, protegido o público de
<<Josep V.>>
Consideremos la Clase CLIENTE que dispone
de una subclase CLIENTE PERSONAL.
Consideremos también que el objeto <<Josep
V.>>, es una instancia de CLIENTE
PERSONAL.
<<Josep V.>>
• 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
para CLIENTE y CLIENTE PERSONAL.
<<Josep V.>>, puede acceder a
cualquier variable instanciada dentro
de su propio objeto, si dicha variable
ha sido definida dentro de CLIENTE
o CLIENTE PERSONAL. De esta
manera, el concepto de visibilidad
privada en Smalltalk es parecido al
concepto de visibilidad protegida en
C++.
En Smalltalk no hay diferencia con
respecto a que un objeto sea de la
misma Clase o no. Podemos acceder
sólo a los elementos públicos de otro
objeto.
En C++, podemos acceder a elementos de otros
objetos de la propia Clase, de la misma manera
que podemos acceder a los propios elementos
de un objeto.
En Smalltalk, <<Miquel M.>>, no
puede acceder a las variables
instanciadas privadas de <<Josep
V.>>, sólo a sus operaciones públicas.
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
pueden ser usados por otras Clases del
mismo package.
CU Realizar pedido
Flujo Principal
Descripción
de la Dinámica del Sistema
enviado un pedido.
y cantidad.
pedido.
pedido .
• Todos los posibles estados que sus objetos pueden tener.
• Todas las posibles secuencias de eventos que pueden
ocurrir.
• Todas las transiciones posibles, de un estado a otro,
como consecuencia de los eventos que afectan a los objetos.
Diagrama de Estados
de un Pedido
Aparcar pedido.
[email protected]
Notación UML 1.3
/seleccionar primer item
*
2
1
ionar primer item
hacer /
inicio de
entregas
le
ib
on
sp
di
le
n ib
po
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
d is
rimer item
rimer item
Esperando
Entregado
Dinámica
Estados
hacer /
inicio de
entregas
6
Pedido Entregado
5
s]
Sirviendo
hacer /
comprobación
item
hacer /
comprobación
item
algunos items no estan disponibles
en stock]
Verificando
Sirviendo
3
1
rimer item
Comprobando
s]
[No todos los items comprobados]
/seleccionar siguiente item
It
[T em
od R
os eci
lo bid
s
ite o
m
s
Pedido
fechaRecibido
conPrepago
número: Alfanúm.
importe: Núm&2d.
divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
[T
© Vilalta Consultores 2001 - TRAD Dinámica 1_esp - Rev. 5.1 -
La dinámica de un sistema está determinada por:
Análisis textual
del Use Case
1
4
Item Recibido
[algunos items no estan disponibles
en stock]
Esperando
Entregado
CU Realizar pedido
Flujo Principal
enviado un pedido.
y cantidad.
Análisis textual
del Use Case
2
Descripción
Utilizamos el diagrama de estados para describir el
comportamiento de una Clase dentro de una serie temporal.
pedido.
Notación UML 1.3
Indicador
Acción
1
Comprobando
Estado
2
Sirviendo
hacer /
comprobación
item
hacer /
inicio de
entregas
Transición
di
sp
en stock]
Desencadena
siempre
la Transición
6
Evento
Pedido Entregado
5
Item Recibido
en stock]
Transición
Condició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.
Esperando
ionar primer item
Entregado
rimer item
Verificando
Sirviendo
hacer /
comprobación
item
hacer /
inicio de
entregas
s]
4
le
Auto-Transición
n ib
Procesos que ocurren de manera rápida
dentro de un ciclo contínuo sin interrupción.
[Indicador]
on
ib
3
Los tres elementos son opcionales
/ Acción
le
s]
Evento [Indicador] / Acción
Actividad
po
Sintaxis para etiquetar una transición
Acción
rimer item
d is
1
primera Transición
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Operaciones
fechaRecibido
conPrepago
número: Alfanúm.
importe: Núm&2d.
divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
Inicio
*
rimer item
Esperando
[T
Atributos
Pedido
It
[T em
od R
os eci
lo bid
s
ite o
m
s
© Vilalta Consultores 2001 - TRAD Dinámica 2_esp - Rev.- 5.1 -
[email protected]
Clase
Diagrama de Estados
de un Pedido
Entregado
Transición
Dinámica
Estados
CU Realizar pedido
Flujo Principal
enviado un pedido.
y cantidad.
Análisis textual
del Use Case
Construimos el diagrama de estados a partir de una clase
concreta para mostrar el comportamiento de un objeto
durante su ciclo de vida.
pedido.
Diagrama de Estados
de un Pedido
Notación UML 1.3
[Indicador]
hacer /
inicio de
entregas
Actividad
le
5
Auto-Transición
ionar primer item
Entregado
rimer item
Verificando
Sirviendo
hacer /
comprobación
item
hacer /
inicio de
entregas
po
n ib
le
s]
Esperando
rimer item
rimer item
Transición
Condició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.
Evento
Pedido Entregado
Transición
No hay Actividades para este Estado, por lo
que el Pedido permanecerá a la espera de
un Evento.
d is
Item Recibido
en stock]
Desencadena
siempre
la Transición
6
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
4
Procesos que ocurren dentro de un ciclo discontínuo
y pueden ser interrumpidospor algun evento.
hacer /
comprobación
item
en stock]
Transición
Estado
Comprobando
3
Los tres elementos son opcionales
Procesos que ocurren de manera rápida
dentro de un ciclo contínuo sin interrupción.
/ Actividad
2
Sirviendo
s]
Evento [Indicador] / Acción
Aunque finalize la Actividad
el Pedido permanecerá en
este Estado hasta que ocurre
el Evento que desencadena
su Transición
Esperando
[T
/ Acción
Indicador
Acción
1
ib
Sintaxis para etiquetar una transición
Estado
Acción
on
1
primera Transición
sp
fechaRecibido
conPrepago
número: Alfanúm.
importe: Núm&2d.
divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
Inicio
*
di
Pedido
Cuando una Transición no dispone de un Evento
en su etiqueta, significa que la Transición se
realiza tan pronto como la Actividad asociada
con un Estado es finalizada
It
[T em
od R
os eci
lo bid
s
ite o
m
s
Operaciones
Implementación
[email protected]
Clase
Atributos
3
Descripción
Entregado
Dinámica
Estados
CU Realizar pedido
Flujo Principal
enviado un pedido.
pedido.
2
Sirviendo
hacer /
comprobación
item
hacer /
inicio de
entregas
s]
ib
on
5
4
Pedido
Entregado
Pedido
Cancelado
Entregado
sp
on
ib
6
Pedido
Cancelado
Cancelado
sin Superestados
5
6
Pedido
Cancelado
hacer /
inicio de
entregas
le
s]
Sirviendo
hacer /
comprobación
item
n ib
Notación UML 1.3
rimer item
rimer item
Esperando
Cancelado
Entregado
Verificando
po
con Superestados
ionar primer item
rimer item
d is
Diagrama de Estados
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
Pedido
Entregado
[T
4
Item Recibido
[algunos items
Esperando
no estan
disponibles en stock]
Pedido
Cancelado
Item Recibido
[algunos items
Esperando
no estan
di
[Todos los items
comprobados &&
algunos items no estan
le
s]
3
le
3
[Todos los items
comprobados &&
algunos items no estan
hacer /
inicio de
entregas
sp
[No todos los items
comprobados]
/seleccionar
Comprobando
siguiente item
1
[No todos los items
2
comprobados]
/seleccionar
Comprobando todos los items disponibles]
Sirviendo
siguiente item
hacer /
comprobación
item
Activo
Hay que distinguir un Evento como tal, del objeto que
representa el registro de los efectos de dicho Evento.
di
1
Sólo nos interesan aquellos Eventos que provocan un cambio
de estado en los objetos de nuestro modelo.
It
[T em
od R
os eci
lo bid
s
ite o
m
s
[email protected]
Nombre del Superestado
Sólo podemos conocer que un Evento ha ocurrido,
detectando sus “efectos” en nuestro modelo.
It
[T em
od R
os eci
lo bid
s
ite o
m
s
Análisis textual
del Use Case
4
Un Evento no es un objeto. Un Evento es la “causa” que
justifica la existencia de una información.
y cantidad.
Descripción
Entregado
Dinámica
Estados
CU Realizar pedido
Flujo Principal
enviado un pedido.
y cantidad.
artículo...
5
Descripción
muestra...
Los diagramas de estados son muy útiles para describir el
comportamiento de un objeto a través de múltiples Casos
de Uso.
b. SI existen suficientes items...
c. NO existen suficientes items...
Aparcar pedido.
Autorizando
hacer /
comprobación
del pago
[pago NO correcto]
[pago SI correcto]
Esperando
Cancelado
Autorizado
Rechazado
Pedido Cancelado
Sirviendo
Entregado
Pedido Entregado
ionar primer item
Verificando
Sirviendo
hacer /
comprobación
item
hacer /
inicio de
entregas
le
s]
rimer item
n ib
Autorizado
po
Autorizando
Entregado
rimer item
Rechazado
Pedido Rechazado
Diagrama de Estados
Concurrentes
Notación UML 1.3
d is
Comprobando
Entregado
I te
m
od R
o s e c ib
lo id
s
it e o
m
s
[email protected]
rimer item
Esperando
[T
Análisis textual
del Use Case
pedido .
Entregado
Dinámica
Estados
Arquitectura del sistema
1
Una Arquitectura es un conjunto organizado de elementos.
Se utiliza para especificar las decisiones estratégicas acerca
de la estructura y funcionalidad del sistema, las colaboraciones
entre sus distintos elementos y su despliegue físico para
cumplir unas responsabilidades bien definidas.
Vista de
© Vilalta Consultores 2001 - TRAD Arquitectura 1_esp - Rev. 5.1 -
[email protected]
Vista del
Componentes
Modulares
Modelo de Referencia
Vista de la
Funcionalidad
Use Cases
Vista de
Vista de
Implementación
Ejecutables
Distribución Física
Elementos
Vista de la Arquitectura 4+1
Notación UML 1.3
Arquitectura
Vista del
2
La vista del Modelo de Referencia (Reference Information
Model), está determinada por la arquitectura lógica.
La arquitectura lógica es capturada por los diagramas de
Clases que contienen las Clases y relaciones que representan
las abstracciones esenciales del sistema a desarrollar.
• Clases
• Asociaciones
Vista del
• Agregaciones
• Generalización
• Packages
Pedidos
[email protected]
Cliente
El Modelo de Referencia se construye en sucesivas
iteraciones durante la fase de Formalización.
Las Clases y Packages del modelo reflejan las
decisiones tomadas con respecto a los “mecanismos
clave” del sistema.
Una eficiente implementación de los “mecanismos
clave” requiere seleccionar Patrones (Patterns) que
se ajusten a los requerimientos esenciales del
proyecto.
Pedido
fechaRecibido
conPrepago
número: Alfanúm.
importe: Núm&2d.
divisa
...
seleccionar ( )
comprobar ( )
servir ( )
cerrar ( )
...
*
1
hacer /
comprobación
Artículos
1
Cliente
Corporativo
La implementación de “mecanismos clave” requiere
seleccionar también:
*
• Motor de Base de Datos
• Tratamiento de errores
• Mecanismos de comunicación
• Migración y distribución de objetos
• Networking
Cliente
Personal
hacer /
comprobación
item
• Lenguaje de programación
• Interface gráfico de usuario “look and feel”
Clientes
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
*
1
Producto
Arquitectura
3
Vista de
Vista del
Componentes
Modulares
La vista de Componentes Modulares refleja la organización
de módulos de software dentro del entorno de desarrollo.
Esta vista de arquitectura toma en cuenta los requerimientos
que 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ísica
del sistema.
Vista de
• Componentes: En esta vista representan la organización
de módulos de código fuente.
[email protected]
Componentes
Modulares
Pe d i d o
Los Packages estan organizados en una jerarquía
de capas que disponen de una interface bien definida:
4
Interface de Usuario
3
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
2
Pa c k a g e s r e u t i l i z a b l e s
1
Mecanismos clave CORE
ø
Pa c k a g e s d e p l a t a f o r m a
Entrada
Pedidos
AWT
Mailing
Interface Usuario
Java GUI toolkit
Interface Usuario
Información
Artículos
Dominio
(OS -Hardware)
Pedidos
Los Packages de la vista lógica del modelo estan
mapeados con los Packages físicos y los componentes
de software (subsistemas).
Clientes
Artículos
Arquitectura
Vista de
Vista del
Componentes
Modulares
Esta vista se centra en la estructura de los componentes
“run-time”, los ejecutables del sistema.
Esta arquitectura tiene muy en cuenta los siguientes
requerimientos no funcionales:
Vista de
Implementación
Ejecutables
[email protected]
Implementación
Ejecutables
Los componentes run-time muestran los mappings
de las Clases a librerías de tipo ActiveX, Applets de
Java y librerías dinámicas.
Los componentes ejecutables muestran sus interfaces
y niveles de dependencia dentro de la aplicación.
• Rendimiento
• Integridad
• Fiabilidad
• Seguridad
• Escalabilidad
• Sincronización
• Administración del sistema
Vista de
4
Entrada
Pedidos
AWT
Mailing
Interface Usuario
Java GUI toolkit
Interface Usuario
Entrada
Pedidos
Mailing
Aplicación
Aplicación
Dominio
Pedidos
P e d i d o s . exe
Clientes
Artículos
Artículos.dll
Oracle
Expedición.dll
Base de
Datos
Interface
Interface global
Ingres
Clientes.dll
Interface
Arquitectura
Vista de
Vista del
Componentes
Modulares
Vista de
Implementación
Ejecutables
5
Esta vista presenta el mapping de componentes de software
ejecutables con los nodos de procesamiento (hardware).
Esta arquitectura tiene en cuenta los siguientes
requerimientos:
Vista de
Elementos
• Disponibilidad del sistema
• Rendimiento
• Escalabilidad
Los diagramas de distribución muestran el despliegue de
nodos (locales y remotos), en la organización de la empresa.
Vista de
[email protected]
Elementos
Permite al equipo de desarrollo comprender mejor la
topología de un sistema distribuido.
TCP/IP
Servidor Contabilidad
Un Nodo es un objeto físico run-time que representa
un recurso informático. Este recurso, generalmente
dispone de datos persistentes y capacidad de proceso.
:Base de
Datos
En la mayoría de los casos un Nodo puede representar
una pieza de hardware, desde un periférico a un
servidor.
:Base de
Datos
Las Conexiones entre Nodos muestran las líneas de
comunicación con las que el sistema tendrá que
interactuar.
Servidor Área Comercial
:Contabilidad
:Comercial
Configuración
:Servidor
Aplicaciones
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 corre
cada Package en el sistema.
Nodos
:Usuarios
TCP/IP
Las Dependencias muestran cómo los componentes
se comunican con otros componentes. La dirección
de una Dependencia concreta, indica el conocimiento
en la comunicación.
Cliente Win95
:Cliente
Comercial
Interface
:GUI
Comercial
Componente
Conexión
Arquitectura
Vista de
Vista del
Esta vista certifica la validez de:
Componentes
Modulares
• Modelo de Referencia
Vista de la
Funcionalidad
• Componentes modulares de software
Use Cases
Vista de
6
Vista de
Implementación
Ejecutables
Elementos
• Ejecutables
• Distribución de recursos informáticos
Con la funcionalidad requerida del sistema.
Utilizamos los siguientes elementos para describir la
funcionalidad:
Abrir Arqueo
<< Ext >>
• Diagramas de Casos de Uso
Hacer un
Inicio de Día
• Especificación de Casos de Uso
<< Inclu >>
Cajero
Cerrar Arqueo
Supervisor
• Diagramas de Interacción (Escenarios)
• Diagramas de Actividad (Flujos de Trabajo)
Hacer un
Fin de Día
<< Ext >>
<< Inclu >>
<< Inclu >>
Imprimir
documento
Exportar
movimientos
• Diagramas de Estados (Dinámica)
Contabilidad
Recepción
de un
Pedido
Preparar
Pedido
CU Realizar pedido
Flujo Principal
[NO éxito]
Cancelar
Pedido
enviado un pedido.
Comprobar
Comprobar
Pago
Items
[en stock]
[SI éxito]
Asignar
Items
y cantidad.
Una ventana de
introducción de
pedidos
Un pedido
Una línea
de pedido
Un item
de stock
[Requiere reposición]
Reponer
Items
Servir
Pedido
[tieneStock]
nuevo
ionar primer item
rimer item
Verificando
Sirviendo
hacer /
comprobación
item
hacer /
inicio de
entregas
on
ib
le
s]
[tieneStock]
asignar ( )
pedido.
rimer item
di
sp
[tieneStock]
nuevo
rimer item
[tieneStock]
nuevo
Esperando
It
[T em
od R
os eci
lo bid
s
ite o
m
s
[email protected]
Importar nueva
configuración
Entregado
Entregado
Arquitectura

UML Guía Visual

Transcripción

Documentos relacionados