[IS-LADE_2012-13]T16 - PU - Diseño 2012

Tema XIII:

Proceso Unificado: Diseño

Diana Marcela Sánchez Fúquene Análisis y Diseño Orientado a Objetos

Índice

Visión general

Artefactos Modelo de diseño

Clases de diseño

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

Subsistemas en diseño

Interfaz

Actividades Diseño de los casos de uso

Diseño de las clases

Diseño de subsistemas

2 - www.kybele.es Análisis y Diseño Orientado a Objetos

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



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




Objetivos del diseño: Acercar el modelo de análisis al modelo de implementación

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

Identificar requisitos no funcionales y restricciones en relación a: Lenguajes de programación, reutilización de componentes, sistemas

operativos, tecnologías de distribución, concurrencia, bases de datos, interfaces de usuario, gestió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



Diagrama de Subsistemas

Diagramas de Clases de

Diseño

Diagramas de Interacción

Esquemas de Bases de

Datos OO

Formularios, Reportes,

Interfaz Gráfica

Sistemas de Seguridad y de control

Diagrama de Despliegue y

Nodos



Se modela el sistema para que dé soporte a los requisitos funcionales y no funcionales

Su entrada esencial es el modelo de análisis (una comprensión detallada de los requisitos)

Objetivos: Profundizar en los requisitos no funcionales y restricciones dependientes

de la plataforma. Crear una entrada apropiada para la implementación Descomponer los trabajos de implementación en partes mas manejables

y que permitan concurrencia. Utilización de subsistemas Capturar las interfaces entre los subsistemas.

Es el centro de atención final de la fase de elaboración e iteraciones

iniciales de la fase de construcción



Modelo de Análisis Modelo de Diseño

Abstracción del sistema Modelo físico. Plano de implementación

Genérico respecto al diseño (pueden obtenerse varios diseños)

No genérico. Específico a una implementación

Menos formal y menos caro de desarrollar Más formal y mas caro de desarrollar (5 veces mas)

Bosquejo del diseño del sistema Manifiesto del diseño del sistema

No necesariamente tiene que estar mantenido durante todo el ciclo de vida del software

Debe ser mantenido durante todo el ciclo de vida

Entrada esencial para modelar el sistema Da forma al sistema mientras intenta preservar la estructura heredada del modelo de análisis

3 estereotipos conceptuales sobre las clases: interfaz, control y entidad

Cualquier número de estereotipos físicos sobre las clases de diseño (depende del lenguaje de programación)


Diseño Diagramas UML

Modelo de Diseño

Modelo de

Pruebas


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 Artefactos

Análisis y Diseño Orientado a Objetos 11

Diagrama de Clases de Dominio

Diagrama de Casos de Uso

Descripción de Casos de Uso

Diagramas de Colaboración

Diagramas de Actividad

Diagramas de Transición de Estados

Diagrama de Componentes

Diagrama de Despliegue

Diagrama de Clases de Diseño

Diagramas de Interacción (Secuencia)

Diagramas de Transición de Estados de Diseño

Diagramas de Subsistemas

Modelos de Análisis Modelos de Diseño

Diseño Artefactos

Modelo de diseño Diagramas de secuencia

Es un diagrama de interacción que define cómo se lleva a cabo y se ejecuta un caso de uso en términos de objetos de diseño

Para flujos de eventos principales y caminos alternativos

Diagramas de clases de diseño Descripciones textuales de las clases Diagramas de transición de estados para el comportamiento

interno de cada clase Descomposición del modelo en subsistemas

Modelo de despliegue

Diagramas de despliegue: distribución física del sistema en nodos de computo Descripciones de los nodos y sus interrelaciones


Diseño Artefactos

Modelo de diseño Describe la realizacion física de los 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 actividades de implementación

*

Subsistemas de diseño

Realización

en diseño

*

* * * *

Clases de diseño Interfaz

* *

Modelo de diseño


Diseño Artefactos

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

implementación Las operaciones, atributos, tipos, visibilidad (public, protected, private,

etc...), se pueden especifican con la sintaxis del lenguaje elegido para la implementación

