UML - Guia Visual

Gua Visual
Cmo crear formas de vida organizativa
UML
Vi l a l t a C o n s u l t o r e s 2 0 0 1
info@vico.org
R e v. 0 . 1 7
Josep Vilalta
Proyecto: Documento: Historial: Situacin: Proceso: Autor:
Presentacin del borrador: UML Gua Visual UML Gua Visual 03/09/01 9:03 Borrador en curso de revisin Evaluacin de contenidos ref.- contacto: jvilalta@vico.org Josep Vilalta
UML
Gua Visual
Cmo crear formas de vida organizativa
Presentacin
Esta gua describe como definir, organizar y visualizar lo que denominamos formas de vida organizativa (VIO) con la notacin Unified Modelling Language (UML). Una VIO representa un ciclo de actividad realizado por uno o varios agentes con un propsito concreto, en base a una prctica consensuada para utilizar los recursos disponibles y para tomar las decisiones que caracterizan el comportamiento de una organizacin. A diferencia de los sistemas biolgicos, las VIO nacen y se desarrollan a partir de una voluntad compartida, de una idea y de un liderazgo. Pero de la misma manera que la seleccin natural acta en los sistemas biolgicos, la continuidad de una VIO est condicionada a la implementacin eficiente de sus procesos esenciales. Conocer estos procesos, saber como aplicar los recursos y como tomar las decisiones para satisacer la cadena de valor de todos los agentes son los factores que toda organizacin ha de tener en cuenta para evolucionar y asegurar su viabilidad.
La notacin UML (no hay que confundir con las metodologas que utilizan dicha notacin), se ha convertido desde finales de los 90 en un estndar para modelar con tecnologa orientada a objetos todos aquellos elementos que configuran la arquitectura de un sistema de informacin y, por extensin, de los procesos de negocio de una organizacin. De la misma manera que los planos de un arquitecto disponen el esquema director a partir del cual levantamos un edificio, los diagramas UML suministran un modelo de referencia para formalizar los procesos, reglas de negocio, objetos y componentes de una organizacin. La interaccin de todos estos elementos es una representacin de nuestra realidad.
vi co .o rg
Fecha actualizacin:
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org
Revisin:
Pgina:
04/09/01 11:16
18
1 de 9
Nuestros lmites para entender esta realidad estn en nuestro lenguaje. El mundo es la suma total de lo que podemos definir, organizar y visualizar. Cabe preguntarse de qu manera un modelo en UML representa nuestra experiencia?. Ensear a utilizar un lenguaje formal siempre es problemtico. Es necesario mostrar como este lenguaje puede ser aplicado a la realidad tal como la conocemos y tal como la compartimos con los dems. Con esta gua visual mostramos de manera precisa las tcnicas bsicas para usar UML en diferentes contextos. La clave est en discriminar cuales son aquellos procedimientos esenciales que nos permiten evitar costosas confusiones conceptuales. No es mediante el descubrimiento de nuevos objetos y de sus mltiples conexiones que avanzamos en las respuestas a nuestros interrogantes cuando modelamos un dominio, (conceptos) ya conocidos y, en ltimo caso, mediante la reduccin de su nmero despejando aquellos conceptos que no aaden valor a la comprensin de dicho dominio. Reconsiderar lo obvio, desenmascarar presunciones, desambigar conceptos conocidos, todo en busca de la simplicidad y la usabilidad. sino mediante la disolucin de las contradicciones que existen entre los trminos
La tecnologa orientada a objetos persigue el antiguo principio del divide y vencers. Su objetivo es descomponer la complejidad en partes ms manejables y comprensibles. No parece que esto sea algo novedoso con respecto a la tradicional descomposicin funcional de los mtodos estructurados. Sin embargo, la gran diferencia reside en aplicar la dualidad estructura-funcin en pequeas unidades capaces de comunicarse y reaccionar en base a la aparicin de una serie de eventos. El esquema dominante de la separacin de estructuras de datos y funciones (bases de datos y programas) est amenazado pero an se resiste a desaparecer.
vi co .o rg
Fecha actualizacin:
Revisin:
Pgina:
04/09/01 11:16
18
2 de 9
Mucha gente cree que la principal utilidad de la orientacin a objetos es la reutilizacin del cdigo para conseguir un desarrollo ms rpido de las aplicaciones (Rapid Application Development). No comparto esta opinion. Si hay algo que caracteriza un entorno de desarrollo actual es la constante del cambio. Todo proyecto que sobrepase los tres meses est amenazado por la aparicin de nuevas plataformas ms exigentes, la extincin de herramientas sin previo aviso y, de manera sistemtica, por la rotacin del personal crtico encargado del proyecto. Tambin est sometido, como no, a los cambios de requerimientos del cliente que a su vez estn plenamente justificados por la readaptacin de sus procesos de negocio a un mercado inestable. Ante este cuadro de incertidumbre, el mayor desafio de una metodologa de desarrollo es su adaptacin para el cambio. Esto significa crear modelos que faciliten la comunicacin entre todos los agentes involucrados en el sistema en construccin; que hagan visible la trazabilidad entre la concepcin de los componentes, su especificacin, implementacin e instalacin; significa el diseo de arquitecturas que faciliten la gestin de las dependencias entre estos componentes, que sean en fin, facilmente reemplazables por otros ms optimizados o bien por componentes que aporten una mayor funcionalidad y/o facilidad de uso.
La dinmica de cambio no se desarrolla en la ingeniera del software con la misma velocidad vertiginosa con que nos tiene acostumbrados la tecnologa del hardware. La clave reside en que a diferencia de la electrnica, en los dominios del desarrollo de software no existe un vocabulario unificado. Desde la fase de concepcin de un sistema a la instalacin de sus componentes hay que mapear entre s una gran diversidad de lenguajes orientados al anlisis, diseo, cdigo ejecutable, esquemas de bases de datos, componentes de pginas web, entre otros. Esta distancia entre la concepcin y la usabilidad de un producto o de un proceso de negocio, exige cada vez ms la capacidad de cooperacin y comunicacin de un equipo interdisciplinar muy especializado. Esta gua visual de UML est pensada para facilitar este proceso cooperativo y para ayudar a establecer una buena prctica fundamentada en un lenguaje comn.
vi co .o rg
Fecha actualizacin:
Revisin:
Pgina:
04/09/01 11:16
18
3 de 9
A quin va dirigida esta gua visual?

Esta gua ha sido escrita y diseada para los profesionales involucrados en todos los ciclos de actividad del desarrollo de sistemas de informacin (concepcin, anlisis y diseo, implementacin, instalacin de aplicaciones, gestin y certificacin de proyectos); tambin para los que tengan responsabilidades en la especificacin de procesos de negocio con el propsito de evaluar posibles reingenieras de procesos y/o diseo de bases de conocimiento; y finalmente, para aquellos equipos que estn inmersos en la preparacin e implementacin de certificaciones de calidad. La claridad conceptual y los recursos didcticos utilizados en la exposicin de los distintos procedimientos sern de utilidad para los estudiantes que sigan programas de autoaprendizaje y usen esta gua como complemento para sus lecturas de libros sobre UML. Tambin los centros acadmicos y profesores dispondrn con esta gua de material interesante para completar sus diseos curriculares y proporcionar ejemplos prcticos a sus alumnos.
Cmo sacar un mayor provecho a su lectura?
La gua est organizada en unidades didcticas que describen la notacin de los diagramas y las fuentes de informacin necesarias para definir los elementos de cada modelo. Puede usarse como consulta puntual de la notacin de un diagrama, o bien, para revisar como establecer el hilo conductor entre los Casos de Uso (mapa funcional), las Clases de dominio (mapa conceptual), las Clases de Especifiacin (types e interfaces) y las Clases de Implementacin (cdigo).
vi co .o rg
Fecha actualizacin:
Revisin:
Pgina:
04/09/01 11:16
18
4 de 9
Un plan de estudio para realizar una progresiva asimilacin de los conceptos podra empezar con los Casos de Uso (CU) y continuar con el anlisis de los flujos de trabajo de un grupo de CU mediante los diagramas de Actividad; a continuacin, separar los escenarios que agrupan una serie de actividades y hacer aflorar, a travs de los diagramas de Interaccin, los objetos que intercambian una serie de mensajes. A partir de este punto, disponemos del bagaje suficiente como para introducirnos en la abstraccin de los objetos y comprender la importancia de separar las tres perspectivas bsicas en nuestra representacin de las clases: concepcin, especificacin e implementacin. El siguiente paso es identificar alguna clase con un comportamiento complejo que la haga candidata a revisar todos sus posibles estados y averiguar que Transicin ser el adecuado para representar esta dinmica de estados. Finalmente, abordaremos la configuracin de componentes y su despliegue en una arquitectura. Otra lectura de la gua puede estar mas centrada en el seguimiento de la metodologa de desarrollo y la gestin de un proyecto. En este caso, las primeras secciones describen los niveles de concepcin y formalizacin de un proyecto con la metodologa TRAD (Taller de Requerimientos, Anlisis y Diseo basado en el Proceso Unificado de Rational), y se van introduciendo progresivamente los diagramas y actividades que configuran la unidad mnima de documentacin sostenible para un proyecto concreto. El estudiante ms avanzado podr sacar tambin provecho con la consulta puntual de los diagramas en que est ms interesado y la revisin de sus extensiones. Las materias expuestas en las distintas secciones estn actualizadas constantemente y pueden descargarse nuevas ediciones desde: http://www.vico.org/UMLguiavisual/ eventos son capaces de provocar un cambio de estado. El diagrama de Estados-
vi co .o rg
Fecha actualizacin:
Revisin:
Pgina:
04/09/01 11:16
18
5 de 9
De dnde provienen las ideas expuestas?

