lenguaje unificado

UMLGuía Visual

C ó m o c r e a rf o r m a s d e v i d a

o r g a n i z a t i v a

© Vi l a l t a C o n s u l t o r e s 2 0 0 1

i n f o @ v i c o . o r gR e v. 0 . 1 7 Josep V i la l ta

vico.o

rg

Proyecto: Presentación del borrador: UML Guía Visual Documento: UML Guía Visual Historial: 03/09/01 9:03 Situación: Borrador en curso de revisión Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta

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

Fecha actualización:

04/09/01 11:16 Revisión:

18 Página:

1 de 9

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.

vico.o

rg




04/09/01 11:16 Revisión:

18 Página:

2 de 9

Nuestros límites para entender esta realidad están en nuestro lenguaje. El mundo es la

suma total de lo que podemos definir, organizar y visualizar. Cabe preguntarse ¿de qué

manera un modelo en UML representa nuestra experiencia?. Enseñar a utilizar un

lenguaje formal siempre es problemático. Es necesario mostrar como este lenguaje

puede ser aplicado a la realidad tal como la conocemos y tal como la compartimos con

los demás. Con esta guía visual mostramos de manera precisa las técnicas básicas para

usar UML en diferentes contextos. La clave está en discriminar cuales son aquellos

procedimientos esenciales que nos permiten evitar costosas confusiones conceptuales.

No es mediante el descubrimiento de nuevos objetos y de sus múltiples conexiones que

avanzamos en las respuestas a nuestros interrogantes cuando modelamos un dominio,

sino mediante la disolución de las contradicciones que existen entre los términos

(conceptos) ya conocidos y, en último caso, mediante la reducción de su número

despejando aquellos conceptos que no añaden valor a la comprensión de dicho dominio.

Reconsiderar lo obvio, desenmascarar presunciones, desambigüar conceptos conocidos,

todo en busca de la simplicidad y la usabilidad.

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

objetivo es descomponer la complejidad en partes más manejables y comprensibles. No

parece que esto sea algo novedoso con respecto a la tradicional descomposición

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

aplicar la dualidad estructura-función en pequeñas unidades capaces de comunicarse y

reaccionar en base a la aparición de una serie de eventos. El esquema dominante de la

separación de estructuras de datos y funciones (bases de datos y programas) está

amenazado pero aún se resiste a desaparecer.

vico.o

rg




04/09/01 11:16 Revisión:

18 Página:

3 de 9

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.

vico.o

rg




04/09/01 11:16 Revisión:

18 Página:

4 de 9

¿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).

vico.o

rg




04/09/01 11:16 Revisión:

18 Página:

5 de 9

Un plan de estudio para realizar una progresiva asimilación de los conceptos podría

empezar con los Casos de Uso (CU) y continuar con el análisis de los flujos de trabajo

de un grupo de CU mediante los diagramas de Actividad; a continuación, separar los

escenarios que agrupan una serie de actividades y hacer aflorar, a través de los

diagramas de Interacción, los objetos que intercambian una serie de mensajes. A partir

de este punto, disponemos del bagaje suficiente como para introducirnos en la

abstracción de los objetos y comprender la importancia de separar las tres perspectivas

básicas en nuestra representación de las clases: concepción, especificación e

implementación. El siguiente paso es identificar alguna clase con un comportamiento

complejo que la haga candidata a revisar todos sus posibles estados y averiguar que

eventos son capaces de provocar un cambio de estado. El diagrama de Estados-

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/

http://www.vico.org/UMLguiavisual/

vico.o

rg




04/09/01 11:16 Revisión:

18 Página:

6 de 9

¿De dónde provienen las ideas expuestas? El contenido de esta guía ha sido elaborado a partir del trabajo de una serie de

profesionales que el autor ha tenido la oportunidad de estudiar y aplicar en distintos

proyectos. Desde principios de los 90, los artículos publicados en el Journal of Object

Oriented Programming (JOOP) por James Odell, James Rumbaugh, Grady Booch,

Desmond d’Souza, Bertrand Meyer, Steve Cook, John Daniels, Sally Shlaer y

Stephen J. Mellor entre otros, han sido una constante fuente de conocimiento.

Publicaciones pioneras como el Object Oriented Technology, A Manager’s Guide de

David A. Taylor, en su primera edición de 1990 y en la segunda ampliada de 1998, han

tenido una gran influencia en como abordar la presentación didáctica. También los

libros de Peter Coad et al, Object Oriented Analysis, Design and Programming, Object

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.

http://www.vico.org/

vico.o

rg




04/09/01 11:16 Revisión:

18 Página:

7 de 9

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

Entorno sanitario

o Gestión de Bancos de Sangre y Hemoterapia

o Planificación y gestión de campañas de captación de donantes

o Gestión mutual de prestaciones asistenciales

o Tarjeta Sanitaria para certificar transacciones asistenciales

o Automatización de autoanalizadores de laboratorios de análisis

o Integración de peticiones analíticas multicentricas y publicación de

resultados

o Gestión de laboratorios farmacéuticos

o Historia Clínica Orientada por Problemas Automatizada

o Libreta de Salud para programación de citas y exploraciones

o Gestión integrada de servicios de Atención Primaria

o Plan Funcional para la implementación SAP-Gestión Clínica y

Asistencial

vico.o

rg




04/09/01 11:16 Revisión:

18 Página:

8 de 9

Entorno de ingeniería del software

o Framework de clases de análisis para definir mapas conceptuales

o Framework de servicios comunes para la publicación dinámica de

páginas HTML

o Framework de certificación de entregables

Entorno administrativo y de gestión

o Plan Funcional para la implementación SAP-Contabilidad

o Cuadro de control de indicadores de actividad y calidad

o Sistema de información Ejecutivo

Entorno comercial

o Merchandising de productos farmacéuticos

o Subastas y liquidación de lotes

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

Entorno de servicios

o Auditorías Informáticas

o Plan de Sistemas de Información

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

general

Entorno académico

o Programa de acceso a la universidad para mayores de 25 años

o Gestión de títulos universitarios

o Estudios de tercer cliclo: diseño curricular, publicación y gestión

académica

vico.o

rg




04/09/01 11:16 Revisión:

18 Página:

9 de 9

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)

[email protected]

http://www.vico.org

mailto:[email protected]

http://www.vico.org/

Niveles de concepción y formalizaciónde un proyecto

Nivel ø

Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5

ProcesosPrincipales

Glosariode Conceptos

Matrículadel Proyecto

“Code like hell”

EspecificaciónCasos de Uso

Flujosde Trabajo

Có

di

go

DinámicaEventos - Estados

CronogramaPlan Director

Iteraciones

FuncionalidadDiagramas de

Casos de Uso

