Tema 4f: Proceso Unificado: Diseño

Tema 4f:

Proceso Unificado: Diseño

Marcos López Sanz

Í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

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

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

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 físico

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

Diseño

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

Diseño

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

*

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



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 (manera de

nombrar los atributos, operaciones, etc...)

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

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

14

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 puede participar 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



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

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)

Diseño

Artefactos



Flujo de eventos



Para clarificar los diagramas 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.



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,

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

*

Subsistemas de diseño

Realización

en diseño

*

*

Clases de diseño

Interfaz

*

Proporciona

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.

Subsistemas de diseño

*

_{Clases de diseño}

Interfaz

*

realiza

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



Actividades de diseño



_{Diseño de los casos de uso}



_{Diseño de las clases}

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 caso de uso



Distribuir el comportamiento del caso de uso entre las clases

y/o subsistemas de diseño

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 caso de uso

 Estudiar los requisitos especiales del caso de uso: 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

Diseño

Actividades



Diseño de los casos de uso



Identificar las clases de diseño

Validar usuario

Realización en diseño

LectorDeTarjetas

Pantalla

Teclado

GestorDeCliente

UsuariosDelBanco

Diseño

Actividades



Diseño de los casos de uso



Describir interacciones entre objetos de diseño

 Utilizar diagramas de secuencia

• objetos, instancias de actores, enlaces

 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.)

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

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

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

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

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)

Diseño

Actividades



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

Falta:

- se ha superado el límite diario

: 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)

14: visualizar (Retire su dinero) 13: visualizar

(No dispone de saldo suficiente)

15: visualizar (Retire su dinero)

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

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

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 ]

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

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)

4: IntroducirImporte

2: ingresarDinero

3: visualizar (Teclee importe)

5: importe

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

11: ingresarDinero (importe)

12: ingreso (cuenta, importe)

13: ingreso (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 : Cuentas : Cuenta

18: visualizar (Dinero ingresado) 20: visualizar (Retire su tarjeta)

Diseño

Ejemplo



Refinando el c. u. “Ingresar dinero”: cantidad 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: recogerDinero

9: dinero (cantidad)

12: visualizar (Retire su dinero)

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)

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

Diseño

Ejemplo



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