análisis y diseño orientado a objetos 3 - diseño · análisis y diseño orientado a objetos 1 3...
TRANSCRIPT
Análisis y Diseño Orientado a Objetos
1
3 - Diseño
El proceso unificado de desarrollo, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999
The unified software development process, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999
1. Visión general
2. El diseño en el Proceso Unificado de Desarrollo
3.1 Artefactos.3.1.1 Modelo de diseño.3.1.2 Clases de diseño.
Diseño
2
3.1.2 Clases de diseño.3.1.3 Realización en diseño de los casos de uso.3.1.4 Subsistemas en diseño.3.1.5 Interfaz.
3.2 Actividades.3.2.1. Diseño de los casos de uso.3.2.2. Diseño de las clases.3.2.3. Diseño de subsistemas.
Requisitos
AnálisisModelo deAnálisis
Modelo deCasos de Uso
dependencia de traza
1. Visión general
3
Pruebas
Implementación
DiseñoModelo deDespliegue
Modelo deDiseño
Modelo deImplementación
Modelo dePruebas
1. Visión general. 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
4
� 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
Modelo de
Caso de Uso
Modelo de
Análisis
Modelo de
Diagramas de Casos de Uso
Diagramas de Clases
Diagramas de Componentes
Diagramas UML
5
Modelo de
Diseño
Modelo de
Pruebas
Modelo de
Despliegue
Modelo de
Implementación
Diagramas de Secuencias
Diagramas de Colaboración
Diagramas de Estados
Diagramas de Actividad
Diagramas de Objetos
1. Visión general
2. El diseño en el Proceso Unificado de Desarrollo
3.1 Artefactos.3.1.1 Modelo de diseño.3.1.2 Clases de diseño.
Diseño
6
3.1.2 Clases de diseño.3.1.3 Realización en diseño de los casos de uso.3.1.4 Subsistemas en diseño.3.1.5 Interfaz.
3.2 Actividades.3.2.1. Diseño de los casos de uso.3.2.2. Diseño de las clases.3.2.3. Diseño de subsistemas.
3.1.1 Artefactos. 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 actividades de implementación
� Artefactos
� Modelo de diseño
� Clases de diseño� Realización en
diseño
7
*
Subsistemas de diseño
Realización en diseño
Modelo de diseño
*
* * **
Clases de diseñoInterfaz
**
� Subsistemas� Interfaz
� Actividades
3.1.2 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
� Las relaciones entre clases de diseño se traducen de
8
� Las relaciones entre clases de diseño se traducen de manera directa al lenguaje:� generalización: herencia� asociaciones, agregaciones: atributos
� Se pueden postergar algunos requisitos a implementación (por ejemplo: manera de nombrar los atributos, operaciones, ...)
� Realizan interfaces.
3.1.2 Artefactos. Clases de diseño
Transacción
Cuenta
operasaldo : DinerolimiteDiario: Dinero = 300
9
Transacción
cuenta : Cuentacantidad: Dinero……………
retirar(cantidad : Dinero) : Booleaningreso(cantidad : Dinero) : Boolean
1..21..2
limiteDiario: Dinero = 300
� 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
3.1.3 Artefactos. Realización en diseño de los casos de uso
10
Realización en análisis Realización en diseño
<<trace>>
TransacciónCuentaInterfaz
del cajero
MODELO DE ANÁLISIS
3.1.3 Artefactos. Realización en diseño de los casos de uso
11
Dispositivode visualización
Teclado
Lector deTarjetas
ExpendedorDinero
RecogedorDinero
Gestorde Cliente
Cuenta
Gestorde Cuentas
Gestorde Transacciones
MODELO DE DISEÑO
…..
� 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
3.1.3 Artefactos. Realización en diseño de los casos de uso
12
Subsistema dediseño
Clase dediseño
Realización en diseño(from Use Case View)
participanteparticipante
� Requisitos de implementación� Opcionalmente, subsistemas e interfaces
Diagramas de clase
� Una clase de diseño puede participar en varios casos de uso
� Algunas responsabilidades, atributos y asociaciones suelen ser específicos de un sólo caso de uso.
3.1.3 Artefactos. Realización en diseño de los casos de uso
13
suelen ser específicos de un sólo caso de uso.
Dispositivode visualización
Teclado
ExpendedorDinero
Gestorde Cliente
CuentaGestor
de Cuentas
Gestorde Transacciones
Sacar Dinero
Cliente
…..
3.1.3 Artefactos. Realización en diseño de los casos de uso
Transaccion
Sacar Dinero
…..
14
Dispositivode visualización
Teclado
ExpendedorDinero
Gestorde Cliente
CuentaGestor
de Cuentas
Cliente
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.
3.1.3 Artefactos. Realización en diseño de los casos de uso
15
diseño.
� Utilizar mejor diagramas de secuencia que de colaboración. Nos interesa la secuencia cronológica de las interacciones.
� Se pueden incluir subsistemas y las interfaces que proporcionan
3.1.3 Artefactos. Realización en diseño de los casos de uso
Diagramas de interacción -> Diagramas de secuencia
:Dispositivode visualización
:Teclado:Lector deTarjetas
:ExpendedorDinero
:Gestorde Cliente
:Transaccion:Cliente
del Banco
1: Introducir
16
tarjeta2: Tarjeta introducida (ID)
3: Solicitar PIN4: Mostrar petición
5: Especificar código PIN
6: Código PIN (PIN)
7: Solicitar Validación de PIN (PIN)
3.1.3 Artefactos. Realización en diseño de los casos de uso
Flujo de eventos� Para clarificar los d. de secuencia: descripción textual� Una descripción no tiene que ser local a un diagrama.
Puede englobar a varios e indicar cómo se relacionan.
17
Requisitos de implementación� Requisitos a gestionar 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.
*Proporciona 1
3.1.4 Artefactos. Subsistemas de diseño
� Forma de organizar los artefactos de diseño en piezas más manejables: clases de diseño, realización de casos de uso, interfaces y otros subsistemas.
18
*
Subsistemas de diseño
Realización en diseño
**
Clases de diseñoInterfaz
*
� Fuertemente cohesionados y débilmente acoplados.
1.- representa la funcionalidad que exporta en términos de operaciones
3.1.5 Artefactos. Interfaz� 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
19Subsistemas de diseño
* Clases de diseño
Interfaz*
realiza
realiza
su interfaz mediante las clases de diseño (o subsistemas) que contiene.
3.1.5 Artefactos. Interfaz
20
<<design subsystem>>Interfaz Cajero
<<design subsystem>>Gestor transacciones
Este subsistema “Gestor de transacciones”ofrece al subsistema “Interfaz Cajero”un conjunto de operaciones quepueden ser invocadas por el mismo, a través de la interfaz.
3. El diseño en el Proceso Unificado
3.1 Artefactos.3.1.1 Modelo de diseño.3.1.2 Clases de diseño.3.1.3 Realización en diseño de los casos de uso.3.1.4 Subsistemas en diseño.
21
3.1.4 Subsistemas en diseño.3.1.5 Interfaz.
3.2 Actividades.3.2.1. Diseño de los casos de uso.3.2.2 Diseño de las clases.3.2.3. Diseño de subsistemas.
3.2. Actividades� Para ilustrar las actividades, utilizaremos el
ejemplo del cajero automático
Sacar dinero
<<include>>
22
Ingresar dinero
Transferencia
Cliente del banco
Validar usuario
<<include>>
<<include>>
3.2.1 Actividades. Diseño de los casos de uso
� Identificar las clases de diseño y/o subsistemas necesarios para la realización del caso de uso.Distribuir el comportamiento del
2.1 Artefactos.
2.1.1 Modelo de diseño.
2.1.2 Clases de diseño.
2.1.3 Realización en diseño de los C.U.
2.1.4 Subsistemas
2.1.5 Interfaz
23
� Distribuir el comportamiento del caso de uso entre las clases y/o subsistemas de diseño.
2.1.5 Interfaz
2.2 Actividades.
2.2.1. Diseño de los casos de uso.
2.2.2. Diseño de las clases.
2.2.3. Diseño de los subsistemas.
3.2.1 Actividades. Diseño casos de uso
3.2.1.1 Identificar las clases de diseño
� Derivar las clases de diseño de las correspondientes clases de análisis que participan en el caso de uso.
� Estudiar los requisitos especiales del caso de uso: realizarlos con los mecanismos genéricos de diseño o
24
realizarlos con los mecanismos genéricos de diseño o con clases de diseño.
� 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 caso de uso y las relaciones entre ellas.
Validar usuario
(from Use Case View)
Realización en diseño
Diseño del caso de uso: “Validar usuario”
25
LectorDeTarjetas
Pantalla
Teclado
GestorDeCliente UsuariosDelBanco
Transacción
3.2.1 Actividades. Diseño casos de uso
3.2.1.2 Describir interacciones entre objetos de diseño� Utilizar diagramas de secuencia
� objetos, instancias de actores, enlaces� Crear un diagrama de secuencia � Comenzar estudiando la realización en análisis del c.u.
Sobre los diagramas de secuencia:
26
� 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.)
Diseño del caso de uso: “Validar usuario”Secuencia correcta
: Cliente del banco :LectorDeTarjetas : Pantalla : Teclado
1: introducirTarjeta2: datosTarjeta (datos)
3: visualizar (Introducir PIN)
: Transacción: GestorDeCliente : UsuariosDelBanco
4: visualizar (“Introd. PIN”)
27
5: introducirPIN (PIN) 6: datosPIN (PIN)
7: autentica (datos, PIN)
8: valida (datos, PIN)
9: OK*
11: OK
10: almacenaDatos (cuenta)
12: visualizar (opciones)13: visualizar (opciones)
4: visualizar (“Introd. PIN”)
* De alguna forma se obtendrá el número de cuenta asociado a la tarjeta
Diseño del caso de uso: “Validar usuario”Camino alternativo: Código incorrecto
: Cliente del banco :LectorDeTarjetas : Pantalla : Teclado
1: introducirTarjeta2: datosTarjeta (datos)
3: visualizar (Introducir PIN)
: Transacción: GestorDeCliente : UsuariosDelBanco
4: visualizar (“Introd. PIN”)
28
5: introducirPIN (PIN) 6: datosPIN (PIN)
7: autentica (datos, PIN)
8: valida (datos, PIN)
9: error
11: pin erróneo12: visualizar (error PIN)13: visualizar (error PIN)
4: visualizar (“Introd. PIN”)
- ¿Qué más habría que controlar aquí?
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”.
29
Sacar dinero
(from Use Case View)
Realización en diseño
Pantalla TecladoExpendedor
Dinero
GestorDeCliente
Transacción
Cuentas
Cuenta
1: ingreso (numeroDeCuenta, importe)
Refinando el caso de uso: “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.
30
: Transacción : Cuentas
: Cuenta
2: ingreso (importe)Vista parcial del diagrama
UsuariosDelBanco1
autentica
1..n
1..n
1..n
1..n
posee
opera
1
Refinando el caso de uso: “Sacar dinero”
31
Cliente del banco Interfaz de cajero
(from Use Case View)
Cuenta
Transacción Cuentas
1..2
opera
1..2
Diseño del caso de uso: “Sacar dinero” Secuencia correcta
: Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas : Cuenta: Impresora
1: opcion (sacar dinero)2: sacarDinero
3: visualizar (Teclee importe)
4: IntroducirImporte5: importe
6: retirarDinero (importe)
7: retirar (cuenta, importe)
***
: Lector T. : ExpDinero
32
*** Se pueden obviar estos mensajes¿Qué pasa con la impresora?
7: retirar (cuenta, importe)
8: retirar (importe)
9: OK10: OK
11: OK
12: visualizar (Retire su tarjeta)
14: expulsa Tarjeta
16: visualizar (Retire su dinero)
13: visualizar (Retire su tarjeta)
17: visualizar (Retire su dinero)
15: Tarjeta expulsada
Diseño del caso de uso: “Sacar dinero” No hay fondos
: Cliente del banco : Teclado : Pantalla : Impresora
1: opcion (sacar dinero)
4: IntroducirImporte
2: sacarDinero
3: visualizar (Teclee importe)
5: importe
6: retirarDinero (importe)
: GestorDeCliente : Transacción : Cuentas : Cuenta: ExpDinero
33
Falta:- se ha superado el límite diario- en el cajero no hay dinero
7: retirar (cuenta, importe)
8: retirar (importe)
9: no hay saldo10: no hay saldo
11: no hay saldo12: visualizar (No hay saldo)
14: visualizar (Retire su tarjeta)
13: visualizar (No dispone de saldo suficiente)
15: visualizar (Retire su tarjeta)
Diseño del caso de uso: “Ingresar dinero”
Ingresar dinero Realización en diseño
34
PantallaTeclado
RecogedorDinero
GestorDeCliente
Transacción
Cuentas
Cuenta
: Cliente del banco
: Teclado : Pantalla : RecogedorDinero
1: opcion (ingresar dinero)
4: IntroducirImporte
2: ingresarDinero
3: visualizar (Teclee importe)
5: importe
6: visualizar (introducir dinero)
7: abrirCajon8: IntroduceDinero
: GestorDeCliente : Transacción : Cuenta: Cuentas
Diseño del caso de uso: “Ingresar dinero”Secuencia correcta
35
19: visualizar (Dinero ingresado)
21: visualizar (Retire su tarjeta)
13: ingresarDinero (importe)
14: ingreso (cuenta, importe)
15: ingreso (importe)
16: OK17: OK
18: OK
11: DineroContado (cantidad)
12: validar (importe, cantidad)
20: visualizar (Dinero ingresado)
22: visualizar (Retire su tarjeta)
9: Dinero introducido
10: cerrarrCajon
: Cliente del banco : Teclado : Pantalla
1: opcion (ingresar dinero)
4: IntroducirImporte
2: ingresarDinero
3: visualizar (Teclee importe)
:GestorDeCliente
Diseño del caso de uso: “Ingresar dinero”Cantidad incorrecta
: RecogedorDinero
36
13: visualizar (Cantidad errónea)
12: validar (importe, cantidad)
14: visualizar (Retire su dinero)
15: abrirCajon16: Recoge dinero
17: recogido
18: cerrarCajon
*** Volver a evento 3…
Diseño del caso de uso: “Transferencia”
� Suponemos que el usuario ya ha sido identificado (se ha ejecutado el caso de uso anterior). Ahora selecciona la opción “transferencia”.
Transferencia Realización en diseño,
37
Cuenta
Transferencia
(from Use Case View)
Realización en diseño, transferencia
Teclado
Pantalla
2
GestorDeCliente
Transacción
Cuentas
: Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas
CuentaOrigen: Cuenta
1: opcion (transferencia)
4: IntroducirImporte
2: transferencia
3: visualizar (Teclee importe)
5: importe
6: visualizar (Teclee cuenta destino)
7: cuentaDestino (cuentaDestino)
8: cuentaDestino (cuentaDestino)
Diseño del caso de uso: “Transferencia”Secuencia correcta
CuentaDestino: Cuenta
38
19: visualizar (Transferencia realizada)
9: transferencia (cuentaDestino,importe)
10: retirar (cuenta, importe)
11: retirar (importe)12: OK
13: OK
18: OK
8: cuentaDestino (cuentaDestino)
14: ingreso (cuentaDestino, importe)15: ingreso (importe)
16: OK17: OK
: Pantalla: Cliente del banco
1: opcion (transferencia)
4: IntroducirImporte
2: transferencia
3: visualizar (Teclee importe)
5: importe
6: visualizar (Teclee cuenta destino)
: Teclado : GestorDeCliente : Transacción : Cuentas
Diseño del caso de uso: “Transferencia”No hay fondos
CuentaOrigen: Cuenta
39
7: cuentaDestino (cuentaDestino)
15: visualizar (No hay fondos)
8: cuentaDestino (cuentaDestino)
9: transferencia (cuentaDestino,importe)
14: no hay fondos
10: retirar (cuenta, importe)
13: no hay saldo
11: retirar (importe)
12: no hay saldo
Impresora
LectorDeTarjetasCliente del banco
GestorDeCliente
UsuariosDelBanco
Transacción
Modelo de clases de diseño
Recogedor Dinero
40
Pantalla
Teclado
Cuenta
Cuentas
ExpDinero
3.2.2 Actividades. Diseño de las clases� Identificar las responsabilidades de las
clases de diseño (papeles en los casos de uso)
� Identificar:� operaciones� atributos
2.1 Artefactos.
2.1.1 Modelo de diseño.
2.1.2 Clases de diseño.
2.1.3 Realización en diseño de los C.U.
2.1.4 Subsistemas
2.1.5 Interfaz
41
� atributos� relaciones en las que participa� estados (diagramas de estados)� métodos que soportan sus operaciones� Requisitos nuevos…
� ¿¿Quién tiene el control de la ejecución??
2.1.5 Interfaz
2.2 Actividades.
2.2.1. Diseño de los casos de uso.
2.2.2. Diseño de las clases.
2.2.3. Diseño de los subsistemas.
3.2.2. Actividades. Diseño de las clases
3.2.2.1 Identificar operaciones� En el lenguaje de implementación� Mirar responsabilidades que tiene en los casos de uso
42
3.2.2.2 Identificar atributos� Describirlos en el lenguaje de programación� Considerar los atributos de las clases de análisis de las
que se derivan
3.2.2. Actividades. Diseño de las clases3.2.2.3 Identificar asociaciones y agregaciones� Las interacciones en los diagramas de secuencia
precisan de asociaciones entre las clases que interactuan.
� Minimizar el número de relaciones entre clases (disminuir el acoplamiento).
43
el acoplamiento).� Refinar multiplicidad, papeles, etc. � Refinar la navegabilidad (dirección) de las asociaciones
en base a los diagramas de secuencia.� Identificar generalizaciones-especializaciones.
3.2.2. Actividades. Diseño de las clases
3.2.2.4 Describir métodos� Algoritmos para implementar alguna operación (lenguaje
natural).� Esqueletos de métodos generado por la herramienta.
44
� Esqueletos de métodos generado por la herramienta.� En general, en lenguaje de programación se suele
hacer en implementación.
3.2.2.5 Describir estados� Algunos objetos reaccionan en función de su estado
actual. Utilizar diagramas de transición de estados.
LectorDeTarjetas
leerTarjeta() : datosTarjeta
Pantalla
visualizar(mensaje : String)
Teclado
leerPIN() : unPINleerOpcion() : unaOpcion GestorDeCliente
Modelo de clases de diseño
45
RecogedorDinero
abrirCajon()cerrarCajon()contarCantidad() : Dinero
leerOpcion() : unaOpcionleerCantidad() : DineroleerNumCuenta() : unIDCuenta
ExpendedorDinero
expulsar(importe : Dinero)
GestorDeCliente
iniciarSesion()
Impresora
imprimir(mensaje : String)
validar(importe : Dinero, cantidad : Dinero):Boolean
GestorDeCliente
iniciarSesion()validar(importe : Dinero,
cantidad : Dinero):Boolean
Transacción
datosCuenta: CuentanumIntentosFallidos : 1..3 = 0
almacenarDatos(datos : DatosTarjeta)autenticar(datos : DatosTarjeta, PIN : UnPIN) : BooleanretirarDinero(importe : Dinero) : BooleaningresarDinero(importe : Dinero) : Booleantrasnsferencia(cuentaOrigen : Cuenta, cuentaDestino : Cuenta, importe : Dinero) : Boolean
UsuariosDelBancousuarios : Dictionary
validar(datos : DatosTarjeta, PIN : UnPIN,
Modelo de clases de diseño
46
validar(datos : DatosTarjeta, PIN : UnPIN, datosCuenta: Cuenta) : Boolean
Cuentascuentas : Dictionary
retirar(cuenta : Cuenta, importe : Dinero) : Booleaningreso(cuenta : Cuenta, importe : Dinero) : Boolean
Cuenta
limiteDiario : Dinero = 300
retirar(importe : Dinero) : Booleaningreso(importe : Dinero) : Boolean
saldo : Dinero
Especificación de la clase cuenta en Java
class Cuenta {long numero;String titular;float saldo, cantidad_diaria;integer limite_diario;
boolean ingreso (float cantidad) {
47
boolean ingreso (float cantidad) {saldo += cantidad;
}
boolean retirar (float cantidad) {saldo -=cantidad;cantidad_diaria += cantidad
}
float leerSaldo() { return saldo; }}
Especificación de la clase cuenta en Java
public class Cuenta {private long numero;private String titular;private float saldo, cantidad_diaria;private integer limite_diario;
public boolean ingreso (float cantidad) {
48
public boolean ingreso (float cantidad) {saldo += cantidad;
}
public boolean retirar (float cantidad) {saldo -=cantidad;cantidad_diaria += cantidad
}
public float leerSaldo() { return saldo; }}
Especificación de la clase cuenta en Javapublic class Cuenta {
private long numero;private String titular;private float saldo, cantidad_diaria;private integer limite_diario;
// Constructor generalCuenta (long aNumero, String aTitular, integer aLimite_diario) {
numero = aNumero;titular = aTitular;
49
titular = aTitular;saldo = 0;limite_diario = aLimite_diario;
}
public boolean ingreso (float cantidad) {saldo += cantidad;
}public boolean retirar (float cantidad) {
saldo -=cantidad;cantidad_diaria += cantidad
}public float leerSaldo() { return saldo; }
}
Especificación de mensajes enviados a la clase cuenta en Java
// Una referencia a un objeto de la clase CuentaCuenta cuenta_cliente;
cuenta_cliente = new Cuenta(18400200, “Pedro Jiménez”, 600);………………………….………………………….………………………….
50
………………………….using System;
boolean ingreso_OK;………………………….
ingreso_OK = cuenta_cliente.ingreso (1000);
if (ingreso_OK)System.out.println(“Ingreso realizado satisfactoriamente”);System.out.println(“Saldo actual de su cuenta : “ cuenta_cliente.leerSaldo());
………………………….
Diseño de la clase “GestorDeCliente”
� En una aplicación orientada a objetos debe existir una clase que represente la propia aplicación. Este sería el punto donde comenzaría la ejecución de la misma.
� La única clase que tiene un comportamiento parecido a
51
� La única clase que tiene un comportamiento parecido a la propia aplicación sería GestorDeCliente. Su comportamiento se puede representar mediante una máquina de estados. Realizar el diagrama de transición de estados del sistema Cajero Automático.
Diseño de la clase “GestorDeCliente” (boceto de diagrama de estados)
Esperando tarjeta
Leyendo tarjeta
tarjeta introducida
Esperando PIN
Validando PIN
PIN introducido( PIN )
Recogiendo tarjeta
… [ incorrecto ]
Sistema iniciado
52
PINtarjeta
Esperando opción
….[ > 3 intentos ]
… [ correcto ]
Ingresando
Opción ingresoseleccionada
Retirando dinero
Opción retirar dineroseleccionada
Transferencia
Opción Transferencia seleccionada
Expulsando dinero
….[OK]
Expulsando tarjeta
dinero retirado
…[ Not OK ]
Diseño de la clase “GestorDeCliente”
� En Java debe existir una clase “aplicación” de forma obligatoria.� Esta clase se instancia y se llama a una operación especial con nombre “main”. La
existencia de esta operación especial es lo que caracteriza a la clase “aplicación”.� La clase “aplicación” debe ser pública y no tener ningún constructor.� Al menos debe implementar la operación main, con la siguiente declaración: public static
main(String[] args)
public class CajeroAutomaticoApp {public static void main(String[] args) {
private boolean Tarjeta_introducida = false:
53
private boolean Tarjeta_introducida = false:
System.out.println(“Introduzca su tarjeta”);
// loop until Tarjeta_introducida;
/* If Tarjeta_valida ()then
System.out.println(“Introduzca su pin”);loop until Tarjeta_introducida;
elseSystem.out.println(“Tarjeta no válida. Retire su tarjeta”); */
…………………..…………………..}
}
3.2.3. 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 interactuan con qué
54
� Determinar qué clases de unos subsistemas interactuan 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
1. Visión general
2. El diseño en el Proceso Unificado de Desarrollo3.1 Artefactos.
3.1.1 Modelo de diseño.3.1.2 Clases de diseño.3.1.3 Realización en diseño de los casos de uso.
Diseño
55
3.1.3 Realización en diseño de los casos de uso.3.1.4 Subsistemas en diseño.3.1.5 Interfaz.
3.2 Actividades.3.2.1. Diseño de los casos de uso.3.2.2. Diseño de las clases.3.2.3. Diseño de subsistemas.
4. Diseño: Especificación en pseudocódigo y UML
4. Diseño: Especificación en UML y pseudocódigo� DEFINICIÓN DE CLASES
� UML:
NombreClase[<<abstracta>> | <<final>>]
[+ | - | & ] atributo : <tipo>[+ | - | & ] atributo : <tipo>
56
[+ | - | & ] atributo : <tipo>……………..
[+ | - | & ] atributo : <tipo>
[+ | - | & ] operación ( [tipos_p] ) [: <tipo>][+ | - | & ] operación ( [tipos_p] ) [: <tipo>]
……………..[+ | - | & ] operación ( [tipos_p] ) [: <tipo>]
<tipo>: un tipo estándar (entero, real, carácter, booleano o cadena) o tipo abstracto de datos.
4. Diseño: Especificación en UML y pseudocódigo� DEFINICIÓN DE CLASES
� Pseudocódigo:
[publico | privado | protegido] [abstracta | final] clase NombreClase [heredaDe NombreClaseBase]
57
// Inicio declaración de la clase NombreClase
// Inicio declaración de atributos
……………..
// Inicio declaración de operaciones
……………..
fin_clase
4. Diseño: Especificación en UML y pseudocódigo
� DECLARACIÓN DE CONSTANTEScons nombre_constante = <expresión>
cons limiteDiario = 300
58
� DECLARACIÓN DE VARIABLES<tipo> <lista_de_variables>
real saldo, importe, cantidad
4. Diseño: Especificación en UML y pseudocódigo
� DEFINICIÓN DE UN MÉTODO
[publico | privado | protegido] [<tipo>] [estático] [abstracto] nombre_método ([lista_parámetros])
// Cuerpo de la operación[retornar (valor)]
59
[retornar (valor)]fin_método
publico booleano validar (real cantidad, real importe)
retornar (cantidad == importe)
4. Diseño: Especificación en UML y pseudocódigo
� INVOCACIÓN DE UN MÉTODO:
[variable = ] nombre_objeto.nombre_método ([lista_parámetros_actuales])
60
Booleano validacionCorrecta…………………………….validacionCorrecta = validar (cantidad, importe)
4. Diseño: Especificación en UML y pseudocódigo
� DECLARACIÓN DE OBJETOS:
NombreClase objeto1 [, objeto 2,…., objeto N]
61
MovimientoCuenta MovimientoActual
� CREACIÓN DE OBJETOS:
NombreClase objeto1 = nuevo NombreClase ()
MovimientoCuenta MovimientoActual = nuevo MovimientoCuenta()
4. Diseño: Especificación en UML y pseudocódigo� ENTRADA Y SALIDA ESTÁNDAR
importar sistema
// Hay una clase Leer y otra Imprimir
62
real cantidadentero pin…………cantidad = Leer.datoReal ()pin = Leer.datoEntero ()…………….Imprimir (“Pin incorrecto. Vuelva a introducir su pin”)