P. 1
UML - Guia Visual

UML - Guia Visual

|Views: 28|Likes:
Publicado porJean Paul Perea

More info:

Published by: Jean Paul Perea on Jun 22, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

07/04/2013

pdf

text

original

Guía Visual

Cómo 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: Situación: Proceso: Autor:

Presentación del borrador: UML Guía Visual UML Guía Visual 03/09/01 9:03 Borrador en curso de revisión Evaluación de contenidos ref.- contacto: jvilalta@vico.org 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 para tomar las decisiones que caracterizan el comportamiento de una organización. A diferencia de los sistemas biológicos, las VIO nacen y se desarrollan a partir de una voluntad compartida, de una idea y de un liderazgo. Pero de la misma manera que la selección natural actúa en los sistemas biológicos, la continuidad de una VIO está condicionada a la implementación eficiente de sus procesos esenciales. Conocer estos procesos, saber como aplicar los recursos y como tomar las decisiones para satisacer la cadena de valor de todos los agentes son los factores que toda organización ha de tener en cuenta para evolucionar y asegurar su viabilidad.

La notación UML (no hay que confundir con las metodologías que utilizan dicha notación), se ha convertido desde finales de los 90 en un estándar para modelar con tecnología orientada a objetos todos aquellos elementos que configuran la arquitectura de un sistema de información y, por extensión, de los procesos de negocio de una organización. De la misma manera que los planos de un arquitecto disponen el esquema director a partir del cual levantamos un edificio, los diagramas UML suministran un modelo de referencia para formalizar los procesos, reglas de negocio, objetos y componentes de una organización. La interacción de todos estos elementos es una representación de nuestra realidad.

vi co .o rg
Fecha actualización:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org

Revisión:

Página:

04/09/01 11:16

18

1 de 9

Proyecto: Documento: Historial: Situación: Proceso: Autor:

Presentación del borrador: UML Guía Visual UML Guía Visual 03/09/01 9:03 Borrador en curso de revisión Evaluación de contenidos ref.- contacto: jvilalta@vico.org Josep Vilalta

Nuestros límites para entender esta realidad están en nuestro lenguaje. El mundo es la suma total de lo que podemos definir, organizar y visualizar. Cabe preguntarse ¿de qué manera un modelo en UML representa nuestra experiencia?. Enseñar a utilizar un lenguaje formal siempre es problemático. Es necesario mostrar como este lenguaje puede ser aplicado a la realidad tal como la conocemos y tal como la compartimos con los demás. Con esta guía visual mostramos de manera precisa las técnicas básicas para usar UML en diferentes contextos. La clave está en discriminar cuales son aquellos procedimientos esenciales que nos permiten evitar costosas confusiones conceptuales. No es mediante el descubrimiento de nuevos objetos y de sus múltiples conexiones que avanzamos en las respuestas a nuestros interrogantes cuando modelamos un dominio, (conceptos) ya conocidos y, en último caso, mediante la reducción de su número despejando aquellos conceptos que no añaden valor a la comprensión de dicho dominio. Reconsiderar lo obvio, desenmascarar presunciones, desambigüar conceptos conocidos, todo en busca de la simplicidad y la usabilidad. sino mediante la disolución de las contradicciones que existen entre los términos

La tecnología orientada a objetos persigue el antiguo principio del divide y vencerás. Su objetivo es descomponer la complejidad en partes más manejables y comprensibles. No parece que esto sea algo novedoso con respecto a la tradicional descomposición funcional de los métodos estructurados. Sin embargo, la gran diferencia reside en aplicar la dualidad estructura-función en pequeñas unidades capaces de comunicarse y reaccionar en base a la aparición de una serie de eventos. El esquema dominante de la separación de estructuras de datos y funciones (bases de datos y programas) está amenazado pero aún se resiste a desaparecer.

vi co .o rg
Fecha actualización:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org

Revisión:

Página:

04/09/01 11:16

18

2 de 9

Proyecto: Documento: Historial: Situación: Proceso: Autor:

Presentación del borrador: UML Guía Visual UML Guía Visual 03/09/01 9:03 Borrador en curso de revisión Evaluación de contenidos ref.- contacto: jvilalta@vico.org Josep Vilalta

Mucha gente cree que la principal utilidad de la orientación a objetos es la reutilización del código para conseguir un desarrollo más rápido de las aplicaciones (Rapid Application Development). No comparto esta opinion. Si hay algo que caracteriza un entorno de desarrollo actual es la constante del cambio. Todo proyecto que sobrepase los tres meses está amenazado por la aparición de nuevas plataformas más exigentes, la extinción de herramientas sin previo aviso y, de manera sistemática, por la rotación del personal crítico encargado del proyecto. También está sometido, como no, a los cambios de requerimientos del cliente que a su vez están plenamente justificados por la readaptación de sus procesos de negocio a un mercado inestable. Ante este cuadro de incertidumbre, el mayor desafio de una metodología de desarrollo es su adaptación para el cambio. Esto significa crear modelos que faciliten la comunicación entre todos los agentes involucrados en el sistema en construcción; que hagan visible la trazabilidad entre la concepción de los componentes, su especificación, implementación e instalación; significa el diseño de arquitecturas que faciliten la gestión de las dependencias entre estos componentes, que sean en fin, facilmente reemplazables por otros más optimizados o bien por componentes que aporten una mayor funcionalidad y/o facilidad de uso.

La dinámica de cambio no se desarrolla en la ingeniería del software con la misma velocidad vertiginosa con que nos tiene acostumbrados la tecnología del hardware. La clave reside en que a diferencia de la electrónica, en los dominios del desarrollo de software no existe un vocabulario unificado. Desde la fase de concepción de un sistema a la instalación de sus componentes hay que mapear entre sí una gran diversidad de lenguajes orientados al análisis, diseño, código ejecutable, esquemas de bases de datos, componentes de páginas web, entre otros. Esta distancia entre la concepción y la usabilidad de un producto o de un proceso de negocio, exige cada vez más la capacidad de cooperación y comunicación de un equipo interdisciplinar muy especializado. Esta guía visual de UML está pensada para facilitar este proceso cooperativo y para ayudar a establecer una buena práctica fundamentada en un lenguaje común.

vi co .o rg
Fecha actualización:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org

Revisión:

Página:

04/09/01 11:16

18

3 de 9

Proyecto: Documento: Historial: Situación: Proceso: Autor:

Presentación del borrador: UML Guía Visual UML Guía Visual 03/09/01 9:03 Borrador en curso de revisión Evaluación de contenidos ref.- contacto: jvilalta@vico.org Josep Vilalta

¿A quién va dirigida esta guía visual?
Esta guía ha sido escrita y diseñada para los profesionales involucrados en todos los ciclos de actividad del desarrollo de sistemas de información (concepción, análisis y diseño, implementación, instalación de aplicaciones, gestión y certificación de proyectos); también para los que tengan responsabilidades en la especificación de procesos de negocio con el propósito de evaluar posibles reingenierías de procesos y/o diseño de bases de conocimiento; y finalmente, para aquellos equipos que estén inmersos en la preparación e implementación de certificaciones de calidad. La claridad conceptual y los recursos didácticos utilizados en la exposición de los distintos procedimientos serán de utilidad para los estudiantes que sigan programas de autoaprendizaje y usen esta guía como complemento para sus lecturas de libros sobre UML. También los centros académicos y profesores dispondrán con esta guía de material interesante para completar sus diseños curriculares y proporcionar ejemplos prácticos a sus alumnos.

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

La guía está organizada en unidades didácticas que describen la notación de los diagramas y las fuentes de información necesarias para definir los elementos de cada modelo. Puede usarse como consulta puntual de la notación de un diagrama, o bien, para revisar como establecer el hilo conductor entre los Casos de Uso (mapa funcional), las Clases de dominio (mapa conceptual), las Clases de Especifiación (types e interfaces) y las Clases de Implementación (código).

vi co .o rg
Fecha actualización:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org

Revisión:

Página:

04/09/01 11:16

18

4 de 9

Proyecto: Documento: Historial: Situación: Proceso: Autor:

Presentación del borrador: UML Guía Visual UML Guía Visual 03/09/01 9:03 Borrador en curso de revisión Evaluación de contenidos ref.- contacto: jvilalta@vico.org Josep Vilalta

Un plan de estudio para realizar una progresiva asimilación de los conceptos podría empezar con los Casos de Uso (CU) y continuar con el análisis de los flujos de trabajo de un grupo de CU mediante los diagramas de Actividad; a continuación, separar los escenarios que agrupan una serie de actividades y hacer aflorar, a través de los diagramas de Interacción, los objetos que intercambian una serie de mensajes. A partir de este punto, disponemos del bagaje suficiente como para introducirnos en la abstracción de los objetos y comprender la importancia de separar las tres perspectivas básicas en nuestra representación de las clases: concepción, especificación e implementación. El siguiente paso es identificar alguna clase con un comportamiento complejo que la haga candidata a revisar todos sus posibles estados y averiguar que Transición será el adecuado para representar esta dinámica de estados. Finalmente, abordaremos la configuración de componentes y su despliegue en una arquitectura. Otra lectura de la guía puede estar mas centrada en el seguimiento de la metodología de desarrollo y la gestión de un proyecto. En este caso, las primeras secciones describen los niveles de concepción y formalización de un proyecto con la metodología TRAD (Taller de Requerimientos, Análisis y Diseño basado en el Proceso Unificado de Rational), y se van introduciendo progresivamente los diagramas y actividades que configuran la unidad mínima de documentación sostenible para un proyecto concreto. El estudiante más avanzado podrá sacar también provecho con la consulta puntual de los diagramas en que esté más interesado y la revisión de sus extensiones. Las materias expuestas en las distintas secciones están actualizadas constantemente y pueden descargarse nuevas ediciones desde: http://www.vico.org/UMLguiavisual/ eventos son capaces de provocar un cambio de estado. El diagrama de Estados-