El contenido de esta gua ha sido elaborado a partir del trabajo de una serie de profesionales que el autor ha tenido la oportunidad de estudiar y aplicar en distintos proyectos. Desde principios de los 90, los artculos publicados en el Journal of Object Oriented Programming (JOOP) por James Odell, James Rumbaugh, Grady Booch, Desmond dSouza, Bertrand Meyer, Steve Cook, John Daniels, Sally Shlaer y Stephen J. Mellor entre otros, han sido una constante fuente de conocimiento. Publicaciones pioneras como el Object Oriented Technology, A Managers Guide de David A. Taylor, en su primera edicin de 1990 y en la segunda ampliada de 1998, han tenido una gran influencia en como abordar la presentacin didctica. Tambin los Models y Java Modeling Color with UML, han sido de una ayuda extraordinaria. La obra enciclopdica The Unified Modeling Language: Reference Manual de Rumbaugh & Jacobson & Booch, es un punto de referencia constante. Sin duda, uno de los autores ms influyentes ha sido Martin Fowler. Su primer libro Analysis Patterns continua siendo una referencia clave. Posteriormente, la primera edicin de UML Distilled en 1997 y su ltima edicin ampliada en 2000, se ha convertido en el libro de cabecera de UML. Otro clsico por la excelencia de su trabajo es Applying UML and Patterns de Craig Larman que en su segunda edicin aparecida en verano de 2001 se ha superado a si mismo. Tambin recientes y con muy buen material que ha sido incorporado a la gua, tenemos los libros de Wendy & Michael Boggs, Mastering UML with Rational Rose, de Alistair Cockburn, Writing Effective Use Cases; de Scott W. Ambler, The Object Primer segunda edicin; y de John Chessman & John Daniels, UML Components, una de las novedades ms interesantes de 2001. En la bibliografa sobre UML publicada en http://www.vico.org hay una relacin completa de los libros consultados que se actualiza peridicamente con las ltimas novedades. libros de Peter Coad et al, Object Oriented Analysis, Design and Programming, Object
vi co .o rg
Fecha actualizacin:
Revisin:
Pgina:
04/09/01 11:16
18
6 de 9
Competencia y actuacin
En los ltimos veinte aos de mi carrera profesional en el desarrollo de sistemas de informacin he participado en una gran diversidad de proyectos con distintos grados de responsabilidad e involucracin, pero siempre con un compromiso firme en la calidad y usabilidad del producto final. Entorno industrial o CIM para la extrusin de polietileno y fabricacin de mallas agrcolas y de embalaje. o CIM para el fraccionamiento de hemoderivados o Plan Funcional para la implementacin SAP-Logstica
vi co .o rg
Entorno sanitario o Gestin de Bancos de Sangre y Hemoterapia o Gestin mutual de prestaciones asistenciales resultados o Gestin de laboratorios farmacuticos o Gestin integrada de servicios de Atencin Primaria Asistencial
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org Fecha actualizacin:
o Planificacin y gestin de campaas de captacin de donantes o Tarjeta Sanitaria para certificar transacciones asistenciales o Automatizacin de autoanalizadores de laboratorios de anlisis o Integracin de peticiones analticas multicentricas y publicacin de
o Historia Clnica Orientada por Problemas Automatizada o Libreta de Salud para programacin de citas y exploraciones o Plan Funcional para la implementacin SAP-Gestin Clnica y
Revisin:
Pgina:
04/09/01 11:16
18
7 de 9
Entorno de ingeniera del software o Framework de clases de anlisis para definir mapas conceptuales o Framework de servicios comunes para la publicacin dinmica de pginas HTML o Framework de certificacin de entregables Entorno administrativo y de gestin o Plan Funcional para la implementacin SAP-Contabilidad o Cuadro de control de indicadores de actividad y calidad o Sistema de informacin Ejecutivo
vi co .o rg
Entorno comercial o Merchandising de productos farmacuticos o Subastas y liquidacin de lotes Entorno de servicios o Auditoras Informticas o Plan de Sistemas de Informacin general Entorno acadmico o Gestin de ttulos universitarios acadmica
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org Fecha actualizacin:
o Gestin de redes de puntos de venta con videoconferencia
o Integracin de sistemas de informacin de contabilidad administrativa y
o Programa de acceso a la universidad para mayores de 25 aos o Estudios de tercer cliclo: diseo curricular, publicacin y gestin
Revisin:
Pgina:
04/09/01 11:16
18
8 de 9
Entorno docente o Tutoras de proyectos de fin de carrera con UML o Cursos de Anlisis, Diseo y Patrones o Talleres de introduccin a UML o Talleres avanzados de UML con Rose y Visio o Talleres monogrficos (Casos de Uso, Mtrica, Metodologa) Entorno de I+D o Bases de conocimiento con vocabularios controlados o Procesador de lenguaje natural dentro del dominio mdico o Reconocimiento automtico de conceptos clnicos a partir de textos no estructurados
Agradecimientos
En primer lugar a los clientes que con su confianza han permitido que pueda desarrollar mi carrera profesional. Tambin a los autores antes mencionados por su valioso trabajo en el avance de la disciplina de la ingeniera del software y en la consolidacin de UML como lingua franca.
Josep Vilalta Badalona, Barcelona (Espaa) jvilalta@vico.org http://www.vico.org
vi co .o rg
Fecha actualizacin:
Revisin:
Pgina:
04/09/01 11:16
18
9 de 9
Niveles de concepcin y formalizacin de un proyecto

Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5
Nivel
Use Case Use Case

Una ventana de introduccin de pedidos Un pedido Una lnea de pedido Un item de stock
Cliente Pedido
hacer / comprobacin item
hacer / comprobacin
M
jvilalta@vico.org
G
Actor << Communicates >> << Communicates >> Actor
<< Extends >> << Extends >>
Una ventana de introduccin de pedidos

[tieneStock] nuevo
Un pedido
Una lnea de pedido
Un item de stock
Cliente Pedido
hacer / comprobacin
tieneStock:= comprobar ( ) [tieneStock] nuevo [tieneStock] nuevo [tieneStock] nuevo tieneStock:( )
Cliente Corporativo
Cliente Personal Cliente Personal
: Pedido
Cliente Corporativo
* 0..1
xxx lnea : Lnea de pedido Pedido :
xxx stock : item de stock
<< Uses >> << Uses >>

xxx lnea : Lnea de pedido : Item de Expedicin : Item de Pedido de reposicin xxx stock : item de stock
* Lnea de Pedido
hacer / comprobacin
Comercial
* 0..1
* 1 * Lnea de Pedido
hacer / comprobacin
Producto
Comercial
: Item de Expedicin
: Item de Pedido de reposicin
Producto
Vilalta Consultores 2001 - TRAD UMD_esp - Rev. 5.2 -
Matrcula del Proyecto
Glosario de Conceptos
Funcionalidad
Diagramas de Casos de Uso
Escenarios
Interaccin de objetos
Clases
Anlisis Diseo Implementacin
Code like hell
PDI P
Procesos Principales
Especificacin Casos de Uso
Flujos de Trabajo
Entrar
Reposicin
Dinmica Eventos - Estados

