El Proceso Unificado de Desarrollo · Diagramas de Componentes Diagramas de Secuencia Diagramas de...

53
El Proceso Unificado de Desarrollo 3- Diseño Profesor: David Granada

Transcript of El Proceso Unificado de Desarrollo · Diagramas de Componentes Diagramas de Secuencia Diagramas de...

El Proceso Unificado de Desarrollo

3- Diseño

Profesor: David Granada

Índice  

n  Visión  general  

n  Artefactos  ¨ Modelo  de  diseño  ¨  Clases  de  diseño  ¨  Realización  en  diseño  de  los  casos  de  uso  ¨  Subsistemas  en  diseño  ¨  Interfaz  

n  Ac=vidades  ¨  Diseño  de  los  casos  de  uso  ¨  Diseño  de  las  clases  ¨  Diseño  de  subsistemas  

Diseño  Visión  general  

Requisitos

 Diseño    

 Implementación    

Prueba

 Análisis    

Planificación  Anál.  Riesgos  Preparación  

Elaboración   Construcción  Verificación   Transición  

Fases Flujos de

trabajo

Iteración(es)  Inicial(es)    

Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7

(Adaptado de Jacobson, 1999)

Modelo  de    análisis  

Modelo  de    diseño  

Modelo de despliegue

Modelo  de    implementación  

Modelo de pruebas

Modelo de casos de uso

Soportado por

Distribuido por

Diseño  Visión  general  

Requisitos

Pruebas

Implementación  

Diseño  

Análisis

Modelo de Despliegue

Modelo de Análisis

Modelo  de  Diseño  

Modelo  de  Implementación  

Modelo de Pruebas

Modelo de Casos de Uso

Dependencia de traza

Diseño  Visión  general  

Diseño  Diagramas  UML  

Modelo  de    Diseño  

Modelo de

Pruebas

Modelo de Despliegue

Modelo de

Implementación

Diagramas de Casos de Uso

Diagramas de Clases

Diagramas de Componentes

Diagramas de Secuencia

Diagramas de Colaboración

Diagramas de Estados

Diagramas de Actividad

Diagramas de Objetos

Incluidos subsistemas

Modelo de

Casos de Uso

Diagramas de Interacción

Modelo  de    

Análisis  

Diagramas de Despliegue

Incluidas clases activas y componentes

Diseño  Visión  general  

Modelo  de  Análisis   Modelo  de  Diseño  

Modelo  conceptual   Modelo  Ksico  

Pueden  obtenerse  varios  diseños   Específico  a  una  implementación  

Menos  formal   Más  formal  

Menos  caro  de  desarrollar   Más  caro  (5  veces  más)  

Puede  eliminarse   Debe  mantenerse  durante  todo  el  ciclo  de  vida  

Diseño  Visión  general  

n  Obje=vos  del  diseño:  ¨  Acercar  el  modelo  de  análisis  al  modelo  de  implementación  

n  Los  milagros  más  comunes  de  la  ingeniería  del  so2ware  son  las  transiciones  desde  el  análisis  hasta  el  diseño  y  desde  el  diseño  al  código.  Richard  Due  

¨  Iden=ficar  requisitos  no  funcionales  y  restricciones  en  relación  a:  n  Lenguajes  de  programación,  reu=lización  de  componentes,  sistemas  

opera=vos,  tecnologías  de  distribución,  concurrencia,  bases  de  datos,  interfaces  de  usuario,  ges=ón  de  transacciones,  etc.  

¨  Descomponer  el  modelo  de  análisis  en  subsistemas  que  puedan  desarrollarse  en  paralelo  

¨  Definir  la  interfaz  de  cada  subsistema  

¨  Derivar  una  representación  arquitectónica  del  sistema    

8

Índice  

n  Visión  general  

n  Artefactos  ¨ Modelo  de  diseño  ¨  Clases  de  diseño  ¨  Realización  en  diseño  de  los  casos  de  uso  ¨  Subsistemas  en  diseño  ¨  Interfaz  

n  Ac=vidades  ¨  Diseño  de  los  casos  de  uso  ¨  Diseño  de  las  clases  ¨  Diseño  de  subsistemas  

Diseño  Artefactos  

n  Modelo  de  diseño  ¨  Casos  de  uso  en  el  dominio  de  la  solución  ¨  Cómo  soportar  requisitos  funcionales/no  funcionales  y  otras  