vi co .o rg
Fecha actualización:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org

Revisión:

Página:

04/09/01 11:16

18

5 de 9

Proyecto: Documento: Historial: Situación: Proceso: Autor:

Presentación del borrador: UML Guía Visual UML Guía Visual 03/09/01 9:03 Borrador en curso de revisión Evaluación de contenidos ref.- contacto: jvilalta@vico.org Josep Vilalta

¿De dónde provienen las ideas expuestas?
El contenido de esta guía ha sido elaborado a partir del trabajo de una serie de profesionales que el autor ha tenido la oportunidad de estudiar y aplicar en distintos proyectos. Desde principios de los 90, los artículos publicados en el Journal of Object Oriented Programming (JOOP) por James Odell, James Rumbaugh, Grady Booch, Desmond d’Souza, Bertrand Meyer, Steve Cook, John Daniels, Sally Shlaer y Stephen J. Mellor entre otros, han sido una constante fuente de conocimiento. Publicaciones pioneras como el Object Oriented Technology, A Manager’s Guide de David A. Taylor, en su primera edición de 1990 y en la segunda ampliada de 1998, han tenido una gran influencia en como abordar la presentación didáctica. También los Models y Java Modeling Color with UML, han sido de una ayuda extraordinaria. La obra enciclopédica The Unified Modeling Language: Reference Manual de Rumbaugh & Jacobson & Booch, es un punto de referencia constante. Sin duda, uno de los autores más influyentes ha sido Martin Fowler. Su primer libro Analysis Patterns continua siendo una referencia clave. Posteriormente, la primera edición de UML Distilled en 1997 y su última edición ampliada en 2000, se ha convertido en el libro de cabecera de UML. Otro clásico por la excelencia de su trabajo es Applying UML and Patterns de Craig Larman que en su segunda edición aparecida en verano de 2001 se ha superado a si mismo. También recientes y con muy buen material que ha sido incorporado a la guía, tenemos los libros de Wendy & Michael Boggs, Mastering UML with Rational Rose, de Alistair Cockburn, Writing Effective Use Cases; de Scott W. Ambler, The Object Primer segunda edición; y de John Chessman & John Daniels, UML Components, una de las novedades más interesantes de 2001. En la bibliografía sobre UML publicada en http://www.vico.org hay una relación completa de los libros consultados que se actualiza periódicamente con las últimas novedades. libros de Peter Coad et al, Object Oriented Analysis, Design and Programming, Object

vi co .o rg
Fecha actualización:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org

Revisión:

Página:

04/09/01 11:16

18

6 de 9

Proyecto: Documento: Historial: Situación: Proceso: Autor:

Presentación del borrador: UML Guía Visual UML Guía Visual 03/09/01 9:03 Borrador en curso de revisión Evaluación de contenidos ref.- contacto: jvilalta@vico.org Josep Vilalta

Competencia y actuación
En los últimos veinte años de mi carrera profesional en el desarrollo de sistemas de información he participado en una gran diversidad de proyectos con distintos grados de responsabilidad e involucración, pero siempre con un compromiso firme en la calidad y usabilidad del producto final. Entorno industrial o CIM para la extrusión de polietileno y fabricación de mallas agrícolas y de embalaje. o CIM para el fraccionamiento de hemoderivados o Plan Funcional para la implementación SAP-Logística

vi co .o rg
Entorno sanitario o Gestión de Bancos de Sangre y Hemoterapia o Gestión mutual de prestaciones asistenciales resultados o Gestión de laboratorios farmacéuticos o Gestión integrada de servicios de Atención Primaria Asistencial
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org Fecha actualización:

o Planificación y gestión de campañas de captación de donantes 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

o Historia Clínica Orientada por Problemas Automatizada o Libreta de Salud para programación de citas y exploraciones o Plan Funcional para la implementación SAP-Gestión Clínica y

Revisión:

Página:

04/09/01 11:16

18

7 de 9

Proyecto: Documento: Historial: Situación: Proceso: Autor:

Presentación del borrador: UML Guía Visual UML Guía Visual 03/09/01 9:03 Borrador en curso de revisión Evaluación de contenidos ref.- contacto: jvilalta@vico.org Josep Vilalta

Entorno de ingeniería del software o Framework de clases de análisis para definir mapas conceptuales o Framework de servicios comunes para la publicación dinámica de páginas HTML o Framework de certificación de entregables Entorno administrativo y de gestión o Plan Funcional para la implementación SAP-Contabilidad o Cuadro de control de indicadores de actividad y calidad o Sistema de información Ejecutivo

vi co .o rg
Entorno comercial o Merchandising de productos farmacéuticos o Subastas y liquidación de lotes Entorno de servicios o Auditorías Informáticas o Plan de Sistemas de Información general Entorno académico o Gestión de títulos universitarios académica
Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org Fecha actualización:

o Gestión de redes de puntos de venta con videoconferencia

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

o Programa de acceso a la universidad para mayores de 25 años o Estudios de tercer cliclo: diseño curricular, publicación y gestión

Revisión:

Página:

04/09/01 11:16

18

8 de 9

Proyecto: Documento: Historial: Situación: Proceso: Autor:

Presentación del borrador: UML Guía Visual UML Guía Visual 03/09/01 9:03 Borrador en curso de revisión Evaluación de contenidos ref.- contacto: jvilalta@vico.org Josep Vilalta

Entorno docente o Tutorías de proyectos de fin de carrera con UML o Cursos de Análisis, Diseño y Patrones o Talleres de introducción a UML o Talleres avanzados de UML con Rose y Visio o Talleres monográficos (Casos de Uso, Métrica, Metodología) Entorno de I+D o Bases de conocimiento con vocabularios controlados o Procesador de lenguaje natural dentro del dominio médico o Reconocimiento automático de conceptos clínicos a partir de textos no estructurados

Agradecimientos

En primer lugar a los clientes que con su confianza han permitido que pueda desarrollar mi carrera profesional. También a los autores antes mencionados por su valioso trabajo en el avance de la disciplina de la ingeniería del software y en la consolidación de UML como lingua franca.

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

vi co .o rg
Fecha actualización:

Dir.: C:\Mis documentos\TRAD CD Borrador\UML Guía Visual Presentación.doc Equipo: www.vico.org

Revisión:

Página:

04/09/01 11:16

18

9 de 9

1

Niveles de concepción y formalización de un proyecto
Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5

Nivel

ø
Use Case Use Case
Una ventana de introducción de pedidos Un pedido Una línea de pedido Un item de stock

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

M
jvilalta@vico.org

G
Actor << Communicates >> << Communicates >> Actor

<< Extends >> << Extends >>

Una ventana de introducción de pedidos
[tieneStock] nuevo

Un pedido

Una línea de pedido

Un item de stock

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

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

1

1

Cliente Corporativo
hacer / comprobación item

Cliente Personal Cliente Personal

: Pedido

Cliente Corporativo
hacer / comprobación item

* 0..1

xxx línea : Línea de pedido Pedido :

xxx stock : item de stock

<< Uses >> << Uses >>
xxx línea : Línea de pedido : Item de Expedición : Item de Pedido de reposición xxx stock : item de stock

* Línea de Pedido
hacer / comprobación

Comercial

* 0..1

* 1 * Línea de Pedido
hacer / comprobación

Producto

Comercial

: Item de Expedición

: Item de Pedido de reposición

*

1

Producto

© Vilalta Consultores 2001 - TRAD UMD_esp - Rev. 5.2 -

Matrícula del Proyecto

Glosario de Conceptos

Funcionalidad
Diagramas de Casos de Uso

Escenarios
Interacción de objetos

Clases
Análisis Diseño Implementación

“Code like hell”

PDI P

Procesos Principales

Especificación Casos de Uso

Flujos de Trabajo
Entrar
Reposición

Dinámica 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
Reposición

Entrar
Pedido
Seleccionar Pedidos Pendientes

Validar
Riesgo

Entrar
Reposición