<< Extends >>

<< Uses >>

<< Communicates >>

Use Case

<< Extends >>

Use Case

<< Uses >>

<< Communicates >>

Actor

Actor

C l a s e sA n á l i s i s

D i s e ñ o

I m p l e m e n t a c i ó n

Pedido

hacer /comprobaciónitem

Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobación


Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Verificando Sirviendo

EntregadoEsperando

ionar primer item


item

hacer /inicio deentregas

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

Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item


ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

P

M

* [para cada pedido seleccionado]

EntrarReposición

SeleccionarPedidos

Pendientes

AsignarItems

RegularizarStock

ActivarPedido

EntrarReposición

EntrarReposición


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

PPDI

G

CUCU

EscenariosInteracción

de objetos

tieneStock:= comprobar ( )

Una ventana deintroducción de

pedidos

Un itemde stock

Una líneade pedidoUn pedido

[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido

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

: Item de Expedición : Item de Pedido de reposición

tieneStock:( )


pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



1©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D U

MD

_es

p -

Rev

. 5

.2 -

j

vila

lta@

vico

.org

Esfuerzo de desarrol loP D P

ProductoProcesosActividadesEntregables

TiempoFases

Iteraciones

M i s i ó n

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

I t e r a c i o n e s

Iteracionespreliminares Iter #1 Iter #2 Iter #n

Iter#n+1 Iter #n

Iter#n+2

Iter#n+1

M o d e l o

C o m p o n e n t e s

C e r t i f i c a c i ó n

P r o t o t i p o

© V

ilal

ta C

on

sult

ore

s 2

00

0 -

TR

AD

PD

P i

tera

cio

nes

_es

p -

Rev

. 4

.2 -

j

vila

lta@

vico

.org

2

© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

PD

P m

isió

n_

esp

2 -

Rev

. 5

.2 -

j

vila

lta@

vico

.org

M i s i ó n




Iter#n+1 Iter #n

Iter#n+2

Iter#n+1

M o d e l o



P r o t o t i p oPlan Director de ProyectoP D P

C o n c e p c i ó n

Anteproyecto

Patrones deAnálisis

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1



hacer /comprobaciónP

Patrones deFuncionalidad

<< Extends >>

<< Uses >>

<< Communicates >>

Use Case

Actor 2

Actor 1

<<Extiende >>

<<Incluye>>

Use Case

Use Case

Use Case

Use Case

Use Case

<<Incluye>>

<<Generalización>>

PProcesos

principalesMatrícula

del proyecto



Iteraciones

PM

PPDIG

Misión

3

© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

PD

P m

od

elo

_es

p2

- R

ev.

5.3

-

jvi

lalt

a@vi

co.o

rg

M i s i ó n




Iter#n+1 Iter #n

Iter#n+2

Iter#n+1

M o d e l o



P r o t o t i p oPlan Director de Proyecto

P D P

Fo r m a l i z a c i ó n

Patrones deAnálisis

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1



hacer /comprobaciónP

Patrones deFuncionalidad

<< Extends >>

<< Uses >>

<< Communicates >>

Use Case

Actor 2

Actor 1

<<Extiende >>

<<Incluye>>

Use Case

Use Case

Use Case

Use Case

Use Case

<<Incluye>>

<<Generalización>>

PModelo


Casos de Uso


y D i s e ñ o

<< Extends >>

<< Uses >>

<< Communicates >>

Use Case

<< Extends >>

Use Case

<< Uses >>

<< Communicates >>

Actor

Actor

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1





Flujos deTrabajo

DinámicaEventosEstados


EntregadoEsperando

ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item


ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

CU * [para cada pedido seleccionado]

EntrarReposición

SeleccionarPedidos

Pendientes

AsignarItems

RegularizarStock

ActivarPedido

EntrarReposición

EntrarReposición


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo


de objetos



pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



tieneStock:( )


pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



4

© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

PD

P c

on

stru

cció

n_

esp

2 -

Rev

. 5

.3 -

j

vila

lta@

vico

.org

M i s i ó n




Iter#n+1 Iter #n

Iter#n+2

Iter#n+1

M o d e l o




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Alumno P. Global P. Esp. ResultadoSelección Ver

✔

✔

Destino

Versión

Tribunal

Año Académico*

**FechaActa

Alumnos

Frameworkde Aplicaciones

Patrones deDiseño

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




P

C o n s t r u c c i ó n


✔

✔

Destino

Versión

Tribunal

Año Académico*

**FechaActa

Alumnos

C l a s e sD i s e ñ o


Base de DatosEsquema de Persistencia

ArquitecturaComponentes

InterfaceGráfico de Usuario

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Componentes

5

© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

PD

P_

esp

2 -

Rev

. 6

.2 -

j

vila

lta@

vico

.org

Fo r m a l i z a c i ó n

M i s i ó n




Iter#n+1 Iter #n

Iter#n+2

Iter#n+1

M o d e l o




Modelo


Casos de Uso


y D i s e ñ o

<< Extends >>

<< Uses >>

<< Communicates >>

Use Case

<< Extends >>

Use Case

<< Uses >>

<< Communicates >>

Actor

Actor

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1





Flujos deTrabajo

DinámicaEventosEstados


EntregadoEsperando

ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item


ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

CU * [para cada pedido seleccionado]

EntrarReposición

SeleccionarPedidos

Pendientes

AsignarItems

RegularizarStock

ActivarPedido

EntrarReposición

EntrarReposición


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

C o n c e p c i ó n

Anteproyecto

Procesosprincipales

Matrículadel proyecto



Iteraciones

PM

PPDIG

Misión

C o n s t r u c c i ó n


✔

✔

Destino

Versión

Tribunal

Año Académico*

**FechaActa

Alumnos

C l a s e sD i s e ñ o


Base de DatosEsquema de Persistencia

ArquitecturaComponentes

InterfaceGráfico de Usuario

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Componentes


de objetos



pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



tieneStock:( )


pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



6

A la búsqueda de Actores.-

1. ¿ Quien está interesado en un requerimiento concreto ?

2. ¿ En qué dominios de la organización se usará el sistema ?

3. ¿ Quien será beneficiario de la nueva funcionalidad ?

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

5. ¿ Quien dará soporte y administrará el sistema ?

6. ¿ Usará el sistema un recurso externo ?

7. ¿ Un usuario actuará con diferentes roles ?

8. ¿ Diferentes usuarios actuarán con un mismo rol ?

9. ¿ Interaccionará el nuevo sistema con un sistema antiguo ?

¿ Cómo identificar Actores ?

Sistema en proceso de modelado

Interacción de unActor con el Sistema

Interacción delSistema con un ActorCliente

- Role de usuario -

Actores

• Representan a un agente que interactúa con el sistema• No son parte del sistema que se desarrolla• Entran información al sistema• Reciben información del sistema• Entran y reciben información

Relación que indica laespecialización a partir de una

función genérica

Realizar unatransacción

Usar CajeroAutomático

<< Incluye >> Subsis temade cuentas

cl iente- Role de subsis tema -

Subsi temade cer t i f icación

de mediosde pago

- Role de subsis tema -

A c t i v a rTa r j e t a

R e t i r a rE f e c t i v o

C o n s u l t a rM o v i m i e n t o s

<<Generaliza>>

<<Generaliza>>

<<Generaliza>>

FuncionalidadDiagramas deCasos de Uso

<< Extends >>

Use Case

<< Uses >>

<< Communicates >>

Actor

Actor

1©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

cto

res_

esp

- R

ev.

5.1

-

jvi

lalt

a@vi

co.o

rg

A la búsqueda de Casos de Uso.-

1. ¿ Cuales son las tareas y responsabilidades de cada actor ?

2. ¿ Algún actor creará, almacenará, cambiará, borrará o leerá información del sistema ?

3. ¿ Qué Casos de Uso crearán, almacenarán, cambiarán, borrarán o leerán esta información ?

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

5. ¿ Es necesario que un Actor sea informado sobre ciertas incidencias del sistema ?

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

7. ¿ Pueden ser realizados por los Casos de Uso todos los requerimientos funcionales documentados ?

¿ Cómo identificar Casos de Uso ?

Abrir ArqueoHacer un

Inicio de Día

Hacer unFin de Día

Exportarmovimientos

Piezas de funcionalidad del sistemaque suministran valor a un Actor y son

reutilizables en diferentes procesos

Relación que describe una variaciónposible del comportamiento normal

de un Use Case

Relación que permite descomponerun Use Case con un determinado

nivel de granularidad

Imprimirdocumento

Sistema en proceso de modelado

Interacción de unActor con el Sistema

Interacción delSistema con un Actor

Supervisor- Rol de usuario -

Importar nuevaconfiguración

Contabi l idad- Sis tema externo -

Cajero- Rol de usuario - Cerrar Arqueo

<< Incluye >>

<< Extiende >>

<< Incluye >>

<< Incluye >>

<< Extiende >>

Relación que indica el uso deuna funcionalidad compartida

por otros Casos de Uso


<< Extends >>

Use Case

<< Uses >>

<< Communicates >>

Actor

Actor

2©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D U

Cs_

esp

- R

ev.

5.1

-

jvi

lalt

a@vi

co.o

rg

Especificaciónde un Caso de Uso

LIMIT

Límites: Cuando empieza y cómo termina el Caso de Uso.

Interacciones: Comportamiento de Actores y Sistema.Acción-Reacción dentro del Caso de Uso.

Masa: Conjunto de Objetos e Interfaces que requiereel Caso de Uso.

Índice de escenarios: Flujo principal de eventos y secuenciade variaciones posibles dentro de un Caso de Uso.

Tribulaciones: Contingencias probables que pueden afectaral flujo de los eventos y son excepciones del Caso de Uso.

Propósito- Regla de Negocio - Precondiciones Activación Flujo Principal Variaciones Excepciones

Cerrar un periodo demovimientos de cajapara obtener unasituación real de dineroen efectivo y endocumentos.

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

• A discreción de un Actorhabilitado

1. Sistema requiere confirmación decierre de arqueo.

a. Si Actor decide aparcar el cierre de arqueo,sistema activa UC Aparca_arqueo y terminael UC.

2. Sistema comprueba la configuraciónde TPV para identificar tipo de cierre.

3. Sistema calcula los totales teóricospara cada forma de cobro.

4. Actor introduce totales reales para cadaforma de cobro.

5. Sistema registra el cierre: importesreales para cada forma de cobro ydescuadres.

6. Sistema imprime el documento “Tirade Arqueo”.

a. Cierre de arqueo de tipo abierto:• Actor decide el momento de imprimir el

documento “Tira de Arqueo”.

a. Si el servidor está off-line, sistema informaal usuario, termina el UC manteniendo elarqueo abierto.

b. Cierre de arqueo de tipo ciego:• Sistema no muestra los totales teóricos para

cada forma de cobro.

a. Si impresora está off-line, sistema informaal usuario y le pide confirmación paracontinuar.

Hacer unFin de Día

Imprimirdocumento

Cerrar Arqueo << Extiende >>

<< Incluye >>

Caso de Uso principal

Casos de Uso secundarios

Caso de Uso especializadoCaso de Uso genérico

<<Generaliza>>Imprimir

t i ra de arqueo


<< Extends >>

Use Case

<< Uses >>

<< Communicates >>

Actor

Actor

3©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D L

IMIT

UC

s_es

p -

Rev

. 5

.1 -

j

vila

lta@

vico

.org

Ventajas del modeloUse Case

Piezas de funcionalidad reutilizablesen diferentes procesos de negocio

1. Lenguaje de comunicación entre usuariosy desarrolladores.

2. Comprensión detallada de la funcionalidaddel sistema.

3. Acotación precisa de las habilitaciones delos usuarios.

4. Gestión de riesgo más eficiente paragobernar la complejidad.

5. Estimación más exacta para determinartiempo, recursos y prioridades en la dosificaciónde esfuerzo de desarrollo.

6. Fiel trazabilidad para verificar la traducciónde requerimientos en código ejecutable.

7. Mayor control para mantener las sucesivasrevisiones de los programas.

8. Certificación contractual Cliente-Desarrollador.

9. Documentación orientada al usuario: Helps- Manual de Procedimientos - Reglas de Negocio.

10. Documentación orientada al administradordel sistema: Soporte de Mantenimiento.

Hacer unInicio de Día

Exportarmovimientos

Imprimirdocumento

Importar nuevaconfiguración

Cerrar Arqueo

<< Incluye >>

<< Extiende >>

<< Extiende >>

<< Incluye >>

<<Generaliza>>

Hacer unFin de Día

<< Incluye >>

Imprimirt i ra de arqueo

Abrir Arqueo


<< Extends >>

Use Case

<< Uses >>

<< Communicates >>

Actor

Actor

4©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D m

od

elo

UC

_es

p -

Rev

. 5

.1 -

j

vila

lta@

vico

.org

Requerimientos y Casos de UsoLos Casos de Uso son requerimientos funcionales que describende una manera detallada el comportamiento del sistema conlos distintos Actores que interactúan con él.

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

Caso de Uso

Requerimientos

Mod

elo

Arquitectu

ra

Gestión

de Proyecto

Cer

tif i

caci

ón

Reglasde Negocio

y protocolos deintercambio de

información

Funcionales,no funcionalese interfaces de

usuario

Mapa conceptual:Clases de análisis

Dinámica deClases complejas

Mapa funcional:Flujos de trabajo

principales yvariaciones

Escenarios deinteracciónde objetos:

Clases de diseño

Métrica:Escandallo de

recursosy actividades

Plan Directorde Iteraciones:

Cronogramay prioridades

Funcionalidad,Análisis y Diseño

Implementaciónde código yRefactoring


<< Extends >>

Use Case

<< Uses >>

<< Communicates >>

Actor

Actor

5©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D R

eq y

CU

s_es

p -

Rev

. 1

.1 -

j

vila

lta@

vico

.org

Descripciónde un Flujo de Trabajo

Un flujo de trabajo muestra la secuencia de actividadesque se desarrollan dentro de uno o varios Casos deUso, como una pieza de funcionalidad concreta quesatisface los requerimientos de un Actor.

Diagrama de ActividadNotación UML 1.3

* [para cada línea de pedido]

Concurrencia dinámica de actividades

Recepciónde un

Pedido

[SI vigente]

[NO]

Barra de sincronización

Actividad

Punto de decisión

Barra de fusión

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

Evento quedesencadenala secuencia deactividades

Análisis textualdel Caso de Uso

F l u j o P r i n c i p a l Va r i a c i o n e s

2. Usuario entra lineas de pedido, con sucódigo de artículo, tipo de presentacióny cantidad.

b. SI existen suficientes items del artículo enel stock, sistema asigna items al pedido.

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

4. Sistema comprueba la situación delpedido .

a. SI se ha realizado el pago y SI todos los itemsdel pedido han sido asignados, sistemainforma que procede a servir el pedidoactivando el CU Servir pedido.

b. SI se ha realizado el pago y NO existensuficientes items del artículo en stock, sistemaaparca el pedido del cliente activando el CUAparcar pedido.

c. SI no se ha realizado el pago según el plazoconvenido, sistema cancela el pedido.

CU Realizar pedido

1. Usuario identifica el cliente que haenviado un pedido.

c. NO existen suficientes items del artículo enstock, o la asignación de items deja lasituación del artículo en stock por debajo delnivel de reposición, sistema genera pedidode reposición activando el CU Generarpedido.

a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra artículos alternativos activando elCU Seleccionar artículo.

[NO vigente]

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

[SI]

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

CancelarPedido

IdentificarCliente

Entrarlíneas pedido

ComprobarArtículo

ComprobarPago

ServirPedido

Generarreposición

SeleccionarArtículo alternativo

AsignarItems

Comprobarsituación Pedido

AparcarPedido

Flujos deTrabajo


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

1

© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

Act

ivid

ad 1

_es

p -

Rev

. 7

.1 -

j

vila

lta@

vico

.org



* [para cada pedidoseleccionado]

Recepciónde una

Reposición

[Todos los items asignados] [Todos las reposiciones entradas]

F l u j o P r i n c i p a l

1. Usuario recepciona albaranes dereposición que ha enviado un proveedor.

2. Sistema localiza los pedidos de clientesaparcados que pueden cumplimentarsecon la nueva entrada de items.

3. Usuario selecciona los pedidos declientes aparcados que decidecumplimentar.

4. Sistema asigna los items pendientes alos pedidos de cliente seleccionados.

5. Sistema informa que procede a servirel pedido activando el CU Servirpedido..

6. Sistema regulariza la situación de itemsen stock y revisa los umbrales dereposición automática.

Una diagrama de actividad describe una secuencia deactividades que pueden exhibir un comportamiento enparalelo o estar sujetas a condiciones lógicas.

Los procesos de negocio no muestran siempre una secuenciafija en su desarrollo, es una ventaja así poder modelarbloques de actividades sin restricciones de concurrencia.

Transición de una actividad a otra sujetaa una condición lógica.

Sincronización de actividades quepueden ocurrir en paralelo.

CU Actualizar reposición

ServirPedido

SeleccionarPedido

AsignarItems

Fin de la secuencia deactividades

Análisis textualdel Caso de Uso

EntrarReposición

BuscarPedidos aparcados

RegularizarStock

Flujos deTrabajo


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

2©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

ctiv

idad

2_

esp

- R

ev.

5.2

-

jvi

lalt

a@vi

co.o

rg



Un diagrama de actividad puede mostrar la secuencia deactividades que se desarrolla en un paquete de Casos deUso que define un proceso de negocio y sus áreas deresponsabilidad.

[SI éxito]

[NO éxito]

Contabilidad Comercial Almacén

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


Recepciónde un

PedidoIdentificar

Cliente

Entrarlíneas pedido

ComprobarPago

CancelarPedido

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

Generarreposición

EntrarReposición

[Recepción de Reposición]

[SI vigente]

[NO vigente]Seleccionar

Artículo alternativo

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

ServirPedido

Comprobarsituación Pedido

AparcarPedido

* [para cada pedidoseleccionado]

SeleccionarPedido

BuscarPedidos aparcados

[Todos las reposiciones entradas]

RegularizarStock

ComprobarArtículo

AsignarItems

Flujos deTrabajo


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

3©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

ctiv

idad

3_

esp

- R

ev.

6.1

-

jvi

lalt

a@vi

co.o

rg



Su objetivo no es relacionar actividad con objetos, sólocomprender qué actividades son necesarias y cuales son susrelaciones de dependencia.

El diagrama de actividad nos permite definir en qué ordense van a realizar distintas tareas. Los diagramas de flujo(flowchart) sólo nos permiten modelar procesos secuenciales,mientras que los diagramas de actividad nos permitenestablecer procesos en paralelo.

ComprobarCliente habitual

Importe> 150.000

ComprobarCrédito

Pre-Pagorequerido

[Tarjeta de Crédito]

NO éxito

[NO éxito]

[Cheque]

[SI éxito][SI éxito]

SI éxito

[SI éxito]

[SI éxito]

[NO éxito]

[NO]

[NO]

[SI]

[SI]

[Factura]

[NO éxito]

[NO recibido]

NO éxito

[NO éxito]

Autorización

[Efectivo]

Descomposiciónde la actividad

ComprobarPago

ComprobarPago

ComprobarCheque

Comprobarhistorial pagos

AbrirCuenta Cliente

Pueden procesarse distintasmodalidades de pago demanera simultanea

Flujos deTrabajo


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

4©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

ctiv

idad

4_

esp

- R

ev.

5.2

-

jvi

lalt

a@vi

co.o

rg

Descripciónde un Escenario

Diagrama de SecuenciaNotación UML 1.3

2:generarPedido ( )

4:generarLíneaPedido ( )

5:comprobarStock ( )

6:asignarItems ( )

7:realizarReposición ( )

Objetos queinteractúan

Mensaje

Auto-mensaje

Línea de vidade un objetodurante la interacción

(1)

Mensajes enviados entre los objetos descritos enel flujo de eventos de un Caso de Uso.

Estos mensajes muestran el nivel de colaboraciónentre los distintos objetos existentes e indicancuando se requiere generar nuevos objetos paracumplir con las responsabilidades asignadas.

(1)

Utilizamos dos diagramas de interacción:a/. Secuenciab/. Colaboración

Su finalidad es describir los mensajes que intercambian losdistintos objetos para cumplir con las responsabilidadesdefinidas en un escenario concreto de un Caso de Uso.

• Diagrama de Secuencia.- Representa lasinteracciones de objetos ordenadas en una serie temporalque muestra su ciclo de vida.

1:indentificarCliente ( )

8:generarReposición ( )

Creación deun nuevoobjeto

Un escenario muestra de que manera interactúan los distintosobjetos dentro del flujo principal de eventos de un Caso deUso con alguna variación o extensión concreta del mismo.

:Comercial

3:entrarLíneaPedido ( )

Análisis textualdel Use Case





CU Realizar pedido




:Una Carterade Itemsen Stock

:Un Pedidode

Reposición

:Una Ventana deintroducción de

Pedidos:Un Pedido

:Una Líneade Pedido

Escenarios

tieneStock:( )


pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



1©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D S

ecu

enci

a_es

p -

Rev

. 6

.1 -

j

vila

lta@

vico

.org

Descripciónde un Escenario

Diagrama de ColaboraciónNotación UML 1.3

2: generarPedido ( ) 5: comprobarStock ( )

6: asignarItems ( )

7: realizarReposición ( )

Objeto(Instancia de una Clase)

Auto-mensaje

8: generarReposición ( )

Número de secuencia

Mensajes enviados entre los objetos descritos enel flujo de eventos de un Caso de Uso.

Estos mensajes muestran el nivel de colaboraciónentre los distintos objetos existentes e indicancuando se requiere generar nuevos objetos paracumplir con las responsabilidades asignadas.

(1)

Un escenario describe una instancia del flujo de eventos deun Caso de Uso, con sus variaciones o extensiones posiblesy las excepciones probables.

• Diagrama de colaboración.- Representa unaposible interacción de los objetos ordenados a partirde la topología que muestra el envio de sus mensajes.

Con un escenario representamos el conjunto de eventos queconfigura el comportamiento de un Caso de Uso.

Enlace entredos objetos

Dirección del mensaje

Utilizamos dos diagramas de interacción:a/. Secuenciab/. Colaboración

Su finalidad es describir los mensajes que intercambian losdistintos objetos para cumplir con las responsabilidadesdefinidas en un escenario concreto de un Caso de Uso.






CU Realizar pedido




: Comercial

: Una Ventana de introducción de Pedidos

: Un Pedido

: Una Línea de Pedido

:Una Cartera de Items en Stock

: Un Pedido de ReposiciónEscenarios

tieneStock:( )


pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



1: identificarCliente ( )

3: entrarLíneaPedido ( )4: generarLíneaPedido ( )

Mensaje (1)

2©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

ola

bo

raci

ón

_es

p -

Rev

. 6

.1 -

j

vila

lta@

vico

.org

ClasesDesde una perspectiva conceptual, una Clase representa unconjunto de Objetos que comparten:

• Las mismas propiedades (Atributos)• El mismo comportamiento (Métodos)• Las mismas relaciones con otros Objetos (Mensajes)• La misma semántica dentro del sistema

Un Objeto representa una entidad del mundo real o inventada.Es un concepto, una abstracción o algo que dispone de unoslímites bien definidos y tiene una significación para el sistemaque se pretende modelar.

Estructura y función:• 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

Objetos

Desde una perspectiva física, una Clase es una pieza de softwareque actua como un molde para fabricar tipos particulares deobjetos que disponen de los mismos atributos y métodos.

Estos elementos que configuran cada tipo de objeto sólo sedefinen una vez, cuando especificamos la estructura de la Clasea la que pertenecen.

Los objetos que se han creado a partir de una Clase concreta,se llaman instancias de esta Clase y se diferencian entre ellosúnicamente por los valores de sus atributos (variables).

Diagrama de ClasesNotación UML 1.3

PedidoFechaRecibidoConPrepagoNúmeroImporteDivisa...

Cliente

Línea de Pedido

Producto

Representante

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1

facturarMes( )recordar( )

aceptar ( )

valorarCredito( ): string

seleccionar ( )comprobar ( )servir ( )cerrar ( )...

NombreDireccion

NombreContactoValoracionCreditoLimiteCredito

NumTargetaCredito

CantidadImporteCumplimentada

Objetos Clases

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




1©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s 1

_es

p -

Rev

. 6

.1 -

j

vila

lta@

vico

.org

Abstracción

método 4

mét

odo 1

Atributos

Clases

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




método 2

mét

odo 3

A partir de una abstracción del mundo real, definimosobjetos que representan micromódulos de software ideales.Desde su creación, se mantienen de manera independienteunos de otros, sólo interaccionan con otros objetos a travésde sus mensajes. Cada objeto configura un universo ordenadoy autosuficiente.

vacp 104

2©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s 2

_es

p -

Rev

. 3

.1 -

j

vila

lta@

vico

.org

Objeto

elevarPlataforma

carg

arIte

m

Atributos

Clases

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




moverHacia

bajarP

lataf

orma

Variables.-

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

Estado.-

• Localización• Orientación• Velocidad

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

Vehículo Automático Carga Paletsvacp104

¿Qué puedo hacer?

¿Qué conozco?

¿Quien soy?

3©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s 3

_es

p -

Rev

. 2

.2 -

j

vila

lta@

vico

.org

Mensaje

Clases

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Una aplicación orientada a objetos consiste en un númerodeterminado de objetos que interactuan entre si enviándosemensajes unos a otros para invocar sus métodos. Esteintercambio de mensajes facilita su comportamiento, cambiosde estado, destrucción o almacenamiento.

Ya que todo lo que un objeto puede realizar está expresadoen sus métodos, este simple mecanismo de mensajes soportatodas las posibles interacciones entre ellos.

elevarPlataforma

carg

arIte

m

Atributos

moverHacia

bajarP

lataf

orma

Objeto Receptor

vacp104 moverHacia: binB7Objeto Emisor

Nombre del objeto receptor

Método que se invoca para que lo ejecute el objeto receptor

Parámetro enviado para especificar el método

Signatura del mensaje

vacp104

4©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s 4

_es

p -

Rev

. 1

.2 -

j

vila

lta@

vico

.org

Clases

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




El empaquetado de métodos y atributos dentro de un objetomediante una interface de mensajes, es lo que denominamosencapsulación.

La clave está precisamente en este envoltorio del objeto.La interface que rodea por completo al objeto actúa comopunto de contacto para todos los mensajes que llegan desdecualquier objeto emisor.

La interface de mensajes tiene la misma función que lamembrana de una célula, disponer de una barrera esencialentre la estructura interna de un objeto y el exterior.

Su propósito es garantizar que todas las interacciones delobjeto tengan lugar a través de un sistema de mensajeríapredefinido con el que es capaz de entenderse y reaccionaradecuadamente.

No existe ninguna otra manera con la que un objeto externopueda acceder a los atributos y métodos escondidos dentrode la interface de mensajes de otro objeto.

Encapsulación

M e n s a j e

Interface de mensajes

vacp104 moverHacia: binB7

vacp104

elevarPlataforma

carg

arIte

m

Atributos

moverHacia

bajarP

lataf

orma

Conjunto de operacionesexternamente visibles quedefine el comportamiento

de un objeto

5©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s 5

_es

p -

Rev

. 3

.1 -

j

vila

lta@

vico

.org

Clases

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




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

Herencia

Vehículo Automático Carga Palets

vac 104

vac 104

vac 103

vacp 104

Instancias deVehículo Automático Carga Palets

Interface de mensajes

Identificador del objeto

Métodos

Atributos

La interface de mensajes definida para una Superclasetambién es heredada por las subclases. Esto implica quetodas las Subclases de una Superclase estan preparadaspara responder correctamente a los mismos mensajes quela Clase padre. Esta propiedad es extremadamente útilporque nos permite tratar de la misma manera a todas lasespecializaciones de una Clase.

Vehículo AutomáticoCarga Palets

SubClase

Vehículo AutomáticoCarga Bobinas

SubClase

Vehículo Automático de Carga

SuperClase

elevarPlataforma

carg

arIte

m

Atributos

moverHacia

bajarP

lataf

orma

vacp 104

6©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s 6

_es

p -

Rev

. 1

.2 -

j

vila

lta@

vico

.org

Composición

Clases

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Enter title here

Los objetos que contienen a otros objetos se denominanObjetos Compuestos. Los atributos de un objeto puedenutilizarse de dos maneras. Podemos usarlos para almacenarvalores como el número 15, o bien, el texto “Autorizado”.

Panel de ventana

También pueden contener referencias de otros objetos. Lasreferencias almacenadas en los atributos de un objetocompuesto, permite a este objeto enviar los mensajesapropiados a todos los objetos contenidos.

Tab Tab control

Scroll

Combo box

Slider

Trackbar

67%

Progress

Campo simple

Botones de ventanaRestore Maximize

?Help Minimize

CloseList box

Grid

Enter title here

< Back Next > Cancel

Ventana Wizard

7©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s 7

_es

p -

Rev

. 2

.1 -

j

vila

lta@

vico

.org

Clases

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Diferentes objetos pueden responder a un mismo mensajede diferentes maneras. El polimorfismo permite a los objetosinteractuar entre ellos sin necesidad de conocer previamentea que tipo pertenecen.

Un objeto puede ser de diferentes tipos. Por ejemplo unvehículo automático de carga puede especializarse paracargar bobinas, palets u otro tipo de items. Los demásobjetos del sistema no tienen porque saber cuantos tiposde vehículos disponemos.

El mismo mensaje cargarItem, acompañado del parámetroque identifica dicho item, será intrepretado de distintamanera por cada objeto receptor, el cual ya conocepreviamente como tiene que tratar la naturaleza de sucarga: bobinas, palets, etc.

Hay una reducción de esfuerzo muy significativa por elhecho de que cualquier objeto del sistema puede enviarmensajes a los vehículos automáticos de carga sin necesidadde saber de antemano qué tipo de vehículos estan encirculación.

No hay necesidad así de picar un código específico paracada tipo de vehículo, con lo cual, nos ahorramos prolijassentencias IF o CASE que son complejas de mantener y deactualizar cuando se incorporan nuevos tipos de objetos.

Polimorfismo

M e n s a j e

cargarItem: #A234C19FZ

Vehículo AutomáticoCarga Palets

SubClase

Vehículo AutomáticoCarga Bobinas

SubClase

elevarPlataforma

carg

arIte

m

Atributos

moverHacia

bajarP

lataf

orma

vacb 117elevarPlataform

a

carg

arIte

m

Atributos

moverHacia

bajarP

lataf

orma

vacp 104

Vehículo Automático de Carga

SuperClase

8©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s 8

_es

p -

Rev

. 1

.1 -

j

vila

lta@

vico

.org

Visibilidad•Toda Clase encapsula unos elementos (atributos y operaciones) que disponende ciertos criterios de visibilidad y manipulación para otras Clases.•Los elementos públicos pueden ser usados por cualquier otra Clase.•Los elementos privados pueden ser usados sólo por la Clase propietaria.•Cada plataforma de desarrollo (C++, Smalltalk, Java) desarrolla sus propiasreglas con respecto a la visibilidad y manipulación de atributos y operaciones.•La notación UML especifica que todo atributo y operación de una Clase hade disponer de un indicador de visibilidad.

Clases

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1




Visibilidad C++ Smalltalk Java

+ Publica

- Privada

# Protegida

Package

Ejemplos

Un elemento siempre es visible en cualquierparte del programa y puede ser llamado ymodificado por cualquier objeto delsistema.

Un elemento sólo puede ser usado por laClase que lo define.

Un elemento sólo puede ser usado por laClase que lo define, o por las subclases dedicha Clase.

Consideremos la Clase CLIENTE que disponede una subclase CLIENTE PERSONAL.Consideremos también que el objeto <<JosepV.>>, es una instancia de CLIENTEPERSONAL.<<Josep V.>>• Puede usar todo elemento público de cualquierobjeto del sistema.• Puede usar también todo elemento privado dela Clase CLIENTE PERSONAL.• No puede usar los elementos privados definidosen la Clase CLIENTE.• Puede usar los elementos protegidos definidospara CLIENTE y CLIENTE PERSONAL.

Todas las operaciones sonpúblicas por defecto.

Todas las variablesinstanciadas son privadas.

<<Josep V.>>, puede acceder acualquier variable instanciada dentrode su propio objeto, si dicha variableha sido definida dentro de CLIENTEo CLIENTE PERSONAL. De estamanera, el concepto de visibilidadprivada en Smalltalk es parecido alconcepto de visibilidad protegida enC++.

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

En C++, podemos acceder a elementos de otrosobjetos de la propia Clase, de la misma maneraque podemos acceder a los propios elementosde un objeto.

En Smalltalk no hay diferencia conrespecto a que un objeto sea de lamisma Clase o no. Podemos accedersólo a los elementos públicos de otroobjeto.

En Smalltalk, <<Miquel M.>>, nopuede acceder a las variablesinstanciadas privadas de <<JosepV.>>, sólo a sus operaciones públicas.

Un elemento siempre es visible encualquier parte del programa y puedeser llamado y modificado por cualquierobjeto del sistema.

Un elemento sólo puede ser usado porla Clase que lo define.

Un elemento puede ser usado porsubclases y también por cualquier otraClase en el mismo Package como laClase propietaria. Esto implica que enJava, el concepto de visibilidadprotegida es más público que package.

Un elemento sólo puede ser usado porotras Clases que compartan el mismoPackage.

Pedido- fechaRecibidoconPrepago- número: Alfanúm.- importe: Núm&2d.- divisa...

Cliente

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*

0..1

*

* 1

+ hacer /comprobaciónitem

+ hacer /comprobación

+ crear ()+ seleccionar ( )+ comprobar ( )+ servir ( )+ cerrar ( )

Java permite marcar también las Clasescomo públicas o packages. Los elementosde una Clase pública pueden ser usados porcualquier Clase que importe el package ala que pertenece la Clase.Los elementos de una Clase package sólopueden ser usados por otras Clases delmismo package.

Línea de Pedido

+ hacer /comprobación

9©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s v

isib

ilid

ad_

esp

- R

ev.

5.3

-

jvi

lalt

a@vi

co.o

rg

Descripciónde la Dinámica del Sistema

La dinámica de un sistema está determinada por:

• Todos los posibles estados que sus objetos pueden tener.

• Todas las posibles secuencias de eventos que puedenocurrir.

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

Diagrama de Estadosde un PedidoNotación UML 1.3

Comprobando Sirviendo

EntregadoEsperando

/seleccionar primer item


item


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

/seleccionar siguiente item

[Todos los items comprobados &&algunos items no estan disponiblesen stock]

Item Recibido[algunos items no estan disponiblesen stock]

Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Pedido Entregado

1

2

3

4

5

6

1

DinámicaEstados


ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando









CU Realizar pedido




PedidofechaRecibidoconPrepagonúmero: Alfanúm.importe: Núm&2d.divisa...

*

1



© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

Din

ámic

a 1

_es

p -

Rev

. 5

.1 -

j

vila

lta@

vico

.org




EntregadoEsperando



item


[No todos los items comprobados]/seleccionar siguiente item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Pedido Entregado


*

1


InicioClase

Atributos

Operaciones

primera Transición

E s t a d o

Actividad

Acción

Acción

Indicador

Auto-Transición

Transición

12

Evento3

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

4

5

6

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

/ Acción Transición

Desencadenasiempre

la Transición

[Indicador] TransiciónCondició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.


2

DinámicaEstados


ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

Sintaxis para etiquetar una transición

Evento [Indicador] / Acción

Los tres elementos son opcionales






CU Realizar pedido




© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

Din

ámic

a 2

_es

p -

Rev

.- 5

.1 -

j

vila

lta@

vico

.org




EntregadoEsperando



item


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

/seleccionar siguiente item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Pedido Entregado

Construimos el diagrama de estados a partir de una claseconcreta para mostrar el comportamiento de un objetodurante su ciclo de vida.

Inicio

primera Transición

E s t a d o

Actividad

Acción

Acción

Indicador

Auto-Transición

Transición

Impl

emen

taci

ón

Cuando una Transición no dispone de un Eventoen su etiqueta, significa que la Transición serealiza tan pronto como la Actividad asociadacon un Estado es finalizada

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

/ Acción Transición

/ Actividad EstadoProcesos que ocurren dentro de un ciclo discontínuoy pueden ser interrumpidospor algun evento.

[Indicador] TransiciónCondició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.

12

Evento3

No hay Actividades para este Estado, por loque el Pedido permanecerá a la espera deun Evento.

Desencadenasiempre

la Transición

Aunque finalize la Actividadel Pedido permanecerá eneste Estado hasta que ocurreel Evento que desencadenasu Transición

4

5

6

3

DinámicaEstados


ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando






CU Realizar pedido





*

1


Clase

Atributos

Operaciones

Sintaxis para etiquetar una transición

Evento [Indicador] / Acción

Los tres elementos son opcionales

© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

Din

ámic

a 3

_es

p -

Rev

. 5

.1 -

j

vila

lta@

vico

.org


Diagrama de EstadosNotación UML 1.3

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

Sólo podemos conocer que un Evento ha ocurrido,detectando sus “efectos” en nuestro modelo.

Sólo nos interesan aquellos Eventos que provocan un cambiode estado en los objetos de nuestro modelo.

Hay que distinguir un Evento como tal, del objeto querepresenta el registro de los efectos de dicho Evento.


Esperando



item


[No todos los itemscomprobados]/seleccionarsiguiente item

[Todos los itemscomprobados &&algunos items no estandisponibles en stock]

Item Recibido[algunos itemsno estandisponibles en stock]

Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

PedidoEntregado

1

2

3

4 5

6


sin Superestados


EntregadoEsperando



item


[No todos los itemscomprobados]/seleccionarsiguiente item

[Todos los itemscomprobados &&algunos items no estandisponibles en stock]

Item Recibido[algunos itemsno estandisponibles en stock]

Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

PedidoEntregado

1

2

3

4

5

6


CanceladoPedidoCancelado

PedidoCancelado

PedidoCancelado

Activo

Cancelado Entregado

PedidoCancelado

Nombre del Superestado

con Superestados

4

DinámicaEstados


ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando






CU Realizar pedido




© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

Din

ámic

a 4

_es

p -

Rev

. 5

.1 -

j

vila

lta@

vico

.org


Diagrama de EstadosConcurrentesNotación UML 1.3

Autorizandohacer /

comprobacióndel pago

[pago NO correcto]

Entregado

[pago SI correcto]

RechazadoAutorizado

Rechazado

Cancelado

Entregado

Comprobando

Esperando

Sirviendo

Autorizando AutorizadoPedido Entregado

Pedido Cancelado

Pedido Rechazado

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

5F l u j o P r i n c i p a l Va r i a c i o n e s


b. SI existen suficientes items...

3. Sistema comprueba cada línea delpedido para validar la situación delartículo...





CU Realizar pedido


c. NO existen suficientes items...

a. Artículo NO está vigente en catálogo, sistemainforma que articulo no está vigente ymuestra...


DinámicaEstados


ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

Din

ámic

a 5

_es

p -

Rev

. 5

.1 -

j

vila

lta@

vico

.org

Vista deDistribución Física

Elementos

Vista deImplementación

Ejecutables

Arquitectura del sistema

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

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

Vista delModelo de Referencia

Vista de la

FuncionalidadUse Cases

Vista deComponentes

Modulares

1©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

rqu

itec

tura

1_

esp

- R

ev.

5.1

-

jvi

lalt

a@vi

co.o

rg

Arquitectura del sistemaLa vista del Modelo de Referencia (Reference InformationModel), está determinada por la arquitectura lógica.

La arquitectura lógica es capturada por los diagramas deClases que contienen las Clases y relaciones que representanlas abstracciones esenciales del sistema a desarrollar.

• Clases

• Asociaciones

• Agregaciones

• Generalización

• Packages

Arquitectura



El Modelo de Referencia se construye en sucesivasiteraciones durante la fase de Formalización.

Pedidos Clientes

ArtículosLas Clases y Packages del modelo reflejan lasdecisiones tomadas con respecto a los “mecanismosclave” del sistema.

Una eficiente implementación de los “mecanismosclave” requiere seleccionar Patrones (Patterns) quese ajusten a los requerimientos esenciales delproyecto.

La implementación de “mecanismos clave” requiereseleccionar 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


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1





2©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

rqu

itec

tura

2_

esp

- R

ev.

5.1

-

jvi

lalt

a@vi

co.o

rg

Vista deComponentes

Modulares

Arquitectura del sistemaLa vista de Componentes Modulares refleja la organizaciónde módulos de software dentro del entorno de desarrollo.

Esta vista de arquitectura toma en cuenta los requerimientosque 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ísicadel sistema.

• Componentes: En esta vista representan la organizaciónde módulos de código fuente.

Arquitectura

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

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

I n t e r f a c e d e U s u a r i o

Pa c k a g e s r e u t i l i z a b l e s

M e c a n i s m o s c l a v e C O R E

Pa c k a g e s d e p l a t a f o r m a ( O S - H a r d w a r e )

4

3

2

1

ø

Vista deComponentes

Modulares


Los Packages de la vista lógica del modelo estanmapeados con los Packages físicos y los componentesde software (subsistemas).

InformaciónArtículos

Pe d i d o

Dominio

Clientes

Artículos

Pedidos

MailingInterface Usuario

AWTJava GUI toolkit

EntradaPedidos

Interface Usuario

3©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

rqu

itec

tura

3_

esp

- R

ev.

5.1

-

jvi

lalt

a@vi

co.o

rg


Ejecutables


Ejecutables


Arquitectura

Los componentes run-time muestran los mappingsde las Clases a librerías de tipo ActiveX, Applets deJava y librerías dinámicas.

Vista deComponentes

Modulares


Los componentes ejecutables muestran sus interfacesy niveles de dependencia dentro de la aplicación.

Clientes.dll

Expedición.dll

Artículos.dll

Pe d i d o s . exe

MailingInterface Usuario

AWTJava GUI toolkit

EntradaPedidos

Interface Usuario

Dominio

Clientes

Artículos

Pedidos

EntradaPedidosAplicación

MailingAplicación

Base deDatos

Interface global

OracleInterface

IngresInterface

Esta vista se centra en la estructura de los componentes“run-time”, los ejecutables del sistema.

Esta arquitectura tiene muy en cuenta los siguientesrequerimientos no funcionales:

• Rendimiento

• Fiabilidad

• Escalabilidad

• Integridad

• Seguridad

• Sincronización

• Administración del sistema

4©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

rqu

itec

tura

4_

esp

- R

ev.

5.1

-

jvi

lalt

a@vi

co.o

rg


Elementos


Ejecutables


Un Nodo es un objeto físico run-time que representaun recurso informático. Este recurso, generalmentedispone de datos persistentes y capacidad de proceso.

En la mayoría de los casos un Nodo puede representaruna pieza de hardware, desde un periférico a unservidor.

Las Conexiones entre Nodos muestran las líneas decomunicación con las que el sistema tendrá queinteractuar.

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 correcada Package en el sistema.

Las Dependencias muestran cómo los componentesse comunican con otros componentes. La direcciónde una Dependencia concreta, indica el conocimientoen la comunicación.

Vista deComponentes

Modulares


Esta vista presenta el mapping de componentes de softwareejecutables con los nodos de procesamiento (hardware).

Esta arquitectura tiene en cuenta los siguientesrequerimientos:

• Disponibilidad del sistema

• Rendimiento

• Escalabilidad

Los diagramas de distribución muestran el despliegue denodos (locales y remotos), en la organización de la empresa.

Permite al equipo de desarrollo comprender mejor latopología de un sistema distribuido.


Elementos

Componente

Arquitectura

Interface

Nodos

Conexión

TCP/IP

TCP/IP

Servidor Área Comercial

Cliente Win95

Servidor Contabilidad

:GUIComercial

:ClienteComercial

Configuración

:Usuarios

:Contabilidad

:Base deDatos

:Base deDatos

:Comercial

:ServidorAplicaciones

5©

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

rqu

itec

tura

5_

esp

- R

ev.

5.1

-

jvi

lalt

a@vi

co.o

rg


Ejecutables

Arquitectura del sistemaVista de

ComponentesModulares

Vista delModelo de Referencia Esta vista certifica la validez de:

• Modelo de Referencia

• Componentes modulares de software

• Ejecutables

• Distribución de recursos informáticos

Con la funcionalidad requerida del sistema.

Utilizamos los siguientes elementos para describir lafuncionalidad:

• Diagramas de Casos de Uso

• Especificación de Casos de Uso

• Diagramas de Interacción (Escenarios)

• Diagramas de Actividad (Flujos de Trabajo)

• Diagramas de Estados (Dinámica)


Elementos

Vista de la

FuncionalidadUse Cases

Arquitectura


[tieneStock] asignar ( )

[tieneStock] nuevo


pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo


PrepararPedido

Recepciónde un

Pedido

ComprobarItems

ComprobarPago

CancelarPedido

AsignarItems

ReponerItems

ServirPedido

[en stock]

[SI éxito]

[NO éxito]

[Requiere reposición]


EntregadoEsperando

ionar primer item


item



Item

Rec

ibid

o

[Todos l

os ite

ms d

isponib

les]

Entregadorimer item

rimer item

rimer item

<< Ext >>

<< Inclu >> << Inclu >>

<< Ext >>

<< Inclu >>

Abrir Arqueo Hacer unInicio de Día

Hacer unFin de Día

Exportarmovimientos

Imprimirdocumento

SupervisorImportar nuevaconfiguración

Contabi l idad

CajeroCerrar Arqueo

6





CU Realizar pedido




© V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

Arq

uit

ectu

ra 6

_es

p -

Rev

. 5

.1 -

j

vila

lta@

vico

.org

lenguaje unificado

Documents