Las relaciones entre clases de diseño se traducen de manera directa al lenguaje:

• Generalización herencia

• Asociaciones, agregaciones atributos

Los métodos tienen una correspondencia directa con el correspondiente método en la implementación

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

Realizan interfaces


Diseño Artefactos

Clases de diseño: Ejemplo

Transacción

cuenta : Cuenta

cantidad: Dinero

……………

Cuenta

reintegro(cantidad : Dinero) : Boolean

ingreso(cantidad : Dinero) : Boolean

1..2 1..2

opera saldo : Dinero

limiteDiario: Dinero = 300


Diseño Artefactos

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 Modelo de diseño

Realización en análisis Realización en diseño

<<trace>>


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

La realización en diseño de un caso de uso incluye: Diagramas de clases: clases participantes

Diagramas de interacción: escenarios del caso de uso

Descripción textual del flujo de eventos

Requisitos de implementación

Opcionalmente: subsistemas e interfaces

18

Subsistema de

diseño Clase de

diseño

Realización en diseño

(from Use Case View)

participante participante


Diseño Artefactos

Diagramas de clase Una clase de diseño (y sus objetos) puede participar en varias

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

Retiro

Cliente


Diseño Artefactos

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

Utilizar mejor diagramas de secuencia que de colaboración: interesa la secuencia cronológica de las interacciones Secuencias de interacciones detalladas y ordenadas en el tiempo

Se pueden incluir subsistemas y las interfaces que proporcionan


Diseño Artefactos

Diagrama de Secuencia Tipos de Acciones:

Llamada: Invoca una operación sobre un objeto. Un objeto puede llamarse a si mismo, lo que da lugar a una invocación local

Retorno: Devuelve un valor al invocador

Envío: Envía una señal a un objeto.

Creación: Crea un objeto

Destrucción: Destruye un objeto. Un objeto puede suicidarse al destruirse a si mismo.

El tipo mas común de mensaje es la llamada Señal: un valor que se comunica de manera asíncrona a un

objeto destinatario Después de enviar la señal, el objeto destinatario continúa con su

propia ejecución.


c:Cliente a : AyudaPlanificación

: AgenteBilletes

<<create>>

establecerItinerario(i)

calcularRuta()

ruta

<<destroy>>

notificar()

Diseño Artefactos

Diagrama de Secuencia creación

llamada

retorno

destrucción

llamada local

envío

Línea de vida

Barra de activación


Diagrama de Secuencia Fragmentos Combinados: Una o mas secuencias de procesos incluidas en

un marco

Permiten agregar lógica de procedimientos complejos

Diseño Artefactos

Nombre Descripción

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

…


Diseño Artefactos


Diseño Artefactos

Diagramas de interacción diagramas de secuencia

:Dispositivo

de visualización :Teclado

:Lector de

Tarjetas

:Expendedor

Dinero

:Gestor

de Cliente

:Gestor

de Transacciones :Cliente

del Banco

1: Introducir

tarjeta 2: Tarjeta introducida (ID)

3: Solicitar PIN

4: Mostrar petición

5: Especificar código PIN

6: Código PIN (PIN)

7: Solicitar Validación de PIN (PIN)


Diseño Artefactos

Flujo de eventos Para clarificar los diagramas de secuencia: descripción textual

Debe redactarse en términos de objetos o de subsistemas No debe mencionar ni los atributos, operaciones o asociaciones entre objetos

Una descripción no tiene que ser local a un diagrama. Puede englobar a varios e indicar cómo se relacionan.

Requisitos de implementación Requisitos a gestionar en implementación

Quizás durante esta fase de diseño se obtengan algunos nuevos Se capturan en la fase de diseño, pero se gestionan en la implementación

Representarlos con restricciones {...} asignadas a las clases de diseño, operaciones, atributos, asociaciones, etc.


Diseño Artefactos

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

*


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

Recurso Diagrama de Paquetes Paquete: Abstracciones que organizan un modelo.