ionar primer item [Todos los items comprobados && todos los items disponibles] [Todos los items comprobados && Sirviendo todos los items disponibles] hacer /
inicio de entregasSirviendo hacer / inicio de entregas
P
Cronograma Plan Director Iteraciones
CU CU
Entrar
Reposicin
Entrar
Pedido
Seleccionar Pedidos Pendientes
Validar
Riesgo
Entrar
Reposicin
*Seleccionarpedido seleccionado] [para cada Pedidos Pago
ionar primer item rimer item Verificando

hacer / comprobacin item rimer item
Validar
I te m od R o s e c ib lo id s it e o m s
Esperando
rimer item
Activar Pedido Activar Pedido
Regularizar StockRegularizar
Esperando
[T
rimer item
[T
Entregado Entregado
Stock
d is
rimer item
po
n ib
le
Asignar Items
d is
rimer item
po
n ib
le
Asignar Items
* [para cada pedido seleccionado]
Verificando
s]
Entregado
Entregado
C d i g o
s]
Tiempo
Fases Iteraciones
E s f u e r z o d e d e s a r ro l l o
Formalizacin Construccin Transicin
PDP
Procesos
Actividades Entregables
Producto
Concepcin
Misin
jvilalta@vico.org
Modelo Prototipo Componentes Certificacin

Iteraciones preliminares
Vilalta Consultores 2000 - TRAD PDP iteraciones_esp - Rev. 4.2 -
Iter #1
Iter #2
Iter #n
Iter #n+1
Iter #n+2
Iter #n
Iter #n+1
Iteraciones
P l a n D i re c t o r d e P ro y e c t o
Concepcin
PDP
Concepcin
Formalizacin
Construccin
Transicin
Misin Modelo Prototipo Componentes Certificacin

Iter #1
Iter #2
Iter #n
Iter #n+1
Iter #n+2
Iter #n
Iter #n+1
Iteraciones
jvilalta@vico.org
Pedido
Vilalta Consultores 2001 - TRAD PDP misin_esp2 - Rev. 5.2 -
P
* 1 Pedido * 1
Matrcula del proyecto

Cliente Cliente 1
hacer / comprobacin
Procesos principales
hacer / comprobacin
Cliente Corporativo Cliente Corporativo
0..1 * Lnea de Pedido

hacer / comprobacin
Comercial
* 0..1
hacer / comprobacin
Producto
Comercial
Misin
G
Actor 1
<< Communicates >>
P
<<Incluye>> <<Generalizacin>>
Use Case Use Case Use Case << Extends >> <<Extiende >>
Use Case
Use Case << Uses >> <<Incluye>>
Actor 2
Use Case
Producto
Patrones de Anlisis
PDI P
Patrones de Funcionalidad
Anteproyecto
PDP
Concepcin
Formalizacin
Construccin
Transicin

Iter #1
Iter #2
Iter #n
Iter #n+1
Iter #n+2
Iter #n
Iter #n+1
Iteraciones
Fo r m a l i z a c i n
Use Case Use Case << Extends >> << Extends >>
Cliente Pedido * 1
hacer / comprobacin

[tieneStock] nuevo
Un pedido
Una lnea de pedido
Un item de stock
Cliente Pedido
hacer / comprobacin
tieneStock:= comprobar ( )
1
[tieneStock] nuevo [tieneStock] nuevo [tieneStock] nuevo tieneStock:( )
Cliente Corporativo
: Pedido
Actor << Communicates >> << Communicates >>

xxx lnea : Lnea de pedido Pedido :
Cliente Corporativo
*
0..1 * Lnea de Pedido Comercial * 0..1 * 1 * Lnea de Pedido

hacer / comprobacin
<< Uses >> << Uses >>

jvilalta@vico.org
hacer / comprobacin
Producto
Comercial
Actor
: Item de Expedicin
Producto
Funcionalidad
Escenarios
Clases
Anlisis y Diseo
Pedido
Vilalta Consultores 2001 - TRAD PDP modelo_esp2 - Rev. 5.3 -
Actor 1
<< Communicates >>
P
<<Incluye>> <<Generalizacin>>
Use Case Use Case Use Case << Extends >> <<Extiende >>
Use Case
Use Case << Uses >> <<Incluye>>
Actor 2
Use Case
Modelo
Entrar
Reposicin
P
* 1 Pedido * 1
Cliente
hacer / comprobacin
Cliente 1
hacer / comprobacin
Cliente Corporativo Cliente Corporativo

hacer / comprobacin
Comercial
* 0..1
hacer / comprobacin
Producto
Comercial
Producto
Patrones de Funcionalidad
Entrar
Patrones de Anlisis
Pedido
Entrar
CU
Reposicin
ionar primer item
Validar
Riesgo
[Todos los items comprobados && todos los items disponibles] [Todos los items comprobados && Sirviendo todos los items disponibles] hacer /
Entrar
Reposicin
*Seleccionarpedido seleccionado] [para cada

Pedidos

hacer / comprobacin item rimer item Verificando hacer / comprobacin item
Validar
Pago
Esperando
rimer item
Esperando
[T
rimer item
[T
Entregado Entregado
Stock
Flujos de Trabajo
Dinmica Eventos Estados
d is
rimer item
po
n ib
le
Asignar Items
d is
rimer item
po
n ib
le
Asignar Items
s]
s]
Entregado
Entregado
Construccin
Cliente Pedido
PDP
Concepcin
Formalizacin
Construccin
Transicin

Iter #1
Iter #2
Iter #n
Iter #n+1
Iter #n+2
Iter #n
Iter #n+1
Iteraciones
hacer / comprobacin
Cliente Pedido
hacer / comprobacin
*Acta
Destino
*Acta
Versin Fecha
Versin
Fecha
Ao Acadmico Alumnos
Ao Acadmico Alumnos
** Tribunal
Destino
** Tribunal
Cliente Corporativo
Cliente Corporativo
*
Seleccin Seleccin
Alumno
P. Global
P. Esp.
Resultado
Ver
jvilalta@vico.org
Alumno
P. Global
P. Esp.
Resultado
Ver
0..1 * Lnea de Pedido Comercial * 0..1 * 1 * Lnea de Pedido

hacer / comprobacin
Cliente Pedido
hacer / comprobacin
Producto
Comercial
hacer / comprobacin
Producto
1 Cliente Corporativo
Cliente Personal
* 0..1 * Lnea de Pedido

hacer / comprobacin
Comercial
Interface Grfico de Usuario
Clases
Diseo Implementacin
Pedido
Producto
Vilalta Consultores 2001 - TRAD PDP construccin_esp2 - Rev. 5.3 -
Cliente * 1
hacer / comprobacin
Cliente Pedido
hacer / comprobacin
Cliente Corporativo
Componentes
Framework de Aplicaciones

hacer / comprobacin
Comercial
hacer / comprobacin
Producto
P
Cliente Personal Cliente Corporativo
Cliente Personal
0..1
Comercial
Producto
Patrones de Diseo
Base de Datos
Esquema de Persistencia
Arquitectura
Componentes
PDP
Concepcin
Formalizacin
Construccin
Transicin

Iter #1
Iter #2
Iter #n
Iter #n+1
Iter #n+2
Iter #n
Iter #n+1
Iteraciones
Concepcin
Use Case
Fo r m a l i z a c i n
Use Case << Extends >> << Extends >>
Construccin
Cliente Pedido * 1
hacer / comprobacin
Cliente Pedido
P
Actor Actor
hacer / comprobacin

[tieneStock] nuevo
Un pedido
Una lnea de pedido
Un item de stock
Cliente Pedido
Cliente Pedido
hacer / comprobacin
hacer / comprobacin
tieneStock:= comprobar ( ) [tieneStock] nuevo [tieneStock] nuevo [tieneStock] nuevo tieneStock:( )
Cliente Corporativo
*Acta
Destino
Versin
Fecha
Ao Acadmico Alumnos
** Tribunal
Cliente Corporativo
: Pedido
Cliente Corporativo
Cliente Corporativo
<< Communicates >> << Communicates >>

xxx lnea : Lnea de pedido Pedido : xxx stock : item de stock
*
Seleccin
Alumno
P. Global
P. Esp.
Resultado
Ver
0..1 * Comercial * 0..1 * 1 * Lnea de Pedido

hacer / comprobacin
<< Uses >> << Uses >>

Comercial
* 0..1
Lnea de Pedido
hacer / comprobacin
hacer / comprobacin
hacer / comprobacin
Producto
Comercial
Producto
Comercial
: Item de Expedicin
Producto
Producto
jvilalta@vico.org
Matrcula del proyecto
Procesos principales
Funcionalidad
Escenarios
Clases
Anlisis y Diseo
Interface Grfico de Usuario
Clases
Diseo Implementacin
Vilalta Consultores 2001 - TRAD PDP_esp2 - Rev. 6.2 -
Misin
G
Modelo
Entrar
Reposicin
Componentes
ionar primer item [Todos los items comprobados && todos los items disponibles] [Todos los items comprobados && Sirviendo todos los items disponibles] hacer /
PDI P
Entrar
Entrar
Pedido
CU
Reposicin
Validar
Riesgo
Entrar
Reposicin
*Seleccionarpedido seleccionado] [para cada Pedidos Pago

hacer / comprobacin item rimer item
Validar
Esperando
rimer item
Esperando
[T
rimer item
[T
Entregado Entregado
Stock
Flujos de Trabajo
Anteproyecto
Dinmica Eventos Estados
d is
rimer item
po
n ib
le
Asignar Items
d is
rimer item
po
n ib
le
Asignar Items
Verificando
s]
s]
Entregado
Entregado
Base de Datos
Esquema de Persistencia
Arquitectura
Componentes
Cmo identificar Actores ?

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

- Ro le d e su b sistema Interaccin del Sistema con un Actor
C lien te
- Role de us ua rio -
Relacin que indica la especializacin a partir de una funcin genrica
R e a l i z a r una t ra nsa c c i n <<Generaliza>> <<Generaliza>>
<<Generaliza>>
jvilalta@vico.org
Retirar Efectivo Consultar Movimientos

S is te ma e n proc e s o de mode la do Representan a un agente que interacta con el sistema No son parte del sistema que se desarrolla Entran informacin al sistema Reciben informacin del sistema Entran y reciben informacin
Activar Ta r j e t a
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 -
Vilalta Consultores 2001 - TRAD Actores_esp - Rev. 5.1 -
Actores
A la bsqueda de Actores.1. 2. 3. 4. Quien est interesado en un requerimiento concreto ? En qu dominios de la organizacin se usar el sistema ? Quien ser beneficiario de la nueva funcionalidad ? Quien proveer, usar y/o retirar, informacin ? Quien dar soporte y administrar el sistema ? Usar el sistema un recurso externo ? Un usuario actuar con diferentes roles ? Diferentes usuarios actuarn con un mismo rol ? Interaccionar el nuevo sistema con un sistema antiguo ?
Use Case
<< Extends >>
Actor << Communicates >> << Uses >> Actor
5. 6. 7.
Funcionalidad
8. 9.
Cmo identificar Casos de Uso ?

Abr ir Arque o
Interaccin de un Actor con el Sistema
<< Extiende >>

Relacin que describe una variacin posible del comportamiento normal de un Use Case
Hacer un Ini ci o de D a
<< Incluye >>

Piezas de funcionalidad del sistema que suministran valor a un Actor y son reutilizables en diferentes procesos
Importar nueva configuracin
S u p erv iso r
- Ro l d e u su ario -
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
Relacin que permite descomponer un Use Case con un determinado nivel de granularidad
<< Incluye >>

jvilalta@vico.org
<< Incluye >>
Relacin que indica el uso de una funcionalidad compartida por otros Casos de Uso
Im pri m i r doc um e nt o
E xport ar m ovi m i ent os
S is te ma e n proc e s o de mode la do
Co n tab ilid ad
- S istema ex tern o Interaccin del Sistema con un Actor
Vilalta Consultores 2001 - TRAD UCs_esp - Rev. 5.1 -
A la bsqueda de Casos de Uso.1.

Use Case
Cuales son las tareas y responsabilidades de cada actor ? Algn actor crear, almacenar, cambiar, borrar o leer informacin del sistema ? Qu Casos de Uso crearn, almacenarn, cambiarn, borrarn o leern esta informacin ? Es necesario que un Actor informe al sistema sobre cambios externos ? Es necesario que un Actor sea informado sobre ciertas incidencias del sistema ? Qu Casos de Uso darn soporte y mantendrn el sistema ? Pueden ser realizados por los Casos de Uso todos los requerimientos funcionales documentados ?
2.
<< Extends >>
3. 4.
5. 6. 7.
Funcionalidad
Use Case
3
<< Extends >> << Uses >>
Actor << Communicates >>
Actor
Funcionalidad
Especificacin de un Caso de Uso
Caso de Uso principal
C e r r ar A rque o
<< Extiende >>
Ha c e r un Fin de Da
<< Incluye >>
Casos de Uso secundarios
jvilalta@vico.org
Imprimir doc ume nto

Caso de Uso genrico
<<Generaliza>>
Imprimir tira de a rque o

Caso de Uso especializado
L I M I T
Lmites: Cuando empieza y cmo termina el Caso de Uso. Interacciones: Comportamiento de Actores y Sistema. Accin-Reaccin dentro del Caso de Uso. Masa: Conjunto de Objetos e Interfaces que requiere el Caso de Uso. ndice de escenarios: Flujo principal de eventos y secuencia de variaciones posibles dentro de un Caso de Uso. Tribulaciones: Contingencias probables que pueden afectar al flujo de los eventos y son excepciones del Caso de Uso.
Vilalta Consultores 2001 - TRAD LIMIT UCs_esp - Rev. 5.1 -
Propsito
- Regla de Negocio -
Precondiciones
Arqueo abierto Actor habilitado TPV abierto TPV habilitado
Activacin
A discrecin de un Actor habilitado
Flujo Principal
1. Sistema requiere confirmacin de cierre de arqueo. 2. Sistema comprueba la configuracin de TPV para identificar tipo de cierre.
Variaciones
a. Si Actor decide aparcar el cierre de arqueo, sistema activa UC Aparca_arqueo y termina el UC. a. Cierre de arqueo de tipo abierto: Actor decide el momento de imprimir el documento Tira de Arqueo. b. Cierre de arqueo de tipo ciego: Sistema no muestra los totales tericos para cada forma de cobro.
Excepciones
Cerrar un periodo de movimientos de caja para obtener una situacin real de dinero en efectivo y en documentos.
3. Sistema calcula los totales tericos para cada forma de cobro. 4. Actor introduce totales reales para cada forma de cobro. 5. Sistema registra el cierre: importes reales para cada forma de cobro y descuadres. 6. Sistema imprime el documento Tira de Arqueo.
a. Si el servidor est off-line, sistema informa al usuario, termina el UC manteniendo el arqueo abierto. a. Si impresora est off-line, sistema informa al usuario y le pide confirmacin para continuar.
Ventajas del modelo Use Case

A brir A rque o << Extiende >> H ac e r un Ini c i o de D a
1. Lenguaje de comunicacin entre usuarios y desarrolladores. 2. Comprensin detallada de la funcionalidad del sistema. 3. Acotacin precisa de las habilitaciones de los usuarios. 4. Gestin de riesgo ms eficiente para gobernar la complejidad. 5. Estimacin ms exacta para determinar tiempo, recursos y prioridades en la dosificacin de esfuerzo de desarrollo. 6. Fiel trazabilidad para verificar la traduccin de requerimientos en cdigo ejecutable. 7. Mayor control para mantener las sucesivas revisiones de los programas.
<< Incluye >> Hac e r un Fin de Da
<< Extiende >>

jvilalta@vico.org
<< Incluye >> Export a r movimient os
C e rra r A rque o
Vilalta Consultores 2001 - TRAD modelo UC_esp - Rev. 5.1 -
<< Incluye >>
Imprimir doc ume nto
<<Generaliza>>
Imprim i r tira de arque o
8. Certificacin contractual ClienteDesarrollador. 9. Documentacin orientada al usuario: Helps - Manual de Procedimientos - Reglas de Negocio.
Use Case
<< Extends >>
Piezas de funcionalidad reutilizables en diferentes procesos de negocio
10. Documentacin orientada al administrador del sistema: Soporte de Mantenimiento.
Funcionalidad
Requerimientos y Casos de Uso

Los Casos de Uso son requerimientos funcionales que describen de una manera detallada el comportamiento del sistema con los distintos Actores que interactan con l.
qu Re
erimiento
No definen todos los requerimientos (por ej. los tipos de datos, interfaces externas, niveles de rendimiento esperado, etc.), pero representan el hilo conductor que vincula a todos los requerimientos posibles (actuales y futuros) de una aplicacin.
in
Funcionales, no funcionales e interfaces de usuario Funcionalidad, Anlisis y Diseo
Reglas de Negocio y protocolos de intercambio de informacin Mapa conceptual: Clases de anlisis
Mo
jvilalta@vico.org
Cer tif ic ac
delo
Vilalta Consultores 2001 - TRAD Req y CUs_esp - Rev. 1.1 -
Implementacin de cdigo y Refactoring
Caso de Uso
Dinmica de Clases complejas
Plan Director de Iteraciones: Cronograma y prioridades
Mapa funcional: Flujos de trabajo principales y variaciones
de
Pr
oye
cto
A rq
e ui t
ct
Ge
Mtrica: Escenarios de Escandallo de interaccin recursos de objetos: y actividades Clases de diseo
sti
ur
Use Case
<< Extends >>
Funcionalidad
CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su cdigo de artculo, tipo de presentacin y cantidad. 3. Sistema comprueba cada lnea del pedido para validar la situacin del artculo en catlogo y el nmero de items del artculo en stock.
a. Artculo NO est vigente en catlogo, sistema informa que articulo no est vigente y muestra artculos alternativos activando el CU Seleccionar artculo. b. SI existen suficientes items del artculo en el stock, sistema asigna items al pedido. c. NO existen suficientes items del artculo en stock, o la asignacin de items deja la situacin del artculo en stock por debajo del nivel de reposicin, sistema genera pedido de reposicin activando el CU Generar pedido.
Va r i a c i o n e s
Diagrama de Actividad
Notacin UML 1.3
Recepcin de un Pedido
Evento que desencadena la secuencia de actividades
Anlisis textual del Caso de Uso
Identificar Cliente
Actividad
Entrar lneas pedido

Barra de sincronizacin Concurrencia dinmica de actividades
* [para cada lnea de pedido]
4. Sistema comprueba la situacin del pedido .
a. SI se ha realizado el pago y SI todos los items del pedido han sido asignados, sistema informa que procede a servir el pedido activando el CU Servir pedido. b. SI se ha realizado el pago y NO existen suficientes items del artculo en stock, sistema aparca el pedido del cliente activando el CU Aparcar pedido. c. SI no se ha realizado el pago segn el plazo convenido, sistema cancela el pedido.
Comprobar Pago
Comprobar Artculo
[NO vigente]
jvilalta@vico.org
Punto de decisin
Seleccionar Artculo alternativo
[SI vigente]
Vilalta Consultores 2001 - TRAD Actividad 1_esp - Rev. 7.1 -
Descripcin de un Flujo de Trabajo

1
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.
Cancelar Pedido
Barra de fusin
[NO] [SI]
Asignar Items
[NO Stock] o [SI umbral reposicin]
Generar reposicin
Comprobar situacin Pedido

[Todos los items asignados]
Condicin lgica: verdadera o falsa, que permite la transicin a otra actividad

Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
[Faltan items por asignar]
Validar
Pago
Asignar Items
Servir Pedido
Aparcar Pedido
Activar Pedido
Regularizar
Stock
Flujos de Trabajo
CU Actualizar reposicin
Flujo Principal 1. Usuario recepciona albaranes de reposicin que ha enviado un proveedor. 2. Sistema localiza los pedidos de clientes aparcados que pueden cumplimentarse con la nueva entrada de items. 3. Usuario selecciona los pedidos de clientes aparcados que decide cumplimentar. 4. Sistema asigna los items pendientes a los pedidos de cliente seleccionados. 5. Sistema informa que procede a servir el pedido activando el CU Servir pedido.. 6. Sistema regulariza la situacin de items en stock y revisa los umbrales de reposicin automtica.
jvilalta@vico.org

Recepcin de una Reposicin
Anlisis textual del Caso de Uso
Una diagrama de actividad describe una secuencia de actividades que pueden exhibir un comportamiento en paralelo o estar sujetas a condiciones lgicas. Los procesos de negocio no muestran siempre una secuencia fija en su desarrollo, es una ventaja as poder modelar bloques de actividades sin restricciones de concurrencia.
Entrar Reposicin
Buscar Pedidos aparcados
Seleccionar Pedido
Notacin UML 1.3
Asignar Items
Transicin de una actividad a otra sujeta a una condicin lgica.
Sincronizacin de actividades que pueden ocurrir en paralelo.
[Todos las reposiciones entradas]

Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
Servir Pedido
Regularizar Stock
Fin de la secuencia de actividades
Validar
Pago
Asignar Items
Activar Pedido
Regularizar
Stock
Flujos de Trabajo
Recepcin de un Pedido Identificar Cliente
Notacin UML 1.3
Entrar lneas pedido
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.
[Recepcin de Reposicin]
Comprobar Artculo Seleccionar Artculo alternativo Comprobar Pago

jvilalta@vico.org
Entrar Reposicin
[NO vigente] [SI vigente]
Seleccionar Pedido
Buscar Pedidos aparcados

Lneas para acotar reas de responsabilidad (swim-lines)
Asignar Items
[NO xito] [SI xito]
Cancelar Pedido Generar reposicin

[NO Stock] o [SI umbral reposicin]
Regularizar Stock
Contabilidad
Comprobar situacin Pedido
Comercial
[Todos las reposiciones entradas]
Almacn
Entrar
Pedido
Validar
Riesgo
Seleccionar
Pedidos
Validar
Pago
Asignar Items
[Faltan items por asignar]
Activar Pedido
Regularizar
Stock
Servir Pedido
Aparcar Pedido
Flujos de Trabajo
Descomposicin de la actividad Comprobar Pago
Notacin UML 1.3
Su objetivo no es relacionar actividad con objetos, slo comprender qu actividades son necesarias y cuales son sus relaciones de dependencia. El diagrama de actividad nos permite definir en qu orden se van a realizar distintas tareas. Los diagramas de flujo (flowchart) slo nos permiten modelar procesos secuenciales, mientras que los diagramas de actividad nos permiten establecer procesos en paralelo.
Pueden procesarse distintas modalidades de pago de manera simultanea
Comprobar Pago
[Tarjeta de Crdito] [Factura]

jvilalta@vico.org
Autorizacin
Comprobar Cheque
[Cheque]
Comprobar Cliente habitual

[NO] [SI]
Importe > 150.000

[SI] [NO recibido]
NO xito
[Efectivo] [NO xito] [NO xito]
Comprobar historial pagos

[SI xito] [SI xito] [NO xito]
Pre-Pago requerido
[NO]
Comprobar Crdito
[NO xito]
NO xito
Entrar
Pedido
[SI xito]
Validar
Riesgo
[SI xito]
Seleccionar
Pedidos
Validar
Pago
Abrir Cuenta Cliente
Asignar Items
SI xito
Activar Pedido
Regularizar
Stock
Flujos de Trabajo
CU Realizar pedido
Descripcin de un Escenario
Un escenario muestra de que manera interactan los distintos objetos dentro del flujo principal de eventos de un Caso de Uso con alguna variacin o extensin concreta del mismo. Utilizamos dos diagramas de interaccin: a/. Secuencia b/. Colaboracin Su finalidad es describir los mensajes que intercambian los distintos objetos para cumplir con las responsabilidades definidas en un escenario concreto de un Caso de Uso. Diagrama de Secuencia.- Representa las
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.
Anlisis textual del Use Case
Objetos que interactan
jvilalta@vico.org
: C o m erci al
:Una Ventana de introduccin de Pedidos
:Un Pedido
:Una Lnea de Pedido
:Una Cartera de Items en Stock
1:indentificarCliente ( ) 2:generarPedido ( ) 3:entrarLneaPedido ( ) 4:generarLneaPedido ( ) 5:comprobarStock ( ) Auto-mensaje 7:realizarReposicin ( )
Vilalta Consultores 2001 - TRAD Secuencia_esp - Rev. 6.1 -
Estos mensajes muestran el nivel de colaboracin entre los distintos objetos existentes e indican cuando se requiere generar nuevos objetos para cumplir con las responsabilidades asignadas.
6:asignarItems ( )
(1)
Mensaje Lnea de vida de un objeto durante la interaccin
Creacin de un nuevo objeto
8:generarReposicin ( )
:Un Pedido de Reposicin
Un pedido
Una lnea de pedido
Un item de stock
[tieneStock] nuevo [tieneStock] nuevo tieneStock:( )
: Pedido
xxx lnea : Lnea de pedido xxx stock : item de stock
Diagrama de Secuencia
Notacin UML 1.3
: Item de Expedicin
Escenarios
CU Realizar pedido
Descripcin de un Escenario
Con un escenario representamos el conjunto de eventos que configura el comportamiento de un Caso de Uso. Un escenario describe una instancia del flujo de eventos de un Caso de Uso, con sus variaciones o extensiones posibles y las excepciones probables. Utilizamos dos diagramas de interaccin: a/. Secuencia b/. Colaboracin Su finalidad es describir los mensajes que intercambian los distintos objetos para cumplir con las responsabilidades definidas en un escenario concreto de un Caso de Uso. Diagrama de colaboracin.- Representa una
Objeto
(Instancia de una Clase)
jvilalta@vico.org
: Comercial
1: identificarCliente ( ) 3: entrarLneaPedido ( )
Nmero de secuencia
posible interaccin de los objetos ordenados a partir de la topologa que muestra el envio de sus mensajes.
(1) Mensajes enviados entre los objetos descritos en
el flujo de eventos de un Caso de Uso.
Vilalta Consultores 2001 - TRAD Colaboracin_esp - Rev. 6.1 -
4: generarLneaPedido ( )
: Una Ventana de introduccin de Pedidos

Enlace entre dos objetos 2: generarPedido ( ) Mensaje (1)
: Una Lnea de Pedido

5: comprobarStock ( ) 6: asignarItems ( )
Estos mensajes muestran el nivel de colaboracin entre los distintos objetos existentes e indican cuando se requiere generar nuevos objetos para cumplir con las responsabilidades asignadas.
Auto-mensaje
: Un Pedido
Direccin del mensaje
7: realizarReposicin ( )
:Una Cartera de Items en Stock

[tieneStock] nuevo [tieneStock] nuevo
8: generarReposicin ( )
tieneStock:( )
: Pedido
xxx lnea : Lnea de pedido
Diagrama de Colaboracin
Notacin UML 1.3 : Un Pedido de Reposicin
: Item de Expedicin
Escenarios
Clases
Desde una perspectiva conceptual, una Clase representa un conjunto de Objetos que comparten: Las mismas propiedades (Atributos) El mismo comportamiento (Mtodos) Las mismas relaciones con otros Objetos (Mensajes) La misma semntica dentro del sistema Desde una perspectiva fsica, una Clase es una pieza de software que actua como un molde para fabricar tipos particulares de objetos que disponen de los mismos atributos y mtodos. Estos elementos que configuran cada tipo de objeto slo se definen una vez, cuando especificamos la estructura de la Clase a la que pertenecen.
jvilalta@vico.org
Cliente Pedido
FechaRecibido ConPrepago Nmero Importe Divisa ... seleccionar ( ) comprobar ( ) servir ( ) cerrar ( ) ...
Nombre Direccion valorarCredito( ): string
NombreContacto ValoracionCredito LimiteCredito facturarMes( ) recordar( )
Cliente Personal
NumTargetaCredito

Cantidad Importe Cumplimentada aceptar ( )
Representante
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).
Producto
Vilalta Consultores 2001 - TRAD Clases 1_esp - Rev. 6.1 -
Objetos
Un Objeto representa una entidad del mundo real o inventada. Es un concepto, una abstraccin o algo que dispone de unos lmites bien definidos y tiene una significacin para el sistema que se pretende modelar. Estructura y funcin: Identidad Quien soy? = Atributos Propsito Cual es mi misin? = Justificacin Responsabilidades Qu debo hacer? = Mtodos Procedencia De qu Clase provengo? = Origen Relaciones Qu mensajes entiendo? = Comportamiento
Diagrama de Clases
Notacin UML 1.3
Cliente Pedido
hacer / comprobacin
Cliente Personal