restricciones  en  el  entorno  de  implementación  ¨  Entrada  fundamental  para  ac=vidades  de  implementación  

*

Subsistemas de diseño

Realización en diseño

*

* * * *

Clases de diseño Interfaz

* *

Modelo de diseño

Diseño  Artefactos  

n  Clases  de  diseño  ¨  Una  clase  de  diseño  es  una  abstracción  de  una  clase  de  

implementación  ¨  Las  operaciones,  atributos,  =pos,  visibilidad  (public,  protected,  private,  

etc...),  se  pueden  especificar  con  la  sintaxis  del  lenguaje  elegido  ¨  Las  relaciones  entre  clases  de  diseño  se  traducen  de  manera  directa  al  

lenguaje:  n  Generalización  à  herencia  n  Asociaciones,  agregaciones  à  atributos  

¨  Se  pueden  postergar  algunos  requisitos  a  implementación  (manera  de  nombrar  los  atributos,  operaciones,  etc...)  

¨  Realizan  interfaces  

Diseño  Artefactos  

n  Clases  de  diseño:  Ejemplo  

Transacción cuenta : Cuenta cantidad: Dinero ……………

1..2 1..2

opera

Cuenta

reintegro(cantidad : Dinero) : Boolean ingreso(cantidad : Dinero) : Boolean

saldo : Dinero limiteDiario: Dinero = 300

Diseño  Artefactos  

n  Realización  de  los  casos  de  uso  en  diseño:  ¨  Es  una  colaboración  que  describe  cómo  se  realiza  en  diseño  un  caso  de  

uso  en  términos  de  clases  de  diseño  y  sus  interacciones  

Modelo de análisis

Realización en análisis

Modelo de diseño

Realización en diseño

<<trace>>

n  Realización  de  los  casos  de  uso  en  diseño:  

Diseño  Artefactos  

Transacción Cuenta Interfaz del cajero

Dispositivo de visualización

Teclado

Lector de Tarjetas

Expendedor Dinero

Recogedor Dinero

Gestor de Cliente

Cuenta

Gestor de Cuentas

Gestor de Transacciones

MODELO  DE  ANÁLISIS    

MODELO  DE  DISEÑO    

…..

Diseño  Artefactos  

n  La  realización  en  diseño  de  un  caso  de  uso  incluye:  ¨  Diagramas  de  clases:    clases  par=cipantes  ¨  Diagramas  de  interacción:    escenarios  del  caso  de  uso  ¨  Descripción  textual  del  flujo  de  eventos  ¨  Requisitos  de  implementación  ¨  Opcionalmente:  subsistemas  e  interfaces  

Subsistema de diseño

Clase de diseño

Realización en diseño (from Use Case View)

participante participante

Diseño  Artefactos  

n  Diagramas  de  clase  ¨  Una  clase  de  diseño  puede  par=cipar  en  varios  casos  de  uso  ¨  Algunas  responsabilidades,  atributos  y  asociaciones  suelen  ser  

específicos  de  un  sólo  caso  de  uso.  

Dispositivo de visualización

Teclado

Lector de Tarjetas

Expendedor Dinero

Gestor de Cliente

Cuenta Gestor

de Cuentas

Gestor de Transacciones

Reintegro

Cliente

Diseño  Artefactos  

n  Diagramas  de  interacción  

¨  La  secuencia  de  acciones  en  un  caso  de  uso  comienza  cuando  un  actor  envía  un  mensaje  a  un  objeto  de  diseño  

¨  U=lizar  mejor  diagramas  de  secuencia  que  de  colaboración:  interesa  la  secuencia  cronológica  de  las  interacciones  

¨  Se  pueden  incluir  subsistemas  y  las  interfaces  que  proporcionan  

Diseño  Artefactos  

n  Diagramas  de  interacción  à  diagramas  de  secuencia  

Validarse

:Dispositivo de visualización

:Teclado

:Lector de Tarjetas

:Gestor de Cliente

:Gestor de Transacciones

:Cliente del Banco

UsuariosDelBanco Autenticar Interfaz de cajero

RESOLVER EN CLASE

n  LifeLine: Línea vertical punteada que representa la vida del objeto durante la interacción

n  Barra de activación: Período en el cual el objeto se encuentra realizando una operación.

n  Mensaje: Línea sólida dirigida a otro objeto. n  Retorno: Línea punteada de mensaje de retorno al objeto