*Seleccionarpedido seleccionado] [para cada Pedidos Pago

ionar primer item rimer item Verificando
hacer / comprobación 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

I te m od R o s e c ib lo id s it e o m s

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
hacer / comprobación item

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
Formalización Construcción Transición

PDP

2

Procesos
Actividades Entregables

Producto

Concepción

Misión
jvilalta@vico.org

Modelo Prototipo Componentes Certificación
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

3

P l a n D i re c t o r d e P ro y e c t o
Concepción

PDP

Concepción

Formalización

Construcción

Transición

Misión Modelo Prototipo Componentes Certificación
Iteraciones preliminares

Iter #1

Iter #2

Iter #n

Iter #n+1

Iter #n+2

Iter #n

Iter #n+1

Iteraciones

M

P

jvilalta@vico.org

Pedido

hacer / comprobación item

© Vilalta Consultores 2001 - TRAD PDP misión_esp2 - Rev. 5.2 -

P
* 1 Pedido * 1
hacer / comprobación item

Matrícula del proyecto
Cliente Cliente 1
hacer / comprobación

Procesos principales

hacer / comprobación

1

Cliente Corporativo Cliente Corporativo

Cliente Personal Cliente Personal

hacer / comprobación item

*

hacer / comprobación item

0..1 * Línea de Pedido
hacer / comprobación

Comercial

* 0..1

* 1 * Línea de Pedido
hacer / comprobación

Producto

Comercial

Misión
G
Glosario de Conceptos

Actor 1

<< Communicates >>

P
<<Incluye>> <<Generalización>>

Use Case Use Case Use Case << Extends >> <<Extiende >>

Use Case

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

Actor 2

Use Case

*

1

Producto

Patrones de Análisis

PDI P

Patrones de Funcionalidad

Cronograma Plan Director Iteraciones

Anteproyecto

4

PDP
P l a n D i re c t o r d e P ro y e c t o

Concepción

Formalización

Construcción

Transición

Misión Modelo Prototipo Componentes Certificación
Iteraciones preliminares

Iter #1

Iter #2

Iter #n

Iter #n+1

Iter #n+2

Iter #n

Iter #n+1

Iteraciones

Fo r m a l i z a c i ó n
Use Case Use Case << Extends >> << Extends >>
Una ventana de introducción de pedidos Un pedido Una línea de pedido Un item de stock

Cliente Pedido * 1
hacer / comprobación

Una ventana de introducción de pedidos
[tieneStock] nuevo

Un pedido

Una línea de pedido

Un item de stock

hacer / comprobación item

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

tieneStock:= comprobar ( )

1
[tieneStock] nuevo [tieneStock] nuevo [tieneStock] nuevo tieneStock:( )

1

Cliente Corporativo
hacer / comprobación item

Cliente Personal Cliente Personal

: Pedido

Actor << Communicates >> << Communicates >>
xxx línea : Línea de pedido Pedido :

Cliente Corporativo
hacer / comprobación item

*
xxx stock : item de stock

0..1 * Línea de Pedido Comercial * 0..1 * 1 * Línea de Pedido
hacer / comprobación

<< Uses >> << Uses >>
xxx línea : Línea de pedido : Item de Expedición : Item de Pedido de reposición xxx stock : item de stock

jvilalta@vico.org

hacer / comprobación

Producto

Comercial

Actor

: Item de Expedición

: Item de Pedido de reposición

*

1

Producto

Funcionalidad

Escenarios
Interacción de objetos

Clases
Análisis y Diseño
Pedido
hacer / comprobación item

© Vilalta Consultores 2001 - TRAD PDP modelo_esp2 - Rev. 5.3 -

Actor 1

<< Communicates >>

P
<<Incluye>> <<Generalización>>

Use Case Use Case Use Case << Extends >> <<Extiende >>

Diagramas de Casos de Uso

Use Case

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

Actor 2

Use Case

Modelo
Entrar
Reposición

P
* 1 Pedido * 1
hacer / comprobación item

Cliente

hacer / comprobación

Cliente 1
hacer / comprobación

1

Cliente Corporativo Cliente Corporativo

Cliente Personal Cliente Personal

hacer / comprobación item

*

hacer / comprobación item

0..1 * Línea de Pedido
hacer / comprobación

Comercial

* 0..1

* 1 * Línea de Pedido
hacer / comprobación

Producto

Comercial

*

1

Producto

Patrones de Funcionalidad
Entrar

Patrones de Análisis
Pedido

Entrar
Seleccionar Pedidos Pendientes

CU

Reposición

ionar primer item

Validar
Riesgo

[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

Entrar
Reposición

*Seleccionarpedido seleccionado] [para cada
Pedidos

ionar primer item rimer item Verificando
hacer / comprobación item rimer item Verificando hacer / comprobación item

Validar
Pago

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

I te m od R o s e c ib lo id s it e o m s

rimer item

[T

Entregado Entregado

Stock

Especificación Casos de Uso

Flujos de Trabajo

Dinámica Eventos Estados

d is

rimer item

po

n ib

le

Asignar Items

d is

rimer item

po

n ib

le

Asignar Items

* [para cada pedido seleccionado]

s]

s]

Entregado

Entregado

5

P l a n D i re c t o r d e P ro y e c t o
Construcción
Cliente Pedido
hacer / comprobación item

PDP

Concepción

Formalización

Construcción

Transición

Misión Modelo Prototipo Componentes Certificación
Iteraciones preliminares

Iter #1

Iter #2

Iter #n

Iter #n+1

Iter #n+2

Iter #n

Iter #n+1

Iteraciones

*

1

hacer / comprobación

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

1

*Acta
Destino

*Acta
Versión Fecha

Versión

Fecha

Año Académico Alumnos

Año Académico Alumnos

** Tribunal

Destino

** Tribunal

1

Cliente Corporativo
hacer / comprobación item

Cliente Personal Cliente Personal

Cliente Corporativo
hacer / comprobación item

*
Selección Selección

Alumno

P. Global

P. Esp.

Resultado

Ver

jvilalta@vico.org

Alumno

P. Global

P. Esp.

Resultado

Ver

0..1 * Línea de Pedido Comercial * 0..1 * 1 * Línea de Pedido
hacer / comprobación

Cliente Pedido
hacer / comprobación item

hacer / comprobación

Producto

Comercial

*

1

hacer / comprobación

*

1

Producto

1 Cliente Corporativo
hacer / comprobación item

Cliente Personal

* 0..1 * Línea de Pedido
hacer / comprobación

Comercial

Interface Gráfico de Usuario

Clases
Diseño Implementación
Pedido
hacer / comprobación item

*

1

Producto

© Vilalta Consultores 2001 - TRAD PDP construcción_esp2 - Rev. 5.3 -

Cliente * 1
hacer / comprobación

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

1

1

Cliente Corporativo
hacer / comprobación item

Componentes
Framework de Aplicaciones

*

0..1 * Línea de Pedido
hacer / comprobación

Comercial

* 1 * Línea de Pedido
hacer / comprobación

Producto

*

P
Cliente Personal Cliente Corporativo
hacer / comprobación item

Cliente Personal

*

0..1

Comercial

1

Producto

Patrones de Diseño

Base de Datos
Esquema de Persistencia

Arquitectura
Componentes

6

P l a n D i re c t o r d e P ro y e c t o

PDP

Concepción

Formalización

Construcción

Transición

Misión Modelo Prototipo Componentes Certificación
Iteraciones preliminares

Iter #1

Iter #2

Iter #n

Iter #n+1

Iter #n+2

Iter #n

Iter #n+1

Iteraciones

Concepción
Use Case

Fo r m a l i z a c i ó n
Use Case << Extends >> << Extends >>
Una ventana de introducción de pedidos Un pedido Una línea de pedido Un item de stock

Construcción
Cliente Pedido * 1
hacer / comprobación

Cliente Pedido
hacer / comprobación item

M

*

1

P
Actor Actor

hacer / comprobación

Una ventana de introducción de pedidos
[tieneStock] nuevo

Un pedido

Una línea de pedido

Un item de stock

hacer / comprobación item

Cliente Pedido
hacer / comprobación item

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

*

1

hacer / comprobación

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

1

1

1

Cliente Corporativo
hacer / comprobación item

Cliente Personal Cliente Personal

*Acta
Destino

Versión

Fecha

Año Académico Alumnos

** Tribunal

1

Cliente Corporativo
hacer / comprobación item

Cliente Personal Cliente Personal

: Pedido

Cliente Corporativo
hacer / comprobación item

Cliente Corporativo
hacer / comprobación item

<< Communicates >> << Communicates >>
xxx línea : Línea de pedido Pedido : xxx stock : item de stock

* 0..1 * Línea de Pedido

*
Selección

Alumno

P. Global

P. Esp.

Resultado

Ver

0..1 * Comercial * 0..1 * 1 * Línea de Pedido
hacer / comprobación

<< Uses >> << Uses >>
xxx línea : Línea de pedido : Item de Expedición : Item de Pedido de reposición xxx stock : item de stock

Comercial

* 0..1

Línea de Pedido
hacer / comprobación

hacer / comprobación

* 1 * Línea de Pedido
hacer / comprobación

Producto

Comercial

Producto

Comercial

: Item de Expedición

: Item de Pedido de reposición

*

1

*

1

Producto

Producto

jvilalta@vico.org

Matrícula del proyecto

Procesos principales

Funcionalidad
Diagramas de Casos de Uso

Escenarios
Interacción de objetos

Clases
Análisis y Diseño

Interface Gráfico de Usuario

Clases
Diseño Implementación

© Vilalta Consultores 2001 - TRAD PDP_esp2 - Rev. 6.2 -

Misión
G
Glosario de Conceptos

Modelo
Entrar
Reposición

Componentes
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

PDI P

Entrar

Entrar
Pedido
Seleccionar Pedidos Pendientes

CU

Reposición

Validar
Riesgo

Entrar
Reposición

*Seleccionarpedido seleccionado] [para cada Pedidos Pago

ionar primer item rimer item Verificando
hacer / comprobación 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

Cronograma Plan Director Iteraciones

Activar Pedido Activar Pedido

Regularizar StockRegularizar

Esperando

[T

I te m od R o s e c ib lo id s it e o m s

rimer item

[T

Entregado Entregado

Stock

Especificación Casos de Uso

Flujos de Trabajo

Anteproyecto

Dinámica Eventos Estados

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
hacer / comprobación item

s]

s]

Entregado

Entregado

Base de Datos
Esquema de Persistencia

Arquitectura
Componentes

¿ Cómo identificar Actores ?
Interacción de un Actor con el Sistema

1

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 Interacción del Sistema con un Actor

C lien te
- Role de us ua rio -

Relación que indica la especialización a partir de una función genérica

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 interactúa con el sistema No son parte del sistema que se desarrolla Entran información al sistema Reciben información del sistema Entran y reciben información

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 búsqueda de Actores.1. 2. 3. 4. ¿ Quien está interesado en un requerimiento concreto ? ¿ En qué dominios de la organización se usará el sistema ? ¿ Quien será beneficiario de la nueva funcionalidad ? ¿ Quien proveerá, usará y/o retirará, información ? ¿ Quien dará soporte y administrará el sistema ? ¿ Usará el sistema un recurso externo ? ¿ Un usuario actuará con diferentes roles ? ¿ Diferentes usuarios actuarán con un mismo rol ? ¿ Interaccionará el nuevo sistema con un sistema antiguo ?

Use Case

<< Extends >>

Actor << Communicates >> << Uses >> Actor

5. 6. 7.
Diagramas de Casos de Uso

Funcionalidad

8. 9.

¿ Cómo identificar Casos de Uso ?
Abr ir Arque o
Interacción de un Actor con el Sistema

2

<< Extiende >>
Relación que describe una variación 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 configuración

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

Relación que permite descomponer un Use Case con un determinado nivel de granularidad

<< Incluye >>
jvilalta@vico.org

<< Incluye >>

Relación 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 Interacción del Sistema con un Actor

© Vilalta Consultores 2001 - TRAD UCs_esp - Rev. 5.1 -

A la búsqueda de Casos de Uso.1.
Use Case

¿ Cuales son las tareas y responsabilidades de cada actor ? ¿ Algún actor creará, almacenará, cambiará, borrará o leerá información del sistema ? ¿ Qué Casos de Uso crearán, almacenarán, cambiarán, borrarán o leerán esta información ? ¿ 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 darán soporte y mantendrán el sistema ? ¿ Pueden ser realizados por los Casos de Uso todos los requerimientos funcionales documentados ?

2.
<< Extends >>

3. 4.

Actor << Communicates >> << Uses >> Actor

5. 6. 7.
Diagramas de Casos de Uso

Funcionalidad

Use Case

3
<< Extends >> << Uses >>

Actor << Communicates >>

Actor

Funcionalidad
Diagramas de Casos de Uso

Especificación 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 Día

<< Incluye >>

Casos de Uso secundarios

jvilalta@vico.org

Imprimir doc ume nto
Caso de Uso genérico

<<Generaliza>>

Imprimir tira de a rque o
Caso de Uso especializado

L I M I T

Límites: Cuando empieza y cómo termina el Caso de Uso. Interacciones: Comportamiento de Actores y Sistema. Acción-Reacción dentro del Caso de Uso. Masa: Conjunto de Objetos e Interfaces que requiere el Caso de Uso. Índice de escenarios: Flujo principal de eventos y secuencia de variaciones posibles dentro de un Caso de Uso. Tribulaciones: Contingencias probables que pueden afectar al flujo de los eventos y son excepciones del Caso de Uso.

© Vilalta Consultores 2001 - TRAD LIMIT UCs_esp - Rev. 5.1 -

Propósito
- Regla de Negocio -

Precondiciones
• • • • Arqueo abierto Actor habilitado TPV abierto TPV habilitado

Activación
• A discreción de un Actor habilitado

Flujo Principal
1. Sistema requiere confirmación de cierre de arqueo. 2. Sistema comprueba la configuración 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 teóricos para cada forma de cobro.

Excepciones

Cerrar un periodo de movimientos de caja para obtener una situación real de dinero en efectivo y en documentos.

3. Sistema calcula los totales teóricos para cada forma de cobro. 4. Actor introduce totales reales para cada forma de cobro. 5. Sistema registra el cierre: importes reales para cada forma de cobro y descuadres. 6. Sistema imprime el documento “Tira de Arqueo”.

a. Si el servidor está off-line, sistema informa al usuario, termina el UC manteniendo el arqueo abierto. a. Si impresora está off-line, sistema informa al usuario y le pide confirmación para continuar.

4

Ventajas del modelo Use Case
A brir A rque o << Extiende >> H ac e r un Ini c i o de Dí a

1. Lenguaje de comunicación entre usuarios y desarrolladores. 2. Comprensión detallada de la funcionalidad del sistema. 3. Acotación precisa de las habilitaciones de los usuarios. 4. Gestión de riesgo más eficiente para gobernar la complejidad. 5. Estimación más exacta para determinar tiempo, recursos y prioridades en la dosificación de esfuerzo de desarrollo. 6. Fiel trazabilidad para verificar la traducción de requerimientos en código ejecutable. 7. Mayor control para mantener las sucesivas revisiones de los programas.

<< Incluye >> Hac e r un Fin de Día

Importar nueva configuración

<< 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. Certificación contractual ClienteDesarrollador. 9. Documentación orientada al usuario: Helps - Manual de Procedimientos - Reglas de Negocio.

Use Case

<< Extends >>

Actor << Communicates >> << Uses >> Actor

Piezas de funcionalidad reutilizables en diferentes procesos de negocio

10. Documentación orientada al administrador 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.

qu Re

erimiento

s

No definen todos los requerimientos (por ej. los tipos de datos, interfaces externas, niveles de rendimiento esperado, etc.), pero representan el hilo conductor que vincula a todos los requerimientos posibles (actuales y futuros) de una aplicación.

ión

Funcionales, no funcionales e interfaces de usuario Funcionalidad, Análisis y Diseño

Reglas de Negocio y protocolos de intercambio de información Mapa conceptual: Clases de análisis

Mo

jvilalta@vico.org

Cer tif ic ac

delo

© Vilalta Consultores 2001 - TRAD Req y CUs_esp - Rev. 1.1 -

Implementación de código y Refactoring

Caso de Uso

Dinámica 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

a

Ge

n

Métrica: Escenarios de Escandallo de interacción recursos de objetos: y actividades Clases de diseño

sti

ur

Use Case

ó

<< Extends >>

Actor << Communicates >> << Uses >> Actor

Funcionalidad
Diagramas de Casos de Uso

CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su código de artículo, tipo de presentación y cantidad. 3. Sistema comprueba cada línea del pedido para validar la situación del artículo en catálogo y el número de items del artículo en stock.
a. Artículo NO está vigente en catálogo, sistema informa que articulo no está vigente y muestra artículos alternativos activando el CU Seleccionar artículo. b. SI existen suficientes items del artículo en el stock, sistema asigna items al pedido. c. NO existen suficientes items del artículo en stock, o la asignación de items deja la situación del artículo en stock por debajo del nivel de reposición, sistema genera pedido de reposición activando el CU Generar pedido.

Va r i a c i o n e s

Diagrama de Actividad
Notación UML 1.3

Recepción de un Pedido

Evento que desencadena la secuencia de actividades

Análisis textual del Caso de Uso

Identificar Cliente

Actividad

Entrar líneas pedido
Barra de sincronización Concurrencia dinámica de actividades

* [para cada línea de pedido]

4. Sistema comprueba la situación 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 artículo en stock, sistema aparca el pedido del cliente activando el CU Aparcar pedido. c. SI no se ha realizado el pago según el plazo convenido, sistema cancela el pedido.

Comprobar Pago

Comprobar Artículo
[NO vigente]

jvilalta@vico.org

Punto de decisión

Seleccionar Artículo alternativo

[SI vigente]

© Vilalta Consultores 2001 - TRAD Actividad 1_esp - Rev. 7.1 -

Descripción 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 fusión

[NO] [SI]

Asignar Items
[NO Stock] o [SI umbral reposición]

Generar reposición

Comprobar situación Pedido
[Todos los items asignados]

Condición lógica: verdadera o falsa, que permite la transición a otra actividad
Entrar
Pedido

Validar
Riesgo

Seleccionar
Pedidos

[Faltan items por asignar]

Validar
Pago

* [para cada pedido seleccionado]

Asignar Items

Servir Pedido

Aparcar Pedido

Activar Pedido

Regularizar

Stock

Flujos de Trabajo

CU Actualizar reposición
Flujo Principal 1. Usuario recepciona albaranes de reposición que ha enviado un proveedor. 2. Sistema localiza los pedidos de clientes aparcados que pueden cumplimentarse con la nueva entrada de items. 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 situación de items en stock y revisa los umbrales de reposición automática.
jvilalta@vico.org

Descripción de un Flujo de Trabajo
Recepción de una Reposición

2

Análisis textual del Caso de Uso

Una diagrama de actividad describe una secuencia de actividades que pueden exhibir un comportamiento en paralelo o estar sujetas a condiciones lógicas. Los procesos de negocio no muestran siempre una secuencia fija en su desarrollo, es una ventaja así poder modelar bloques de actividades sin restricciones de concurrencia.

Entrar Reposición

Buscar Pedidos aparcados

Diagrama de Actividad
Seleccionar Pedido
* [para cada pedido seleccionado]

Notación UML 1.3

© Vilalta Consultores 2001 - TRAD Actividad 2_esp - Rev. 5.2 -

Asignar Items

Transición de una actividad a otra sujeta 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 Pedido

Regularizar Stock
Fin de la secuencia de actividades

Validar
Pago

* [para cada pedido seleccionado]

Asignar Items

Activar Pedido

Regularizar

Stock

Flujos de Trabajo

Recepción de un Pedido Identificar Cliente

Descripción de un Flujo de Trabajo

3

Diagrama de Actividad
Notación UML 1.3

Entrar líneas 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.

* [para cada línea de pedido]

[Recepción de Reposición]

Comprobar Artículo Seleccionar Artículo alternativo Comprobar Pago
jvilalta@vico.org

Entrar Reposición

[NO vigente] [SI vigente]

Seleccionar Pedido
* [para cada pedido seleccionado]

Buscar Pedidos aparcados
Líneas para acotar áreas de responsabilidad (swim-lines)

Asignar Items
[NO éxito] [SI éxito]

© Vilalta Consultores 2001 - TRAD Actividad 3_esp - Rev. 6.1 -

Cancelar Pedido Generar reposición
[NO Stock] o [SI umbral reposición]

Regularizar Stock

Contabilidad

Comprobar situación Pedido

Comercial
[Todos las reposiciones entradas]

Almacén
Entrar
Pedido

Validar
Riesgo

Seleccionar
Pedidos

Validar
Pago

* [para cada pedido seleccionado]

Asignar Items

[Todos los items asignados]

[Faltan items por asignar]

Activar Pedido

Regularizar

Stock

Servir Pedido

Aparcar Pedido

Flujos de Trabajo

Descomposición de la actividad Comprobar Pago

Descripción de un Flujo de Trabajo

4

Diagrama de Actividad
Notación UML 1.3

Su objetivo no es relacionar actividad con objetos, sólo 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) 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 manera simultanea