hacer / comprobacin
Comercial
Producto
Objetos
Clases
Abstraccin
A partir de una abstraccin del mundo real, definimos objetos que representan micromdulos de software ideales. Desde su creacin, se mantienen de manera independiente unos de otros, slo interaccionan con otros objetos a travs de sus mensajes. Cada objeto configura un universo ordenado y autosuficiente.
jvilalta@vico.org
vacp 104
o od t
Atributos
do to 3
t m od o 2
m o od t 4
m
Cliente Pedido
hacer / comprobacin
Cliente Personal

hacer / comprobacin
Comercial
Producto
Clases
Objeto
Quien soy?
Todo lo que un objeto conoce est representado en sus atributos (variables y estado actual), y todo lo que puede realizar est definido en sus mtodos (comportamiento), y en sus interacciones con otros objetos a travs del intercambio de mensajes (dinmica del ciclo de vida).
Vehculo Automtico Carga Palets
vacp104
Qu puedo hacer?
ca
jvilalta@vico.org
rg
It ar
em
Atributos
rm fo ta a
ov m er ac H ia
ar ev el m or af at Pl
la rP a aj
Qu conozco?
Variables. Identificacin Medidas de la carga Capacidad de carga Velocidad mxima Tipo de carga
Cliente Pedido
hacer / comprobacin
Estado. Localizacin Orientacin Velocidad
Cliente Personal