que llama (no se usa). n  Mensaje a sí mismos: Métodos recursivos o llamadas a si

mismos n  Destrucción del Objeto: Se representa con una X

19

Diseño  Artefactos  

Diagramas  de  secuencia  

20

Diseño  Artefactos  

Diagramas  de  secuencia  Fragmentos Combinados: Una o mas secuencias de procesos incluidas en un marco

Alt Alternativa: Divide la interacción mediante la condición opt Alternativa simple: Solo si cumple la condición loop Bucle: Se ejecuta varias veces según indica la restricción sd Diagrama de secuencia: Representa un diagrama de secuencia

completo …

Permiten agregar lógica de procedimientos complejos

21

Diseño  Artefactos   Diagramas  de  secuencia  

Diseño  Artefactos  

n  Flujo  de  eventos  ¨  Para  clarificar  los  diagramas  de  secuencia:  descripción  textual  ¨  Una  descripción  no  =ene  que  ser  local  a  un  diagrama.  Puede  englobar  

a  varios  e  indicar  cómo  se  relacionan.  

n  Requisitos  de  implementación  ¨  Requisitos  a  ges=onar  en  implementación  ¨  Quizás  durante  esta  fase  de  diseño  se  obtengan  algunos  nuevos  ¨  Representarlos  con  restricciones  {...}  asignadas  a  las  clases  de    diseño,  

operaciones,  atributos,  asociaciones,  etc.  

Diseño  Artefactos  n  Subsistemas  de  diseño  

¨  Para  organizar  los  artefactos  de  diseño:  clases  de  diseño,  realización  de  casos  de  uso,  interfaces  y  otros  subsistemas  

¨  Fuertemente  cohesionados  y  débilmente  acoplados  ¨  Representan  una  separación  de  aspectos  de  diseño:  Desarrollo  por  

separado  

*

Subsistemas de diseño

Realización en diseño

* *

Clases de diseño Interfaz

*

Proporciona 1

1.- representa la funcionalidad que exporta en términos de operaciones

Diseño  Artefactos  n  Interfaces  

¨  Las  interfaces  se  u=lizan  para  especificar  las  operaciones  de  las  clases  y  los  subsistemas  de  diseño.  

¨  Las  clases  de  diseño  soportan  las  operaciones  de  su  interfaz  mediante  métodos.  

¨  Los  subsistemas  de  diseño  soportan  las  operaciones  de  su  interfaz  mediante  las  clases  de  diseño  (o  subsistemas)  que  con=ene.  

¨  Separar  la  especificación  de  la  funcionalidad.  

Subsistemas de diseño

* Clases de diseño

Interfaz *

realiza

realiza

Diseño  Ejemplo  

n  Para  ilustrar  las  ac=vidades,  u=lizaremos  el  ejemplo  del  cajero  automá=co  

Sacar dinero

Ingresar dinero

Transferencia

Cliente del banco

Validar usuario

<<include>>

<<include>>

<<include>>

Índice  

n  Visión  general  

n  Artefactos  ¨ Modelo  de  diseño  ¨  Clases  de  diseño  ¨  Realización  en  diseño  de  los  casos  de  uso  ¨  Subsistemas  en  diseño  ¨  Interfaz  

n  Ac=vidades  ¨  Diseño  de  los  casos  de  uso  ¨  Diseño  de  las  clases  ¨  Diseño  de  subsistemas  

Diseño  Ac=vidades  

n  Diseño  de  los  casos  de  uso  ¨  Iden=ficar  las  clases  de  diseño  y/o  subsistemas  necesarios  para  la  realización  del  caso  de  uso  

¨ Distribuir  el  comportamiento  del  caso  de  uso  entre  las  clases  y/o  subsistemas  de  diseño  

Diseño  Ac=vidades  

n  Diseño  de  los  casos  de  uso  ¨  Iden=ficar  las  clases  de  diseño  

n  Derivar  las  clases  de  diseño  de  las  correspondientes  clases  de  análisis  que  par=cipan  en  el  caso  de  uso  

n  Estudiar  los  requisitos  especiales  del  caso  de  uso:  realizarlos  con  los  mecanismos  genéricos  de  diseño  o  con  clases  de  diseño  

