Uml Guia 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
info@vico.org
R e v. 0 . 1 7 Josep Vilalta
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: jvilalta@vico.org
Autor: 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
concreto, en base a una práctica consensuada para utilizar los recursos disponibles y
rg
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
.o
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á
co
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.
vi
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 Fecha actualización: Revisión: Página:
Presentación.doc Equipo: www.vico.org 04/09/01 11:16 18 1 de 9
Historial: 03/09/01 9:03
Nuestros límites para entender esta realidad están en nuestro lenguaje. El mundo es la
suma total de lo que podemos definir, organizar y visualizar. Cabe preguntarse ¿de qué
manera un modelo en UML representa nuestra experiencia?. Enseñar a utilizar un
lenguaje formal siempre es problemático. Es necesario mostrar como este lenguaje
puede ser aplicado a la realidad tal como la conocemos y tal como la compartimos con
los demás. Con esta guía visual mostramos de manera precisa las técnicas básicas para
usar UML en diferentes contextos. La clave está en discriminar cuales son aquellos
procedimientos esenciales que nos permiten evitar costosas confusiones conceptuales.
No es mediante el descubrimiento de nuevos objetos y de sus múltiples conexiones que
avanzamos en las respuestas a nuestros interrogantes cuando modelamos un dominio,
sino mediante la disolución de las contradicciones que existen entre los términos
rg
(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,
.o
todo en busca de la simplicidad y la usabilidad.
co
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
vi
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.
Historial: 03/09/01 9:03
Mucha gente cree que la principal utilidad de la orientación a objetos es la reutilización

del código para conseguir un desarrollo más rápido de las aplicaciones (Rapid
Application Development). No comparto esta opinion. Si hay algo que caracteriza un
entorno de desarrollo actual es la constante del cambio. Todo proyecto que sobrepase
los tres meses está amenazado por la aparición de nuevas plataformas más exigentes, la
extinción de herramientas sin previo aviso y, de manera sistemática, por la rotación del
personal crítico encargado del proyecto. También está sometido, como no, a los
cambios de requerimientos del cliente que a su vez están plenamente justificados por la
readaptación de sus procesos de negocio a un mercado inestable.
Ante este cuadro de incertidumbre, el mayor desafio de una metodología de desarrollo
rg
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,
.o
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
co
reemplazables por otros más optimizados o bien por componentes que aporten una
mayor funcionalidad y/o facilidad de uso.
vi
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.
Historial: 03/09/01 9:03
¿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
rg
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
.o
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.
co
vi
¿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).
Historial: 03/09/01 9:03
Un plan de estudio para realizar una progresiva asimilación de los conceptos podría
empezar con los Casos de Uso (CU) y continuar con el análisis de los flujos de trabajo
de un grupo de CU mediante los diagramas de Actividad; a continuación, separar los
escenarios que agrupan una serie de actividades y hacer aflorar, a través de los
diagramas de Interacción, los objetos que intercambian una serie de mensajes. A partir
de este punto, disponemos del bagaje suficiente como para introducirnos en la
abstracción de los objetos y comprender la importancia de separar las tres perspectivas
básicas en nuestra representación de las clases: concepción, especificación e
implementación. El siguiente paso es identificar alguna clase con un comportamiento
complejo que la haga candidata a revisar todos sus posibles estados y averiguar que
eventos son capaces de provocar un cambio de estado. El diagrama de Estados-
rg
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.
.o
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
co
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
vi
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/
Historial: 03/09/01 9:03
¿De dónde provienen las ideas expuestas?

El contenido de esta guía ha sido elaborado a partir del trabajo de una serie de
profesionales que el autor ha tenido la oportunidad de estudiar y aplicar en distintos
proyectos. Desde principios de los 90, los artículos publicados en el Journal of Object
Oriented Programming (JOOP) por James Odell, James Rumbaugh, Grady Booch,
Desmond d’Souza, Bertrand Meyer, Steve Cook, John Daniels, Sally Shlaer y
Stephen J. Mellor entre otros, han sido una constante fuente de conocimiento.
Publicaciones pioneras como el Object Oriented Technology, A Manager’s Guide de
David A. Taylor, en su primera edición de 1990 y en la segunda ampliada de 1998, han
tenido una gran influencia en como abordar la presentación didáctica. También los
libros de Peter Coad et al, Object Oriented Analysis, Design and Programming, Object
rg
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
.o
& 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
co
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
vi
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.
Historial: 03/09/01 9:03
Competencia y actuación
En los últimos veinte años de mi carrera profesional en el desarrollo de sistemas de
información he participado en una gran diversidad de proyectos con distintos grados de
responsabilidad e involucración, pero siempre con un compromiso firme en la calidad y
usabilidad del producto final.
Entorno industrial
o CIM para la extrusión de polietileno y fabricación de mallas agrícolas y
de embalaje.
o CIM para el fraccionamiento de hemoderivados
o Plan Funcional para la implementación SAP-Logística
rg
Entorno sanitario
.o
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
co
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
vi
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
Historial: 03/09/01 9:03
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
rg
Entorno comercial
o Merchandising de productos farmacéuticos
o Subastas y liquidación de lotes
.o
o Gestión de redes de puntos de venta con videoconferencia
co
Entorno de servicios
o Auditorías Informáticas
o Plan de Sistemas de Información
vi
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
Historial: 03/09/01 9:03
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
rg estructurados
.o
Agradecimientos
co
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
vi
como lingua franca.
Josep Vilalta
Badalona, Barcelona (España)
jvilalta@vico.org
http://www.vico.org
1
Niveles de concepción y formalización
de un proyecto
Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5
Nivel ø
C ó d i g o
Use Case Una ventana de Una línea Un item
introducción de Un pedido Cliente
de pedido de stock
Pedido
Use Case pedidos * 1 hacer /
comprobación
hacer /
M G
Una ventana de comprobación Cliente
Una línea Un item item
introducción de Un pedido de pedido Pedido
de stock * hacer /
pedidos 1
<< Extends >> [tieneStock] hacer /
comprobación
nuevo tieneStock:= comprobar ( ) 1 comprobación

<< Extends >> item
[tieneStock]
Cliente Cliente
nuevo
[tieneStock] Corporativo Personal
1
nuevo
hacer /
comprobación
jvilalta@vico.org
[tieneStock] item Cliente Cliente

: Pedido Personal
Corporativo
Actor nuevo
tieneStock:( ) hacer /
<< Communicates >> * comprobación
item
0..1
<< Communicates >> xxx línea : Línea de pedido: Pedido
xxx stock : item de stock
*
<< Uses >> Comercial *
Línea de Pedido
<< Uses >> xxx línea : Línea de pedido
hacer /
0..1
: Item de Expedición : Item de Pedido de reposición
xxx stock : item de stock comprobación * 1
* Comercial
Producto
Línea de Pedido
Actor hacer /
comprobación
: Item de Expedición : Item de Pedido de reposición * 1
Producto
Matrícula Glosario Funcionalidad Escenarios Clases

del Proyecto de Conceptos Diagramas de Interacción Análisis
© Vilalta Consultores 2001 - TRAD UMD_esp - Rev. 5.2 -
Casos de Uso de objetos Diseño

Implementación
Procesos Especificación Flujos Dinámica

