guía visual uml 0.17

8/18/2019 Guía Visual UML 0.17

1/47

UMLGuía Visual

C ó m o c r e a r

f o r m a s d e v i d a

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

© V i l a l t a Consu l t o r e s 2001

in fo@v ico .orgRev. 0.17

Josep V i l a l ta Marzo

Reg í s t r a t e e n

vico virtual c@mpus

mailto:[email protected]:[email protected]:[email protected]://www.vico.org/aRecursosPrivats/JosepVilaltaMarzo.pdfhttp://www.vico.org/learning/learning.phphttp://www.vico.org/learning/learning.phpmailto:[email protected]://www.vico.org/aRecursosPrivats/JosepVilaltaMarzo.pdfhttp://www.vico.org/http://www.vico.org/learning/learning.php


2/47

r g

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

UMLGuí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 nat ral actúa en los sistemas biológicos la contin idad de na VIO está


3/47

r g



Historial: 03/09/01 9:03




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

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

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

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

puede ser aplicado a la realidad tal como la conocemos y tal como la compartimos conlos 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 .


4/47

r g



Historial: 03/09/01 9:03




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

del código para conseguir un desarrollo más rápido de las aplicaciones (Rapid

Application Development). No comparto esta opinion. Si hay algo que caracteriza un

entorno de desarrollo actual es la constante del cambio. Todo proyecto que sobrepase

los tres meses está amenazado por la aparición de nuevas plataformas más exigentes, laextinció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


5/47

r g



Historial: 03/09/01 9:03


Proceso: Evaluación de contenidos ref.- contacto: [email protected] Autor: 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


6/47

r g



Historial: 03/09/01 9:03



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

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

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

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

diagramas de Interacción, los objetos que intercambian una serie de mensajes. A partirde 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


7/47

r g



Historial: 03/09/01 9:03



¿De dónde provienen las ideas expuestas?

El contenido de esta guía ha sido elaborado a partir del trabajo de una serie de

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

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

Ori ented 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 loslibros 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


8/47

r g



Historial: 03/09/01 9:03



Competencia y actuación

En los últimos veinte años de mi carrera profesional en el desarrollo de sistemas de

información he participado en una gran diversidad de proyectos con distintos grados de

responsabilidad e involucración, pero siempre con un compromiso firme en la calidad y

usabilidad del producto final.

Entorno industrial

o CIM para la extrusión de polietileno y fabricación de mallas agrícolas y

de embalaje.

o

CIM para el fraccionamiento de hemoderivadoso 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


9/47

r g



Historial: 03/09/01 9:03



Entorno de ingeniería del software

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

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

páginas HTML

o Framework de certificación de entregables

Entorno administrativo y de gestión

o Plan Funcional para la implementación SAP-Contabilidad

o Cuadro de control de indicadores de actividad y calidad

o Sistema de información Ejecutivo

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


10/47

r g



Historial: 03/09/01 9:03



Entorno docente

o Tutorías de proyectos de fin de carrera con UML

o Cursos de Análisis, Diseño y Patrones

o Talleres de introducción a UML

o Talleres avanzados de UML con Rose y Visio

o Talleres monográficos (Casos de Uso, Métrica, Metodología)

Entorno de I+D

o Bases de conocimiento con vocabularios controlados

o Procesador de lenguaje natural dentro del dominio médico

o Reconocimiento automático de conceptos clínicos a partir de textos no

estructurados


11/47

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

ó

d

i g o

DinámicaEventos - Estados

CronogramaPlan Director

Iteraciones

FuncionalidadDiagramas de

Casos de Uso

>

>

>

Use Case

>

Use ase

>

>

Actor

Actor

ClasesAná l i s i s

D iseño

I mplementac ión

Pedido

hacer /comprobaciónitem

Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

Client ePersonal

1*

1

*0. .1

*

* 1


hacer /comprobación


Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporat ivo

ClientePersonal

1*

1

*0..1

*

* 1