n  Asignar  responsabilidades  a  las  clases  iden=ficadas  n  Realizar  un  diagrama  de  clases  que  muestre  las  clases  de  diseño  que  intervienen  en  la  realización  del  caso  de  uso  y  las  relaciones  entre  ellas  

Diseño  Ac=vidades  n  Diseño  de  los  casos  de  uso  

¨  Iden=ficar  las  clases  de  diseño  

Validar usuario Realización en diseño

LectorDeTarjetas

Pantalla

Teclado

GestorDeCliente

Transacción

UsuariosDelBanco

Diseño  Ac=vidades  

n  Diseño  de  los  casos  de  uso  ¨ Describir  interacciones  entre  objetos  de  diseño  

n  U=lizar  diagramas  de  secuencia    ¨  objetos,  instancias  de  actores,  enlaces  

n  Comenzar  estudiando  la  realización  en  análisis  del  caso  de  uso  n  Sobre  los  diagramas  de  secuencia:  

¨  el  caso  de  uso  comienza  cuando  una  instancia  de  un  actor  envía  un  mensaje  a  un  objeto  interfaz  

¨  cada  clase  de  diseño  iden=ficada  debería  tener  al  menos  un  objeto  par=cipando  en  el  diagrama  de  secuencia  

n  En  esta  fase  ges=onar  excepciones  y  errores  (entradas  incorrectas,  situaciones  anormales,  etc.)  

Diseño  Ac=vidades  

n  Diseño  del  c.u.  “Validar  usuario”  –  Error  Pin  

: Teclado : Cliente del banco :LectorDeTarjetas : Pantalla

1: introducirTarjeta 2: datosTarjeta (datos)

3: visualizar (Introducir PIN)

5: introducirPIN (PIN) 6: datosPIN (PIN)

7: autentica (datos, PIN)

8: valida (datos, PIN)

9: error

11: presenta (error PIN) 12: visualizar (error PIN)

: Transacción : GestorDeCliente : UsuariosDelBanco

13: visualizar (error PIN)

4: visualizar (Introducir PIN)

10: almacenaDatos (datos)

Diseño  Ac=vidades  

n  Diseño  del  caso  de  uso  “Sacar  dinero”  ¨  Suponemos  que  el  usuario  ya  ha  sido  iden=ficado  (se  ha  ejecutado  el  

caso  de  uso  anterior)  ¨  Ahora  selecciona  la  opción  “sacar  dinero”  

Sacar dinero Realización en diseño

Pantalla Teclado Expendedor

Dinero

GestorDeCliente

Transacción

Cuentas

Cuenta

Diseño  Ac=vidades  

n  Diseño  del  c.u.  “Sacar  dinero”  ¨  Añadimos  la  clase  Cuentas  que  asocia  número  de  cuenta  con  una  

instancia  de  la  clase  Cuenta.  ¨  La  clase  Transacción  ya  no  actuará  directamente  sobre  Cuenta.  

: Transacción : Cuentas

1: ingreso (numeroDeCuenta, importe)

: Cuenta

2: ingreso (importe) Vista parcial del diagrama (modelo de análisis)

Diseño  Ac=vidades  

n  Refinando  el  caso  de  uso  “Sacar  dinero”  

Cliente del banco Interfaz de cajero

Cuenta

UsuariosDelBanco

Transacción

1

autentica

Cuentas

1..n

1..n

1..n

1..n posee

1..2

opera

1..2

1

Diseño  Ac=vidades  n  Refinando  el  c.  u.  “Sacar  dinero”:  secuencia  correcta  

¿Qué pasa con la impresora?

: Cliente del banco : Teclado : Pantalla : ExpDinero : GestorDeCliente : Transacción : Cuentas : Cuenta : Impresora

1: opcion (sacar dinero) 2: sacarDinero

3: visualizar (Teclee importe)

4: IntroducirImporte 5: importe

6: retirarDinero (importe)

7: reintegro (cuenta, importe)

8: reintegro (importe) 9: OK

10: OK 11: OK

12: visualizar (Retire su tarjeta)

14: expulsa (importe)

15: visualizar (Retire su dinero)

13: visualizar (Retire su tarjeta)

16: visualizar (Retire su dinero)

Diseño  Ac=vidades  n  Refinando  el  c.  u.  “Sacar  dinero”:  no  hay  fondos  

Falta: [retirar tarjeta] - se ha superado el límite diario - en el cajero no hay dinero