Comprobar Pago

[Tarjeta de Crédito] [Factura]
jvilalta@vico.org

Autorización

Comprobar Cheque

[Cheque]

Comprobar Cliente habitual
[NO] [SI]

Importe > 150.000
[SI] [NO recibido]

NO éxito
[Efectivo] [NO éxito] [NO éxito]

© Vilalta Consultores 2001 - TRAD Actividad 4_esp - Rev. 5.2 -

Comprobar historial pagos
[SI éxito] [SI éxito] [NO éxito]

Pre-Pago requerido
[NO]

Comprobar Crédito
[NO éxito]

NO éxito
Entrar
Pedido

[SI éxito]
Validar
Riesgo

[SI éxito]

Seleccionar
Pedidos

Validar
Pago

* [para cada pedido seleccionado]

Abrir Cuenta Cliente

Asignar Items

SI éxito

Activar Pedido

Regularizar

Stock

Flujos de Trabajo

CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su código de artículo, tipo de presentación y cantidad. 3. Sistema comprueba cada línea del pedido para validar la situación del artículo en catálogo y el número de items del artículo en stock.
a. Artículo NO está vigente en catálogo, sistema informa que articulo no está vigente y muestra artículos alternativos activando el CU Seleccionar artículo. b. SI existen suficientes items del artículo en el stock, sistema asigna items al pedido. c. NO existen suficientes items del artículo en stock, o la asignación de items deja la situación del artículo en stock por debajo del nivel de reposición, sistema genera pedido de reposición activando el CU Generar pedido.