Los paquetes se utilizan para organizar los elementos de modelado

Visibilidad: Se puede seleccionar que elementos son visibles fuera del paquete y cuales quedan ocultos. • +: Publico; - : Privado; #: Protegido;

Se pueden emplear para mostrar una vista arquitectónica del sistema

Agrupan elementos cercanos semánticamente o que suelen cambiar juntos

Se pueden crear paquetes de servicio reutilizables


«subsystem»

Cliente

+Formulario de Pedido

-Seguimiento

«subsystem»

Políticas

+Reglas de Pedidos

-GUI::Ventana«subsystem»

GUI

+Formulario

+Ventana

#GestorEventos

«import»

«import»

Sensores::Vision

Diseño Artefactos

Diagrama de Paquetes Nombre simple estereotipado

Nombre calificado

Paquete contenedor

Nombre del paquete

Exportaciones

Importaciones


Diseño Artefactos

Interfaces

Los interfaces se utilizan 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 contiene.


* Clases de diseño

Interfaz *

realiza

realiza


Diseño Artefactos

Interfaces Definen una línea entre la especificación de lo que una

abstracción hace y la implementación de cómo lo hace.

Colección de operaciones que sirven para especificar un servicio de una clase o un componente

Para mostrar la relación entre una clase y sus interfaces existe una notación especial. Interfaz proporcionada: Representa servicios prestados por la

clase

Interfaz requerida: Representa servicios que una clase espera de otra

Una interfaz especifica un contrato para una clase o un componente sin dictar su implementación


Rastreador de Objetivo

Observador

Objetivo

«interface»

Observador

Observador

Rastreador de Objetivo Objetivo«uses»

Diseño Artefactos

Representación de Interfaces

Interfaz proporcionada

Interfaz requerida

Realización (dependencia proporcionada)

Uso (dependencia requerida)

Definición de Interfaz


Diseño Artefactos


Modelo de objetos que describen la distribución física del sistema de acuerdo a la funcionalidad entre los nodos de computo

Nodo: Recurso de cómputo. Por ejemplo: procesador o dispositivo hardware

Los nodos poseen relaciones que representan medios de comunicación. Por ejemplo: Internet, intranet, bus

Describe diferentes configuraciones de red

La funcionalidad de cada nodo se define por sus componentes

Correspondencia entre la arquitectura software y la arquitectura del sistema (hardware)

*

Modelo de

despliegue

Nodo


Diseño Artefactos

Diagramas de despliegue :

Se utilizan para modelar los aspectos físicos de los sistemas orientados a objetos

Muestra la configuración de nodos que participan en la ejecución y de los componentes que residen en ellos

Contienen:

Nodos

Relaciones de dependencia y asociación

Notas y restricciones

Componentes que residen en algún nodo

Diagrama de despliegue de un sistema cliente/servidor

Multiplicidades explícitas

Nodos

estereotipados

servidores clientes


Diseño Artefactos

Ejemplo de Diagrama de Despliegue


Diseño Ejemplo

Para ilustrar las actividades, utilizaremos el ejemplo del cajero automático

Sacar dinero

Ingresar dinero

Transferencia

Cliente

del banco

Validar usuario

<<include>>

<<include>>

<<include>>


Diseño Actividades

Diseño de la arquitectura Arquitecto Identificar nodos y configuración Identificar subsistemas y clases

Diseñar un caso de uso Ingeniero de CU

Identificar clases de diseño y subsistemas Distribuir comportamiento del caso de uso Capturar requisitos de implementación

Diseñar una clase Ingeniero de Componentes

Identificar responsabilidades y atributos Capturar requisitos especiales sobre la realización del CU

Diseñar un subsistema Ingeniero de Componentes


Diseño Actividades

Diseño de la arquitectura: Identificar nodos y configuraciones de Red Configuraciones físicas influyen sobre la Arquitectura del Software.

Determina: Clases activas que se necesitan Distribución de la funcionalidad entre los nodos de red.