hacer / comprobacin
Comercial
Producto
Clases
Mensaje
Una aplicacin orientada a objetos consiste en un nmero determinado de objetos que interactuan entre si envindose mensajes unos a otros para invocar sus mtodos. Este intercambio de mensajes facilita su comportamiento, cambios de estado, destruccin o almacenamiento. Ya que todo lo que un objeto puede realizar est expresado en sus mtodos, este simple mecanismo de mensajes soporta todas las posibles interacciones entre ellos.
Mtodo que se invoca para que lo ejecute el objeto receptor Parmetro enviado para especificar el mtodo Nombre del objeto receptor
jvilalta@vico.org
vacp104
ca
rg
It ar
em
Atributos
fo a rm
Signatura del mensaje
ov m er ac H ia
vacp104
moverHacia: binB7
Objeto Emisor
ar ev el m or af at Pl a
ba ja
ta la rP
Cliente Pedido
hacer / comprobacin
Cliente Personal
Objeto Receptor

hacer / comprobacin
Comercial
Producto
Clases
Encapsulacin
Interface de mensajes
El empaquetado de mtodos y atributos dentro de un objeto mediante una interface de mensajes, es lo que denominamos encapsulacin. La clave est precisamente en este envoltorio del objeto. La interface que rodea por completo al objeto acta como punto de contacto para todos los mensajes que llegan desde cualquier objeto emisor. La interface de mensajes tiene la misma funcin que la membrana de una clula, disponer de una barrera esencial entre la estructura interna de un objeto y el exterior. Su propsito es garantizar que todas las interacciones del objeto tengan lugar a travs de un sistema de mensajera predefinido con el que es capaz de entenderse y reaccionar adecuadamente.
a rg e rIt m ov m
Conjunto de operaciones externamente visibles que define el comportamiento de un objeto
jvilalta@vico.org
ca
No existe ninguna otra manera con la que un objeto externo pueda acceder a los atributos y mtodos escondidos dentro de la interface de mensajes de otro objeto.
er ac H ia
Atributos
ar ev el m or af at Pl a
ba ja at Pl r af a rm o
vacp104
moverHacia: binB7
Cliente Pedido
hacer / comprobacin
Mensaje
Cliente Personal