Va r i a c i o n e s

Descripción de un Escenario

1

Un escenario muestra de que manera interactúan los distintos objetos dentro del flujo principal de eventos de un Caso de Uso con alguna variación o extensión concreta del mismo. Utilizamos dos diagramas de interacción: a/. Secuencia b/. Colaboración Su finalidad es describir los mensajes que intercambian los distintos objetos para cumplir con las responsabilidades definidas en un escenario concreto de un Caso de Uso. • 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.

Análisis textual del Use Case

Objetos que interactúan

jvilalta@vico.org

: C o m erci al

:Una Ventana de introducción de Pedidos

:Un Pedido

:Una Línea de Pedido

:Una Cartera de Items en Stock

1:indentificarCliente ( ) 2:generarPedido ( ) 3:entrarLíneaPedido ( ) 4:generarLíneaPedido ( ) 5:comprobarStock ( ) Auto-mensaje 7:realizarReposición ( )

© Vilalta Consultores 2001 - TRAD Secuencia_esp - Rev. 6.1 -

Estos mensajes muestran el nivel de colaboración entre los distintos objetos existentes e indican cuando se requiere generar nuevos objetos para cumplir con las responsabilidades asignadas.

6:asignarItems ( )
(1)

Mensaje Línea de vida de un objeto durante la interacción

Creación de un nuevo objeto

8:generarReposición ( )

:Un Pedido de Reposición

Una ventana de introducción de pedidos

Un pedido

Una línea de pedido

Un item de stock

[tieneStock] nuevo [tieneStock] nuevo tieneStock:( )

: Pedido

xxx línea : Línea de pedido xxx stock : item de stock

Diagrama de Secuencia
Notación UML 1.3

: Item de Expedición

: Item de Pedido de reposición

Escenarios

CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su código de artículo, tipo de presentación y cantidad. 3. Sistema comprueba cada línea del pedido para validar la situación del artículo en catálogo y el número de items del artículo en stock.
a. Artículo NO está vigente en catálogo, sistema informa que articulo no está vigente y muestra artículos alternativos activando el CU Seleccionar artículo. b. SI existen suficientes items del artículo en el stock, sistema asigna items al pedido. c. NO existen suficientes items del artículo en stock, o la asignación de items deja la situación del artículo en stock por debajo del nivel de reposición, sistema genera pedido de reposición activando el CU Generar pedido.

Va r i a c i o n e s

Descripción de un Escenario

2

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 interacción: a/. Secuencia b/. Colaboración Su finalidad es describir los mensajes que intercambian los distintos objetos para cumplir con las responsabilidades definidas en un escenario concreto de un Caso de Uso. • Diagrama de colaboración.- Representa una

Análisis textual del Use Case

Objeto
(Instancia de una Clase)
jvilalta@vico.org

: Comercial
1: identificarCliente ( ) 3: entrarLíneaPedido ( )

Número de secuencia

posible interacción de los objetos ordenados a partir de la topología que muestra el envio de sus mensajes.
(1) Mensajes enviados entre los objetos descritos en
el flujo de eventos de un Caso de Uso.

© Vilalta Consultores 2001 - TRAD Colaboración_esp - Rev. 6.1 -

4: generarLíneaPedido ( )

: Una Ventana de introducción de Pedidos
Enlace entre dos objetos 2: generarPedido ( ) Mensaje (1)

: Una Línea de Pedido
5: comprobarStock ( ) 6: asignarItems ( )

Estos mensajes muestran el nivel de colaboración entre los distintos objetos existentes e indican cuando se requiere generar nuevos objetos para cumplir con las responsabilidades asignadas.

Auto-mensaje

: Un Pedido
Dirección del mensaje

7: realizarReposición ( )

:Una Cartera de Items en Stock
Una ventana de introducción de pedidos Un pedido Una línea de pedido Un item de stock
[tieneStock] nuevo [tieneStock] nuevo

8: generarReposición ( )

tieneStock:( )

: Pedido

xxx línea : Línea de pedido

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

xxx stock : item de stock

: Item de Expedición

: Item de Pedido de reposición

Escenarios

Clases
Desde una perspectiva conceptual, una Clase representa un conjunto de Objetos que comparten: • Las mismas propiedades (Atributos) • El mismo comportamiento (Métodos) • Las mismas relaciones con otros Objetos (Mensajes) • La misma semántica dentro del sistema Desde una perspectiva física, una Clase es una pieza de software que actua como un molde para fabricar tipos particulares de objetos que disponen de los mismos atributos y métodos. Estos elementos que configuran cada tipo de objeto sólo se definen una vez, cuando especificamos la estructura de la Clase a la que pertenecen.
jvilalta@vico.org

Cliente Pedido
FechaRecibido ConPrepago Número Importe Divisa ... seleccionar ( ) comprobar ( ) servir ( ) cerrar ( ) ...

1

*

1

Nombre Direccion valorarCredito( ): string

1 Cliente Corporativo
NombreContacto ValoracionCredito LimiteCredito facturarMes( ) recordar( )

Cliente Personal
NumTargetaCredito

* 0..1 * Línea de Pedido
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).

*