Patrones Arquitectónicos Modelo de Capas Modelo de Niveles Modelos Orientados a Servicios

Preguntas a resolver: ¿Todos los actores del caso de uso interactuarán con el sistema en el mismo sitio

físico? ¿Qué requerimientos de computación necesito en cada nodo? ¿Qué tipo de conexiones o red existe entre los nodos? ¿Qué protocolos manejan? ¿Cuáles son sus características? ¿Tengo requisitos del tipo Copias Redundantes para caso de fallos? ¿Copia de seguridad de BBDD?


Diseño Actividades

Ejemplo: Patrón de 3 capas

IU

Lógica de Negocio

Acceso a Datos

IU IU …

BD

IU

Servidor Web

IU

Servidor Ventas

Servidor Compras

intranet intranet

Internet


Diseño Actividades

Diseño de los casos de uso

Identificar las clases de diseño y/o subsistemas necesarios para la realización del CU

Distribuir el comportamiento del CU entre las objetos y/o subsistemas de diseño

Definir los requisitos sobre las operaciones de las clases de diseño y/o sobre los subsistemas y sus interfaces

Capturar los requisitos de implementación del CU


Diseño Actividades

Diseño de los casos de uso Identificar las clases de diseño

Derivar las clases de diseño de las correspondientes clases de análisis que participan en el CU

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

• Persistencia

• Distribución

• Seguridad

• Transacciones

Asignar responsabilidades a las clases identificadas

Realizar un diagrama de clases que muestre las clases de diseño que intervienen en la realización del CU y las relaciones entre ellas


Diseño Actividades

Identificar las clases de diseño Derivar clases de diseño de las correspondientes clases de análisis que participan

en el caso de uso.

Identificar Clases Activas: se deben considerar los requerimientos de concurrencia en el sistema como por ejemplo:

Requerimientos de disponibilidad y performance que los distintos actores tienen al interactuar con el Sistema.

La distribución del Sistema sobre nodos. Los objetos activos deben distribuirse en distintos nodos, los cuales podrían requerir al menos un objeto activo por cada nodo y un objeto activo separado para manejar la comunicación entre los mismos. y

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 Actividades

Identificar clases

De interfaz: depende tecnología

De entidad: persistencia, bases de datos

De control: distribución, rendimiento, transacción

Requisitos Especiales

Persistencia, Remotos. Ej Cajero: Cuenta es persistente


Diseño Actividades

Persistencia

Consiste en preservar de forma permanente los objetos.

Almacenamiento en BD

BD Relacional

BD Objetos

Almacenamiento en Ficheros

Binario

XML

Otros


Diseño Actividades


Identificar las clases de diseño

Validar usuario Realización en diseño

LectorDeTarjetas

Pantalla

Teclado

GestorDeCliente UsuariosDelBanco

Transacción


Diseño Actividades


Describir interacciones entre objetos de diseño

Utilizar diagramas de secuencia • objetos, instancias de actores, enlaces (trasmisiones de mensajes)

Comenzar estudiando la realización en análisis del caso de uso

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 identificada debería tener al menos un objeto participando en el diagrama de secuencia

En esta fase gestionar excepciones y errores (entradas incorrectas, situaciones anormales, etc.) 46 - www.kybele.es Análisis y Diseño Orientado a Objetos

Diseño Actividades

Diseño del c.u. “Validar usuario”: secuencia correcta

: Cliente del banco :LectorDeTarjetas : Pantalla : Teclado

1: introducirTarjeta 2: datosTarjeta (datos)

3: visualizar (Introducir PIN)

4: OK

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

7: autentica (datos, PIN)

8: valida (datos, PIN)

9: OK

11: presenta (opciones)

10: almacenaDatos (datos)

12: visualizar (opciones)

: Transacción : GestorDeCliente : UsuariosDelBanco

13: visualizar (opciones)


Diseño Actividades

Diseño del c.u. “Validar usuario”: código incorrecto

: Cliente del banco :LectorDeTarjetas : Pantalla : Teclado

1: introducirTarjeta 2: datosTarjeta (datos)

