lenguaje unificado

UMLGua 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.org

Proyecto: Presentacin del borrador: UML Gua Visual Documento: UML Gua Visual Historial: 03/09/01 9:03 Situacin: Borrador en curso de revisin Proceso: Evaluacin de contenidos ref.- contacto: [email protected] Autor: Josep Vilalta

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

Fecha actualizacin:

04/09/01 11:16 Revisin:

18 Pgina:

1 de 9

UML Gua Visual

Cmo crear formas de vida organizativa

Presentacin Esta gua describe como definir, organizar y visualizar lo que denominamos formas de

vida organizativa (VIO) con la notacin Unified Modelling Language (UML). Una VIO

representa un ciclo de actividad realizado por uno o varios agentes con un propsito

concreto, en base a una prctica consensuada para utilizar los recursos disponibles y

para tomar las decisiones que caracterizan el comportamiento de una organizacin.

A diferencia de los sistemas biolgicos, las VIO nacen y se desarrollan a partir de una

voluntad compartida, de una idea y de un liderazgo. Pero de la misma manera que la

seleccin natural acta en los sistemas biolgicos, la continuidad de una VIO est

condicionada a la implementacin eficiente de sus procesos esenciales. Conocer estos

procesos, saber como aplicar los recursos y como tomar las decisiones para satisacer la

cadena de valor de todos los agentes son los factores que toda organizacin ha de tener

en cuenta para evolucionar y asegurar su viabilidad.

La notacin UML (no hay que confundir con las metodologas que utilizan dicha

notacin), se ha convertido desde finales de los 90 en un estndar para modelar con

tecnologa orientada a objetos todos aquellos elementos que configuran la arquitectura

de un sistema de informacin y, por extensin, de los procesos de negocio de una

organizacin. De la misma manera que los planos de un arquitecto disponen el esquema

director a partir del cual levantamos un edificio, los diagramas UML suministran un

modelo de referencia para formalizar los procesos, reglas de negocio, objetos y

componentes de una organizacin. La interaccin de todos estos elementos es una

representacin de nuestra realidad.

vico.org



Fecha actualizacin:

04/09/01 11:16 Revisin:

18 Pgina:

2 de 9

Nuestros lmites para entender esta realidad estn en nuestro lenguaje. El mundo es la

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

manera un modelo en UML representa nuestra experiencia?. Ensear a utilizar un

lenguaje formal siempre es problemtico. Es necesario mostrar como este lenguaje

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

los dems. Con esta gua visual mostramos de manera precisa las tcnicas bsicas para

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

procedimientos esenciales que nos permiten evitar costosas confusiones conceptuales.

No es mediante el descubrimiento de nuevos objetos y de sus mltiples conexiones que

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

sino mediante la disolucin de las contradicciones que existen entre los trminos

(conceptos) ya conocidos y, en ltimo caso, mediante la reduccin de su nmero

despejando aquellos conceptos que no aaden valor a la comprensin de dicho dominio.

Reconsiderar lo obvio, desenmascarar presunciones, desambigar conceptos conocidos,

todo en busca de la simplicidad y la usabilidad.

La tecnologa orientada a objetos persigue el antiguo principio del divide y vencers. Su

objetivo es descomponer la complejidad en partes ms manejables y comprensibles. No

parece que esto sea algo novedoso con respecto a la tradicional descomposicin

funcional de los mtodos estructurados. Sin embargo, la gran diferencia reside en

aplicar la dualidad estructura-funcin en pequeas unidades capaces de comunicarse y

reaccionar en base a la aparicin de una serie de eventos. El esquema dominante de la

separacin de estructuras de datos y funciones (bases de datos y programas) est

amenazado pero an se resiste a desaparecer.

vico.org



Fecha actualizacin:

04/09/01 11:16 Revisin:

18 Pgina:

3 de 9

Mucha gente cree que la principal utilidad de la orientacin a objetos es la reutilizacin