hacer / comprobacin
Comercial
vacp104
Producto
Clases
Herencia
Es el mecanismo por el cual una clase de objetos puede ser definida como un caso especial de otra clase ms genrica. Los casos especiales de una clase se denominan Subclases. La clase ms genrica, se conoce como la Superclase de todos sus casos especiales. Adems de los mtodos y atributos que heredan, las Subclases definen sus propios mtodos y atributos. Tambien, pueden redefinir algunos de los heredados (overriding).
6
La interface de mensajes definida para una Superclase tambin es heredada por las subclases. Esto implica que todas las Subclases de una Superclase estan preparadas para responder correctamente a los mismos mensajes que la Clase padre. Esta propiedad es extremadamente til porque nos permite tratar de la misma manera a todas las especializaciones de una Clase.
Vehculo Automtico de Carga

SuperClase
jvilalta@vico.org
Vehculo Automtico Carga Bobinas
vac 104 vac 104 vac 103 vacp 104

ca rg a em r It
m H er ov ia ac
SubClase
SubClase
Interface de mensajes Mtodos

a
Cliente Pedido
hacer / comprobacin
Atributos
or af at m
Atributos
ev el ar or af at Pl
Cliente Personal
Instancias de Vehculo Automtico Carga Palets
ba
ja
l rP

hacer / comprobacin
vacp 104
m a
Comercial
Producto
Identificador del objeto
Clases
Composicin
Los objetos que contienen a otros objetos se denominan Objetos Compuestos. Los atributos de un objeto pueden utilizarse de dos maneras. Podemos usarlos para almacenar valores como el nmero 15, o bien, el texto Autorizado.
7
Tambin pueden contener referencias de otros objetos. Las referencias almacenadas en los atributos de un objeto compuesto, permite a este objeto enviar los mensajes apropiados a todos los objetos contenidos.
Ventana Wizard
Enter title here
Progress
67%
Tab
Tab control Trackbar

< Back Next > Cancel
jvilalta@vico.org
Panel de ventana
Grid
Enter title here
Slider
Campo simple
Scroll Botones de ventana

Restore Help
?
Maximize Minimize
Combo box List box
Cliente Pedido
hacer / comprobacin
Cliente Personal

hacer / comprobacin
Close
Comercial
Producto
Clases
Polimorfismo
Vehculo Automtico de Carga
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. Un objeto puede ser de diferentes tipos. Por ejemplo un vehculo automtico de carga puede especializarse para cargar bobinas, palets u otro tipo de items. Los dems objetos del sistema no tienen porque saber cuantos tipos de vehculos disponemos. El mismo mensaje cargarItem, acompaado del parmetro que identifica dicho item, ser intrepretado de distinta manera por cada objeto receptor, el cual ya conoce previamente como tiene que tratar la naturaleza de su carga: bobinas, palets, etc. Hay una reduccin de esfuerzo muy significativa por el hecho de que cualquier objeto del sistema puede enviar mensajes a los vehculos automticos de carga sin necesidad de saber de antemano qu tipo de vehculos estan en circulacin. No hay necesidad as de picar un cdigo especfico para cada tipo de vehculo, con lo cual, nos ahorramos prolijas sentencias IF o CASE que son complejas de mantener y de actualizar cuando se incorporan nuevos tipos de objetos.
SuperClase
jvilalta@vico.org
Vehculo Automtico Carga Bobinas
SubClase
SubClase
m Ite ar rg ca
Atributos
r fo ta la m a
ev el ar or af at Pl m a ev el
rP ja ba
vacb 117
m H er ov ia ac
rg ca
m Ite ar
Atributos
rm fo ta la a
ar or af at Pl m a
rP ja ba
vacp 104
m H er ov ia ac
cargarItem: #A234C19FZ
Cliente Pedido
hacer / comprobacin
Mensaje
Cliente Personal

hacer / comprobacin
Comercial
Producto
Clases
Cliente Pedido
- fechaRecibido conPrepago - nmero: Alfanm. - importe: Nm&2d. - divisa ... + crear () + seleccionar ( ) + comprobar ( ) + servir ( ) + cerrar ( )
1
+ hacer / comprobacin
Visibilidad
Cliente Personal
Toda Clase encapsula unos elementos (atributos y operaciones) que disponen de ciertos criterios de visibilidad y manipulacin para otras Clases. Los elementos pblicos pueden ser usados por cualquier otra Clase. Los elementos privados pueden ser usados slo por la Clase propietaria. Cada plataforma de desarrollo (C++, Smalltalk, Java) desarrolla sus propias reglas con respecto a la visibilidad y manipulacin de atributos y operaciones. La notacin UML especifica que todo atributo y operacin de una Clase ha de disponer de un indicador de visibilidad. C++ Smalltalk Java
Un elemento siempre es visible en cualquier parte del programa y puede ser llamado y modificado por cualquier objeto del sistema. Un elemento slo puede ser usado por la Clase que lo define. Un elemento puede ser usado por subclases y tambin por cualquier otra Clase en el mismo Package como la Clase propietaria. Esto implica que en Java, el concepto de visibilidad protegida es ms pblico que package. Un elemento slo puede ser usado por otras Clases que compartan el mismo Package.
Consideremos la Clase CLIENTE que dispone de una subclase CLIENTE PERSONAL. Consideremos tambin que el objeto <<Josep V.>>, es una instancia de CLIENTE PERSONAL. <<Josep V.>> Puede usar todo elemento pblico de cualquier objeto del sistema. Puede usar tambin todo elemento privado de la Clase CLIENTE PERSONAL. No puede usar los elementos privados definidos en la Clase CLIENTE. Puede usar los elementos protegidos definidos para CLIENTE y CLIENTE PERSONAL. 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. <<Josep V.>>, puede acceder a cualquier variable instanciada dentro de su propio objeto, si dicha variable ha sido definida dentro de CLIENTE o CLIENTE PERSONAL. De esta manera, el concepto de visibilidad privada en Smalltalk es parecido al concepto de visibilidad protegida en C++. En Smalltalk no hay diferencia con respecto a que un objeto sea de la misma Clase o no. Podemos acceder slo a los elementos pblicos de otro objeto. En Smalltalk, <<Miquel M.>>, no puede acceder a las variables instanciadas privadas de <<Josep V.>>, slo a sus operaciones pblicas. Java permite marcar tambin las Clases como pblicas o packages. Los elementos de una Clase pblica pueden ser usados por cualquier Clase que importe el package a la que pertenece la Clase. Los elementos de una Clase package slo pueden ser usados por otras Clases del mismo package.
+ hacer / comprobacin item
Visibilidad + Publica - Privada
* 0..1 *
jvilalta@vico.org
Un elemento siempre es visible en cualquier Todas las operaciones son parte del programa y puede ser llamado y pblicas por defecto. modificado por cualquier objeto del sistema. Un elemento slo puede ser usado por la Clase que lo define. Un elemento slo puede ser usado por la Clase que lo define, o por las subclases de dicha Clase. Todas las variables instanciadas son privadas.
Comercial
Lnea de Pedido
+ hacer / comprobacin
Producto
# Protegida
Vilalta Consultores 2001 - TRAD Clases visibilidad_esp - Rev. 5.3 -
Package
Cliente Pedido
hacer / comprobacin
Ejemplos
Cliente Personal