3: visualizar (Introducir PIN)

4: OK

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)


Diseño Actividades

Diseño del caso de uso “Sacar dinero” Suponemos que el usuario ya ha sido identificado (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 Actividades

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 Actividades

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 Actividades

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)




Diseño Actividades

Refinando el c. u. “Sacar dinero”: no hay fondos

Falta:

- 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


5: importe

6: retirarDinero (importe)

7: reintegro (cuenta, 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 Actividades

Modelo de clases de diseño

Impresora

LectorDeTarjetas

Pantalla

Teclado

Cliente del banco

GestorDeCliente

Cuenta

UsuariosDelBanco

Transacción

Cuentas

Recogedor Dinero

ExpDinero


Diseño Actividades

Diseño de las clases Identificar las responsabilidades de las clases de diseño (papeles en los

casos de uso)

Identificar: operaciones

atributos

relaciones en las que participa

estados (diagramas de estados)

métodos que soportan sus operaciones

requisitos nuevos…


Diseño Actividades

Diseño de las clases: Identificar operaciones

En el lenguaje de implementación

Mirar responsabilidades que tiene en los casos de uso

Identificar atributos Describirlos en el lenguaje de programación

Considerar los atributos de las clases de análisis de las que se derivan

Identificar asociaciones y agregaciones Las interacciones en los diagramas de secuencia precisan de asociaciones entre las

clases que interactúan

Minimizar el número de relaciones entre clases (disminuir el acoplamiento)

Refinar multiplicidad, papeles, etc.

Refinar la navegabilidad (dirección) de las asociaciones en base a los diagramas de secuencia

Identificar generalizaciones-especializaciones


Diseño Actividades

Diseño de las clases: Describir métodos

Algoritmos para implementar alguna operación (lenguaje natural)

Esqueletos de métodos generado por la herramienta

En general, esto se suele hacer en implementación

Describir estados Algunos objetos reaccionan en función de su estado actual

Utilizar diagramas de transición de estados


Diseño Actividades

Modelo de clases de diseño:

RecogedorDinero

crearCajon() : CajonDinero

abrirCajon()

cerrarCajon()

contarCantidad() : Dinero

LectorDeTarjetas

crearLector() : LectorDeTarjetas

leerTarjeta() : datosTarjeta

Pantalla

visualizar(mensaje : String)

crearPantalla() : Pantalla

Teclado

crearTeclado() : Teclado

leerPIN() : unPIN

leerOpcion() : unaOpcion

leerCantidad() : Dinero

leerNumCuenta() : unIDCuenta

ExpendedorDinero

crear() : ExpendedorDinero

expulsar(importe : Dinero)

GestorDeCliente

crear() : GestorDeCliente

iniciarSesion()

Impresora

crearImpresora() : Impresora

imprimir(mensaje : String)


Diseño Actividades

Modelo de clases de diseño:

GestorDeCliente miTransaccion : Transacción

crear() : GestorDeCliente iniciarSesion() visualizar(resultados : String)

Transacción miCliente : GestorDeCliente datosTarjeta : DatosTarjeta numIntentosFallidos : 1..3 = 0 cuentas : Cuentas usuarios : UsuariosDelBanco

almacenarDatos(datos : DatosTarjeta) validar(importe : Dinero, cantidad : Dinero) autenticar(datos : DatosTarjeta, PIN : UnPIN) : Boolean retirarDinero(importe : Dinero) : Boolean ingresarDinero(importe : Dinero) : Boolean trasnsferencia(cuentaOrigen : Cuenta, cuentaDestino : Cuenta, importe : Dinero) : Boolean

UsuariosDelBanco usuarios : Dictionary

validar(datos : DatosTarjeta, PIN : UnPIN) : Boolean

Cuentas cuentas : Dictionary

reintegro(cuenta : Cuenta, importe : Dinero) : Boolean ingreso(cuenta : Cuenta, importe : Dinero) : Boolean

Cuenta datos : DatosCuenta limiteDiario : Dinero = 300

reintegro(importe : Dinero) : Boolean ingreso(importe : Dinero) : Boolean


Diseño Actividades

Diseño de una clase:

La única clase que tiene un comportamiento parecido a una máquina de estados es GestorDeCliente

Realizar el diagrama de transición de estados del sistema Cajero Automático


Diseño Actividades

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 Actividades

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

Objetivos: Subsistemas independientes

Garantizar corrección de interfaces

Garantizar la realización de dichas interfaces


Diseño Actividades

Identificación de Subsistemas Funciones específicas de aplicación

Funcionalidades compartidas

MIddlewares

Protocolos

Sistemas operativos, SGBD, Sw de comunicaciones, kits GUI, gestión transacciones


Gestión de

facturas del

comprador

TCP/IP

Gestión de

Planificación

de Pagos

Gestión de

cuentas

Java.applet Java.awt

Máquina

virtual de

JavaNavegador

de Internet

Capa específica de aplicación

Capa general de aplicación

Capa Intermedia

Capa de software del sistema

Java.rmi

Diseño Actividades

Cajero Automático

Diagrama de Subsistemas

Correspondencia con Diagrama de Despliegue


Cajero Automático

Servidor Central

Intranet

Interfaz de

Usuario

Controlador

de

Peticiones

Bases de

Datos

Paquete superior::Cliente

Diseño Ejemplo

Refinando el c. u. “Ingresar dinero”:

Ingresar dinero Realización en diseño

Pantalla Teclado

RecogedorDinero

GestorDeCliente

Transacción

Cuentas

Cuenta


Diseño Ejemplo

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

: Cliente del banco

: Teclado : Pantalla : Recogedor

Dinero

1: opcion (ingresar dinero)


2: ingresarDinero


5: importe

17: visualizar (Dinero ingresado)


11: ingresarDinero (importe)

12: ingreso (cuenta, importe)


14: OK 15: OK

16: OK

6: visualizar (introducir dinero)

7: abrirCajon

8: IntroduceDinero 9: ContarDinero (cantidad)

10: validar (importe, cantidad)

: GestorDeCliente : Transacción : Cuenta : Cuentas

18: visualizar (Dinero ingresado)



Diseño Ejemplo

Refinando el c. u. “Ingresar dinero”: cantidad incorrecta

: Cliente del banco : Teclado : Pantalla

1: opcion (ingresar dinero)


2: ingresarDinero


5: importe

11: visualizar (Cantidad errónea)


6: visualizar (introducir dinero)

10: validar (importe, cantidad)

7: abrirCajon

8: recogerDinero 9: dinero (cantidad)


13: abrirCajon 14: dineroRecogido

15: recogido

16: cerrarCajon

:GestorDeCliente : Recogedor

Dinero


Diseño Ejemplo

Refinando el c. u. “Transferencia”:

Cuenta

Transferencia Realización en diseño,

transferencia

Teclado

Pantalla

GestorDeCliente

Transacción

Cuentas


Diseño Ejemplo

Refinando el c. u. “Transferencia”: secuencia correcta

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

1: opcion (transferencia)


2: transferencia


5: importe

19: visualizar (Transferencia realizada)


6: visualizar (Teclee cuenta destino)

9: transferencia (cuentaOrigen, cuentaDestino,importe)

10: reintegro (cuentaOrigen, importe)


12: OK 13: OK

18: OK

7: cuentaDestino (cuenta)


14: ingreso (cuentaDestino, importe)


16: OK 17: OK


Diseño Ejemplo

Refinando el c. u. “Transferencia”: no hay fondos

: Pantalla

: Cliente del banco

1: opcion (transferencia)



2: transferencia


5: importe

15: visualizar (No hay fondos)


6: visualizar (Teclee cuenta destino)


9: transferencia (cuentaOrigen, cuentaDestino,importe)

14: no hay fondos

10: reintegro (cuentaOrigen, importe)

13: no hay saldo


12: no hay saldo

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


Documents

[IS-LADE_2012-13]T16 - PU - Diseño 2012