del cdigo para conseguir un desarrollo ms rpido de las aplicaciones (Rapid

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

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

los tres meses est amenazado por la aparicin de nuevas plataformas ms exigentes, la

extincin de herramientas sin previo aviso y, de manera sistemtica, por la rotacin del

personal crtico encargado del proyecto. Tambin est sometido, como no, a los

cambios de requerimientos del cliente que a su vez estn plenamente justificados por la

readaptacin de sus procesos de negocio a un mercado inestable.

Ante este cuadro de incertidumbre, el mayor desafio de una metodologa de desarrollo

es su adaptacin para el cambio. Esto significa crear modelos que faciliten la

comunicacin entre todos los agentes involucrados en el sistema en construccin; que

hagan visible la trazabilidad entre la concepcin de los componentes, su especificacin,

implementacin e instalacin; significa el diseo de arquitecturas que faciliten la

gestin de las dependencias entre estos componentes, que sean en fin, facilmente

reemplazables por otros ms optimizados o bien por componentes que aporten una

mayor funcionalidad y/o facilidad de uso.

La dinmica de cambio no se desarrolla en la ingeniera del software con la misma

velocidad vertiginosa con que nos tiene acostumbrados la tecnologa del hardware. La

clave reside en que a diferencia de la electrnica, en los dominios del desarrollo de

software no existe un vocabulario unificado. Desde la fase de concepcin de un sistema

a la instalacin de sus componentes hay que mapear entre s una gran diversidad de

lenguajes orientados al anlisis, diseo, cdigo ejecutable, esquemas de bases de datos,

componentes de pginas web, entre otros. Esta distancia entre la concepcin y la

usabilidad de un producto o de un proceso de negocio, exige cada vez ms la capacidad

de cooperacin y comunicacin de un equipo interdisciplinar muy especializado. Esta

gua visual de UML est pensada para facilitar este proceso cooperativo y para ayudar a

establecer una buena prctica fundamentada en un lenguaje comn.

vico.org



Fecha actualizacin:

04/09/01 11:16 Revisin:

18 Pgina:

4 de 9

A quin va dirigida esta gua visual? Esta gua ha sido escrita y diseada para los profesionales involucrados en todos los

ciclos de actividad del desarrollo de sistemas de informacin (concepcin, anlisis y

diseo, implementacin, instalacin de aplicaciones, gestin y certificacin de

proyectos); tambin para los que tengan responsabilidades en la especificacin de

procesos de negocio con el propsito de evaluar posibles reingenieras de procesos y/o

diseo de bases de conocimiento; y finalmente, para aquellos equipos que estn

inmersos en la preparacin e implementacin de certificaciones de calidad.

La claridad conceptual y los recursos didcticos utilizados en la exposicin de los

distintos procedimientos sern de utilidad para los estudiantes que sigan programas de

autoaprendizaje y usen esta gua como complemento para sus lecturas de libros sobre

UML. Tambin los centros acadmicos y profesores dispondrn con esta gua de

material interesante para completar sus diseos curriculares y proporcionar ejemplos

prcticos a sus alumnos.

Cmo sacar un mayor provecho a su lectura? La gua est organizada en unidades didcticas que describen la notacin de los

diagramas y las fuentes de informacin necesarias para definir los elementos de cada

modelo. Puede usarse como consulta puntual de la notacin de un diagrama, o bien,

para revisar como establecer el hilo conductor entre los Casos de Uso (mapa funcional),

las Clases de dominio (mapa conceptual), las Clases de Especifiacin (types e

interfaces) y las Clases de Implementacin (cdigo).

vico.org



Fecha actualizacin:

04/09/01 11:16 Revisin:

18 Pgina:

5 de 9

Un plan de estudio para realizar una progresiva asimilacin de los conceptos podra

empezar con los Casos de Uso (CU) y continuar con el anlisis de los flujos de trabajo

de un grupo de CU mediante los diagramas de Actividad; a continuacin, separar los

escenarios que agrupan una serie de actividades y hacer aflorar, a travs de los

diagramas de Interaccin, los objetos que intercambian una serie de mensajes. A partir

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

abstraccin de los objetos y comprender la importancia de separar las tres perspectivas

bsicas en nuestra representacin de las clases: concepcin, especificacin e

implementacin. El siguiente paso es identificar alguna clase con un comportamiento

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

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

Transicin ser el adecuado para representar esta dinmica de estados. Finalmente,

abordaremos la configuracin de componentes y su despliegue en una arquitectura.

Otra lectura de la gua puede estar mas centrada en el seguimiento de la metodologa de

desarrollo y la gestin de un proyecto. En este caso, las primeras secciones describen

los niveles de concepcin y formalizacin de un proyecto con la metodologa TRAD

(Taller de Requerimientos, Anlisis y Diseo basado en el Proceso Unificado de

Rational), y se van introduciendo progresivamente los diagramas y actividades que

configuran la unidad mnima de documentacin sostenible para un proyecto concreto.

El estudiante ms avanzado podr sacar tambin provecho con la consulta puntual de

los diagramas en que est ms interesado y la revisin de sus extensiones. Las materias

expuestas en las distintas secciones estn actualizadas constantemente y pueden

descargarse nuevas ediciones desde: http://www.vico.org/UMLguiavisual/

vico.org



Fecha actualizacin:

04/09/01 11:16 Revisin:

18 Pgina:

6 de 9

De dnde provienen las ideas expuestas? El contenido de esta gua ha sido elaborado a partir del trabajo de una serie de

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

proyectos. Desde principios de los 90, los artculos publicados en el Journal of Object

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

Desmond dSouza, Bertrand Meyer, Steve Cook, John Daniels, Sally Shlaer y

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

Publicaciones pioneras como el Object Oriented Technology, A Managers Guide de

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

tenido una gran influencia en como abordar la presentacin didctica. Tambin los

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 enciclopdica The Unified Modeling Language: Reference Manual de Rumbaugh

& Jacobson & Booch, es un punto de referencia constante. Sin duda, uno de los autores

ms influyentes ha sido Martin Fowler. Su primer libro Analysis Patterns continua

siendo una referencia clave. Posteriormente, la primera edicin de UML Distilled en

1997 y su ltima edicin ampliada en 2000, se ha convertido en el libro de cabecera de

UML. Otro clsico por la excelencia de su trabajo es Applying UML and Patterns de

Craig Larman que en su segunda edicin aparecida en verano de 2001 se ha superado

a si mismo. Tambin recientes y con muy buen material que ha sido incorporado a la

gua, tenemos los libros de Wendy & Michael Boggs, Mastering UML with Rational

Rose, de Alistair Cockburn, Writing Effective Use Cases; de Scott W. Ambler, The

Object Primer segunda edicin; y de John Chessman & John Daniels, UML

Components, una de las novedades ms interesantes de 2001. En la bibliografa sobre

UML publicada en http://www.vico.org hay una relacin completa de los libros

consultados que se actualiza peridicamente con las ltimas novedades.

vico.org



Fecha actualizacin:

04/09/01 11:16 Revisin:

18 Pgina:

7 de 9

Competencia y actuacin En los ltimos veinte aos de mi carrera profesional en el desarrollo de sistemas de

informacin he participado en una gran diversidad de proyectos con distintos grados de

responsabilidad e involucracin, pero siempre con un compromiso firme en la calidad y

usabilidad del producto final.

Entorno industrial o CIM para la extrusin de polietileno y fabricacin de mallas agrcolas y

de embalaje.

o CIM para el fraccionamiento de hemoderivados o Plan Funcional para la implementacin SAP-Logstica

Entorno sanitario o Gestin de Bancos de Sangre y Hemoterapia o Planificacin y gestin de campaas de captacin de donantes o Gestin mutual de prestaciones asistenciales o Tarjeta Sanitaria para certificar transacciones asistenciales o Automatizacin de autoanalizadores de laboratorios de anlisis o Integracin de peticiones analticas multicentricas y publicacin de

resultados

o Gestin de laboratorios farmacuticos o Historia Clnica Orientada por Problemas Automatizada o Libreta de Salud para programacin de citas y exploraciones o Gestin integrada de servicios de Atencin Primaria o Plan Funcional para la implementacin SAP-Gestin Clnica y

Asistencial

vico.org



Fecha actualizacin:

04/09/01 11:16 Revisin:

18 Pgina:

8 de 9

Entorno de ingeniera del software o Framework de clases de anlisis para definir mapas conceptuales o Framework de servicios comunes para la publicacin dinmica de

pginas HTML

o Framework de certificacin de entregables

Entorno administrativo y de gestin o Plan Funcional para la implementacin SAP-Contabilidad o Cuadro de control de indicadores de actividad y calidad o Sistema de informacin Ejecutivo

Entorno comercial o Merchandising de productos farmacuticos o Subastas y liquidacin de lotes o Gestin de redes de puntos de venta con videoconferencia

Entorno de servicios o Auditoras Informticas o Plan de Sistemas de Informacin o Integracin de sistemas de informacin de contabilidad administrativa y

general

Entorno acadmico o Programa de acceso a la universidad para mayores de 25 aos o Gestin de ttulos universitarios o Estudios de tercer cliclo: diseo curricular, publicacin y gestin

acadmica

vico.org



Fecha actualizacin:

04/09/01 11:16 Revisin:

18 Pgina:

9 de 9

Entorno docente o Tutoras de proyectos de fin de carrera con UML o Cursos de Anlisis, Diseo y Patrones o Talleres de introduccin a UML o Talleres avanzados de UML con Rose y Visio o Talleres monogrficos (Casos de Uso, Mtrica, Metodologa)

Entorno de I+D o Bases de conocimiento con vocabularios controlados o Procesador de lenguaje natural dentro del dominio mdico o Reconocimiento automtico de conceptos clnicos a partir de textos no

estructurados

Agradecimientos En primer lugar a los clientes que con su confianza han permitido que pueda desarrollar

mi carrera profesional. Tambin a los autores antes mencionados por su valioso trabajo

en el avance de la disciplina de la ingeniera del software y en la consolidacin de UML

como lingua franca.

Josep Vilalta

Badalona, Barcelona (Espaa)

[email protected]

http://www.vico.org

Niveles de concepcin y formalizacinde un proyecto

Nivel

Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5

ProcesosPrincipales

Glosariode Conceptos

Matrculadel Proyecto

Code like hell

EspecificacinCasos de Uso

Flujosde Trabajo

C

di

go

DinmicaEventos - Estados

CronogramaPlan Director

Iteraciones

FuncionalidadDiagramas de

Casos de Uso

>

>

>

Use Case

>

Use Case

>

>

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 /comprobacinitem

Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Verificando Sirviendo

EntregadoEsperando

ionar primer item

hacer /comprobacin

item

hacer /inicio deentregas

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

Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item


ionar primer item

hacer /comprobacin

item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

P

M

* [para cada pedido seleccionado]

EntrarReposicin

SeleccionarPedidos

Pendientes

AsignarItems

RegularizarStock

ActivarPedido

EntrarReposicin

EntrarReposicin


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

PPDI

G

CUCU

EscenariosInteraccin

de objetos

tieneStock:= comprobar ( )

Una ventana deintroduccin de

pedidos

Un itemde stock

Una lneade pedidoUn pedido

[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido

xxx stock : item de stockxxx lnea : Lnea de pedido

: Item de Expedicin : Item de Pedido de reposicin

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

[email protected]

vico

.org

Esfuerzo de desarrol loP D P

ProductoProcesosActividadesEntregables

TiempoFases

Iteraciones

M i s i n

Concepcin Formalizacin Construccin Transicin

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

[email protected]

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

[email protected]

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 deAnlisis

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacinP

Patrones deFuncionalidad

>

>

>

Use Case

Actor 2

Actor 1

Use Case

Use Case

Use Case

Use Case

Use Case

PProcesos

principalesMatrcula

del proyecto



Iteraciones

PM

PPDIG

Misin

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

[email protected]

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 deAnlisis

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacinP

Patrones deFuncionalidad

>

>

>

Use Case

Actor 2

Actor 1

Use Case

Use Case

Use Case

Use Case

Use Case

PModelo


Casos de Uso


y D i s e o

>

>

>

Use Case

>

Use Case

>

>

Actor

Actor

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin


Flujos deTrabajo

DinmicaEventosEstados


EntregadoEsperando

ionar primer item

hacer /comprobacin

item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item


ionar primer item

hacer /comprobacin

item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

CU * [para cada pedido seleccionado]Entrar

Reposicin

SeleccionarPedidos

Pendientes

AsignarItems

RegularizarStock

ActivarPedido

EntrarReposicin

EntrarReposicin


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

[email protected]

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

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Alumno P. Global P. Esp. ResultadoSeleccin Ver

4

4

Destino

Versin

Tribunal

Ao Acadmico*

**FechaActa

Alumnos

Frameworkde Aplicaciones

Patrones deDiseo

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

P

C o n s t r u c c i n


4

4

Destino

Versin

Tribunal

Ao Acadmico*

**FechaActa

Alumnos

C l a s e sD i s e o


Base de DatosEsquema de Persistencia

ArquitecturaComponentes

InterfaceGrfico de Usuario

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Componentes

5

V

ilal

ta C

on

sult

ore

s 2

00

1 -

TR

AD

PD

P_

esp

2 -

Rev

. 6

.2 -

j

vila

[email protected]

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

>

>

>

Use Case

>

Use Case

>

>

Actor

Actor

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin


Flujos deTrabajo

DinmicaEventosEstados


EntregadoEsperando

ionar primer item

hacer /comprobacin

item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item


ionar primer item

hacer /comprobacin

item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

CU * [para cada pedido seleccionado]Entrar

Reposicin

SeleccionarPedidos

Pendientes

AsignarItems

RegularizarStock

ActivarPedido

EntrarReposicin

EntrarReposicin


ActivarPedido

RegularizarStock

AsignarItems

EntrarPedido

ValidarPago

SeleccionarPedidos

ValidarRiesgo

C o n c e p c i n

Anteproyecto

Procesosprincipales

Matrculadel proyecto



Iteraciones

PM

PPDIG

Misin

C o n s t r u c c i n


4

4

Destino

Versin

Tribunal

Ao Acadmico*

**FechaActa

Alumnos

C l a s e sD i s e o


Base de DatosEsquema de Persistencia

ArquitecturaComponentes

InterfaceGrfico de Usuario

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

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 bsqueda de Actores.-

1. Quien est interesado en un requerimiento concreto ?

2. En qu dominios de la organizacin se usar el sistema ?

3. Quien ser beneficiario de la nueva funcionalidad ?

4. Quien proveer, usar y/o retirar, informacin ?

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 actuarn con un mismo rol ?

9. Interaccionar el nuevo sistema con un sistema antiguo ?

Cmo identificar Actores ?

Sistema en proceso de modelado

Interaccin de unActor con el Sistema

Interaccin delSistema con un ActorCliente

- Role de usuario -

Actores

Representan a un agente que interacta con el sistema No son parte del sistema que se desarrolla Entran informacin al sistema Reciben informacin del sistema Entran y reciben informacin

Relacin que indica laespecializacin a partir de una

funcin genrica

Realizar unatransaccin

Usar CajeroAutomtico

> Subsis temade cuentas

cl iente- Role de subsis tema -

Subsi temade cer t i f icacin

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

FuncionalidadDiagramas deCasos de Uso

>

Use Case

>

>

Actor

Actor

1

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D A

cto

res_

esp

- R

ev.

5.1

-

jvi

lalt

[email protected]

co.o

rg

A la bsqueda de Casos de Uso.-

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

2. Algn actor crear, almacenar, cambiar, borrar o leer informacin del sistema ?

3. Qu Casos de Uso crearn, almacenarn, cambiarn, borrarn o leern esta informacin ?

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 darn soporte y mantendrn el sistema ?

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

Cmo identificar Casos de Uso ?

Abrir ArqueoHacer un

Inicio de Da

Hacer unFin de Da

Exportarmovimientos

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

reutilizables en diferentes procesos

Relacin que describe una variacinposible del comportamiento normal

de un Use Case

Relacin que permite descomponerun Use Case con un determinado

nivel de granularidad

Imprimirdocumento

Sistema en proceso de modelado

Interaccin de unActor con el Sistema

Interaccin delSistema con un Actor

Supervisor- Rol de usuario -

Importar nuevaconfiguracin

Contabi l idad- Sis tema externo -

Cajero- Rol de usuario - Cerrar Arqueo

>

>

>

>

>

Relacin que indica el uso deuna funcionalidad compartida

por otros Casos de Uso


>

Use Case

>

>

Actor

Actor

2

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D U

Cs_

esp

- R

ev.

5.1

-

jvi

lalt

[email protected]

co.o

rg

Especificacinde un Caso de Uso

LIMIT

Lmites: Cuando empieza y cmo termina el Caso de Uso.

Interacciones: Comportamiento de Actores y Sistema.Accin-Reaccin dentro del Caso de Uso.

Masa: Conjunto de Objetos e Interfaces que 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.

Propsito- Regla de Negocio - Precondiciones Activacin Flujo Principal Variaciones Excepciones

Cerrar un periodo demovimientos de cajapara obtener unasituacin real de dineroen efectivo y endocumentos.

Arqueo abierto Actor habilitado TPV abierto TPV habilitado

A discrecin de un Actorhabilitado

1. Sistema requiere confirmacin decierre de arqueo.

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

2. Sistema comprueba la configuracinde TPV para identificar tipo de cierre.

3. Sistema calcula los totales tericospara 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 tericos para

cada forma de cobro.

a. Si impresora est off-line, sistema informaal usuario y le pide confirmacin paracontinuar.

Hacer unFin de Da

Imprimirdocumento

Cerrar Arqueo >

>

Caso de Uso principal

Casos de Uso secundarios

Caso de Uso especializadoCaso de Uso genrico

Imprimir

t i ra de arqueo


>

Use Case

>

>

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

[email protected]

vico

.org

Ventajas del modeloUse Case

Piezas de funcionalidad reutilizablesen diferentes procesos de negocio

1. Lenguaje de comunicacin entre usuariosy desarrolladores.

2. Comprensin detallada de la funcionalidaddel sistema.

3. Acotacin precisa de las habilitaciones delos usuarios.

4. Gestin de riesgo ms eficiente paragobernar la complejidad.

5. Estimacin ms exacta para determinartiempo, recursos y prioridades en la dosificacinde esfuerzo de desarrollo.

6. Fiel trazabilidad para verificar la traduccinde requerimientos en cdigo ejecutable.

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

8. Certificacin contractual Cliente-Desarrollador.

9. Documentacin orientada al usuario: Helps- Manual de Procedimientos - Reglas de Negocio.

10. Documentacin orientada al administradordel sistema: Soporte de Mantenimiento.

Hacer unInicio de Da

Exportarmovimientos

Imprimirdocumento

Importar nuevaconfiguracin

Cerrar Arqueo

>

>

>

>

Hacer unFin de Da

>

Imprimirt i ra de arqueo

Abrir Arqueo


>

Use Case

>

>

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

[email protected]

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 interactan 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 unaaplicacin.

Caso de Uso

Requerimientos

Mod

elo

Arquit

ectu

ra

Gestin

de Proyecto

Cer

tif i

caci

n

Reglasde Negocio

y protocolos deintercambio de

informacin

Funcionales,no funcionalese interfaces de

usuario

Mapa conceptual:Clases de anlisis

Dinmica deClases complejas

Mapa funcional:Flujos de trabajo

principales yvariaciones

Escenarios deinteraccinde objetos:

Clases de diseo

Mtrica:Escandallo de

recursosy actividades

Plan Directorde Iteraciones:

Cronogramay prioridades

Funcionalidad,Anlisis y Diseo

Implementacinde cdigo yRefactoring


>

Use Case

>

>

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

[email protected]

vico

.org

Descripcinde 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 ActividadNotacin UML 1.3

* [para cada lnea de pedido]

Concurrencia dinmica de actividades

Recepcinde un

Pedido

[SI vigente]

[NO]

Barra de sincronizacin

Actividad

Punto de decisin

Barra de fusin

Condicin lgica: verdadera o falsa,que permite la transicina otra actividad

Evento quedesencadenala secuencia deactividades

Anlisis 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 sucdigo de artculo, tipo de presentaciny cantidad.

b. SI existen suficientes items del artculo enel stock, sistema asigna items al pedido.

3. Sistema comprueba cada lnea delpedido para validar la situacin delartculo en catlogo y el nmero deitems del artculo en stock.

4. Sistema comprueba la situacin 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 artculo en stock, sistemaaparca el pedido del cliente activando el CUAparcar pedido.

c. SI no se ha realizado el pago segn el plazoconvenido, sistema cancela el pedido.

CU Realizar pedido

1. Usuario identifica el cliente que haenviado un pedido.

c. NO existen suficientes items del artculo enstock, o la asignacin de items deja lasituacin del artculo en stock por debajo delnivel de reposicin, sistema genera pedidode reposicin activando el CU Generarpedido.

a. Artculo NO est vigente en catlogo, sistemainforma que articulo no est vigente ymuestra artculos alternativos activando elCU Seleccionar artculo.

[NO vigente]

[NO Stock] o[SI umbral reposicin]

[SI]

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

CancelarPedido

IdentificarCliente

Entrarlneas pedido

ComprobarArtculo

ComprobarPago

ServirPedido

Generarreposicin

SeleccionarArtculo alternativo

AsignarItems

Comprobarsituacin 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

[email protected]

vico

.org



* [para cada pedidoseleccionado]

Recepcinde una

Reposicin

[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 dereposicin 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 situacin de itemsen stock y revisa los umbrales dereposicin automtica.

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

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

Transicin de una actividad a otra sujetaa una condicin lgica.

Sincronizacin de actividades quepueden ocurrir en paralelo.

CU Actualizar reposicin

ServirPedido

SeleccionarPedido

AsignarItems

Fin de la secuencia deactividades

Anlisis textualdel Caso de Uso

EntrarReposicin

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

[email protected]

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 Almacn

Lneas para acotarreas de responsabilidad(swim-lines)

* [para cada lnea de pedido]

Recepcinde un

PedidoIdentificar

Cliente

Entrarlneas pedido

ComprobarPago

CancelarPedido

[NO Stock]o [SI umbral reposicin]

Generarreposicin

EntrarReposicin

[Recepcin de Reposicin]

[SI vigente]

[NO vigente]Seleccionar

Artculo alternativo

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

ServirPedido

Comprobarsituacin Pedido

AparcarPedido

* [para cada pedidoseleccionado]

SeleccionarPedido

BuscarPedidos aparcados

[Todos las reposiciones entradas]

RegularizarStock

ComprobarArtculo

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

[email protected]

co.o

rg



Su objetivo no es relacionar actividad con objetos, slocomprender 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) slo nos permiten modelar procesos secuenciales,mientras que los diagramas de actividad nos permitenestablecer procesos en paralelo.

ComprobarCliente habitual

Importe> 150.000

ComprobarCrdito

Pre-Pagorequerido

[Tarjeta de Crdito]

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]

Autorizacin

[Efectivo]

Descomposicinde 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

[email protected]

co.o

rg

Descripcinde un Escenario

Diagrama de SecuenciaNotacin UML 1.3

2:generarPedido ( )

4:generarLneaPedido ( )

5:comprobarStock ( )

6:asignarItems ( )

7:realizarReposicin ( )

Objetos queinteractan

Mensaje

Auto-mensaje

Lnea de vidade un objetodurante la interaccin

(1)

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

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

(1)

Utilizamos dos diagramas de interaccin:a/. Secuenciab/. Colaboracin

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:generarReposicin ( )

Creacin deun nuevoobjeto

Un escenario muestra de que manera interactan los distintosobjetos dentro del flujo principal de eventos de un Caso deUso con alguna variacin o extensin concreta del mismo.

:Comercial

3:entrarLneaPedido ( )

Anlisis textualdel Use Case





CU Realizar pedido




:Una Carterade Itemsen Stock

:Un Pedidode

Reposicin

:Una Ventana deintroduccin de

Pedidos:Un Pedido

:Una Lneade 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

[email protected]

vico

.org

Descripcinde un Escenario

Diagrama de ColaboracinNotacin UML 1.3

2: generarPedido ( ) 5: comprobarStock ( )

6: asignarItems ( )

7: realizarReposicin ( )

Objeto(Instancia de una Clase)

Auto-mensaje

8: generarReposicin ( )

Nmero de secuencia

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

Estos mensajes muestran el nivel de colaboracinentre 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 colaboracin.- Representa unaposible interaccin de los objetos ordenados a partirde la topologa 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

Direccin del mensaje

Utilizamos dos diagramas de interaccin:a/. Secuenciab/. Colaboracin

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 introduccin de Pedidos

: Un Pedido

: Una Lnea de Pedido

:Una Cartera de Items en Stock

: Un Pedido de ReposicinEscenarios

tieneStock:( )


pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo

: Pedido



1: identificarCliente ( )

3: entrarLneaPedido ( )4: generarLneaPedido ( )

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

[email protected]

vico

.org

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

Las mismas propiedades (Atributos) El mismo comportamiento (Mtodos) Las mismas relaciones con otros Objetos (Mensajes) La misma semntica dentro del sistema

Un Objeto representa una entidad del mundo real o inventada.Es un concepto, una abstraccin o algo que dispone de unoslmites bien definidos y tiene una significacin para el sistemaque se pretende modelar.

Estructura y funcin: Identidad Quien soy? = Atributos Propsito Cual es mi misin? = Justificacin Responsabilidades Qu debo hacer? = Mtodos Procedencia De qu Clase provengo? = Origen Relaciones Qu mensajes entiendo? = Comportamiento

Objetos

Desde una perspectiva fsica, una Clase es una pieza de softwareque actua como un molde para fabricar tipos particulares deobjetos que disponen de los mismos atributos y mtodos.

Estos elementos que configuran cada tipo de objeto slo 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 ellosnicamente por los valores de sus atributos (variables).

Diagrama de ClasesNotacin UML 1.3

PedidoFechaRecibidoConPrepagoNmeroImporteDivisa...

Cliente

Lnea 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

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

1

Vil

alta

Co

nsu

lto

res

20

01

- T

RA

D C

lase

s 1

_es

p -

Rev

. 6

.1 -

j

vila

[email protected]

vico

.org

Abstraccin

mtodo 4

mto

do 1

Atributos

Clases

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

mtodo 2

mto

do 3

A partir de una abstraccin del mundo real, definimosobjetos que representan micromdulos de software ideales.Desde su creacin, se mantienen de manera independienteunos de otros, slo interaccionan con otros objetos a travsde 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

[email protected]

vico

.org

Objeto

elevarPlataforma

carga

rItem

Atributos

Clases

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

moverHacia

bajarP

latafor

ma

Variables.-

Identificacin Medidas de la carga Capacidad de carga Velocidad mxima Tipo de carga

Estado.-

Localizacin Orientacin Velocidad

Todo lo que un objeto conoce est representado en susatributos (variables y estado actual), y todo lo que puederealizar est definido en sus mtodos (comportamiento),y en sus interacciones con otros objetos a travs delintercambio de mensajes (dinmica del ciclo de vida).

Vehculo Automtico 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

[email protected]

vico

.org

Mensaje

Clases

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Una aplicacin orientada a objetos consiste en un nmerodeterminado de objetos que interactuan entre si envindosemensajes unos a otros para invocar sus mtodos. Esteintercambio de mensajes facilita su comportamiento, cambiosde estado, destruccin o almacenamiento.

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

elevarPlataforma

carga

rItem

Atributos

moverHacia

bajarP

latafor

ma

Objeto Receptor

vacp104 moverHacia: binB7Objeto Emisor

Nombre del objeto receptor

Mtodo que se invoca para que lo ejecute el objeto receptor

Parmetro enviado para especificar el mtodo

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

[email protected]

vico

.org

Clases

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

El empaquetado de mtodos y atributos dentro de un objetomediante una interface de mensajes, es lo que denominamosencapsulacin.

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

La interface de mensajes tiene la misma funcin que lamembrana de una clula, disponer de una barrera esencialentre la estructura interna de un objeto y el exterior.

Su propsito es garantizar que todas las interacciones delobjeto tengan lugar a travs de un sistema de mensajerapredefinido 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 mtodos escondidos dentrode la interface de mensajes de otro objeto.

Encapsulacin

M e n s a j e

Interface de mensajes

vacp104 moverHacia: binB7

vacp104

elevarPlataforma

carga

rItem

Atributos

moverHacia

bajarP

latafor

ma

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

[email protected]

vico

.org

Clases

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

Es el mecanismo por el cual una clase de objetos puede serdefinida como un caso especial de otra clase ms genrica.Los casos especiales de una clase se denominan Subclases.La clase ms genrica, se conoce como la Superclase detodos sus casos especiales. Adems de los mtodos y atributosque heredan, las Subclases definen sus propios mtodos yatributos. Tambien, pueden redefinir algunos de losheredados (overriding).

Herencia

Vehculo Automtico Carga Palets

vac 104

vac 104

vac 103

vacp 104

Instancias deVehculo Automtico Carga Palets

Interface de mensajes

Identificador del objeto

Mtodos

Atributos

La interface de mensajes definida para una Superclasetambin 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.

Vehculo AutomticoCarga Palets

SubClase

Vehculo AutomticoCarga Bobinas

SubClase

Vehculo Automtico de Carga

SuperClase

elevarPlataforma

carga

rItem

Atributos

moverHacia

bajarP

latafor

ma

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

[email protected]

vico

.org

Composicin

Clases

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

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 nmero 15, o bien, el texto Autorizado.

Panel de ventana

Tambin 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

[email protected]

vico

.org

Clases

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

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 unvehculo automtico de carga puede especializarse paracargar bobinas, palets u otro tipo de items. Los demsobjetos del sistema no tienen porque saber cuantos tiposde vehculos disponemos.

El mismo mensaje cargarItem, acompaado del parmetroque 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 reduccin de esfuerzo muy significativa por elhecho de que cualquier objeto del sistema puede enviarmensajes a los vehculos automticos de carga sin necesidadde saber de antemano qu tipo de vehculos estan encirculacin.

No hay necesidad as de picar un cdigo especfico paracada tipo de vehculo, 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

Vehculo AutomticoCarga Palets

SubClase

Vehculo AutomticoCarga Bobinas

SubClase

elevarPlataforma

carga

rItem

Atributos

moverHacia

bajarP

latafor

ma

vacb 117elevarPlataforma

carga

rItem

Atributos

moverHacia

bajarP

latafor

ma

vacp 104

Vehculo Automtico 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

[email protected]

vico

.org

VisibilidadToda Clase encapsula unos elementos (atributos y operaciones) que disponende ciertos criterios de visibilidad y manipulacin para otras Clases.Los elementos pblicos pueden ser usados por cualquier otra Clase.Los elementos privados pueden ser usados slo por la Clase propietaria.Cada plataforma de desarrollo (C++, Smalltalk, Java) desarrolla sus propiasreglas con respecto a la visibilidad y manipulacin de atributos y operaciones.La notacin UML especifica que todo atributo y operacin de una Clase hade disponer de un indicador de visibilidad.

Clases

Pedido


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin

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 slo puede ser usado por laClase que lo define.

Un elemento slo 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 tambin que el objeto , es una instancia de CLIENTEPERSONAL.

Puede usar todo elemento pblico de cualquierobjeto del sistema. Puede usar tambin 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 sonpblicas por defecto.

Todas las variablesinstanciadas son privadas.

, 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, , este objetopuede acceder a cualquier elemento de , que ha sido definido tambin como unainstancia de CLIENTE PERSONAL, seapblico, privado o protegido. ,a su vez tambin puede acceder a cualquierelemento privado, protegido o pblico de

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 accederslo a los elementos pblicos de otroobjeto.

En Smalltalk, , nopuede acceder a las variablesinstanciadas privadas de , slo a sus operaciones pblicas.

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

Un elemento slo puede ser usado porla Clase que lo define.

Un elemento puede ser usado porsubclases y tambin por cualquier otraClase en el mismo Package como laClase propietaria. Esto implica que enJava, el concepto de visibilidadprotegida es ms pblico que package.

Un elemento slo puede ser usado porotras Clases que compartan el mismoPackage.

Pedido- fechaRecibidoconPrepago- nmero: Alfanm.- importe: Nm&2d.- divisa...

Cliente

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*

0..1

*

* 1

+ hacer /comprobacinitem

+ hacer /comprobacin

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

Java permite marcar tambin las Clasescomo pblicas o packages. Los elementosde una Clase pblica pueden ser usados porcualquier Clase que importe el package ala que pertenece la Clase.Los elementos de una Clase package slopueden ser usados por otras Clases delmismo package.

Lnea de Pedido

+ hacer /comprobacin

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

[email protected]

co.o

rg

Descripcinde la Dinmica del Sistema

La dinmica 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 PedidoNotacin UML 1.3

Comprobando Sirviendo

EntregadoEsperando

/seleccionar primer item

hacer /comprobacin

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

[Tod

os lo

s ite

ms d

ispon

ible

s]

Pedido Entregado

1

2

3

4

5

6

1

DinmicaEstados


ionar primer item

hacer /comprobacin

item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando





4. Sistema comprueba la situacin 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 artculo en stock, sistemaaparca el pedido del cliente activando el CUAparcar pedido.

c. SI no se ha realizado el pago segn el plazoconvenido, sistema cancela el pedido.

CU Realizar pedido




PedidofechaRecibidoconPrepagonmero: Alfanm.importe: Nm&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

[email protected]

vico

.org




EntregadoEsperando


hacer /comprobacin

item


[No todos los items comprobados]/seleccionar siguiente item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Pedido Entregado


*

1


InicioClase

Atributos

Operaciones

primera Transicin

E s t a d o

Actividad

Accin

Accin

Indicador

Auto-Transicin

Transicin

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 rpidadentro de un ciclo contnuo sin interrupcin.

/ Accin Transicin

Desencadenasiempre

la Transicin

[Indicador] TransicinCondicin lgica con dos categorias: verdadero o falso.Una Transicin con [Indicador] slo ocurre si este es verdadero.Slo podemos extraer una Transicin para un Estado concreto.


2

DinmicaEstados


ionar primer item

hacer /comprobacin

item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando

Sintaxis para etiquetar una transicin

Evento [Indicador] / Accin

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

[email protected]

vico

.org




EntregadoEsperando


hacer /comprobacin

item


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

/seleccionar siguiente item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

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 Transicin

E s t a d o

Actividad

Accin

Accin

Indicador

Auto-Transicin

Transicin

Impl

emen

taci

n

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

Procesos que ocurren de manera rpidadentro de un ciclo contnuo sin interrupcin.

/ Accin Transicin

/ Actividad EstadoProcesos que ocurren dentro de un ciclo discontnuoy pueden ser interrumpidospor algun evento.

[Indicador] TransicinCondicin lgica con dos categorias: verdadero o falso.Una Transicin con [Indicador] slo ocurre si este es verdadero.Slo podemos extraer una Transicin para un Estado concreto.

12

Evento3

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

Desencadenasiempre

la Transicin

Aunque finalize la Actividadel Pedido permanecer eneste Estado hasta que ocurreel Evento que desencadenasu Transicin

4

5

6

3

DinmicaEstados


ionar primer item

hacer /comprobacin

item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando






CU Realizar pedido





*

1


Clase

Atributos

Operaciones

Sintaxis para etiquetar una transicin

Evento [Indicador] / Accin

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

[email protected]

vico

.org


Diagrama de EstadosNotacin UML 1.3

Un Evento no es un objeto. Un Evento es la causa quejustifica la existencia de una informacin.

Slo podemos conocer que un Evento ha ocurrido,detectando sus efectos en nuestro modelo.

Slo 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


hacer /comprobacin

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

[Tod

os lo

s ite

ms d

ispon

ible

s]

PedidoEntregado

1

2

3

4 5

6


sin Superestados


EntregadoEsperando


hacer /comprobacin

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

[Tod

os lo

s ite

ms d

ispon

ible

s]

PedidoEntregado

1

2

3

4

5

6


CanceladoPedidoCancelado

PedidoCancelado

PedidoCancelado

Activo

Cancelado Entregado

PedidoCancelado

Nombre del Superestado

con Superestados

4

DinmicaEstados


ionar primer item

hacer /comprobacin

item



Item

Rec

ibid

o

[Tod

os lo

s ite

ms d

ispon

ible

s]

Entregadorimer item

rimer item

rimer item

EntregadoEsperando




b. SI existen suficientes items del artculo enel stock, sistema asigna ite

lenguaje unificado

Documents

Introducción Al Lenguaje de Modelo Unificado - Uml

INTRODUCCION AL LENGUAJE UNIFICADO MODELADOgaleon.com/rcruz0423/docs/clase1p2.pdf · Con el objetivo de corregir este inconveniente se crea el Lenguaje Unificado de Modelado (UML)

Lenguaje Unificado de Modelado, manual de referencia (2007)

Booch 2006 El Lenguaje Unificado Modelado

Guia Del Curso (UNAD) 200609 Lenguaje de Modelado Unificado - UML

Lenguaje Unificado de Modelado Grady Booch

Uml lenguaje unificado de modelado

Lenguaje de modelado unificado (UML)

Lenguaje Unificado de modelado

El Lenguaje Unificado de Modelado - Manual de Referencia

El lenguaje unificado de modelado manual de referencia

Lenguaje de Modelamiento Unificado

El Lenguaje Unificado de Modelado Manual de Referencia

Lenguaje Unificado de Modelado

UML - Lenguaje Unificado de Modelado (2008)

Lenguaje Unificado de Modelado (UML) - webdelprofesor.ula.vewebdelprofesor.ula.ve/ingenieria/ibc/bda/s1uml.pdf · Lenguaje Unificado de Modelado (UML) Grupo de Ingeniería de Datos

Tema 5: El Lenguaje Unificado de Modelado - Inicio | … · diagrama de clases, pero desde perspectiva de casos reales Diagramas de componentes ... El Lenguaje Unificado de Modelado

Modelado estático usando el Lenguaje de Modelado Unificado ...aisii.azc.uam.mx › mcbc › Cursos › POO › Sesion9.pdf · el Lenguaje de Modelado Unificado (UML) 1 . Clases Nombre

UML(Lenguaje Unificado de Modelado)

Lenguaje Unificado de Modelado - dtm.unicauca.edu.codtm.unicauca.edu.co/esptelematica-cali/Arquitecturas/transp/3-UML.pdf · Lenguaje Unificado de Modelado (v1.4.2 ISO/IEC 19501)

Lenguaje de modelado unificado uml

El lenguaje unificado de modelado manual de referencia - rumbaugh, jacobson, booch

Lenguaje Unificado de Modelado (UML)

Lenguaje de Modelado Unificado

Boch (2007).El Lenguaje Unificado de Modelado. Manual de Referencia

El lenguaje Unificado de Modelado - Manual de Referencia.pdf

UML Lenguaje de Modelado Unificado Unified Modeling Languaje

Lenguaje Unificado de Modelado EXPO ADS 2

UML Lenguaje de Modelaje Unificado

ENTORNOS DE DESARROLLO · 2021. 2. 4. · UNIDAD 5: Lenguaje Unificado de Modelado (UML) INDICE 1- LENGUAJE UML 2.0 2- DIAGRAMAS DE CLASES ... conjunto unificado de estándares para

El lenguaje de modelado unificado

El Lenguaje Unificado de Modelado UML 2.0

8963147 Lenguaje Unificado de Modelado

UML - Lenguaje de Modelamiento Unificado

Trabajo final lenguaje unificado de modelado uml 200609 18