: Cliente del banco : Teclado : Pantalla : Impresora

1: opcion (sacar dinero)

4: IntroducirImporte

2: sacarDinero

3: visualizar (Teclee importe)

5: importe

6: retirarDinero (importe)

7: reintegro (cuenta, importe)

8: reintegro (importe) 9: no hay saldo

10: no hay saldo 11: no hay saldo

: GestorDeCliente : Transacción : Cuentas : Cuenta

12: visualizar (No hay saldo) 13: visualizar (No dispone de saldo suficiente)

: ExpDinero

Diseño  Ac=vidades  n  Modelo  de  clases  de  diseño  

Impresora

LectorDeTarjetas

Pantalla

Teclado

Cliente del banco

GestorDeCliente

Cuenta

UsuariosDelBanco

Transacción

Cuentas

Recogedor Dinero

ExpDinero

Diseño  Ac=vidades  

n  Diseño  de  las  clases  ¨  Iden=ficar  las  responsabilidades  de  las  clases  de  diseño  (papeles  en  los  

casos  de  uso)  ¨  Iden=ficar:  

n  operaciones  n  atributos  n  relaciones  en  las  que  par=cipa  n  estados  (diagramas  de  estados)  n  métodos  que  soportan  sus  operaciones  n  requisitos  nuevos…  

Diseño  Ac=vidades  

n  Diseño  de  las  clases:  ¨  Iden=ficar  operaciones  

n  En  el  lenguaje  de  implementación  n  Mirar  responsabilidades  que  =ene  en  los  casos  de  uso  

¨  Iden=ficar  atributos  n  Describirlos  en  el  lenguaje  de  programación  n  Considerar  los  atributos  de  las  clases  de  análisis  de  las  que  se  derivan  

¨  Iden=ficar  asociaciones  y  agregaciones  n  Las  interacciones  en  los  diagramas  de  secuencia  precisan  de  asociaciones  entre  las  

clases  que  interactúan  n  Minimizar  el  número  de  relaciones  entre  clases  (disminuir  el  acoplamiento)  n  Refinar  mul=plicidad,  papeles,  etc.    n  Refinar  la  navegabilidad  (dirección)  de  las  asociaciones  en  base  a  los  diagramas  de  

secuencia  n  Iden=ficar  generalizaciones-­‐especializaciones  

Diseño  Ac=vidades  

n  Diseño  de  las  clases:  ¨  Describir  métodos  

n  Algoritmos  para  implementar  alguna  operación  (lenguaje  natural)  n  Esqueletos  de  métodos  generado  por  la  herramienta  n  En  general,  esto  se  suele  hacer  en  implementación  

¨  Describir  estados  n  Algunos  objetos  reaccionan  en  función  de  su  estado  actual  n  U=lizar  diagramas  de  transición  de  estados  

41

Diseño  Ac=vidades  

n  Modelo  de  clases  de  diseño:  

42

Diseño  Ac=vidades  

n  Modelo  de  clases  de  diseño:  

43 Falta: multiplicidad y navegabilidad

Diseño  Ac=vidades  

n  Modelo  de  clases  de  diseño:  

Diseño  Ac=vidades  

n  Diseño  de  una  clase:  ¨  La  única  clase  que  =ene  un  comportamiento  parecido  a  una  máquina  

de  estados  es  GestorDeCliente  

¨  Realizar  el  diagrama  de  transición  de  estados  del  sistema  Cajero  Automá=co  

Diseño  Ac=vidades  

n  Diseño  de  una  clase:  Esperando

tarjeta

Leyendo tarjeta

tarjeta introducida

Esperando PIN

Validando PIN

PIN introducido( PIN )

Recogiendo tarjeta

Esperando opción

[ incorrecto ] [ > 3 intentos ] [ correcto ]

Ingresando

ingreso( importe )

Reintegrando

reintegro (importe ) Transferencia

transferencia( cuenta, importe )

Expulsando dinero

[ OK ]

Expulsar tarjeta

dinero retirado

[ Not OK ]

Diseño  Ac=vidades  

n  Diseño  de  los  subsistemas:  ¨  Intentar  que  los  subsistemas  de  diseño  estén  débilmente  acoplados  ¨  Intentar  que  las  clases  dentro  de  los  subsistemas  tengan  una  alta  