hacer / comprobacin
Comercial
Producto
Clases
Consideremos la instancia de CLIENTE PERSONAL, <<Miquel M.>>, este objeto puede acceder a cualquier elemento de <<Josep V.>>, que ha sido definido tambin como una instancia de CLIENTE PERSONAL, sea pblico, privado o protegido. <<Miquel M.>>, a su vez tambin puede acceder a cualquier elemento privado, protegido o pblico de <<Josep V.>>
CU Realizar pedido
Descripcin de la Dinmica del Sistema

La dinmica de un sistema est determinada por: Todas las posibles secuencias de eventos que pueden ocurrir.
Todos los posibles estados que sus objetos pueden tener.
Todas las transiciones posibles, de un estado a otro, como consecuencia de los eventos que afectan a los objetos.
jvilalta@vico.org
Diagrama de Estados de un Pedido

Notacin UML 1.3
Vilalta Consultores 2001 - TRAD Dinmica 1_esp - Rev. 5.1 -
Pedido
fechaRecibido conPrepago nmero: Alfanm. importe: Nm&2d. divisa ... seleccionar ( ) comprobar ( ) servir ( ) cerrar ( ) ...
*
1
/seleccionar primer item

2
[No todos los items comprobados] /seleccionar siguiente item
Comprobando
[Todos los items comprobados && Sirviendo todos los items disponibles]
hacer / inicio de entregas
ib
le
s]
1
ionar primer item [Todos los items comprobados && todos los items disponibles] rimer item
Verificando
Sirviendo
5 4
rimer item
[T
d is
rimer item
Entregado
Esperando
Entregado
Dinmica Estados
Item Recibido [algunos items no estan disponibles en stock]
Esperando
It [T em od R os eci lo bid s ite o m s
[Todos los items comprobados && algunos items no estan disponibles en stock]
sp
on
Pedido Entregado
po
n ib
le
s]
di
Entregado
CU Realizar pedido
Utilizamos el diagrama de estados para describir el comportamiento de una Clase dentro de una serie temporal.
Clase
jvilalta@vico.org
Pedido
Inicio

Notacin UML 1.3
*
primera Transicin
Atributos Operaciones
/seleccionar primer item Accin Indicador [No todos los items comprobados] /seleccionar siguiente item Accin
1 3
Estado
2
Vilalta Consultores 2001 - TRAD Dinmica 2_esp - Rev.- 5.1 -
1
Sintaxis para etiquetar una transicin Evento [Indicador] / Accin
Comprobando
Actividad
le
s]
/ Accin
Transicin
4
Procesos que ocurren de manera rpida dentro de un ciclo contnuo sin interrupcin.
Auto-Transicin Item Recibido [algunos items no estan disponibles en stock]
di
sp
on
Los tres elementos son opcionales
Evento Pedido Entregado
Desencadena siempre la Transicin
ib
ionar primer item
Esperando
[Todos los items comprobados && todos los items disponibles]
Entregado
rimer item
Verificando
Sirviendo
rimer item
Esperando
[T
d is
rimer item
po
n ib
le
s]
Entregado
Entregado
[Indicador]
Transicin
Transicin
Condicin lgica con dos categorias: verdadero o falso. Una Transicin con [Indicador] slo ocurre si este es verdadero. Slo podemos extraer una Transicin para un Estado concreto.
Dinmica Estados
CU Realizar pedido
Construimos el diagrama de estados a partir de una clase concreta para mostrar el comportamiento de un objeto durante su ciclo de vida.

Notacin UML 1.3 Cuando una Transicin no dispone de un Evento en su etiqueta, significa que la Transicin se realiza tan pronto como la Actividad asociada con un Estado es finalizada Aunque finalize la Actividad el Pedido permanecer en este Estado hasta que ocurre el Evento que desencadena su Transicin
Clase
jvilalta@vico.org
Pedido
Inicio
*
primera Transicin
Atributos Operaciones
/seleccionar primer item Accin Indicador [No todos los items comprobados] /seleccionar siguiente item Accin
1 3
Estado
2
Implementacin
1
Sintaxis para etiquetar una transicin Evento [Indicador] / Accin
Los tres elementos son opcionales
Comprobando
Actividad
Desencadena siempre la Transicin
le
s]
/ Accin
Transicin
4
Procesos que ocurren de manera rpida dentro de un ciclo contnuo sin interrupcin.
Auto-Transicin
/ Actividad
Evento Pedido Entregado
di
sp
on
ib
ionar primer item
Estado
rimer item
[Indicador]
Transicin
No hay Actividades para este Estado, por lo que el Pedido permanecer a la espera de un Evento.
Transicin
Esperando
[T
Procesos que ocurren dentro de un ciclo discontnuo y pueden ser interrumpidospor algun evento.
Item Recibido [algunos items no estan disponibles en stock]
Esperando
Entregado
rimer item
Verificando
Sirviendo
d is
rimer item
po
n ib
le
s]
Entregado
Entregado
Condicin lgica con dos categorias: verdadero o falso. Una Transicin con [Indicador] slo ocurre si este es verdadero. Slo podemos extraer una Transicin para un Estado concreto.
Dinmica Estados
CU Realizar pedido

Slo podemos conocer que un Evento ha ocurrido, detectando sus efectos en nuestro modelo.
Un Evento no es un objeto. Un Evento es la causa que justifica la existencia de una informacin.
Slo nos interesan aquellos Eventos que provocan un cambio de estado en los objetos de nuestro modelo. Hay que distinguir un Evento como tal, del objeto que representa el registro de los efectos de dicho Evento.
Nombre del Superestado

jvilalta@vico.org
1 /seleccionar primer item [No todos los items 2 comprobados] [Todos los items comprobados && /seleccionar Comprobando todos los items disponibles] Sirviendo siguiente item hacer / comprobacin item 3 hacer / inicio de entregas
[No todos los items comprobados] /seleccionar Comprobando siguiente item

4
sp
on
/seleccionar primer item
ib
Activo
Pedido Cancelado
le
6
di
4
sp
on
ib
le
s]
Item Recibido [algunos items Esperando no estan disponibles en stock] Pedido Cancelado
Pedido Cancelado
s]
Pedido Entregado
Entregado
di
Cancelado
sin Superestados
6
Item Recibido [algunos items Esperando no estan disponibles en stock] Pedido Cancelado
Pedido Entregado
Diagrama de Estados con Superestados

Notacin UML 1.3
ionar primer item
rimer item
Verificando
Sirviendo
rimer item
Esperando
[T
d is
rimer item
po
n ib
le
s]
Entregado
Entregado
Cancelado
Entregado
Dinmica Estados
CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su cdigo de artculo, tipo de presentacin y cantidad. 3. Sistema comprueba cada lnea del pedido para validar la situacin del artculo...
a. Artculo NO est vigente en catlogo, sistema informa que articulo no est vigente y muestra... b. SI existen suficientes items... c. NO existen suficientes items...
Los diagramas de estados son muy tiles para describir el comportamiento de un objeto a travs de mltiples Casos de Uso.
Autorizando
hacer / comprobacin del pago
[pago NO correcto]
jvilalta@vico.org
[pago SI correcto]
Esperando Cancelado
Pedido Cancelado
Autorizado
Rechazado
Comprobando
Sirviendo
Entregado
Pedido Entregado
Entregado
Autorizando
Autorizado
ionar primer item
rimer item
Verificando
Sirviendo
Rechazado
Pedido Rechazado
Diagrama de Estados Concurrentes

Notacin UML 1.3
rimer item
Esperando
[T
d is
rimer item
po
n ib
le
s]
Entregado
Entregado
Dinmica Estados
Arquitectura del sistema
Una Arquitectura es un conjunto organizado de elementos. Se utiliza para especificar las decisiones estratgicas acerca de la estructura y funcionalidad del sistema, las colaboraciones entre sus distintos elementos y su despliegue fsico para cumplir unas responsabilidades bien definidas.
jvilalta@vico.org
Modelo de Referencia
Vista de la
Vista del
Componentes Modulares
Vista de
Vilalta Consultores 2001 - TRAD Arquitectura 1_esp - Rev. 5.1 -
Funcionalidad
Use Cases
Implementacin Ejecutables
Vista de
Distribucin Fsica Elementos
Vista de
Vista de la Arquitectura 4+1

