Download - 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 /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
Verificando Sirviendo
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
EntregadoEsperando
P
M
* [para cada pedido seleccionado]
EntrarReposicin
SeleccionarPedidos
Pendientes
AsignarItems
RegularizarStock
ActivarPedido
EntrarReposicin
EntrarReposicin
* [para cada pedido seleccionado]
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:( )
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
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
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 oPlan Director de ProyectoP D P
C o n c e p c i n
Anteproyecto
Patrones deAnlisis
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
Glosariode Conceptos
CronogramaPlan Director
Iteraciones
PM
PPDIG
Misin
3
-
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 oPlan Director de Proyecto
P D P
Fo r m a l i z a c i n
Patrones deAnlisis
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacinP
Patrones deFuncionalidad
>
>
>
Use Case
Actor 2
Actor 1
Use Case
Use Case
Use Case
Use Case
Use Case
PModelo
FuncionalidadDiagramas de
Casos de Uso
C l a s e sA n l i s i s
y D i s e o
>
>
>
Use Case
>
Use Case
>
>
Actor
Actor
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
EspecificacinCasos de Uso
Flujos deTrabajo
DinmicaEventosEstados
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
Verificando Sirviendo
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
EntregadoEsperando
CU * [para cada pedido seleccionado]Entrar
Reposicin
SeleccionarPedidos
Pendientes
AsignarItems
RegularizarStock
ActivarPedido
EntrarReposicin
EntrarReposicin
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
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:( )
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
4
-
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 oPlan Director de ProyectoP D P
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
P
C o n s t r u c c i n
Alumno P. Global P. Esp. ResultadoSeleccin Ver
4
4
Destino
Versin
Tribunal
Ao Acadmico*
**FechaActa
Alumnos
C l a s e sD i s e o
I m p l e m e n t a c i n
Base de DatosEsquema de Persistencia
ArquitecturaComponentes
InterfaceGrfico de Usuario
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Componentes
5
-
Fo r m a l i z a c i n
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 oPlan Director de ProyectoP D P
Modelo
FuncionalidadDiagramas de
Casos de Uso
C l a s e sA n l i s i s
y D i s e o
>
>
>
Use Case
>
Use Case
>
>
Actor
Actor
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
EspecificacinCasos de Uso
Flujos deTrabajo
DinmicaEventosEstados
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
Verificando Sirviendo
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
EntregadoEsperando
CU * [para cada pedido seleccionado]Entrar
Reposicin
SeleccionarPedidos
Pendientes
AsignarItems
RegularizarStock
ActivarPedido
EntrarReposicin
EntrarReposicin
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
C o n c e p c i n
Anteproyecto
Procesosprincipales
Matrculadel proyecto
Glosariode Conceptos
CronogramaPlan Director
Iteraciones
PM
PPDIG
Misin
C o n s t r u c c i n
Alumno P. Global P. Esp. ResultadoSeleccin Ver
4
4
Destino
Versin
Tribunal
Ao Acadmico*
**FechaActa
Alumnos
C l a s e sD i s e o
I m p l e m e n t a c i n
Base de DatosEsquema de Persistencia
ArquitecturaComponentes
InterfaceGrfico de Usuario
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
Componentes
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:( )
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
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
FuncionalidadDiagramas deCasos 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
FuncionalidadDiagramas deCasos de Uso
>
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
FuncionalidadDiagramas deCasos de Uso
>
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
FuncionalidadDiagramas deCasos de Uso
>
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
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
1
-
Descripcinde un Flujo de Trabajo
Diagrama de ActividadNotacin UML 1.3
* [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
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
2
-
Descripcinde un Flujo de Trabajo
Diagrama de ActividadNotacin UML 1.3
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
* [para cada pedido seleccionado]
ActivarPedido
RegularizarStock
AsignarItems
EntrarPedido
ValidarPago
SeleccionarPedidos
ValidarRiesgo
3
-
Descripcinde un Flujo de Trabajo
Diagrama de ActividadNotacin UML 1.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
* [para cada pedido seleccionado]
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
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.
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.
:Una Carterade Itemsen Stock
:Un Pedidode
Reposicin
:Una Ventana deintroduccin de
Pedidos:Un Pedido
:Una Lneade Pedido
Escenarios
tieneStock:( )
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
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.
Anlisis textualdel Use Case
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.
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.
: Comercial
: Una Ventana de introduccin de Pedidos
: Un Pedido
: Una Lnea de Pedido
:Una Cartera de Items en Stock
: Un Pedido de ReposicinEscenarios
tieneStock:( )
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
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
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
1
-
Abstraccin
mtodo 4
mto
do 1
Atributos
Clases
Pedido
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
hacer /comprobacinitem
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
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
hacer /inicio deentregas
[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
Verificando Sirviendo
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
EntregadoEsperando
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.
PedidofechaRecibidoconPrepagonmero: Alfanm.importe: Nm&2d.divisa...
*
1
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
Anlisis textualdel Use Case
-
Descripcinde la Dinmica del Sistema
Diagrama de Estadosde un PedidoNotacin UML 1.3
Comprobando Sirviendo
EntregadoEsperando
/seleccionar primer item
hacer /comprobacin
item
hacer /inicio deentregas
[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
PedidofechaRecibidoconPrepagonmero: Alfanm.importe: Nm&2d.divisa...
*
1
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
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.
[Todos los items comprobados &&todos los items disponibles]
2
DinmicaEstados
Verificando Sirviendo
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
EntregadoEsperando
Sintaxis para etiquetar una transicin
Evento [Indicador] / Accin
Los tres elementos son opcionales
Anlisis textualdel Use Case
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.
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.
-
Descripcinde la Dinmica del Sistema
Diagrama de Estadosde un PedidoNotacin UML 1.3
Comprobando Sirviendo
EntregadoEsperando
/seleccionar primer item
hacer /comprobacin
item
hacer /inicio deentregas
[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
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
Verificando Sirviendo
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
EntregadoEsperando
Anlisis textualdel Use Case
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.
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.
PedidofechaRecibidoconPrepagonmero: Alfanm.importe: Nm&2d.divisa...
*
1
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
Clase
Atributos
Operaciones
Sintaxis para etiquetar una transicin
Evento [Indicador] / Accin
Los tres elementos son opcionales
-
Descripcinde la Dinmica del Sistema
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.
Comprobando Sirviendo
Esperando
/seleccionar primer item
hacer /comprobacin
item
hacer /inicio deentregas
[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
[Todos los items comprobados &&todos los items disponibles]
sin Superestados
Comprobando Sirviendo
EntregadoEsperando
/seleccionar primer item
hacer /comprobacin
item
hacer /inicio deentregas
[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
[Todos los items comprobados &&todos los items disponibles]
CanceladoPedidoCancelado
PedidoCancelado
PedidoCancelado
Activo
Cancelado Entregado
PedidoCancelado
Nombre del Superestado
con Superestados
4
DinmicaEstados
Verificando Sirviendo
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
EntregadoEsperando
Anlisis textualdel Use Case
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.
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.
-
Descripcinde la Dinmica del Sistema
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
2. Usuario entra lineas de pedido, con sucdigo de artculo, tipo de presentaciny cantidad.
b. SI existen suficientes items...
3. Sistema comprueba cada lnea delpedido para validar la situacin delartculo...
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...
a. Artculo NO est vigente en catlogo, sistemainforma que articulo no est vigente ymuestra...
Anlisis textualdel Use Case
DinmicaEstados
Verificando Sirviendo
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
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
Vista delModelo de Referencia
Vista delModelo de Referencia
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
PedidofechaRecibidoconPrepagonmero: Alfanm.importe: Nm&2d.divisa...
Cliente
Lnea de Pedido
Producto
Comercial
ClienteCorporativo
ClientePersonal
1*
1
*0..1
*
* 1
hacer /comprobacinitem
hacer /comprobacin
hacer /comprobacin
seleccionar ( )comprobar ( )servir ( )cerrar ( )...
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
Vista delModelo de Referencia
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
-
Vista deImplementacin
Ejecutables
Vista deImplementacin
Ejecutables
Arquitectura del sistema
Arquitectura
Los componentes run-time muestran los mappingsde las Clases a libreras de tipo ActiveX, Applets deJava y libreras dinmicas.
Vista deComponentes
Modulares
Vista delModelo de Referencia
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
-
Vista deDistribucin Fsica
Elementos
Vista deImplementacin
Ejecutables
Arquitectura del sistema
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
Vista delModelo de Referencia
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.
Vista deDistribucin Fsica
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
-
Vista deImplementacin
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)
Vista deDistribucin Fsica
Elementos
Vista de la
FuncionalidadUse Cases
Arquitectura
tieneStock:= comprobar ( )
[tieneStock] asignar ( )
[tieneStock] nuevo
Una ventana deintroduccin de
pedidos
Un itemde stock
Una lneade pedidoUn pedido
[tieneStock] nuevo
[tieneStock]
nuevo
* [para cada lnea de pedido]
PrepararPedido
Recepcinde un
Pedido
ComprobarItems
ComprobarPago
CancelarPedido
AsignarItems
ReponerItems
ServirPedido
[en stock]
[SI xito]
[NO xito]
[Requiere reposicin]
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
>
> >
>
>
Abrir Arqueo Hacer unInicio de Da
Hacer unFin de Da
Exportarmovimientos
Imprimirdocumento
SupervisorImportar nuevaconfiguracin
Contabi l idad
CajeroCerrar Arqueo
6
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.
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.
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