Verificando Sirviendo

EntregadoEsperando

ionar primer item


item

hacer /inicio deentregas

[Todos los items comprobados &&

todos los items disponibles]

I t e m

R e c i b i d

o

[ T o d

o s l o s i t e

m s d i s p

o n i b l e

s ]

Entregadorimer item

rimer item

rimer item


ionar primer item


item




I t e m

R e c i b i d

o

[ T o d

o s l o s i

t e m s d i s p

o n i b l e

s ]

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

ValidarP ago

SeleccionarPedidos

ValidarRiesgo

PPDI

G

CUCU

EscenariosI nteracció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 stock xxx línea : Línea de pedido

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

tieneStock:( )


pedidos

Un itemde stock

Una líneade pedido

Un pedido

[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido


: I te m de E xp ed ic i ón : I te m de P e di do d e re po si ci ón

1

©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D

U M

D_

e s p - R e v .

5 . 2 -

j v i l a l t a @ v i c o . o r g


12/47

Esfuerzo de desarrolloP D P

ProductoProcesosActividades

Entregables

TiempoFases

I teraciones

M i s i ó n

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

I ter a ci ones

I teracionespreliminares Iter #1 Iter #2 Iter #n

I ter#n+1 I ter #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

©


P D P i t e r a c i o n e s_

e s p - R e v .

4 . 2 -

j v i l a l t a @

v i c o . o r g

2


13/47

©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D P D

P m i s i ó n_

e s p 2 - R e v .

5 . 2 -

j v i l a l t a @ v i c o . o

r g

M i s i ó n

Con ce pc ión F or ma li z ac ión Con st ru cc ión T ra ns ic ión

I ter aci ones

Iteracionespreliminares Iter #1 Iter #2 Iter #n

Iter#n+1 Iter #n

Iter#n+2

Iter#n+1

Mo d e l o

C o m p o n e n te s


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

Concepc ión

Anteproyecto

Pa t rones de

Anál i sis

Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

ClientePersonal

1*

1

*0. .1

*

* 1




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporat ivo

ClientePersonal

1*

1

*0..1

*

* 1



hacer /comprobaciónP

Pa t rones de

Fu n c i o n a l i d a d

>

>

>

Use Case

Actor 2

Actor 1

Use Case

Use Case

Use Case

Use Case

Use Case

P

Procesos

principales

Matrícula

del proyecto



Iteraciones

PM

PPDIG

Misión

3


14/47

©


P m o d e l o

_ e s p 2 - R e v .

5 . 3 -


M i s i ó n


I ter aci ones


Iter#n+1 Iter #n

Iter#n+2

Iter#n+1

Mo d e l o



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

P D P

Fo r ma l i z ac i ón

Pa t rones de

Anál i sis

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporat ivo

ClientePersonal

1*

1

*0..1

*

* 1




Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

ClienteP ersonal

1*

1

*0..1

*

* 1



hacer /comprobaciónP

Pa t rones de

Fu n c i o n a l i d a d

>

>

>

Use Case

Actor 2

Actor 1

Use Case

Use Case

Use Case

Use Case

Use Case

P Modelo


Casos de Uso


y D i seño

>

>

>

Use Case

>

Use ase

>

>

Actor

Actor

Pedido


Cliente

Línea de P edido

Producto

Comercial

Client eCorporat ivo

ClientePersonal

1*

1

*0. .1

*

* 1




Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

ClientePersonal

1*

1

*0. .1

*

* 1





Flujos de Trabajo

DinámicaEventosEstados


EntregadoEsperando

ionar primer item


item




I t e m

R e c i b i d

o

[ T o d

o s l o s i

t e m s d i

s p o n i b l e

s ]

Entregadorimer item

rimer item

rimer item


ionar primer item


item




I t e m

R e c i b i d

o

[ T o d

o s l o s i t e m

s d i s p

o n i b l e

s ]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

CU * [para cada pedido seleccionado]

Entrar

Reposición

SeleccionarPedidos

Pendientes

AsignarItems

RegularizarStock

ActivarPedido

EntrarReposición

EntrarReposición


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarP ago

SeleccionarPedidos

ValidarRiesgo

EscenariosInteracción

de objetos



pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido


: I te m de E xp ed ic ió n : I te m de P ed id o de r ep os ic i ón

tieneStock:( )


pedidos

Un itemde stock

Una líneade pedido

Un pedido

[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido


: I te m de E xp ed ic i ón : I te m de P ed id o de r ep os ic ió n

4


15/47

©


P c o n s t r u c c i ó n_

e s p 2 - R e v .

5 . 3 -

j v i l a l t a @

v i c o . o r g

M i s i ó n


I ter aci ones


Iter#n+1 Iter #n

Iter#n+2

Iter#n+1

Mo d e l o




Pedido


Client e

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

ClienteP ersonal

1*

1

*0..1

*

* 1




Alumno P . Gl o ba l P . E sp . ResultadoSelección Ver

Destino

Versión

Tribunal

Año Académico*

**FechaActa

Alumnos

F ramewo r k de Ap l i c a c i o nes

Pa t rones de

D i seño

Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

Client ePersonal

1*

1

*0. .1

*

* 1




Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporat ivo

ClientePersonal

1*

1

*0..1

*

* 1




P

Const rucc ión

Alumno P . G lo ba l P . Es p. ResultadoSelección Ver

Destino

Versión

Tribunal

AñoAcadémico*

**

FechaActa

Alumnos

ClasesDiseño

I mplementac ión

Base de DatosEsquema de Persistencia

ArquitecturaComponentes

InterfaceGráfico de Usuario

Pedido


Cliente

Línea de P edido

Producto

Comercial


ClientePersonal

1*

1

*0. .1

*

* 1




Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

ClientePersonal

1*

1

*0. .1

*

* 1




Componentes

5


16/47

©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D P D P

_ e s p 2 - R e v .

6 . 2 -


Fo r ma l i z ac i ón

M i s i ó n

Con ce pc ión F or ma l iz ac ión Con st r ucc ió n T ra ns ic ión

I ter aci ones

Iteracionespreliminares Iter #1 Iter #2 Iter #n Iter#n+1 Iter #nIter#n+2 Iter#n+1

Mo d e l o




Modelo


Casos de Uso


y D i seño

>

>

>

Use Case

>

Use ase

>

>

Actor

Actor

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporat ivo

ClientePersonal

1*

1

*0..1

*

* 1




Pedido


Client e

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

ClienteP ersonal

1*

1

*0..1

*

* 1





Flujos de Trabajo

DinámicaEventosEstados


EntregadoEsperando

ionar primer item


item




I t e m

R e c i b i d

o

[ T o d

o s l o s i t e

m s d i s p

o n i b l e

s ]

Entregadorimer item

rimer item

rimer item


ionar primer item


item




I t e m

R e c i b i d

o

[ T o d

o s l o s i t e

m s d i s p

o n i b l e

s ]

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

Concepc ión

Anteproyecto

Procesosprincipales

Matrículadel proyecto



I teraciones

PM

PPDIG

Misión

Const rucc ión

Alumno P . G l o ba l P . E s p . ResultadoSelección Ver

Destino

Versión

Tribunal

Año Académico*

**FechaActa

Alumnos

ClasesDiseño

I mplementac ión

Base de DatosEsquema de Persistencia

ArquitecturaComponentes

I nterfaceGráfico de Usuario

Pedido


Cliente

Línea de Pedido

Producto

Comercial

ClienteCorporat ivo

ClienteP ersonal

1*

1

*0..1

*

* 1




Pedido


Client e

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

ClienteP ersonal

1*

1

*0..1

*

* 1




Componentes

EscenariosI nteracción

de objetos



pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido


: I te m de E xp ed ic i ón : I te m de P ed id o de r ep os ic i ón

tieneStock:( )


pedidos

Un itemde stock

Una líneade pedido

Un pedido

[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido


: I te m de E xp ed ic ió n : I te m de P e di do d e re po si ci ón

6


17/47

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

I nteracció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 Cajero

Automático> Subsistema

de cuentascliente

- Role de subsistema -

Subsitemade cert if icación

de mediosde pago

- Role de subsistema -

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

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

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

FuncionalidadDiagramas deCasos de Uso

>

Use ase

>

>

Actor

Actor

1

©


A c t o r e s_

e s p - R e v .

5 . 1 -



18/47

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

Exportar movimientos

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

reutili zables 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

Imprimir documento

Sistema en proceso de modelado

I nteracción de un

Actor con el Sistema

Interacción delSistema con un Actor

Supervisor - Rol de usuario -

Importar nuevaconfiguración

Contabil idad- Sistema externo -

Cajero- Rol de usuario - Cerrar Arqueo

>

>

>

>

>

Relación que indica el uso deuna funcionalidad compartida

por otros Casos de Uso


>

U se ase

>

>

Actor

Actor

2

©


U C s_

e s p - R e v .

5 . 1 -



19/47

Especificaciónde un Caso de Uso

LIMI

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 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 una

situació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 termina

el UC.

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

3. Sistema calcula los totales teóricos para cad a fo rma de cobr o.

4. Actor introduce totales reales para cadaforma de cobro.

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

descuadres.

6. Sistema imprime el documento “Tirade Arqueo”.

a. Cierre de arqueo de tipo abierto:• Actor decide el momento de imprimir eldocumento “Tira de Arqueo”.

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

arqueo 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 con fir mac ión para

continuar.

Hacer unFin de Día

Imprimir documento

Cerrar Arqueo >

>

Caso de Uso principal

Casos de Uso secundarios

Caso de Uso especializadoCaso de Uso genérico

Imprimir

t i ra de arqueo


>

U se ase

>

>

Actor

Actor

3

©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D L I M I T U C s_

e s p - R e v .

5 . 1 -

j v i l a l t a @ v i c o . o r

g


20/47

Ventajas del modeloUse Case

Pi ezas de funcionalidad reutil izablesen 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

Exportar movimientos

Imprimir documento

Importar nuevaconfiguración

Cerrar Arqueo

>

>

>

>

Hacer unFin de Día

>

Imprimir t i ra de arqueo

Abrir Arqueo


>

Use ase

>

>

Actor

Actor

4

©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D m o d e l o U C

_ e s p - R e v .

5 . 1 -



21/47

Requerimientos y Casos de Uso

Los Casos de Uso son requerimientos funcionales que describende una manera detallada el comportamiento del sistema con

los distintos Actores que interactúan con él.

No definen todos los requerimientos (por ej. los tipos 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

R e q uer

imie n t o s

M o d e

l

o

A r q u i

t e c t u r a

G e s t i ó

n d e

P r o y e c t o

C e r

t i f

i c a c i ó 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 prior idades

Funcionalidad,Análisis y Diseño

Implementaciónde código yRefactoring


>

Use ase

>

>

Actor

Actor

5

©


R e

q y C U s_

e s p - R e v .

1 . 1 -


Recepción Evento queCU Realizar pedido


22/47

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

Flu jo Pr inc ipa l Var iac iones

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

y cantidad.

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

3. Sistema comprueba cada línea de l pedi do p ara val idar la sit uac ión del

artículo en catálogo y el número de

items del artículo en stock.

4. Sistema comprueba la situación del pedi do .

a. SI se ha realizado el pago y SI todos los itemsdel 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 existensuficientes items del artículo en stock, sistema

aparca 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 ex iste n su fici ente s ite ms de l art ícul o enstock, 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 Generarpedido.

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

muestra artículos alternativos activando el

CU 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 de Trabajo


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarP ago

SeleccionarPedidos

ValidarRiesgo

1

©


A c

t i v i d a d 1

_ e s p - R e v .

7 . 1 -


CU A t li i ió


23/47



* [para cada pedido

seleccionado]

Recepciónde una

Reposición

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

F lu jo Pr in c ip a l

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

2. Sistema localiza los pedidos de clientesaparcados que pueden cumplimentarse

con la nueva entrada de items.

3. Usuario selecciona los pedidos declientes aparcados que decide

cumplimentar.

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

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

6. Sistema regulariza la situación de itemsen stock y revisa los umbrales de

reposició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 de Trabajo


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarP ago

SeleccionarPedidos

ValidarRiesgo

2

©


A c

t i v i d a d 2

_ e s p - R e v .

5 . 2 -


DescripciónRecepción 3


24/47



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 responsabil idad(swim-lines)

* [para cada línea de pedido]

Recepciónde un

Pedido

IdentificarCliente

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 pedido

seleccionado]

Seleccionar

Pedido

BuscarPedidos aparcados

[Todos las reposiciones entradas]

RegularizarStock

ComprobarArtículo

AsignarItems

Flujos de Trabajo


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

3

©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D A c t i v i d a d 3

_ e s p - R e v .

6 . 1 -

j v i l a l t a @ v i c o . o r

g

Descripción 4


25/47



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 de Trabajo


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

4

©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D A

c t i v i d a d 4

_ e s p - R e v .

5 . 2 -


óCU Realizar pedido


26/47

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 en

el flujo de eventos de un Caso de Uso.

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.

(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 nuevo

objeto

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

Flu jo Pr inc ipa l Var iac ion es


y cantidad.

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

3. Sistema comprueba ca da línea del ped ido para val ida r la sit uac ión del



p


c. NO ex isten sufi cien tes items del a rtíc ulo e nstock, o la asignación de items deja la






CU Seleccionar artículo.

:Una Cartera

de Items

en Stock

:Un Pedido

de

Reposición

:Una Ventana de

introducción de

Pedidos

:Un Pedido:Una Línea

de Pedido

Escenarios

tieneStock:( )


pedidos

Un itemde stock

Una líneade pedido

Un pedido

[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



1

©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D S

e c u e n c i a

_ e s p - R e v .

6 . 1 -


DescripciónCU Realizar pedido 2


27/47

Descripciónde un Escenario

Diagrama de ColaboraciónNotación UML 1.3

2: generarPedido ( ) 5: comprobarStock ( )

6: asignarItems ( )

7: realizarReposición ( )

Objeto(I nstancia de una Clase)

Auto-mensaje

8: generarReposición ( )

Número de secuencia

Mensajes enviados entre los objetos descritos en

el flujo de eventos de un Caso de Uso.

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.

(1)

Un escenario describe una instancia del flujo de eventos deun Caso de Uso, con sus variaciones o extensiones posibles

y 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.


Flu jo Pr inc ipa l Var iac iones


y cantidad.

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

3. Sistema comprueba cada línea de l pedi do p ara val idar la sit uac ión del



CU Realizar pedido


c. NO ex iste n su fici ente s ite ms d el a rtícu lo e nstock, o la asignación de items deja la







: 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

Una líneade pedido

Un pedido

[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



1: identificarCliente ( )

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

Mensaje (1)

2

©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C

o l a b o r a c i ó n_

e s p - R e v .

6 . 1 -

j v i l a l t a @ v i c o

. o r g

1


28/47

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:• I dentidad ¿Quien soy? = Atributos• P ropósito ¿Cual es mi misión? = J ustificació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 P edido

Producto

Comercial


ClientePersonal

1*

1

*0. .1

*

* 1




1

©


l a s e s 1

_ e s p - R e v .

6 . 1 -


Ab t ió 2


29/47

Abstracción

m é t o d o 4

m é t o d

o 1

Atributos

Clases

Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

Client ePersonal

1*

1

*0. .1

*

* 1




m é t o d o 2

m é t o d

o 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 ordenado

y autosuficiente.

vacp 104

2

©


l a s e s 2

_ e s p - R e v .

3 . 1 -


Obj t 3


30/47

Objeto

e l e v a r P l a t a f o r m a

c a r g

a r I t e

m

Atributos

Clases

Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

Client ePersonal

1*

1

*0. .1

*

* 1




m o v e r H a c

i a

b a j a

r P l a t a

f o r m

a

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 susa t r i bu tos (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 Palets

vacp104¿Qué puedo hacer?

¿Qué conozco?

¿Quien soy?

3

©


l a s e s 3

_ e s p - R e v .

2 . 2 -


Mensaje 4


31/47

Mensaje

Clases

Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

Client ePersonal

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.

e l e v

a r P l a t a f o r m a

c a r g a r I t e

m

Atributos

m o v e r H a c i a

b a j a

r P l a t a f o

r m a

Objeto Receptor

vacp104 moverHacia: binB7Objeto Emisor

Nomb re d el obje to rec ept or

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

©


l a s e s 4

_ e s p - R e v .

1 . 2 -


Encapsulación 5


32/47

Clases

Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

Client ePersonal

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

e l e v a r P l a t a f o r m

a

c a r g

a r I t e

m

Atributos

m o v e r H a c i a

b a j a r P

l a t a

f o r m

a

Conjunto de operaciones

externamente visibles que

define el comportamiento

de un objeto

5

©


l a s e s 5

_ e s p - R e v .

3 . 1 -


Herencia

6


33/47

Clases

Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

Client ePersonal

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 y

atributos. Tambien, pueden redefinir algunos de losheredados (overriding).

Herencia


vac 104

vac 104

vac 103vacp 104

Instancias de


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 las

especializaciones de una Clase.

Vehículo AutomáticoCarga Palets

SubClase

Vehículo AutomáticoCarga Bobinas

SubClase

Vehículo Automático de Carga

SuperClase


c a r g a r I t e

m

Atributos

m o v e r H

a c i a

b a j a

r P l a t a

f o r m

a

vacp 104 © V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D C

l a s e s 6

_ e s p - R e v .

1 . 2 -


Composición 7


34/47

Composición

Clases

Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

ClienteP ersonal

1*

1

*0..1

*

* 1




E n te r t i t l e h e r e

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 MinimizeClose

List box

Grid

Entertitle here

< B ac k N ex t > C an ce l

Ventana Wizard

©


l a s e s 7

_ e s p - R e v .

2 . 1 -


Polimorfismo 8


35/47

Clases

Pedido


Cliente

Línea de P edido

Producto

Comercial

ClienteCorporat ivo

Client ePersonal

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 un

vehí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 cargarI tem , 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ático

Carga Palets

SubClase

Vehículo Automático

Carga Bobinas

SubClase


c a r g

a r I t e

m

Atributos

m o v e r H a c i a

b a j a

r P l a t a

f o r m

a

vacb 117


c a r g a r I t e

m

Atributos

m o v e r H a c i a

b a j a

r P l a t a

f o r m

a

vacp 104

Vehículo Automático de Carga

SuperClase

©


l a s e s 8

_ e s p - R e v .

1 . 1 -


VisibilidadP didCliente 9


36/47

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 desarrol lo (C++, Smalltalk, J ava) desarrol la 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 hade disponer de un indicador de visibilidad.

Clases

Pedido


Cliente

Línea de P edido

Producto

Comercial


ClientePersonal

1*

1

*0. .1

*

* 1




Visibilidad C++ Smalltalk J ava

+ Publica

- Privada

# P rotegida

Package

Ejemplos

Un elemento siempre es visible en cualquier

pa rt e de l prog ra ma y pued e se r ll am ad o y

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 laClase que lo define, o por las subclases de

dicha Clase.

Consideremos la Clase CLIENTE que disponede una subclase CLIENTE PERSONAL.Consideremos también que el objeto , es una instancia de CLIENTEPERSONAL.

• 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

par a CLIENTE y CLIENTE PERSONAL.

Todas las operaciones son

púb licas p or de fec to.

Todas las variables

instanciadas son privadas.

, puede acceder acualquier variable instanciada dentro

de su propio objeto, si dicha variable

ha sido definida dentro de CLIENTEo CLIENTE PERSONAL. De esta

manera, el concepto de visibilidad priv ada en Smal lta lk e s p are cido al

concepto de visibilidad protegida en

C++.

Consideremos la instancia de CLIENTEPERSONAL, >, este objeto

pued e ac cede r a cual quie r el emen to de , que ha sido definido también como unainstancia de CLIENTE PERSONAL, sea

públ ico , pr iva do o prot egi do. ,a su vez también puede acceder a cualquier

elemento privado, protegido o público de

En C++, podemos acceder a elementos de otros

objetos de la propia Clase, de la misma manera

que podemos acceder a los propios elementos

de un objeto.

En Smalltalk 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, , n o pued e a cce der a l as vari abl es

instanciadas privadas de , sólo a sus operaciones públicas.

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 otraClase en el mismo Package como la

Clase propietaria. Esto implica que en

Java, el concepto de visibilidad

prot egida es más públ ico que package .

Un elemento sólo puede ser usado por

otras Clases que compartan el mismo

Package.

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

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 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 pued en ser usa dos por otra s C las es del

mismo package.

Línea de Pedido

+ hacer /comprobación

9

©


C l a s e s v i s i b i l i d a d

_ e s p - R e v .

5 . 3 -

j v i l a l t a @ v i c

o . o r g

Descripción1

Flu jo Pr in c ip a l Var iac iones

CU Realizar pedido


37/47

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 pueden

ocurrir.• 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 disponibles][No todos los items comprobados]

/seleccionar siguiente item


algunos items no estan disponibles

en stock]

Item Recibido

[algunos items no estan disponibles

en stock]

I t e m

R e c i b i d

o

[ T o d

o s l o s i t e

m s d i s p

o n i b l

e s ]

Pedido Entregado

1

2

3

4

5

6

DinámicaEstados


ionar primer item


item




I t e m

R e c i b i d

o

[ T o d

o s l o s i t e

m s d i s p

o n i b

l e s ]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

Flu jo Pr in c ip a l Var iac iones


y cantidad.

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

3. Sistema comprueba cada línea de l pedi do p ara vali dar la sit uac ión del



4. Sistema comprueba la situación del ped ido .

a. SI se ha realizado el pago y SI todos los itemsdel 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 existensuficientes 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 plazoconvenido, sistema cancela el pedido.


c. NO ex iste n su ficie ntes items del artíc ulo enstock, o la asignación de items deja la







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

*

1

seleccionar ( )comprobar ( )servir ( )

cerrar ( )...


©

V i l a l t a C o n s u l t o r e s 2 0 0 1 - T R A D D

i n á m i c a 1

_ e s p - R e v .

5 . 1 -

j v i l a l t a @ v i c o . o

r g

Descripción

2Flu jo Pr inc ipa l Var iac ion es

CU Realizar pedido


38/47

Descripciónde la Dinámica del Sistema

Diagrama de Estadosde un PedidoNotación UML 1.3

Comprobando Sirviendo

EntregadoEsperando

/seleccionar primer item


item


[No todos los items comprobados]

/seleccionar siguiente item


algunos items no estan disponibles

en stock]

Item Recibido

[algunos items no estan disponibles

en stock]

I t e m

R e c i b i

d o

[ T o d

o s l o s i t e m

s d i s p

o n i b l e

s ]

Pedido Entregado

PedidofechaRecibidoconPrepagonúmero: Alfanúm.

importe: Núm&2d.divisa...

*

1

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

InicioClase

Atributos

Operaciones

prim era Transición

Estado

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ápida

d

guía visual uml 0.17

Documents