PDI Principales Casos de Uso de Trabajo Eventos - Estados
P
“Code like hell”
CU
Entrar
Reposición
Entrar Entrar
P
Pedido
CU
Reposición
Seleccionar ionar primer item
Validar Pedidos [Todos los items comprobados &&
Riesgo Pendientes todos los items disponibles]
Entrar ionar primer item
*Seleccionar
[para cada pedido seleccionado] rimer item Verificando Sirviendo
[Todos los items comprobados &&
Reposición
Pedidos hacer / todos los items disponibles]
hacer /
comprobación inicio de
Validar Asignar * [para cada pedido seleccionado] item
rimer item Verificando entregasSirviendo
Pago
Items hacer /
s]
hacer /
le
n ib
Asignar item entregas
po
rimer item Entregado
d is
Items
s]
it e o
s
le
Cronograma
m
lo id
n ib
o s e c ib
po
rimer item
s
Entregado
od R
d is
m
rimer item
it e o
s
I te
m
lo id
o s e c ib
[T
Esperando Entregado
s
Plan Director
od R
m
rimer item
I te
[T
Activar Regularizar Esperando Entregado
Pedido Activar StockRegularizar
Pedido Stock
Iteraciones
Tiempo
Fases
Iteraciones
PDP 2
E s f u e r z o d e d e s a r ro l l o
Procesos Producto
Actividades
Entregables
Concepción Formalización Construcción Transición
Misión
Modelo
jvilalta@vico.org
Prototipo
© Vilalta Consultores 2000 - TRAD PDP iteraciones_esp - Rev. 4.2 -
Componentes
Certificación
Iteraciones Iter Iter Iter

preliminares Iter #1 Iter #2 Iter #n #n+1 #n+2 Iter #n #n+1
Iteraciones
3
PDP Misión
Modelo
P l a n D i re c t o r d e P ro y e c t o Prototipo
Componentes
Certificación

Concepción Iteraciones
M P
Matrícula Procesos
jvilalta@vico.org
del proyecto principales
P P
Use Case
Use Case
Cliente
Pedido
* hacer /
<<Incluye>>
hacer /
1 comprobación Use Case
comprobación Cliente
item
Pedido
<< Extends >>
* hacer /
1 comprobación
hacer /
comprobación
<<Extiende >>
1 item
Use Case
Cliente Cliente
Corporativo Personal
1
Misión
hacer /
comprobación
item Cliente Cliente Actor 1
Corporativo Personal << Communicates >> Use Case
© Vilalta Consultores 2001 - TRAD PDP misión_esp2 - Rev. 5.2 -
hacer /
* comprobación
item
0..1 <<Generalización>> << Uses >>
*
Comercial *
Línea de Pedido
0..1 <<Incluye>>
hacer /
comprobación * 1
* Comercial
Línea de Pedido
Producto Actor 2 Use Case
hacer /
comprobación
* 1
Producto
Patrones de Patrones de
Análisis Funcionalidad
PDI
P
G
Cronograma
Glosario Plan Director
de Conceptos Iteraciones
Anteproyecto
4
PDP Misión
Modelo
Componentes
Certificación

Iteraciones
Fo r m a l i z a c i ó n
Una ventana de
Use Case introducción de Un pedido
Una línea Un item
de pedido de stock Cliente
pedidos
Pedido
Use Case * 1 hacer /
comprobación
Una ventana de Una línea Un item
hacer /
introducción de Un pedido de pedido item
de stock
pedidos Pedido hacer /
* 1
<< Extends >> [tieneStock]
nuevo tieneStock:= comprobar ( ) hacer /
comprobación
1 comprobación
item
nuevo
[tieneStock] Cliente Cliente
nuevo Corporativo Personal
1
hacer /
[tieneStock] comprobación
: Pedido item Cliente Cliente
Actor tieneStock:( )
hacer /
item
xxx línea : Línea de pedido: Pedido
xxx stock : item de stock 0..1
<< Communicates >> *
<< Uses >> Comercial *
Línea de Pedido
xxx stock : item de stock hacer /
0..1
jvilalta@vico.org
comprobación * 1
* Comercial
Producto
Línea de Pedido
Actor : Item de Expedición : Item de Pedido de reposición
hacer /
comprobación
* 1
Producto
Funcionalidad Escenarios Clases
P
Diagramas de Interacción Análisis
P
Use Case
Use Case
<<Incluye>>
Use Case
Casos de Uso de objetos y Diseño Pedido
* 1
Cliente
hacer /
comprobación
hacer /
comprobación
<< Extends >> item
Cliente
Pedido hacer /
*
© Vilalta Consultores 2001 - TRAD PDP modelo_esp2 - Rev. 5.3 -
1 comprobación
<<Extiende >> hacer /
comprobación
1 item
Use Case
Cliente Cliente
1
hacer /
Actor 1 comprobación
item Cliente Cliente
<< Communicates >>
Modelo
Use Case
hacer /
* comprobación
item
<<Generalización>> << Uses >> 0..1
*
Comercial *
<<Incluye>> Línea de Pedido
0..1
hacer /
comprobación * 1
* Comercial
Actor 2 Use Case Línea de Pedido
Producto
hacer /
comprobación
* 1
Producto
Patrones de Patrones de
Funcionalidad Entrar
Reposición
Análisis
Entrar Entrar
Pedido
CU
Reposición
*Seleccionar
Reposición
hacer /
Pago
Items hacer /
s]
hacer /
le
n ib
po
d is
Items
s]
it e o
s
le
m
lo id
n ib
o s e c ib
po
rimer item
s
Entregado
od R
d is
m
rimer item
it e o
s
I te
m
lo id
o s e c ib
[T
Esperando Entregado
s
od R
m
rimer item
I te
[T
Pedido Stock
Especificación Flujos de Dinámica

Casos de Uso Trabajo Eventos
Estados
5
PDP Misión
Modelo
Componentes
Certificación

Iteraciones
Construcción
Cliente
Pedido hacer /
* 1 comprobación
hacer /
item
Pedido hacer /
* 1 comprobación
hacer /
1 comprobación
item
*Acta Cliente Cliente

Versión Fecha Año Académico Corporativo Personal
*Acta Versión Fecha 1
Año Académico Destino Alumnos ** Tribunal
hacer /
Destino Alumnos ** Tribunal comprobación
hacer /
* comprobación
item
Selección Alumno P. Global P. Esp. Resultado Ver
0..1
Selección Alumno P. Global P. Esp. Resultado Ver
*
jvilalta@vico.org
Comercial *
Línea de Pedido
✔ 0..1
✔
hacer /
Cliente comprobación * 1
* Comercial
Pedido Producto
* hacer / ✔ Línea de Pedido
1 comprobación
✔
hacer / hacer /
comprobación comprobación
* 1
item Producto
Clases
Cliente Cliente
Interface
hacer /
comprobación
item
Gráfico de Usuario
*
Línea de Pedido
0..1
Comercial Diseño
Implementación
hacer /
comprobación
* 1
Producto
Cliente
© Vilalta Consultores 2001 - TRAD PDP construcción_esp2 - Rev. 5.3 -
Pedido hacer /
* 1 comprobación
hacer /
item
Pedido hacer /
* 1 comprobación
hacer /
1 comprobación
item
P
Cliente Cliente
1
hacer /
comprobación
Componentes
hacer /
* comprobación
item
0..1
*
Comercial *
Línea de Pedido
0..1
hacer /
comprobación * 1
* Comercial
Producto
Línea de Pedido
hacer /
comprobación
* 1
Producto
Patrones de
Framework Diseño
de Aplicaciones
Base de Datos Arquitectura

Esquema de Persistencia Componentes
6
PDP
Misión
Modelo
Componentes
Certificación

Iteraciones
Concepción Fo r m a l i z a c i ó n Construcción
Use Case Una ventana de Una línea Un item Cliente

introducción de Un pedido de pedido Cliente
de stock Pedido
pedidos Pedido * 1 hacer /
Use Case
M
* hacer / comprobación
1
P
comprobación hacer /
hacer / comprobación Cliente
Una ventana de Una línea Un item comprobación item
Cliente
introducción de Un pedido de pedido
item Pedido hacer /
de stock Pedido * 1
pedidos * hacer / comprobación
1
hacer /
comprobación hacer /
comprobación
nuevo tieneStock:= comprobar ( ) comprobación 1 item
1
<< Extends >> item
[tieneStock] Cliente Cliente
Cliente Cliente *Acta Versión Fecha
nuevo
[tieneStock]
Año Académico Corporativo Personal
Corporativo Personal ** Tribunal 1
nuevo 1 Destino Alumnos hacer /
hacer / comprobación
comprobación item Cliente Cliente
[tieneStock] item Cliente Cliente
: Pedido Corporativo Personal
Actor tieneStock:( )
hacer / *
hacer /
comprobación
item Selección Alumno P. Global P. Esp. Resultado Ver
item
0..1
xxx línea : Línea de pedido: Pedido 0..1
<< Communicates >> xxx stock : item de stock
*
*
Comercial *
<< Uses >> Comercial * Línea de Pedido
Línea de Pedido ✔ 0..1
hacer /
: Item de Expedición : Item de Pedido de reposición hacer /
0..1
comprobación
*
* 1 Comercial
xxx stock : item de stock comprobación * 1
* Comercial Producto
Producto ✔ Línea de Pedido
Línea de Pedido
hacer /
Actor : Item de Expedición : Item de Pedido de reposición
hacer /
comprobación
comprobación
* 1
* 1 Producto
Producto
Matrícula Procesos Funcionalidad Escenarios Clases Interface Clases

jvilalta@vico.org
del proyecto principales Diagramas de Interacción Análisis Gráfico de Usuario Diseño

Casos de Uso de objetos y Diseño Implementación
Misión Modelo Componentes

© Vilalta Consultores 2001 - TRAD PDP_esp2 - Rev. 6.2 -
Entrar
Reposición
PDI
P
Entrar
G
Entrar
Pedido
CU
Reposición
*Seleccionar
Reposición
hacer /
Pago
Items hacer /
s]
hacer /
le
n ib
po
d is
Items
s]
it e o
s
le
m
lo id
n ib
o s e c ib
po
rimer item
s
Entregado
od R
d is
m
rimer item
it e o
s
I te
m
lo id
o s e c ib
[T
Esperando Entregado
s
od R
m
rimer item
I te
[T
Pedido Stock
Cronograma
Glosario Plan Director Especificación Flujos de Dinámica
de Conceptos Iteraciones Casos de Uso Trabajo Eventos Base de Datos Arquitectura
Esquema de Persistencia Componentes
Estados
Anteproyecto
1
¿ Cómo identificar Actores ?
Interacción de un
Actor con el Sistema
Us ar Caje ro
Automátic o
<< Incluye >> S u b sistema
d e cu en tas
clien te
- Ro le d e su b sistema -
R e a l i z a r una
Relación que indica la t ra nsa c c i ón
especialización a partir de una Interacción del
C lien te función genérica Sistema con un Actor
- Role de us ua rio - <<Generaliza>> <<Generaliza>>
<<Generaliza>>
Retirar Activar
jvilalta@vico.org
Efectivo Ta r j e t a S u b sitema
Consultar d e certificació n
Movimientos
d e med io s
d e p ag o
S is te ma e n proc e s o de mode la do
Actores
© Vilalta Consultores 2001 - TRAD Actores_esp - Rev. 5.1 -
- 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
A la búsqueda de Actores.-
• Entran información al sistema
• Reciben información del sistema 1. ¿ Quien está interesado en un requerimiento concreto ?
• Entran y reciben información
2. ¿ En qué dominios de la organización se usará el sistema ?
3. ¿ Quien será beneficiario de la nueva funcionalidad ?
Use Case
4. ¿ Quien proveerá, usará y/o retirará, información ?

<< Extends >>
Actor
5. ¿ Quien dará soporte y administrará el sistema ?
6. ¿ Usará el sistema un recurso externo ?
<< Communicates >>
<< Uses >>
Actor
7. ¿ Un usuario actuará con diferentes roles ?

Funcionalidad 8. ¿ Diferentes usuarios actuarán con un mismo rol ?
Diagramas de
Casos de Uso 9. ¿ Interaccionará el nuevo sistema con un sistema antiguo ?
2
¿ Cómo identificar Casos de Uso ?
Hacer un
Abr ir Arque o << Extiende >> Ini ci o de Dí a
Relación que describe una variación
Interacción de un posible del comportamiento normal
Actor con el Sistema de un Use Case
<< Incluye >>
Piezas de funcionalidad del sistema

que suministran valor a un Actor y son
reutilizables en diferentes procesos
Importar nueva
S u p erv iso r
configuración - Ro l d e u su ario -
C ajero
- Rol de us ua rio - Ha c e r un
C e r r ar Arque o << Extiende >> Fi n de Dí a Relación que permite descomponer
un Use Case con un determinado
nivel de granularidad
<< Incluye >> << Incluye >>
Relación que indica el uso de
jvilalta@vico.org
una funcionalidad compartida

por otros Casos de Uso
Im pri m i r E xport ar
doc um e nt o 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 -
© Vilalta Consultores 2001 - TRAD UCs_esp - Rev. 5.1 -
Interacción del
Sistema con un Actor
A la búsqueda de Casos de Uso.-

1. ¿ Cuales son las tareas y responsabilidades de cada actor ?
Use Case
2. ¿ Algún actor creará, almacenará, cambiará, borrará o leerá información del sistema ?
<< Extends >>
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 ?

Actor
<< Communicates >>
<< Uses >>
Actor 5. ¿ Es necesario que un Actor sea informado sobre ciertas incidencias del sistema ?
Funcionalidad 6. ¿ Qué Casos de Uso darán soporte y mantendrán el sistema ?

Diagramas de
Casos de Uso 7. ¿ Pueden ser realizados por los Casos de Uso todos los requerimientos funcionales documentados ?
Use Case
3
<< Extends >>
Especificación
Actor
<< Communicates >>
<< Uses >>
de un Caso de Uso
Actor
Funcionalidad
Diagramas de
L
Casos de Uso
Caso de Uso principal Límites: Cuando empieza y cómo termina el Caso de Uso.
I
Ha c e r un
C e r r ar A rque o << Extiende >> Fin de Día Interacciones: Comportamiento de Actores y Sistema.
Acción-Reacción dentro del Caso de Uso.
<< Incluye >> Casos de Uso secundarios

M Masa: Conjunto de Objetos e Interfaces que requiere
el Caso de Uso.
Imprimir
doc ume nto <<Generaliza>>
Imprimir
tira de a rque o
I Índice de escenarios: Flujo principal de eventos y secuencia
de variaciones posibles dentro de un Caso de Uso.
jvilalta@vico.org
Caso de Uso genérico Caso de Uso especializado

T Tribulaciones: Contingencias probables que pueden afectar
al flujo de los eventos y son excepciones del Caso de Uso.
© Vilalta Consultores 2001 - TRAD LIMIT UCs_esp - Rev. 5.1 -
Propósito
- Regla de Negocio - Precondiciones Activación Flujo Principal Variaciones Excepciones
Cerrar un periodo de • Arqueo abierto • A discreción de un Actor 1. Sistema requiere confirmación de a. Si Actor decide aparcar el cierre de arqueo,
movimientos de caja • Actor habilitado habilitado cierre de arqueo. sistema activa UC Aparca_arqueo y termina
• TPV abierto el UC.
para obtener una 2. Sistema comprueba la configuración
• TPV habilitado a. Cierre de arqueo de tipo abierto:
situación real de dinero de TPV para identificar tipo de cierre. • Actor decide el momento de imprimir el
en efectivo y en documento “Tira de Arqueo”.
documentos. b. Cierre de arqueo de tipo ciego:
3. Sistema calcula los totales teóricos • Sistema no muestra los totales teóricos para
para cada forma de cobro. cada forma de cobro.
4. Actor introduce totales reales para cada

forma de cobro. a. Si el servidor está off-line, sistema informa
5. Sistema registra el cierre: importes al usuario, termina el UC manteniendo el
reales para cada forma de cobro y arqueo abierto.
descuadres. a. Si impresora está off-line, sistema informa
6. Sistema imprime el documento “Tira al usuario y le pide confirmación para
de Arqueo”. continuar.
4
Ventajas del modelo 1. Lenguaje de comunicación entre usuarios
Use Case y desarrolladores.
2. Comprensión detallada de la funcionalidad

del sistema.
H ac e r un
A brir A rque o << Extiende >> Ini c i o de Dí a 3. Acotación precisa de las habilitaciones de
los usuarios.
<< Incluye >>
4. Gestión de riesgo más eficiente para
Hac e r un
gobernar la complejidad.
Fin de Día Importar nueva
configuración 5. Estimación más exacta para determinar
tiempo, recursos y prioridades en la dosificación
<< Extiende >> << Incluye >>
de esfuerzo de desarrollo.
jvilalta@vico.org
C e rra r A rque o
Export a r
movimient os
6. Fiel trazabilidad para verificar la traducción
de requerimientos en código ejecutable.
<< Incluye >> 7. Mayor control para mantener las sucesivas
© Vilalta Consultores 2001 - TRAD modelo UC_esp - Rev. 5.1 -
revisiones de los programas.
Imprimir
<<Generaliza>>
Imprim i r
tira de arque o
8. Certificación contractual Cliente-
doc ume nto
Desarrollador.
9. Documentación orientada al usuario: Helps

Use Case
- Manual de Procedimientos - Reglas de Negocio.
Piezas de funcionalidad reutilizables
<< Extends >>
Actor en diferentes procesos de negocio 10. Documentación orientada al administrador

<< Communicates >>
Actor
<< Uses >>
del sistema: Soporte de Mantenimiento.
Funcionalidad
Diagramas de
Casos de Uso
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.
No definen todos los requerimientos (por ej. los tipos de
qu erimiento datos, interfaces externas, niveles de rendimiento esperado,

Re s etc.), pero representan el hilo conductor que vincula a todos
los requerimientos posibles (actuales y futuros) de una
aplicación.
Reglas
Funcionales, de Negocio
no funcionales y protocolos de
e interfaces de intercambio de
ión
usuario información
Mo
jvilalta@vico.org
Cer tif ic ac
Funcionalidad, Mapa conceptual:

Análisis y Diseño Clases de análisis
delo
Caso de Uso
Implementación
Dinámica de
© Vilalta Consultores 2001 - TRAD Req y CUs_esp - Rev. 1.1 -
de código y
Refactoring Clases complejas
Plan Director Mapa funcional:

de Iteraciones: Flujos de trabajo
Cronograma principales y
y prioridades variaciones
Ge
Métrica: Escenarios de
Escandallo de interacción
sti
recursos de objetos:
n y actividades Clases de diseño
ur
Use Case
a
ó
de
ct
<< Extends >>
Pr e
ui t
Actor
oye
A rq
<< Communicates >>
cto
<< Uses >>
Actor
Funcionalidad
Diagramas de
Casos de Uso
Recepción Evento que
CU Realizar pedido de un desencadena
la secuencia de
Flujo Principal Va r i a c i o n e s Diagrama de Actividad Pedido
actividades
1. Usuario identifica el cliente que ha
Notación UML 1.3
enviado un pedido.
2. Usuario entra lineas de pedido, con su
código de artículo, tipo de presentación
y cantidad.
Identificar Actividad
3. Sistema comprueba cada línea del a. Artículo NO está vigente en catálogo, sistema Análisis textual Cliente
pedido para validar la situación del informa que articulo no está vigente y del Caso de Uso
artículo en catálogo y el número de muestra artículos alternativos activando el
items del artículo en stock. CU Seleccionar artículo.
b. SI existen suficientes items del artículo en
Entrar
el stock, sistema asigna items al pedido.
líneas pedido
c. NO existen suficientes items del artículo en
stock, o la asignación de items deja la Concurrencia dinámica de actividades
situación del artículo en stock por debajo del Barra de sincronización
nivel de reposición, sistema genera pedido
de reposición activando el CU Generar
pedido. * [para cada línea de pedido]
4. Sistema comprueba la situación del a. SI se ha realizado el pago y SI todos los items
pedido . del pedido han sido asignados, sistema
informa que procede a servir el pedido Comprobar Comprobar
activando el CU Servir pedido. Artículo
Pago
b. SI se ha realizado el pago y NO existen
suficientes items del artículo en stock, sistema
[NO vigente] Seleccionar
aparca el pedido del cliente activando el CU
jvilalta@vico.org
Aparcar pedido. Punto de decisión Artículo alternativo

c. SI no se ha realizado el pago según el plazo [SI vigente]
convenido, sistema cancela el pedido.
[NO]
© Vilalta Consultores 2001 - TRAD Actividad 1_esp - Rev. 7.1 -
Asignar
Descripción
Cancelar
1 Pedido Items
[SI] [NO Stock] o
de un Flujo de Trabajo Barra de fusión

[SI umbral reposición] Generar
reposición
Condición lógica: verdadera o falsa,

Un flujo de trabajo muestra la secuencia de actividades que permite la transición
Comprobar
que se desarrollan dentro de uno o varios Casos de situación Pedido
a otra actividad
Uso, como una pieza de funcionalidad concreta que
Entrar
Pedido
Validar
Riesgo
satisface los requerimientos de un Actor.

Seleccionar
Pedidos
Validar
[Todos los items asignados] [Faltan items por asignar] Pago

* [para cada pedido seleccionado]
Asignar
Items
Servir Aparcar Activar

Pedido
Regularizar
Stock
Pedido Pedido
Flujos de
Trabajo
CU Actualizar reposición
Flujo Principal
Descripción 2
1. Usuario recepciona albaranes de

reposición que ha enviado un proveedor.
de un Flujo de Trabajo
Recepción
de una Una diagrama de actividad describe una secuencia de
2. Sistema localiza los pedidos de clientes Análisis textual
aparcados que pueden cumplimentarse del Caso de Uso
Reposición actividades que pueden exhibir un comportamiento en
con la nueva entrada de items. paralelo o estar sujetas a condiciones lógicas.
3. Usuario selecciona los pedidos de
clientes aparcados que decide Los procesos de negocio no muestran siempre una secuencia
cumplimentar. fija en su desarrollo, es una ventaja así poder modelar
4. Sistema asigna los items pendientes a bloques de actividades sin restricciones de concurrencia.
los pedidos de cliente seleccionados.
Entrar
Reposición
5. Sistema informa que procede a servir
el pedido activando el CU Servir
pedido..
6. Sistema regulariza la situación de items

Buscar
en stock y revisa los umbrales de Pedidos aparcados
reposición automática.
Diagrama de Actividad
jvilalta@vico.org
Notación UML 1.3

Seleccionar
Pedido
* [para cada pedido

seleccionado]
Asignar Transición de una actividad a otra sujeta

Items a una condición lógica.
Sincronización de actividades que

pueden ocurrir en paralelo.
[Todos los items asignados] [Todos las reposiciones entradas]

Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
Servir Regularizar
Validar
Pago
* [para cada pedido seleccionado]
Asignar
Pedido Stock
Items
Activar Regularizar
Pedido Stock
Fin de la secuencia de
actividades Flujos de
Trabajo
Recepción
de un Descripción 3
Identificar
Pedido
de un Flujo de Trabajo
Cliente
Un diagrama de actividad puede mostrar la secuencia de
actividades que se desarrolla en un paquete de Casos de
Entrar Uso que define un proceso de negocio y sus áreas de
Diagrama de Actividad líneas pedido responsabilidad.
Notación UML 1.3
* [para cada línea de pedido]
[Recepción de Reposición] Entrar

Comprobar Reposición
Artículo
[NO vigente]
Seleccionar
Artículo alternativo
[SI vigente]
Comprobar Buscar
Pago Seleccionar
Pedido Pedidos aparcados
jvilalta@vico.org
* [para cada pedido Líneas para acotar

seleccionado] áreas de responsabilidad
Asignar (swim-lines)
Items
[NO éxito] Cancelar
Pedido
[SI éxito]
Generar Regularizar
reposición Stock
[NO Stock]
o [SI umbral reposición]
Comprobar
Contabilidad situación Pedido Comercial Almacén
Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
Validar * [para cada pedido seleccionado]

Pago
[Todos las reposiciones entradas] Asignar

Items
[Todos los items asignados] [Faltan items por asignar] Activar

Pedido
Regularizar
Stock
Servir Aparcar
Pedido Pedido Flujos de
Trabajo
Descomposición
de la actividad
Descripción 4
Comprobar de un Flujo de Trabajo
Pago
Su objetivo no es relacionar actividad con objetos, sólo
comprender qué actividades son necesarias y cuales son sus
Diagrama de Actividad relaciones de dependencia.
Notación UML 1.3
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.
Pueden procesarse distintas
modalidades de pago de Comprobar
manera simultanea Pago
[Tarjeta de Crédito]
[Factura]
jvilalta@vico.org
Comprobar [Cheque] Comprobar Importe

Autorización
Cheque Cliente habitual > 150.000
NO éxito
[NO] [SI]
[Efectivo]
[NO éxito] [NO éxito]
[SI] [NO recibido]

Pre-Pago
requerido
Comprobar [NO]
historial pagos
Comprobar
[NO éxito] Crédito
[SI éxito] [SI éxito]
NO éxito
[NO éxito]
[SI éxito]
Entrar
Pedido
Validar
Riesgo
[SI éxito] Seleccionar

Pedidos
Validar * [para cada pedido seleccionado]

Pago
Asignar
Items
Abrir
Cuenta Cliente
Activar Regularizar
Pedido
SI éxito
Stock
Flujos de
Trabajo
CU Realizar pedido
Flujo Principal Va r i a c i o n e s Descripción 1
de un Escenario
enviado un pedido.
código de artículo, tipo de presentación Un escenario muestra de que manera interactúan los distintos
y cantidad.
objetos dentro del flujo principal de eventos de un Caso de
3. Sistema comprueba cada línea del a. Artículo NO está vigente en catálogo, sistema
pedido para validar la situación del informa que articulo no está vigente y Uso con alguna variación o extensión concreta del mismo.
Análisis textual
del Use Case
Utilizamos dos diagramas de interacción:
c. NO existen suficientes items del artículo en a/. Secuencia
stock, o la asignación de items deja la b/. Colaboración
situación del artículo en stock por debajo del
nivel de reposición, sistema genera pedido Su finalidad es describir los mensajes que intercambian los
de reposición activando el CU Generar distintos objetos para cumplir con las responsabilidades
Objetos que pedido.
interactúan
definidas en un escenario concreto de un Caso de Uso.
• Diagrama de Secuencia.- Representa las

:Una Ventana de :Una Cartera interacciones de objetos ordenadas en una serie temporal
:Una Línea
introducción de :Un Pedido de Items que muestra su ciclo de vida.
de Pedido
en Stock
jvilalta@vico.org
: C o m erci al Pedidos
(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
3:entrarLíneaPedido ( ) cuando se requiere generar nuevos objetos para
© Vilalta Consultores 2001 - TRAD Secuencia_esp - Rev. 6.1 -
4:generarLíneaPedido ( ) cumplir con las responsabilidades asignadas.
5:comprobarStock ( )
6:asignarItems ( ) Auto-mensaje
Creación de
(1) Mensaje 7:realizarReposición ( ) un nuevo
objeto
Línea de vida
de un objeto
durante la interacción
:Un Pedido
8:generarReposición ( ) Una ventana de
introducción de Un pedido
Una línea
de pedido
Un item
de stock
de
pedidos
Reposición
[tieneStock]
nuevo
[tieneStock]
nuevo
tieneStock:( )
: Pedido
xxx línea : Línea de pedido

Diagrama de Secuencia
Notación UML 1.3 Escenarios

CU Realizar pedido Descripción 2
Flujo Principal
Va r i a c i o n e s
de un Escenario
enviado un pedido.
2. Usuario entra lineas de pedido, con su Con un escenario representamos el conjunto de eventos que
y cantidad.
configura el comportamiento de un Caso de Uso.
3. Sistema comprueba cada línea del a. Artículo NO está vigente en catálogo, sistema Un escenario describe una instancia del flujo de eventos de
pedido para validar la situación del informa que articulo no está vigente y
artículo en catálogo y el número de muestra artículos alternativos activando el un Caso de Uso, con sus variaciones o extensiones posibles
Análisis textual
y las excepciones probables.
del Use Case el stock, sistema asigna items al pedido.
c. NO existen suficientes items del artículo en Utilizamos dos diagramas de interacción:
stock, o la asignación de items deja la
a/. Secuencia
nivel de reposición, sistema genera pedido b/. Colaboración
pedido. 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
(Instancia de una Clase)
• Diagrama de colaboración.- Representa una
jvilalta@vico.org
: Comercial posible interacción de los objetos ordenados a partir

Número de secuencia
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 ( )
© Vilalta Consultores 2001 - TRAD Colaboración_esp - Rev. 6.1 -
4: generarLíneaPedido ( ) Estos mensajes muestran el nivel de colaboración

entre los distintos objetos existentes e indican
: Una Ventana de introducción de Pedidos : Una Línea de Pedido cuando se requiere generar nuevos objetos para
cumplir con las responsabilidades asignadas.
Enlace entre 2: generarPedido ( ) Mensaje (1) 5: comprobarStock ( )

dos objetos
6: asignarItems ( )
Auto-mensaje
: Un Pedido 7: realizarReposición ( )
:Una Cartera de Items en Stock

Dirección del mensaje 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
xxx línea : Línea de pedido

Diagrama de Colaboración : Item de Expedición : Item de Pedido de reposición
Notación UML 1.3 : Un Pedido de Reposición

Escenarios
Cliente
1
Clases Pedido
FechaRecibido
ConPrepago
Número
Importe
* 1
Nombre
Direccion
valorarCredito( ): string
Desde una perspectiva conceptual, una Clase representa un Divisa

...
conjunto de Objetos que comparten: seleccionar ( )
comprobar ( )
• Las mismas propiedades (Atributos) servir ( )
cerrar ( )
• El mismo comportamiento (Métodos) ...
• Las mismas relaciones con otros Objetos (Mensajes) 1

Cliente Cliente
• La misma semántica dentro del sistema Corporativo Personal
NombreContacto NumTargetaCredito
Desde una perspectiva física, una Clase es una pieza de software ValoracionCredito
LimiteCredito
que actua como un molde para fabricar tipos particulares de facturarMes( )
objetos que disponen de los mismos atributos y métodos. recordar( )
*
Estos elementos que configuran cada tipo de objeto sólo se
0..1
definen una vez, cuando especificamos la estructura de la Clase
*
a la que pertenecen. Representante
Línea de Pedido
jvilalta@vico.org
Los objetos que se han creado a partir de una Clase concreta, Cantidad
se llaman instancias de esta Clase y se diferencian entre ellos Importe
Cumplimentada * 1
únicamente por los valores de sus atributos (variables). Producto
aceptar ( )
Objetos
© Vilalta Consultores 2001 - TRAD Clases 1_esp - Rev. 6.1 -
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: Pedido
hacer /
comprobación
* 1
Cliente
hacer /
comprobación
• Identidad ¿Quien soy? = Atributos

item
Cliente Cliente
• Propósito ¿Cual es mi misión? = Justificación

hacer /
comprobación
item
• Responsabilidades ¿Qué debo hacer? = Métodos

*
0..1
*
Comercial
Línea de Pedido
• Procedencia ¿De qué Clase provengo? = Origen

hacer /
comprobación
* 1
Producto
• Relaciones ¿Qué mensajes entiendo? = Comportamiento Objetos Clases

Abstracción 2
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.
jvilalta@vico.org
vacp 104
m
do
ét
o
od
ét
o
m
2
Atributos
3
m
Cliente
Pedido
o
* hacer /
1 comprobación
hacer /
ét
od
comprobación
item
od
t
1
é Cliente
Corporativo
Cliente
Personal
o
hacer /
m
comprobación
item
4
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
* 1
Producto
Clases
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
¿Quien soy? intercambio de mensajes (dinámica del ciclo de vida).
Vehículo Automático Carga Palets

vacp104 ¿Qué puedo hacer?
em
m
It
ov
ar
er
rg
H
ca
ac
ia
jvilalta@vico.org
Atributos
a
el
m
ev
or
ar
f
ta
Pl
a
Pl
at
af
a r
or
aj
m
b ¿Qué conozco?
a
Variables.-
• Identificación
• Medidas de la carga
• Capacidad de carga
• Velocidad máxima
• Tipo de carga Pedido
* 1
Cliente
hacer /
comprobación
hacer /
comprobación
item
Estado.- Cliente
Corporativo
Cliente
Personal
hacer /
comprobación
item
• Localización *
Línea de Pedido
0..1
Comercial
• Orientación
hacer /
comprobación
* 1
Producto
• Velocidad
Clases
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
jvilalta@vico.org
em
m
It vacp104 moverHacia: binB7

ov
ar
er
rg Objeto Emisor
H
ca
ac
ia
Atributos
Signatura del mensaje
a
el
rm
ev
fo
ar
a
Pl
at
at
l
rP
af
ja
or
ba
m
Cliente
a
Pedido hacer /
* 1 comprobación
hacer /
comprobación
item
Cliente Cliente
hacer /
comprobación
item
Objeto Receptor *
*
0..1
Comercial
Línea de Pedido
hacer /
comprobación
* 1
Producto
Clases
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.
Interface de mensajes
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
Conjunto de operaciones cualquier objeto emisor.
externamente visibles que
define el comportamiento
de un objeto
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.
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.
jvilalta@vico.org
m
m
e
rIt
ov
No existe ninguna otra manera con la que un objeto externo

a
er
rg pueda acceder a los atributos y métodos escondidos dentro

H
ca
ac
de la interface de mensajes de otro objeto.

ia
Atributos
el
a
ev
r m
o
ar
af
Pl
t
la
at
P
af
r
ja
or
ba
m
vacp104 moverHacia: binB7

a
Cliente
Pedido hacer /
* 1 comprobación
hacer /
comprobación
item
Mensaje 1
Cliente Cliente
hacer /
comprobación
item
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
* 1
Producto
vacp104
Clases
Herencia 6
Es el mecanismo por el cual una clase de objetos puede ser La interface de mensajes definida para una Superclase
definida como un caso especial de otra clase más genérica. también es heredada por las subclases. Esto implica que
Los casos especiales de una clase se denominan Subclases. todas las Subclases de una Superclase estan preparadas
La clase más genérica, se conoce como la Superclase de para responder correctamente a los mismos mensajes que
todos sus casos especiales. Además de los métodos y atributos la Clase padre. Esta propiedad es extremadamente útil
que heredan, las Subclases definen sus propios métodos y porque nos permite tratar de la misma manera a todas las
atributos. Tambien, pueden redefinir algunos de los especializaciones de una Clase.
heredados (overriding).
Vehículo Automático de Carga

Vehículo Automático Carga Palets
SuperClase
jvilalta@vico.org
Vehículo Automático Vehículo Automático

Carga Palets Carga Bobinas
vac 104
vac 104 SubClase SubClase

vac 103
vacp 104
Interface de mensajes
em
m
r It
ov
a
Métodos
er
rg
Cliente
H
Pedido
ca
ac
* hacer /
1 comprobación
ia
hacer /
comprobación
item
Atributos 1
a Atributos
el
Cliente Cliente
m
ev
or
ar
af
hacer /
Pl
comprobación
at
item
at
l
rP
af
Instancias de ja
*
or
ba
m
0..1
a
*
Comercial
Vehículo Automático Carga Palets Línea de Pedido

hacer /
comprobación
* 1
Producto
vacp 104 Identificador del objeto Clases

Composición 7
Los objetos que contienen a otros objetos se denominan También pueden contener referencias de otros objetos. Las
Objetos Compuestos. Los atributos de un objeto pueden referencias almacenadas en los atributos de un objeto
utilizarse de dos maneras. Podemos usarlos para almacenar compuesto, permite a este objeto enviar los mensajes
valores como el número 15, o bien, el texto “Autorizado”. apropiados a todos los objetos contenidos.
Ventana Wizard Progress

Enter title here
67%
Tab Tab control
Trackbar
< Back Next > Cancel
jvilalta@vico.org
Panel de ventana Slider

Grid
Enter title here
Campo simple
Scroll
Botones de ventana
Restore Maximize Combo box Pedido
hacer /
comprobación
* 1
Cliente
hacer /
comprobación
item
Cliente Cliente
hacer /
comprobación
Help Minimize List box

item
? Close *
Línea de Pedido
hacer /
0..1
Comercial
comprobación
* 1
Producto
Clases
Polimorfismo 8
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.
SuperClase
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
Vehículo Automático carga: bobinas, palets, etc.
Vehículo Automático
Carga Bobinas Carga Palets
Hay una reducción de esfuerzo muy significativa por el
jvilalta@vico.org
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.
SubClase SubClase
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
m
Ite m
m
ov
ar Ite
cargarItem: #A234C19FZ
ov
er
rg ar
er
H
ca rg
ac
ca
ac
ia
ia
Atributos Cliente
Atributos Pedido
* 1 hacer /
comprobación
a
el
hacer /
comprobación
m a
ev
el
item
r
rm
ev
fo
ar
ta fo
ar
Pl
ta
1
la
Pl
at
rP la Mensaje
at
af
Cliente
rP
Cliente
ja
af
or
ba ja
or
m
ba
hacer /
m
a
comprobación
item
a
0..1
*
Comercial
Línea de Pedido
hacer /
comprobación
* 1
Producto
vacb 117 vacp 104

Clases
Visibilidad
Cliente
Pedido 9
* 1
- fechaRecibido
conPrepago + hacer /
- número: Alfanúm. comprobación
- importe: Núm&2d.
- divisa •Toda Clase encapsula unos elementos (atributos y operaciones) que disponen
...
+ crear () de ciertos criterios de visibilidad y manipulación para otras Clases.
+ seleccionar ( )
+ comprobar ( ) •Los elementos públicos pueden ser usados por cualquier otra Clase.
+ servir ( )
+ cerrar ( ) •Los elementos privados pueden ser usados sólo por la Clase propietaria.
1 •Cada plataforma de desarrollo (C++, Smalltalk, Java) desarrolla sus propias
Cliente Cliente
Personal
reglas con respecto a la visibilidad y manipulación de atributos y operaciones.
Corporativo
•La notación UML especifica que todo atributo y operación de una Clase ha
de disponer de un indicador de visibilidad.
+ hacer /
comprobación Visibilidad C++ Smalltalk Java
item
Un elemento siempre es visible en cualquier Todas las operaciones son Un elemento siempre es visible en
* parte del programa y puede ser llamado y públicas por defecto. cualquier parte del programa y puede
+ Publica modificado por cualquier objeto del ser llamado y modificado por cualquier
0..1 sistema. objeto del sistema.
* Un elemento sólo puede ser usado por la Un elemento sólo puede ser usado por
Comercial - Privada Clase que lo define.
Todas las variables
la Clase que lo define.
Línea de Pedido instanciadas son privadas.
jvilalta@vico.org
Un elemento puede ser usado por

Un elemento sólo puede ser usado por la
subclases y también por cualquier otra
1 Clase que lo define, o por las subclases de
* Clase en el mismo Package como la
+ hacer /
comprobación Producto # Protegida dicha Clase.
Clase propietaria. Esto implica que en
Java, el concepto de visibilidad
protegida es más público que package.
© Vilalta Consultores 2001 - TRAD Clases visibilidad_esp - Rev. 5.3 -
Un elemento sólo puede ser usado por

Package otras Clases que compartan el mismo
Package.
Pedido
Cliente
Consideremos la Clase CLIENTE que dispone <<Josep V.>>, puede acceder a Java permite marcar también las Clases
Ejemplos
* hacer /
1 comprobación
hacer /
cualquier variable instanciada dentro

comprobación
item
1
de una subclase CLIENTE PERSONAL. como públicas o packages. Los elementos
Cliente
Corporativo
Cliente
Personal Consideremos también que el objeto <<Josep de su propio objeto, si dicha variable de una Clase pública pueden ser usados por
hacer /
comprobación
item
V.>>, es una instancia de CLIENTE ha sido definida dentro de CLIENTE cualquier Clase que importe el package a
*
*
0..1
Comercial
PERSONAL. o CLIENTE PERSONAL. De esta la que pertenece la Clase.
Línea de Pedido
hacer /
comprobación
* 1
Producto <<Josep V.>> manera, el concepto de visibilidad Los elementos de una Clase package sólo
Consideremos la instancia de CLIENTE • Puede usar todo elemento público de cualquier privada en Smalltalk es parecido al pueden ser usados por otras Clases del
PERSONAL, <<Miquel M.>>, este objeto
Clases puede acceder a cualquier elemento de <<Josep
objeto del sistema. concepto de visibilidad protegida en
C++.
mismo package.
• Puede usar también todo elemento privado de
V.>>, que ha sido definido también como una la Clase CLIENTE PERSONAL. En Smalltalk no hay diferencia con
instancia de CLIENTE PERSONAL, sea • No puede usar los elementos privados definidos respecto a que un objeto sea de la
público, privado o protegido. <<Miquel M.>>, en la Clase CLIENTE. misma Clase o no. Podemos acceder
a su vez también puede acceder a cualquier • Puede usar los elementos protegidos definidos sólo a los elementos públicos de otro
elemento privado, protegido o público de para CLIENTE y CLIENTE PERSONAL. objeto.
<<Josep V.>>
En C++, podemos acceder a elementos de otros En Smalltalk, <<Miquel M.>>, no
objetos de la propia Clase, de la misma manera puede acceder a las variables
que podemos acceder a los propios elementos instanciadas privadas de <<Josep
de un objeto. V.>>, sólo a sus operaciones públicas.
CU Realizar pedido 1
Flujo Principal Va r i a c i o n e s Descripción
enviado un pedido. de la Dinámica del Sistema
y cantidad. La dinámica de un sistema está determinada por:
3. Sistema comprueba cada línea del a. Artículo NO está vigente en catálogo, sistema • Todos los posibles estados que sus objetos pueden tener.
CU Seleccionar artículo.
• Todas las posibles secuencias de eventos que pueden
items del artículo en stock.
b. SI existen suficientes items del artículo en ocurrir.
Análisis textual • Todas las transiciones posibles, de un estado a otro,
del Use Case c. NO existen suficientes items del artículo en
stock, o la asignación de items deja la como consecuencia de los eventos que afectan a los objetos.
pedido.

informa que procede a servir el pedido
activando el CU Servir pedido.
Diagrama de Estados
aparca el pedido del cliente activando el CU de un Pedido
jvilalta@vico.org
Aparcar pedido.
Notación UML 1.3
c. SI no se ha realizado el pago según el plazo
convenido, sistema cancela el pedido.
© Vilalta Consultores 2001 - TRAD Dinámica 1_esp - Rev. 5.1 -
Pedido /seleccionar primer item

* 2
fechaRecibido
conPrepago 1 [Todos los items comprobados &&
número: Alfanúm.
importe: Núm&2d. [No todos los items comprobados] Comprobando todos los items disponibles] Sirviendo
divisa hacer /
... /seleccionar siguiente item hacer /
seleccionar ( )
comprobar ( ) item entregas
servir ( )
s]
le
cerrar ( ) 3
ib
...
6
on
sp
1 Pedido Entregado
di
algunos items no estan disponibles
ite o
s
m
lo bid
ionar primer item en stock]
os eci
todos los items disponibles]
s
5
od R
rimer item Verificando Sirviendo
hacer / hacer /
[T em
item entregas
s]
le
n ib
It
po