Notacin UML 1.3
Arquitectura
Vista del
La vista del Modelo de Referencia (Reference Information Model), est determinada por la arquitectura lgica. La arquitectura lgica es capturada por los diagramas de Clases que contienen las Clases y relaciones que representan las abstracciones esenciales del sistema a desarrollar. Clases Vista del Asociaciones Agregaciones Generalizacin Packages
Pedidos Clientes
Cliente
jvilalta@vico.org
El Modelo de Referencia se construye en sucesivas iteraciones durante la fase de Formalizacin. Las Clases y Packages del modelo reflejan las decisiones tomadas con respecto a los mecanismos clave del sistema. Una eficiente implementacin de los mecanismos clave requiere seleccionar Patrones (Patterns) que se ajusten a los requerimientos esenciales del proyecto. La implementacin de mecanismos clave requiere seleccionar tambin: Lenguaje de programacin Motor de Base de Datos Interface grfico de usuario look and feel Tratamiento de errores Mecanismos de comunicacin Migracin y distribucin de objetos Networking
Pedido
1
hacer / comprobacin
Artculos
Cliente Personal

hacer / comprobacin
Comercial
Producto
Arquitectura

Vista del
Vista de
La vista de Componentes Modulares refleja la organizacin de mdulos de software dentro del entorno de desarrollo. Esta vista de arquitectura toma en cuenta los requerimientos que facilitan la programacin, los niveles de reutilizacin, y las limitaciones impuestas por el entorno de desarrollo. Disponemos de dos elementos para modelizar esta vista: Packages: En esta vista representan una particin fsica del sistema. Componentes: En esta vista representan la organizacin de mdulos de cdigo fuente.
Vista de
jvilalta@vico.org
Los Packages estan organizados en una jerarqua de capas que disponen de una interface bien definida:
Pe d i d o
4 3 2 1
Interface de Usuario Pa c k a g e s e s p e c f i c o s d e l d o m i n i o Pa c k a g e s r e u t i l i z a b l e s Mecanismos clave CORE Pa c k a g e s d e p l a t a f o r m a

(OS -Hardware)
Entrada Pedidos
Interface Usuario
AWT
Java GUI toolkit
Mailing
Interface Usuario
Informacin Artculos Dominio
Pedidos Los Packages de la vista lgica del modelo estan mapeados con los Packages fsicos y los componentes de software (subsistemas).
Clientes
Artculos
Arquitectura

Vista del
Vista de
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: Rendimiento Fiabilidad Escalabilidad Integridad Seguridad Sincronizacin
Vista de
Vista de
Administracin del sistema

Entrada Pedidos
Interface Usuario
AWT
Java GUI toolkit
Mailing
Interface Usuario
jvilalta@vico.org
Los componentes run-time muestran los mappings de las Clases a libreras de tipo ActiveX, Applets de Java y libreras dinmicas. Los componentes ejecutables muestran sus interfaces y niveles de dependencia dentro de la aplicacin. Dominio
Entrada Pedidos
Aplicacin
Mailing
Aplicacin
Pedidos
Clientes
P e d i d o s . exe Artculos.dll
Artculos
Oracle
Expedicin.dll Clientes.dll
Base de Datos
Interface global
Interface
Ingres
Interface
Arquitectura

Vista del
Vista de
Esta vista presenta el mapping de componentes de software ejecutables con los nodos de procesamiento (hardware). Esta arquitectura tiene en cuenta los siguientes requerimientos: Disponibilidad del sistema Rendimiento Escalabilidad Los diagramas de distribucin muestran el despliegue de nodos (locales y remotos), en la organizacin de la empresa. Permite al equipo de desarrollo comprender mejor la topologa de un sistema distribuido.
TCP/IP Servidor Contabilidad :Base de Datos :Base de Datos Servidor rea Comercial :Contabilidad
Vista de
Vista de

jvilalta@vico.org
Vista de
Un Nodo es un objeto fsico run-time que representa un recurso informtico. Este recurso, generalmente dispone de datos persistentes y capacidad de proceso. En la mayora de los casos un Nodo puede representar una pieza de hardware, desde un perifrico a un servidor. Las Conexiones entre Nodos muestran las lneas de comunicacin con las que el sistema tendr que interactuar. Los Componentes, en un diagrama de distribucin, representan los mdulos fsicos de cdigo, los cuales, se corresponden con los Packages de ejecutables. De esta manera, el diagrama muestra donde corre cada Package en el sistema. Las Dependencias muestran cmo los componentes se comunican con otros componentes. La direccin de una Dependencia concreta, indica el conocimiento en la comunicacin.
Conexin :GUI Comercial Componente
:Comercial Configuracin :Servidor Aplicaciones :Usuarios Nodos
TCP/IP Cliente Win95 :Cliente Comercial Interface
Arquitectura

Vista de la Vista del
Vista de
Esta vista certifica la validez de: Modelo de Referencia Componentes modulares de software
Funcionalidad
Use Cases
Vista de
Vista de
Ejecutables Distribucin de recursos informticos Con la funcionalidad requerida del sistema. Utilizamos los siguientes elementos para describir la funcionalidad:
Abrir Arqueo
<< Ext >>
Hacer un Inicio de Da
Diagramas de Casos de Uso Especificacin de Casos de Uso

Supervisor
<< Inclu >>
Diagramas de Interaccin (Escenarios) Diagramas de Actividad (Flujos de Trabajo) Diagramas de Estados (Dinmica)
jvilalta@vico.org
Cajero
Cerrar Arqueo << Ext >>
Hacer un Fin de Da << Inclu >>
<< Inclu >>
Imprimir documento
Exportar movimientos
Contabilidad
Recepcin de un Pedido
Preparar Pedido
CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su cdigo de artculo, tipo de presentacin y cantidad.
Cancelar Pedido
[NO xito] Comprobar Comprobar
Pago
[en stock] [SI xito]
Items
Asignar Items
[Requiere reposicin]
3. Sistema comprueba cada lnea del pedido para validar la situacin del artculo en catlogo y el nmero de items del artculo en stock.
a. Artculo NO est vigente en catlogo, sistema informa que articulo no est vigente y muestra artculos alternativos activando el CU Seleccionar artculo. b. SI existen suficientes items del artculo en el stock, sistema asigna items al pedido.
Reponer Items Servir Pedido
[tieneStock] nuevo [tieneStock] nuevo
tieneStock:= comprobar ( )
[tieneStock] asignar ( )
c. NO existen suficientes items del artculo en stock, o la asignacin de items deja la situacin del artculo en stock por debajo del nivel de reposicin, sistema genera pedido de reposicin activando el CU Generar pedido.
ionar primer item
rimer item
Verificando
Sirviendo
sp
rimer item
on
ib
le
s]
rimer item
[tieneStock] nuevo
di
Entregado
Esperando
Entregado
Arquitectura

UML - Guia Visual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UML - Guia Visual

Uploaded by

Copyright:

Available Formats

Gua Visual

Cmo crear formas de vida organizativa

Proyecto: Documento: Historial: Situacin: Proceso: Autor:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org

Proyecto: Documento: Historial: Situacin: Proceso: Autor:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org

Proyecto: Documento: Historial: Situacin: Proceso: Autor:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org

Proyecto: Documento: Historial: Situacin: Proceso: Autor:

A quin va dirigida esta gua visual?

Cmo sacar un mayor provecho a su lectura?

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org

Proyecto: Documento: Historial: Situacin: Proceso: Autor:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org

Proyecto: Documento: Historial: Situacin: Proceso: Autor:

De dnde provienen las ideas expuestas?

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org

Proyecto: Documento: Historial: Situacin: Proceso: Autor:

Proyecto: Documento: Historial: Situacin: Proceso: Autor:

o Gestin de redes de puntos de venta con videoconferencia

o Integracin de sistemas de informacin de contabilidad administrativa y

Proyecto: Documento: Historial: Situacin: Proceso: Autor:

Josep Vilalta Badalona, Barcelona (Espaa) jvilalta@vico.org http://www.vico.org

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Gua Visual Presentacin.doc Equipo: www.vico.org

Niveles de concepcin y formalizacin de un proyecto

Use Case Use Case

<< Extends >> << Extends >>

Una ventana de introduccin de pedidos

Una lnea de pedido

tieneStock:= comprobar ( ) [tieneStock] nuevo [tieneStock] nuevo [tieneStock] nuevo tieneStock:( )

Cliente Personal Cliente Personal

xxx lnea : Lnea de pedido Pedido :

xxx stock : item de stock

<< Uses >> << Uses >>

: Item de Pedido de reposicin

Vilalta Consultores 2001 - TRAD UMD_esp - Rev. 5.2 -

Matrcula del Proyecto

Code like hell

Especificacin Casos de Uso

Dinmica Eventos - Estados

*Seleccionarpedido seleccionado] [para cada Pedidos Pago

ionar primer item rimer item Verificando

Activar Pedido Activar Pedido

* [para cada pedido seleccionado]

Modelo Prototipo Componentes Certificacin

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

Misin Modelo Prototipo Componentes Certificacin

hacer / comprobacin item

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

Matrcula del proyecto

Cliente Corporativo Cliente Corporativo

Cliente Personal Cliente Personal

hacer / comprobacin item

hacer / comprobacin item

0..1 * Lnea de Pedido

<< Communicates >>

Use Case << Uses >> <<Incluye>>

Cronograma Plan Director Iteraciones

Misin Modelo Prototipo Componentes Certificacin

Una ventana de introduccin de pedidos

Una lnea de pedido

hacer / comprobacin item

Cliente Personal Cliente Personal

Actor << Communicates >> << Communicates >>