1

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 abstracción o algo que dispone de unos límites bien definidos y tiene una significación para el sistema que se pretende modelar. Estructura y función: • Identidad ¿Quien soy? = Atributos • Propósito ¿Cual es mi misión? = Justificación • Responsabilidades ¿Qué debo hacer? = Métodos • Procedencia ¿De qué Clase provengo? = Origen • Relaciones ¿Qué mensajes entiendo? = Comportamiento

Diagrama de Clases
Notación UML 1.3

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

1 Cliente Corporativo
hacer / comprobación item

Cliente Personal

* 0..1 * Línea de Pedido
hacer / comprobación

Comercial

*

1

Producto

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

© Vilalta Consultores 2001 - TRAD Clases 2_esp - Rev. 3.1 -

m

o od ét

1

Atributos
do to é 3

ét m od o 2

m o od ét 4
m

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

1 Cliente Corporativo
hacer / comprobación item

Cliente Personal

* 0..1 * Línea de Pedido
hacer / comprobación

Comercial

*

1

Producto

Clases

Objeto
¿Quien soy?

3

Todo lo que un objeto “conoce” está representado en sus atributos (variables y estado actual), y todo lo que puede “realizar” está definido en sus métodos (comportamiento), y en sus “interacciones” con otros objetos a través del intercambio de mensajes (dinámica del ciclo de vida).

Vehículo Automático 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

© Vilalta Consultores 2001 - TRAD Clases 3_esp - Rev. 2.2 -

b

¿Qué conozco?

a

Variables.• • • • • Identificación Medidas de la carga Capacidad de carga Velocidad máxima Tipo de carga

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

Estado.• Localización • Orientación • Velocidad

1 Cliente Corporativo
hacer / comprobación item

Cliente Personal

* 0..1 * Línea de Pedido
hacer / comprobación

Comercial

*

1

Producto

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
jvilalta@vico.org

vacp104

© Vilalta Consultores 2001 - TRAD Clases 4_esp - Rev. 1.2 -

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 / comprobación item

*

1

hacer / comprobación

1 Cliente Corporativo
hacer / comprobación item

Cliente Personal

Objeto Receptor

* 0..1 * Línea de Pedido
hacer / comprobación

Comercial

*

1

Producto

Clases

Encapsulación
Interface de mensajes

5

El empaquetado de métodos y atributos dentro de un objeto mediante una interface de mensajes, es lo que denominamos encapsulación. La clave está precisamente en este envoltorio del objeto. La interface que rodea por completo al objeto actúa como punto de contacto para todos los mensajes que llegan desde cualquier objeto emisor. 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.
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 métodos escondidos dentro de la interface de mensajes de otro objeto.

er ac H ia

© Vilalta Consultores 2001 - TRAD Clases 5_esp - Rev. 3.1 -

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 / comprobación item

*

1

hacer / comprobación

Mensaje

1 Cliente Corporativo
hacer / comprobación item

Cliente Personal

* 0..1 * Línea de Pedido
hacer / comprobación

Comercial

*

1

vacp104

Producto

Clases

Herencia
Es el mecanismo por el cual una clase de objetos puede ser definida como un caso especial de otra clase más genérica. Los casos especiales de una clase se denominan Subclases. La clase más genérica, se conoce como la Superclase de todos sus casos especiales. Además de los métodos y atributos que heredan, las Subclases definen sus propios métodos y atributos. Tambien, pueden redefinir algunos de los heredados (overriding).

6
La interface de mensajes definida para una Superclase también es heredada por las subclases. Esto implica que todas las Subclases de una Superclase estan preparadas para responder correctamente a los mismos mensajes que la Clase padre. Esta propiedad es extremadamente útil porque nos permite tratar de la misma manera a todas las especializaciones de una Clase.

Vehículo Automático de Carga

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

Vehículo Automático Carga Palets

Vehículo Automático Carga Bobinas

© Vilalta Consultores 2001 - TRAD Clases 6_esp - Rev. 1.2 -

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 Métodos
a
Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

Atributos
or af at m

Atributos

1 Cliente Corporativo
hacer / comprobación item

ev el ar or af at Pl

Cliente Personal

Instancias de Vehículo Automático Carga Palets

ba

ja

l rP

* 0..1 * Línea de Pedido
hacer / comprobación

vacp 104

m a

Comercial

*

1

Producto

Identificador del objeto

Clases

Composición
Los objetos que contienen a otros objetos se denominan Objetos Compuestos. Los atributos de un objeto pueden utilizarse de dos maneras. Podemos usarlos para almacenar valores como el número 15, o bien, el texto “Autorizado”.

7
También pueden contener referencias de otros objetos. Las referencias almacenadas en los atributos de un objeto compuesto, permite a este objeto enviar los mensajes apropiados a todos los objetos contenidos.

Ventana Wizard
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

© Vilalta Consultores 2001 - TRAD Clases 7_esp - Rev. 2.1 -

Scroll Botones de ventana
Restore Help
?

Maximize Minimize

Combo box List box

Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

1 Cliente Corporativo
hacer / comprobación item

Cliente Personal

* 0..1 * Línea de Pedido
hacer / comprobación

Close

Comercial

*

1

Producto

Clases

Polimorfismo
Vehículo Automático de Carga

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. 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. El mismo mensaje cargarItem, acompañado del parámetro que identifica dicho item, será intrepretado de distinta manera por cada objeto receptor, el cual ya conoce previamente como tiene que tratar la naturaleza de su carga: bobinas, palets, etc. Hay una reducción de esfuerzo muy significativa por el hecho de que cualquier objeto del sistema puede enviar mensajes a los vehículos automáticos de carga sin necesidad de saber de antemano qué tipo de vehículos estan en circulación. No hay necesidad así de picar un código específico para cada tipo de vehículo, con lo cual, nos ahorramos prolijas sentencias IF o CASE que son complejas de mantener y de actualizar cuando se incorporan nuevos tipos de objetos.

SuperClase

© Vilalta Consultores 2001 - TRAD Clases 8_esp - Rev. 1.1 -

jvilalta@vico.org

Vehículo Automático Carga Bobinas

Vehículo Automático Carga Palets

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 / comprobación item

*

1

hacer / comprobación

Mensaje

1 Cliente Corporativo
hacer / comprobación item

Cliente Personal

* 0..1 * Línea de Pedido
hacer / comprobación

Comercial

*

1

Producto

Clases

Cliente Pedido
- fechaRecibido conPrepago - número: Alfanúm. - importe: Núm&2d. - divisa ... + crear () + seleccionar ( ) + comprobar ( ) + servir ( ) + cerrar ( )

*

1
+ hacer / comprobación

Visibilidad
Cliente Personal

9

1 Cliente Corporativo

•Toda Clase encapsula unos elementos (atributos y operaciones) que disponen de ciertos criterios de visibilidad y manipulación para otras Clases. •Los elementos públicos pueden ser usados por cualquier otra Clase. •Los elementos privados pueden ser usados sólo por la Clase propietaria. •Cada plataforma de desarrollo (C++, Smalltalk, Java) desarrolla sus propias reglas con respecto a la visibilidad y manipulación de atributos y operaciones. •La notación UML especifica que todo atributo y operación de una Clase ha de disponer de un indicador de visibilidad. 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 sólo puede ser usado por la Clase que lo define. Un elemento puede ser usado por subclases y también por cualquier otra Clase en el mismo Package como la Clase propietaria. Esto implica que en Java, el concepto de visibilidad protegida es más público que package. Un elemento sólo puede ser usado por otras Clases que compartan el mismo Package.
Consideremos la Clase CLIENTE que dispone de una subclase CLIENTE PERSONAL. Consideremos también que el objeto <<Josep V.>>, es una instancia de CLIENTE PERSONAL. <<Josep V.>> • Puede usar todo elemento público de cualquier objeto del sistema. • Puede usar también todo elemento privado de la Clase CLIENTE PERSONAL. • No puede usar los elementos privados definidos en la Clase CLIENTE. • Puede usar los elementos protegidos definidos para CLIENTE y CLIENTE PERSONAL. 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 sólo a los elementos públicos de otro objeto. En Smalltalk, <<Miquel M.>>, no puede acceder a las variables instanciadas privadas de <<Josep V.>>, sólo a sus operaciones públicas. Java permite marcar también las Clases como públicas o packages. Los elementos de una Clase pública pueden ser usados por cualquier Clase que importe el package a la que pertenece la Clase. Los elementos de una Clase package sólo pueden ser usados por otras Clases del mismo package.

+ hacer / comprobación 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 públicas por defecto. modificado por cualquier objeto del sistema. Un elemento sólo puede ser usado por la Clase que lo define. Un elemento sólo puede ser usado por la Clase que lo define, o por las subclases de dicha Clase. Todas las variables instanciadas son privadas.

Comercial

Línea de Pedido
+ hacer / comprobación

*

1

Producto

# Protegida

© Vilalta Consultores 2001 - TRAD Clases visibilidad_esp - Rev. 5.3 -

Package
Cliente Pedido
hacer / comprobación item

*

1

hacer / comprobación

1 Cliente Corporativo
hacer / comprobación item

Ejemplos
Cliente Personal

* 0..1 * Línea de Pedido
hacer / comprobación

Comercial

*

1

Producto

Clases

Consideremos la instancia de CLIENTE PERSONAL, <<Miquel M.>>, este objeto puede acceder a cualquier elemento de <<Josep V.>>, que ha sido definido también como una instancia de CLIENTE PERSONAL, sea público, privado o protegido. <<Miquel M.>>, a su vez también puede acceder a cualquier elemento privado, protegido o público de <<Josep V.>>

CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su código de artículo, tipo de presentación y cantidad. 3. Sistema comprueba cada línea del pedido para validar la situación del artículo en catálogo y el número de items del artículo en stock.
a. Artículo NO está vigente en catálogo, sistema informa que articulo no está vigente y muestra artículos alternativos activando el CU Seleccionar artículo. b. SI existen suficientes items del artículo en el stock, sistema asigna items al pedido. c. NO existen suficientes items del artículo en stock, o la asignación de items deja la situación del artículo en stock por debajo del nivel de reposición, sistema genera pedido de reposición activando el CU Generar pedido.

Va r i a c i o n e s

Descripción de la Dinámica del Sistema
La dinámica de un sistema está determinada por: • Todas las posibles secuencias de eventos que pueden ocurrir.

1

• Todos los posibles estados que sus objetos pueden tener.

Análisis textual del Use Case

• Todas las transiciones posibles, de un estado a otro, como consecuencia de los eventos que afectan a los objetos.

4. Sistema comprueba la situación 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 artículo en stock, sistema aparca el pedido del cliente activando el CU Aparcar pedido. c. SI no se ha realizado el pago según el plazo convenido, sistema cancela el pedido.

jvilalta@vico.org

Diagrama de Estados de un Pedido
Notación UML 1.3

© Vilalta Consultores 2001 - TRAD Dinámica 1_esp - Rev. 5.1 -

Pedido
fechaRecibido conPrepago número: Alfanúm. importe: Núm&2d. divisa ... seleccionar ( ) comprobar ( ) servir ( ) cerrar ( ) ...

*
1

/seleccionar primer item
2

[No todos los items comprobados] /seleccionar siguiente item

Comprobando
hacer / comprobación item

[Todos los items comprobados && Sirviendo todos los items disponibles]
hacer / inicio de entregas

ib

3

le

s]

1
ionar primer item [Todos los items comprobados && todos los items disponibles] rimer item

Verificando
hacer / comprobación item

Sirviendo
hacer / inicio de entregas

5 4

rimer item

[T

I te m od R o s e c ib lo id s it e o m s

d is

rimer item

Entregado

Esperando

Entregado

Dinámica 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

6

on

Pedido Entregado

po

n ib

le

s]

di

Entregado

CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su código de artículo, tipo de presentación y cantidad. 3. Sistema comprueba cada línea del pedido para validar la situación del artículo en catálogo y el número de items del artículo en stock.
a. Artículo NO está vigente en catálogo, sistema informa que articulo no está vigente y muestra artículos alternativos activando el CU Seleccionar artículo. b. SI existen suficientes items del artículo en el stock, sistema asigna items al pedido. c. NO existen suficientes items del artículo en stock, o la asignación de items deja la situación del artículo en stock por debajo del nivel de reposición, sistema genera pedido de reposición activando el CU Generar pedido.

Va r i a c i o n e s

Descripción de la Dinámica del Sistema

2

Utilizamos el diagrama de estados para describir el comportamiento de una Clase dentro de una serie temporal.

Análisis textual del Use Case

Clase
jvilalta@vico.org

Pedido
fechaRecibido conPrepago número: Alfanúm. importe: Núm&2d. divisa ... seleccionar ( ) comprobar ( ) servir ( ) cerrar ( ) ...

Inicio

Diagrama de Estados de un Pedido
Notación UML 1.3

*
primera Transición

Atributos Operaciones

/seleccionar primer item Acción Indicador [No todos los items comprobados] /seleccionar siguiente item Acción
1 3

Estado
2

© Vilalta Consultores 2001 - TRAD Dinámica 2_esp - Rev.- 5.1 -

1
Sintaxis para etiquetar una transición Evento [Indicador] / Acción

Comprobando
hacer / comprobación item

[Todos los items comprobados && Sirviendo todos los items disponibles]
hacer / inicio de entregas

Actividad

le

s]

/ Acción

Transición
4

Procesos que ocurren de manera rápida dentro de un ciclo contínuo sin interrupción.

5

Auto-Transición Item Recibido [algunos items no estan disponibles en stock]

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]

di

sp

on

Los tres elementos son opcionales

Evento Pedido Entregado

6

Desencadena siempre la Transición

ib

ionar primer item

Esperando

[Todos los items comprobados && todos los items disponibles]

Entregado

rimer item

Verificando
hacer / comprobación item

Sirviendo
hacer / inicio de entregas

rimer item

Esperando

[T

I te m od R o s e c ib lo id s it e o m s

d is

rimer item

po

n ib

le

s]

Entregado

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”. Sólo podemos extraer una Transición para un Estado concreto.

Dinámica Estados

CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su código de artículo, tipo de presentación y cantidad. 3. Sistema comprueba cada línea del pedido para validar la situación del artículo en catálogo y el número de items del artículo en stock.
a. Artículo NO está vigente en catálogo, sistema informa que articulo no está vigente y muestra artículos alternativos activando el CU Seleccionar artículo. b. SI existen suficientes items del artículo en el stock, sistema asigna items al pedido. c. NO existen suficientes items del artículo en stock, o la asignación de items deja la situación del artículo en stock por debajo del nivel de reposición, sistema genera pedido de reposición activando el CU Generar pedido.

Va r i a c i o n e s

Descripción de la Dinámica del Sistema

3

Construimos el diagrama de estados a partir de una clase concreta para mostrar el comportamiento de un objeto durante su ciclo de vida.

Análisis textual del Use Case

Diagrama de Estados 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 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 Transición

Clase
jvilalta@vico.org

Pedido
fechaRecibido conPrepago número: Alfanúm. importe: Núm&2d. divisa ... seleccionar ( ) comprobar ( ) servir ( ) cerrar ( ) ...

Inicio

*
primera Transición

Atributos Operaciones

/seleccionar primer item Acción Indicador [No todos los items comprobados] /seleccionar siguiente item Acción
1 3

Estado
2

© Vilalta Consultores 2001 - TRAD Dinámica 3_esp - Rev. 5.1 -

Implementación

1
Sintaxis para etiquetar una transición Evento [Indicador] / Acción
Los tres elementos son opcionales

Comprobando
hacer / comprobación item

[Todos los items comprobados && Sirviendo todos los items disponibles]
hacer / inicio de entregas

Actividad
Desencadena siempre la Transición

le

s]

/ Acción

Transición
4

Procesos que ocurren de manera rápida dentro de un ciclo contínuo sin interrupción.

5

Auto-Transición

/ Actividad

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]

Evento Pedido Entregado

di

sp

on

6

ib

ionar primer item

Estado

rimer item

[Indicador]

Transición
No hay Actividades para este Estado, por lo que el Pedido permanecerá a la espera de un Evento.

Transición

Esperando

[T

I te m od R o s e c ib lo id s it e o m s

Procesos que ocurren dentro de un ciclo discontínuo y pueden ser interrumpidospor algun evento.

Item Recibido [algunos items no estan disponibles en stock]

Esperando

Entregado

[Todos los items comprobados && todos los items disponibles]

rimer item

Verificando
hacer / comprobación item

Sirviendo
hacer / inicio de entregas

d is

rimer item

po

n ib

le

s]

Entregado

Entregado

Condición lógica con dos categorias: “verdadero” o “falso”. Una Transición con [Indicador] sólo ocurre si este es “verdadero”. Sólo podemos extraer una Transición para un Estado concreto.

Dinámica Estados

CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su código de artículo, tipo de presentación y cantidad. 3. Sistema comprueba cada línea del pedido para validar la situación del artículo en catálogo y el número de items del artículo en stock.
a. Artículo NO está vigente en catálogo, sistema informa que articulo no está vigente y muestra artículos alternativos activando el CU Seleccionar artículo. b. SI existen suficientes items del artículo en el stock, sistema asigna items al pedido. c. NO existen suficientes items del artículo en stock, o la asignación de items deja la situación del artículo en stock por debajo del nivel de reposición, sistema genera pedido de reposición activando el CU Generar pedido.

Va r i a c i o n e s

Descripción de la Dinámica del Sistema
Sólo podemos conocer que un Evento ha ocurrido, detectando sus “efectos” en nuestro modelo.

4

Un Evento no es un objeto. Un Evento es la “causa” que justifica la existencia de una información.

Análisis textual del Use Case

Sólo 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 / comprobación item 3 hacer / inicio de entregas

It [T em od R os eci lo bid s ite o m s

© Vilalta Consultores 2001 - TRAD Dinámica 4_esp - Rev. 5.1 -

[No todos los items comprobados] /seleccionar Comprobando siguiente item
hacer / comprobación item

2

[Todos los items comprobados && Sirviendo todos los items disponibles]
hacer / inicio de entregas

[Todos los items comprobados && algunos items no estan disponibles en stock]
4

sp

on

1

/seleccionar primer item

ib

Activo

Pedido Cancelado

le
6

di

5

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]
4

sp

on

ib

le

s]

3

Item Recibido [algunos items Esperando no estan disponibles en stock] Pedido Cancelado