d is
it e o
s
m
lo id
o s e c ib
4
s
od R
m
rimer item
I te
[T
Esperando Entregado
Esperando Entregado
Item Recibido
[algunos items no estan disponibles
Dinámica en stock]
Estados
y cantidad. Utilizamos el diagrama de estados para describir el
3. Sistema comprueba cada línea del a. Artículo NO está vigente en catálogo, sistema comportamiento de una Clase dentro de una serie temporal.
Análisis textual
pedido.
Diagrama de Estados
de un Pedido
Inicio
Clase Pedido Notación UML 1.3
*
fechaRecibido
conPrepago
jvilalta@vico.org
número: Alfanúm.
Atributos importe: Núm&2d. primera Transición
divisa
...
seleccionar ( )
Operaciones comprobar ( )
servir ( ) /seleccionar primer item Estado
cerrar ( ) Acción 2
...
1 Indicador [Todos los items comprobados &&
© Vilalta Consultores 2001 - TRAD Dinámica 2_esp - Rev.- 5.1 -
1 [No todos los items comprobados] Comprobando todos los items disponibles] Sirviendo
/seleccionar siguiente item hacer / hacer /
Sintaxis para etiquetar una transición comprobación inicio de Actividad
Acción item entregas
Evento [Indicador] / Acción
s]
le
3 6 Desencadena
ib
Los tres elementos son opcionales Evento
on
[Todos los items comprobados && siempre
sp
di
algunos items no estan disponibles Pedido Entregado la Transición
ite o
s
m
lo bid
en stock]
/ Acción
os eci
Transición
s
5
od R
Procesos que ocurren de manera rápida
[T em
dentro de un ciclo contínuo sin interrupción. Auto-Transición
It
4
ionar primer item
Esperando Entregado rimer item Verificando

hacer /
Sirviendo
hacer /
Item Recibido comprobación

item
inicio de
entregas
s]
le
n ib
po
d is
it e o
s
m
lo id
o s e c ib
s
od R
m
en stock] rimer item
I te
[T
Esperando Entregado
[Indicador] Transición Transición

Condición lógica con dos categorias: “verdadero” o “falso”.
Una Transición con [Indicador] sólo ocurre si este es “verdadero”. Dinámica
Sólo podemos extraer una Transición para un Estado concreto. Estados
y cantidad.
Construimos el diagrama de estados a partir de una clase
concreta para mostrar el comportamiento de un objeto
pedido para validar la situación del informa que articulo no está vigente y durante su ciclo de vida.
Análisis textual
Diagrama de Estados
pedido. de un Pedido
Notación UML 1.3 Cuando una Transición no dispone de un Evento
en su etiqueta, significa que la Transición se
Inicio realiza tan pronto como la Actividad asociada
Clase Pedido con un Estado es finalizada
*
fechaRecibido
conPrepago
número: Alfanúm.
jvilalta@vico.org
Atributos Aunque finalize la Actividad

importe: Núm&2d. primera Transición
divisa el Pedido permanecerá en
... este Estado hasta que ocurre
seleccionar ( ) el Evento que desencadena
Operaciones comprobar ( )
servir ( ) /seleccionar primer item Estado su Transición
cerrar ( )
...
Acción 2
1 Indicador [Todos los items comprobados &&
Implementación
1 Comprobando Sirviendo
[No todos los items comprobados] todos los items disponibles]
/seleccionar siguiente item hacer / hacer /
Sintaxis para etiquetar una transición comprobación inicio de Actividad
Acción item entregas
Evento [Indicador] / Acción
s]
le
3 6
Desencadena
ib
Evento
on
Los tres elementos son opcionales siempre
sp
Pedido Entregado la Transición
di
algunos items no estan disponibles
ite o
s
m
lo bid
/ Acción Transición en stock]
os eci
s
5
od R
Procesos que ocurren de manera rápida
[T em
dentro de un ciclo contínuo sin interrupción. Auto-Transición
It
4
/ Actividad
ionar primer item
Estado Esperando Entregado rimer item Verificando

Sirviendo
Procesos que ocurren dentro de un ciclo discontínuo Item Recibido hacer /

comprobación
item
hacer /
inicio de
entregas
s]
le
n ib
y pueden ser interrumpidospor algun evento.
po
d is
it e o
s
m
lo id
o s e c ib
en stock]
s
od R
m
rimer item
I te
[Indicador]
[T
Esperando Entregado
Transición Transición
Condición lógica con dos categorias: “verdadero” o “falso”. No hay Actividades para este Estado, por lo
Una Transición con [Indicador] sólo ocurre si este es “verdadero”. que el Pedido permanecerá a la espera de Dinámica
Sólo podemos extraer una Transición para un Estado concreto. un Evento.
Estados
CU Realizar pedido Descripción 4
de la Dinámica del Sistema
Flujo Principal Va r i a c i o n e s
enviado un pedido.
2. Usuario entra lineas de pedido, con su Un Evento no es un objeto. Un Evento es la “causa” que
y cantidad.
justifica la existencia de una información.
3. Sistema comprueba cada línea del a. Artículo NO está vigente en catálogo, sistema Sólo podemos conocer que un Evento ha ocurrido,
informa que articulo no está vigente y
pedido para validar la situación del
detectando sus “efectos” en nuestro modelo.
CU Seleccionar artículo.
Análisis textual
items del artículo en stock.
Sólo nos interesan aquellos Eventos que provocan un cambio
del Use Case el stock, sistema asigna items al pedido. de estado en los objetos de nuestro modelo.
stock, o la asignación de items deja la Hay que distinguir un Evento como tal, del objeto que
representa el registro de los efectos de dicho Evento.
pedido.
1 /seleccionar primer item

[No todos los items
comprobados] 2
Nombre del Superestado /seleccionar [Todos los items comprobados &&
siguiente item
Comprobando todos los items disponibles] Sirviendo
hacer / hacer /
jvilalta@vico.org
item entregas
s]
Activo
le
1 /seleccionar primer item 3 Pedido
ib
on
[Todos los items Cancelado
sp
[No todos los items
6
di
comprobados] 2 comprobados &&
ite o
s
m
lo bid
algunos items no estan Pedido
os eci
/seleccionar disponibles en stock] 5
s
Comprobando Sirviendo Entregado
od R
siguiente item todos los items disponibles]
[T em
hacer / hacer / 4
It
comprobación inicio de Item Recibido
item entregas [algunos items
3 Esperando Pedido Entregado
no estan
s]
Cancelado
le
[Todos los items disponibles en stock]

ib
on
comprobados &&
sp
Pedido
di
algunos items no estan Cancelado

ite o
s
Cancelado
m
lo bid
disponibles en stock]
os eci
s
4 5 sin Superestados
od R
[T em
Item Recibido
It
[algunos items
Esperando 6
no estan
Pedido ionar primer item
Diagrama de Estados
disponibles en stock] rimer item Verificando

Sirviendo
Entregado hacer /
comprobación
hacer /
inicio de
con Superestados
item entregas
s]
Notación UML 1.3
le
n ib
po
d is
it e o
s
m
lo id
o s e c ib
Pedido
s
od R
m
rimer item
I te
[T
Esperando Entregado
Cancelado
Cancelado Entregado
Dinámica
Estados
Flujo Principal Va r i a c i o n e s
Descripción
enviado un pedido.
de la Dinámica del Sistema
y cantidad.
Los diagramas de estados son muy útiles para describir el
comportamiento de un objeto a través de múltiples Casos
pedido para validar la situación del informa que articulo no está vigente y de Uso.
artículo... muestra...
b. SI existen suficientes items...
c. NO existen suficientes items...

informa que procede a servir el pedido
Análisis textual
activando el CU Servir pedido.
del Use Case
aparca el pedido del cliente activando el CU
Aparcar pedido.
Autorizando
[pago NO correcto]
c. SI no se ha realizado el pago según el plazo hacer /
convenido, sistema cancela el pedido. comprobación
del pago
jvilalta@vico.org
[pago SI correcto]
Esperando
Cancelado Autorizado Rechazado
Pedido Cancelado
Comprobando Sirviendo
Entregado Entregado
Pedido Entregado
Autorizando Autorizado ionar primer item
rimer item Verificando Sirviendo

hacer / hacer /
item entregas
s]
le
n ib
po
d is
it e o
s
m
lo id
o s e c ib
s
od R
m
Diagrama de Estados
rimer item
I te
[T
Esperando Entregado
Rechazado
Concurrentes
Notación UML 1.3
Dinámica
Pedido Rechazado Estados
1
Arquitectura del sistema
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 del Vista de

Modelo de Referencia Componentes
jvilalta@vico.org
Modulares
Vista de la
Funcionalidad
© Vilalta Consultores 2001 - TRAD Arquitectura 1_esp - Rev. 5.1 -
Use Cases
Vista de Vista de
Implementación Distribución Física
Ejecutables Elementos
Vista de la Arquitectura 4+1

Notación UML 1.3
Arquitectura
Vista del
Modelo de Referencia Arquitectura del sistema 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
Modelo de Referencia
• Generalización
• Packages
Cliente Pedidos Clientes

Pedido
jvilalta@vico.org
El Modelo de Referencia se construye en sucesivas * 1

fechaRecibido
iteraciones durante la fase de Formalización. conPrepago hacer /
número: Alfanúm. comprobación
importe: Núm&2d.
Las Clases y Packages del modelo reflejan las divisa
decisiones tomadas con respecto a los “mecanismos ... Artículos
seleccionar ( )
clave” del sistema. comprobar ( )
servir ( )
cerrar ( )
Una eficiente implementación de los “mecanismos ...
clave” requiere seleccionar Patrones (Patterns) que 1
se ajusten a los requerimientos esenciales del Cliente Cliente
proyecto. Corporativo Personal
La implementación de “mecanismos clave” requiere

hacer /
seleccionar también: comprobación
item
• Lenguaje de programación
*
• Motor de Base de Datos
0..1
• Interface gráfico de usuario “look and feel”
*
• Tratamiento de errores Comercial
Línea de Pedido
• Mecanismos de comunicación
• Migración y distribución de objetos 1
hacer / *
Producto
• Networking comprobación
Arquitectura
Arquitectura del sistema 3
Vista del Vista de
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
Componentes
de módulos de código fuente.
Modulares
jvilalta@vico.org
Pe d i d o
Los Packages estan organizados en una jerarquía
de capas que disponen de una interface bien definida:
Entrada
4 Interface de Usuario Pedidos
Interface Usuario
AWT
Java GUI toolkit
Mailing
Interface 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
Información
2 Pa c k a g e s r e u t i l i z a b l e s Artículos
Dominio
1 Mecanismos clave CORE
ø Pa c k a g e s d e p l a t a f o r m a (OS -Hardware)
Pedidos Clientes
Los Packages de la vista lógica del modelo estan

mapeados con los Packages físicos y los componentes
de software (subsistemas).
Artículos
Arquitectura
Vista del Vista de
Modulares
Esta vista se centra en la estructura de los componentes
“run-time”, los ejecutables del sistema.
Vista de
Esta arquitectura tiene muy en cuenta los siguientes
Implementación
Ejecutables requerimientos no funcionales:
• Rendimiento • Integridad
• Fiabilidad • Seguridad
• Escalabilidad • Sincronización
Vista de • Administración del sistema
Implementación
Ejecutables Entrada
AWT Mailing
Pedidos
Interface Usuario Java GUI toolkit Interface Usuario
jvilalta@vico.org
Los componentes run-time muestran los mappings Entrada

Mailing
de las Clases a librerías de tipo ActiveX, Applets de Pedidos
Aplicación Aplicación
Java y librerías dinámicas.
Los componentes ejecutables muestran sus interfaces Dominio

y niveles de dependencia dentro de la aplicación.
Pedidos Clientes
P e d i d o s . exe
Artículos
Artículos.dll
Oracle
Interface
Base de
Datos
Expedición.dll Interface global
Ingres
Clientes.dll Interface Arquitectura
Vista del Vista de
Modulares
Esta vista presenta el mapping de componentes de software
ejecutables con los nodos de procesamiento (hardware).
Vista de Vista de
Esta arquitectura tiene en cuenta los siguientes
Implementación
Ejecutables
Distribución Física
Elementos
requerimientos:
• Disponibilidad del sistema
• Rendimiento
• Escalabilidad
Los diagramas de distribución muestran el despliegue de
Vista de nodos (locales y remotos), en la organización de la empresa.
Distribución Física Permite al equipo de desarrollo comprender mejor la
Elementos topología de un sistema distribuido.
TCP/IP Servidor Contabilidad

jvilalta@vico.org
Un Nodo es un objeto físico run-time que representa

:Base de
un recurso informático. Este recurso, generalmente Datos
dispone de datos persistentes y capacidad de proceso.
En la mayoría de los casos un Nodo puede representar :Base de Servidor Área Comercial
una pieza de hardware, desde un periférico a un Datos :Contabilidad
servidor.
Las Conexiones entre Nodos muestran las líneas de :Comercial
comunicación con las que el sistema tendrá que Configuración
interactuar. Nodos
Los Componentes, en un diagrama de distribución, :Servidor

Aplicaciones :Usuarios
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.
TCP/IP
Las Dependencias muestran cómo los componentes
Cliente Win95
se comunican con otros componentes. La dirección
de una Dependencia concreta, indica el conocimiento :Cliente Interface
en la comunicación. Comercial
Conexión
:GUI Componente
Comercial
Arquitectura
Vista de
Vista del
Modulares
Esta vista certifica la validez de:
Vista de la
• Modelo de Referencia
Funcionalidad
Vista de
Use Cases
• Componentes modulares de software
Vista de
Implementación Distribución Física
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 >>
Hacer un
Inicio de Día • Diagramas de Casos de Uso
• Especificación de Casos de Uso
<< Inclu >>
Supervisor
• Diagramas de Interacción (Escenarios)
Importar nueva
configuración
Cajero
jvilalta@vico.org
• Diagramas de Actividad (Flujos de Trabajo)

Hacer un
Cerrar Arqueo << Ext >> Fin de Día
<< Inclu >> << Inclu >>
Imprimir Exportar
• Diagramas de Estados (Dinámica)
documento movimientos
Contabilidad
Recepción
Preparar
de un Pedido
Pedido
CU Realizar pedido
* [para cada línea de pedido]
Flujo Principal Va r i a c i o n e s [NO éxito]

Cancelar Comprobar Comprobar
1. Usuario identifica el cliente que ha Pedido Pago Items
[en stock]
enviado un pedido. [SI éxito]
Asignar
2. Usuario entra lineas de pedido, con su Items
[Requiere reposición]
y cantidad.
Reponer
Una ventana de 3. Sistema comprueba cada línea del a. Artículo NO está vigente en catálogo, sistema Items
Una línea Un item
introducción de Un pedido de pedido de stock pedido para validar la situación del informa que articulo no está vigente y Servir
pedidos Pedido
[tieneStock]
nuevo tieneStock:= comprobar ( ) c. NO existen suficientes items del artículo en
ionar primer item
[tieneStock] situación del artículo en stock por debajo del [Todos los items comprobados &&
nuevo nivel de reposición, sistema genera pedido
[tieneStock] de reposición activando el CU Generar rimer item Verificando Sirviendo
asignar ( ) hacer / hacer /
pedido. comprobación inicio de
item entregas
s]
le
ib
on
rimer item
sp
Entregado
di
ite o
s
m
lo bid
os eci
s
od R
[T em
rimer item
It
[tieneStock]
Arquitectura
Esperando Entregado
nuevo

Uml Guia Visual

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uml Guia Visual

Enviado por

Direitos autorais:

Formatos disponíveis

UML

condicionada a la implementación eficiente de sus procesos esenciales. Conocer estos

La tecnología orientada a objetos persigue el antiguo principio del divide y vencerás. Su

funcional de los métodos estructurados. Sin embargo, la gran diferencia reside en

Mucha gente cree que la principal utilidad de la orientación a objetos es la reutilización

Ante este cuadro de incertidumbre, el mayor desafio de una metodología de desarrollo

La dinámica de cambio no se desarrolla en la ingeniería del software con la misma

¿A quién va dirigida esta guía visual?

La claridad conceptual y los recursos didácticos utilizados en la exposición de los

¿Cómo sacar un mayor provecho a su lectura?

los niveles de concepción y formalización de un proyecto con la metodología TRAD

configuran la unidad mínima de documentación sostenible para un proyecto concreto.

¿De dónde provienen las ideas expuestas?

1997 y su última edición ampliada en 2000, se ha convertido en el libro de cabecera de

o Tarjeta Sanitaria para certificar transacciones asistenciales

Entorno de ingeniería del software

Entorno administrativo y de gestión

o Integración de sistemas de información de contabilidad administrativa y

como lingua franca.

Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5

nuevo tieneStock:= comprobar ( ) 1 comprobación

[tieneStock] item Cliente Cliente

Matrícula Glosario Funcionalidad Escenarios Clases

Casos de Uso de objetos Diseño

Procesos Especificación Flujos Dinámica

Concepción Formalización Construcción Transición

Iteraciones Iter Iter Iter

Iteraciones Iter Iter Iter

del proyecto principales

Iteraciones Iter Iter Iter

Funcionalidad Escenarios Clases

Especificación Flujos de Dinámica

Iteraciones Iter Iter Iter

*Acta Cliente Cliente

Base de Datos Arquitectura

Iteraciones Iter Iter Iter

Use Case Una ventana de Una línea Un item Cliente

Matrícula Procesos Funcionalidad Escenarios Clases Interface Clases

del proyecto principales Diagramas de Interacción Análisis Gráfico de Usuario Diseño

Misión Modelo Componentes

- Role de us ua rio - <<Generaliza>> <<Generaliza>>

4. ¿ Quien proveerá, usará y/o retirará, información ?

<< Uses >>

7. ¿ Un usuario actuará con diferentes roles ?

Piezas de funcionalidad del sistema

una funcionalidad compartida

A la búsqueda de Casos de Uso.-

4. ¿ Es necesario que un Actor informe al sistema sobre cambios externos ?

<< Communicates >>

<< Uses >>

Funcionalidad 6. ¿ Qué Casos de Uso darán soporte y mantendrán el sistema ?

<< Communicates >>

<< Uses >>

<< Incluye >> Casos de Uso secundarios

Caso de Uso genérico Caso de Uso especializado

4. Actor introduce totales reales para cada

2. Comprensión detallada de la funcionalidad

revisiones de los programas.

9. Documentación orientada al usuario: Helps

Actor en diferentes procesos de negocio 10. Documentación orientada al administrador

Requerimientos y Casos de Uso

No definen todos los requerimientos (por ej. los tipos de

qu erimiento datos, interfaces externas, niveles de rendimiento esperado,

Funcionalidad, Mapa conceptual: