Ejemplo de Implementacion Proyecto UML

Niveles de concepcin y formalizacinde un proyecto

Nivel

Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5

ProcesosPrincipales

Glosariode Conceptos

Matrculadel Proyecto

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

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

2

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

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

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

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

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

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

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

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

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



* [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



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)


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



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

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

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

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

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

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

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

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

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

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

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

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

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









CU Realizar pedido




PedidofechaRecibidoconPrepagonmero: Alfanm.importe: Nm&2d.divisa...

*

1






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







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


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






CU Realizar pedido





Diagrama de EstadosConcurrentesNotacin UML 1.3

Autorizandohacer /

comprobacindel pago

[pago NO correcto]

Entregado

[pago SI correcto]

RechazadoAutorizado

Rechazado

Cancelado

Entregado

Comprobando

Esperando

Sirviendo

Autorizando AutorizadoPedido Entregado

Pedido Cancelado

Pedido Rechazado

Los diagramas de estados son muy tiles para describir elcomportamiento de un objeto a travs de mltiples Casosde Uso.

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


b. SI existen suficientes items...

3. Sistema comprueba cada lnea delpedido para validar la situacin delartculo...





CU Realizar pedido


c. NO existen suficientes items...

a. Artculo NO est vigente en catlogo, sistemainforma que articulo no est vigente ymuestra...


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

Vista deDistribucin Fsica

Elementos

Vista deImplementacin

Ejecutables

Arquitectura del sistema

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

Vista de la Arquitectura 4+1Notacin UML 1.3 Arquitectura

Vista delModelo de Referencia

Vista de la

FuncionalidadUse Cases

Vista deComponentes

Modulares

1

Arquitectura del sistemaLa vista del Modelo de Referencia (Reference InformationModel), est determinada por la arquitectura lgica.

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

Clases

Asociaciones

Agregaciones

Generalizacin

Packages

Arquitectura



El Modelo de Referencia se construye en sucesivasiteraciones durante la fase de Formalizacin.

Pedidos Clientes

ArtculosLas Clases y Packages del modelo reflejan lasdecisiones tomadas con respecto a los mecanismosclave del sistema.

Una eficiente implementacin de los mecanismosclave requiere seleccionar Patrones (Patterns) quese ajusten a los requerimientos esenciales delproyecto.

La implementacin de mecanismos clave requiereseleccionar tambin:

Lenguaje de programacin

Motor de Base de Datos

Interface grfico de usuario look and feel

Tratamiento de errores

Mecanismos de comunicacin

Migracin y distribucin de objetos

Networking


Cliente

Lnea de Pedido

Producto

Comercial

ClienteCorporativo

ClientePersonal

1*

1

*0..1

*

* 1


hacer /comprobacin

hacer /comprobacin


2

Vista deComponentes

Modulares

Arquitectura del sistemaLa vista de Componentes Modulares refleja la organizacinde mdulos de software dentro del entorno de desarrollo.

Esta vista de arquitectura toma en cuenta los requerimientosque facilitan la programacin, los niveles de reutilizacin,y las limitaciones impuestas por el entorno de desarrollo.

Disponemos de dos elementos para modelizar esta vista:

Packages: En esta vista representan una particin fsicadel sistema.

Componentes: En esta vista representan la organizacinde mdulos de cdigo fuente.

Arquitectura

Los Packages estan organizados en una jerarquade capas que disponen de una interface bien definida:

Pa c k a g e s e s p e c f i c o s d e l d o m i n i o

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

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

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

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

4

3

2

1

Vista deComponentes

Modulares


Los Packages de la vista lgica del modelo estanmapeados con los Packages fsicos y los componentesde software (subsistemas).

InformacinArtculos

Pe d i d o

Dominio

Clientes

Artculos

Pedidos

MailingInterface Usuario

AWTJava GUI toolkit

EntradaPedidos

Interface Usuario

3


Ejecutables


Ejecutables


Arquitectura

Los componentes run-time muestran los mappingsde las Clases a libreras de tipo ActiveX, Applets deJava y libreras dinmicas.

Vista deComponentes

Modulares


Los componentes ejecutables muestran sus interfacesy niveles de dependencia dentro de la aplicacin.

Clientes.dll

Expedicin.dll

Artculos.dll

Pe d i d o s . exe

MailingInterface Usuario

AWTJava GUI toolkit

EntradaPedidos

Interface Usuario

Dominio

Clientes

Artculos

Pedidos

EntradaPedidosAplicacin

MailingAplicacin

Base deDatos

Interface global

OracleInterface

IngresInterface

Esta vista se centra en la estructura de los componentesrun-time, los ejecutables del sistema.

Esta arquitectura tiene muy en cuenta los siguientesrequerimientos no funcionales:

Rendimiento

Fiabilidad

Escalabilidad

Integridad

Seguridad

Sincronizacin

Administracin del sistema

4


Elementos


Ejecutables


Un Nodo es un objeto fsico run-time que representaun recurso informtico. Este recurso, generalmentedispone de datos persistentes y capacidad de proceso.

En la mayora de los casos un Nodo puede representaruna pieza de hardware, desde un perifrico a unservidor.

Las Conexiones entre Nodos muestran las lneas decomunicacin con las que el sistema tendr queinteractuar.

Los Componentes, en un diagrama de distribucin,representan los mdulos fsicos de cdigo, los cuales,se corresponden con los Packages de ejecutables.De esta manera, el diagrama muestra donde correcada Package en el sistema.

Las Dependencias muestran cmo los componentesse comunican con otros componentes. La direccinde una Dependencia concreta, indica el conocimientoen la comunicacin.

Vista deComponentes

Modulares


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

Esta arquitectura tiene en cuenta los siguientesrequerimientos:

Disponibilidad del sistema

Rendimiento

Escalabilidad

Los diagramas de distribucin muestran el despliegue denodos (locales y remotos), en la organizacin de la empresa.

Permite al equipo de desarrollo comprender mejor latopologa de un sistema distribuido.


Elementos

Componente

Arquitectura

Interface

Nodos

Conexin

TCP/IP

TCP/IP

Servidor rea Comercial

Cliente Win95

Servidor Contabilidad

:GUIComercial

:ClienteComercial

Configuracin

:Usuarios

:Contabilidad

:Base deDatos

:Base deDatos

:Comercial

:ServidorAplicaciones

5


Ejecutables

Arquitectura del sistemaVista de

ComponentesModulares

Vista delModelo de Referencia Esta vista certifica la validez de:

Modelo de Referencia

Componentes modulares de software

Ejecutables

Distribucin de recursos informticos

Con la funcionalidad requerida del sistema.

Utilizamos los siguientes elementos para describir lafuncionalidad:

Diagramas de Casos de Uso

Especificacin de Casos de Uso

Diagramas de Interaccin (Escenarios)

Diagramas de Actividad (Flujos de Trabajo)

Diagramas de Estados (Dinmica)


Elementos

Vista de la

FuncionalidadUse Cases

Arquitectura


[tieneStock] asignar ( )

[tieneStock] nuevo


pedidos

Un itemde stock


[tieneStock] nuevo

[tieneStock]

nuevo


PrepararPedido

Recepcinde un

Pedido

ComprobarItems

ComprobarPago

CancelarPedido

AsignarItems

ReponerItems

ServirPedido

[en stock]

[SI xito]

[NO xito]

[Requiere reposicin]


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

>

> >

>

>

Abrir Arqueo Hacer unInicio de Da

Hacer unFin de Da

Exportarmovimientos

Imprimirdocumento

SupervisorImportar nuevaconfiguracin

Contabi l idad

CajeroCerrar Arqueo

6





CU Realizar pedido




Plan DirectorConcepcin y formalizacinEsfuerzo de desarrolloMisinModeloComponentesVisin global

Casos de UsoIdentificar ActoresIdentificar Casos de UsoEspecificacinModelo Caso de UsoRequerimientos y Casos de Uso

Diagramas de ActividadDescripcin de un flujo de trabajo 1Descripcin de un flujo de trabajo 2Descripcin de un flujo de trabajo 3Descripcin de un flujo de trabajo 4

Diagramas de Interaccin de ObjetosDiagrama de secuenciaDiagrama de colaboracin

Clases y ObjetosDefinicionesAbstraccinObjetoMensajeEncapsulacinHerenciaComposicinPolimorfismoVisibilidad

Diagramas de Estados TransicinDescripcin de la dinmica del sistema 1Descripcin de la dinmica del sistema 2Descripcin de la dinmica del sistema 3Descripcin de la dinmica del sistema 4Descripcin de la dinmica del sistema 5

ArquitecturaVista del modelo de referenciaVista de Componentes ModularesVista de Implementacin EjecutablesVista de Distribucin Fsica de ElementosVista global de la arquitectura

Ejemplo de Implementacion Proyecto UML

Documents

Transcript of Ejemplo de Implementacion Proyecto UML