cohesión  ¨  Describir  las  dependencias  entre  los  subsistemas  ¨  Determinar  qué  clases  de  unos  subsistemas  interactúan  con  qué  otras  

clases  de  otros  subsistemas  ¨  Asegurarse  que  el  subsistema  soporta  sus  interfaces  ¨  Obje=vos:  

n  Subsistemas  independientes  n  Garan=zar  corrección  de  interfaces    n  Garan=zar  la  realización  de  dichas  interfaces  

Diseño  Ejemplo  

n  Refinando  el  c.  u.  “Ingresar  dinero”:    

Ingresar dinero Realización en diseño

Pantalla Teclado

RecogedorDinero

GestorDeCliente

Transacción

Cuentas

Cuenta

Diseño  Ejemplo  

n  Refinando  el  c.  u.  “Ingresar  dinero”:    secuencia  correcta  

: Cliente del banco : Teclado : Pantalla : Recogedor

Dinero 1: opcion (ingresar dinero)

5: IntroduceImporte

2: ingresarDinero 3: visualizar (Teclee importe)

6: importe

19: visualizar (Dinero ingresado) 21: visualizar (Retire su tarjeta)

13: ingresarDinero (importe) 14: ingreso (cuenta, importe)

15: ingreso (importe) 16: OK

17: OK 18: OK

7: visualizar (introducir dinero) 9: abrirCajon

10: IntroduceDinero 11: ContarDinero (cantidad)

12: validar (importe, cantidad)

: GestorDeCliente : Transacción : Cuenta : Cuentas

20: visualizar (Dinero ingresado)

22: visualizar (Retire su tarjeta)

4: visualizar (Teclee importe)

¿Qué podríamos agregar o modificar?

8: visualizar (introducir dinero)

Diseño  Ejemplo  

n  Refinando  el  c.  u.  “Ingresar  dinero”:    can=dad  incorrecta  

: Cliente del banco : Teclado : Pantalla

1: opcion (ingresar dinero)

4: IntroducirImporte

2: ingresarDinero

3: visualizar (Teclee importe)

5: importe

11: visualizar (Cantidad errónea)

17: visualizar (Retire su tarjeta)

6: visualizar (introducir dinero)

10: validar (importe, cantidad)

7: abrirCajon 8: ingresarDinero

9: dinero (cantidad)

12: visualizar (Retire su dinero)

13: abrirCajon 14: dineroRecogido

15: recogido

16: cerrarCajon

:GestorDeCliente : Recogedor Dinero

¿Mensajes desde la Pantalla hacia el usuario?

Diseño  Ejemplo  

n  Refinando  el  c.  u.  “Transferencia”:      

Cuenta

Transferencia Realización en diseño, transferencia

Teclado

Pantalla

GestorDeCliente

Transacción

Cuentas

Diseño  Ejemplo  n  Refinando  el  c.  u.  “Transferencia”:    secuencia  correcta  

: Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas : Cuenta

1: opcion (transferencia)

4: IntroducirImporte

2: transferencia

3: visualizar (Teclee importe)

5: importe

19: visualizar (Transferencia realizada)

20: visualizar (Retire su tarjeta)

6: visualizar (Teclee cuenta destino)

9: transferencia (cuentaOrigen, cuentaDestino,importe) 10: reintegro (cuentaOrigen, importe)

11: reintegro (importe) 12: OK

13: OK

18: OK

7: cuentaDestino (cuenta) 8: cuentaDestino (cuenta)

14: ingreso (cuentaDestino, importe) 15: ingreso (importe)

16: OK 17: OK

Diseño  Ejemplo  n  Refinando  el  c.  u.  “Transferencia”:    no  hay  fondos  

: Pantalla : Cliente del banco

1: opcion (transferencia)

4: IntroducirImporte

7: cuentaDestino (cuenta)

2: transferencia

3: visualizar (Teclee importe)

5: importe

15: visualizar (No hay fondos)

16: visualizar (Retire su tarjeta)

6: visualizar (Teclee cuenta destino)

8: cuentaDestino (cuenta)

9: transferencia (cuentaOrigen, cuentaDestino,importe)

14: no hay fondos

10: reintegro (cuentaOrigen, importe)

13: no hay saldo

11: reintegro (importe)

12: no hay saldo

: Teclado : GestorDeCliente : Transacción : Cuentas : Cuenta

El Proceso Unificado de Desarrollo

3- Diseño

Profesor: David Granada