Pedido Cancelado

s]

Pedido Entregado

Entregado

di

Cancelado

5

sin Superestados
6

Item Recibido [algunos items Esperando no estan disponibles en stock] Pedido Cancelado

Pedido Entregado

Diagrama de Estados con Superestados
Notación UML 1.3

ionar primer item

[Todos los items comprobados && todos los items disponibles]

rimer item

Verificando
hacer / comprobación item

Sirviendo
hacer / inicio de entregas

rimer item

Esperando

[T

I te m od R o s e c ib lo id s it e o m s

d is

rimer item

po

n ib

le

s]

Entregado

Entregado

Cancelado

Entregado

Dinámica Estados

CU Realizar pedido
Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su código de artículo, tipo de presentación y cantidad. 3. Sistema comprueba cada línea del pedido para validar la situación del artículo...
a. Artículo NO está vigente en catálogo, sistema informa que articulo no está vigente y muestra... b. SI existen suficientes items... c. NO existen suficientes items...

Va r i a c i o n e s

Descripción de la Dinámica del Sistema

5

Los diagramas de estados son muy útiles para describir el comportamiento de un objeto a través de múltiples Casos de Uso.

Análisis textual del Use Case

4. Sistema comprueba la situación 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 artículo en stock, sistema aparca el pedido del cliente activando el CU Aparcar pedido. c. SI no se ha realizado el pago según el plazo convenido, sistema cancela el pedido.

Autorizando
hacer / comprobación del pago

[pago NO correcto]

jvilalta@vico.org

[pago SI correcto]

Esperando Cancelado
Pedido Cancelado

© Vilalta Consultores 2001 - TRAD Dinámica 5_esp - Rev. 5.1 -

Autorizado

Rechazado

Comprobando

Sirviendo

Entregado
Pedido Entregado

Entregado

Autorizando

Autorizado

ionar primer item

[Todos los items comprobados && todos los items disponibles]

rimer item

Verificando
hacer / comprobación item

Sirviendo
hacer / inicio de entregas

Rechazado
Pedido Rechazado

Diagrama de Estados Concurrentes
Notación UML 1.3

rimer item

Esperando

[T

I te m od R o s e c ib lo id s it e o m s

d is

rimer item

po

n ib

le

s]

Entregado

Entregado

Dinámica Estados

Arquitectura del sistema

1

Una Arquitectura es un conjunto organizado de elementos. Se utiliza para especificar las decisiones estratégicas acerca de la estructura y funcionalidad del sistema, las colaboraciones entre sus distintos elementos y su despliegue físico para cumplir unas responsabilidades bien definidas.

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
Implementación Ejecutables
Vista de

Distribución Física Elementos

Vista de

Vista de la Arquitectura 4+1
Notación UML 1.3

Arquitectura

Modelo de Referencia

Vista del

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 Vista del • Asociaciones • Agregaciones • Generalización • Packages
Pedidos Clientes

Modelo de Referencia

Cliente
jvilalta@vico.org

El Modelo de Referencia se construye en sucesivas iteraciones durante la fase de Formalización. Las Clases y Packages del modelo reflejan las decisiones tomadas con respecto a los “mecanismos clave” del sistema. Una eficiente implementación de los “mecanismos clave” requiere seleccionar Patrones (Patterns) que se ajusten a los requerimientos esenciales del proyecto. La implementación de “mecanismos clave” requiere seleccionar también: • Lenguaje de programación • Motor de Base de Datos • Interface gráfico de usuario “look and feel” • Tratamiento de errores • Mecanismos de comunicación • Migración y distribución de objetos • Networking

Pedido
fechaRecibido conPrepago número: Alfanúm. importe: Núm&2d. divisa ... seleccionar ( ) comprobar ( ) servir ( ) cerrar ( ) ...

*

1
hacer / comprobación

Artículos

© Vilalta Consultores 2001 - TRAD Arquitectura 2_esp - Rev. 5.1 -

1 Cliente Corporativo

Cliente Personal

hacer / comprobación item

* 0..1 * Línea de Pedido
hacer / comprobación

Comercial

*

1

Producto

Arquitectura

Arquitectura del sistema
Modelo de Referencia
Vista del

3

Componentes Modulares

Vista de

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. • Componentes: En esta vista representan la organización de módulos de código fuente.

Componentes Modulares

Vista de

jvilalta@vico.org

Los Packages estan organizados en una jerarquía de capas que disponen de una interface bien definida:

Pe d i d o

© Vilalta Consultores 2001 - TRAD Arquitectura 3_esp - Rev. 5.1 -

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

Información Artículos Dominio

Pedidos Los Packages de la vista lógica del modelo estan mapeados con los Packages físicos y los componentes de software (subsistemas).

Clientes

Artículos

Arquitectura

Arquitectura del sistema
Modelo de Referencia
Vista del

4

Componentes Modulares

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 • Sincronización

Implementación Ejecutables

Vista de

Implementación Ejecutables

Vista de

• Administración 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 librerías de tipo ActiveX, Applets de Java y librerías dinámicas. Los componentes ejecutables muestran sus interfaces y niveles de dependencia dentro de la aplicación. Dominio

Entrada Pedidos
Aplicación

Mailing
Aplicación

© Vilalta Consultores 2001 - TRAD Arquitectura 4_esp - Rev. 5.1 -

Pedidos

Clientes

P e d i d o s . exe Artículos.dll

Artículos

Oracle

Expedición.dll Clientes.dll

Base de Datos
Interface global

Interface

Ingres
Interface

Arquitectura

Arquitectura del sistema
Modelo de Referencia
Vista del

5

Componentes Modulares

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 distribución muestran el despliegue de nodos (locales y remotos), en la organización de la empresa. Permite al equipo de desarrollo comprender mejor la topología de un sistema distribuido.
TCP/IP Servidor Contabilidad :Base de Datos :Base de Datos Servidor Área Comercial :Contabilidad

Implementación Ejecutables

Vista de

Distribución Física Elementos

Vista de

Distribución Física Elementos
jvilalta@vico.org

Vista de

Un Nodo es un objeto físico run-time que representa un recurso informático. Este recurso, generalmente dispone de datos persistentes y capacidad de proceso. En la mayoría de los casos un Nodo puede representar una pieza de hardware, desde un periférico a un servidor. Las Conexiones entre Nodos muestran las líneas de comunicación con las que el sistema tendrá que interactuar. Los Componentes, en un diagrama de distribución, representan los módulos físicos de código, los cuales, se corresponden con los Packages de ejecutables. De esta manera, el diagrama muestra donde corre cada Package en el sistema. Las Dependencias muestran cómo los componentes se comunican con otros componentes. La dirección de una Dependencia concreta, indica el conocimiento en la comunicación.
Conexión :GUI Comercial Componente

© Vilalta Consultores 2001 - TRAD Arquitectura 5_esp - Rev. 5.1 -

:Comercial Configuración :Servidor Aplicaciones :Usuarios Nodos

TCP/IP Cliente Win95 :Cliente Comercial Interface

Arquitectura

Arquitectura del sistema
Modelo de Referencia
Vista de la Vista del

6

Componentes Modulares

Vista de

Esta vista certifica la validez de: • Modelo de Referencia • Componentes modulares de software

Funcionalidad
Use Cases
Implementación Ejecutables
Vista de

Distribución Física Elementos

Vista de

• 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
Supervisor

<< Inclu >>

Importar nueva configuración

• Diagramas de Interacción (Escenarios) • Diagramas de Actividad (Flujos de Trabajo) • Diagramas de Estados (Dinámica)

jvilalta@vico.org

Cajero
Cerrar Arqueo << Ext >>

Hacer un Fin de Día << Inclu >>

<< Inclu >>

Imprimir documento

Exportar movimientos

Contabilidad

© Vilalta Consultores 2001 - TRAD Arquitectura 6_esp - Rev. 5.1 -

Recepción de un Pedido

Preparar Pedido

CU Realizar pedido
* [para cada línea de pedido]

Flujo Principal 1. Usuario identifica el cliente que ha enviado un pedido. 2. Usuario entra lineas de pedido, con su código de artículo, tipo de presentación y cantidad.
Una ventana de introducción de pedidos Un pedido Una línea de pedido Un item de stock

Va r i a c i o n e s
Cancelar Pedido

[NO éxito] Comprobar Comprobar

Pago
[en stock] [SI éxito]

Items

Asignar Items
[Requiere reposición]

3. Sistema comprueba cada línea del pedido para validar la situación del artículo en catálogo y el número de items del artículo en stock.

a. Artículo NO está vigente en catálogo, sistema informa que articulo no está vigente y muestra artículos alternativos activando el CU Seleccionar artículo. b. SI existen suficientes items del artículo 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 artículo en stock, o la asignación de items deja la situación del artículo en stock por debajo del nivel de reposición, sistema genera pedido de reposición activando el CU Generar pedido.

ionar primer item

[Todos los items comprobados && todos los items disponibles]

rimer item

Verificando
hacer / comprobación item

Sirviendo
hacer / inicio de entregas

sp

rimer item

on

ib

le

s]

rimer item

[tieneStock] nuevo

It [T em od R os eci lo bid s ite o m s

di

Entregado

Esperando

Entregado

Arquitectura

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->