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 de subsistemas
Visión general Flujos de trabajo Planificación Anál. Riesgos Preparación Elaboración Fases Construcción Verificación Transición Requisitos Análisis Diseño Implementación Prueba Iteración(es) Inicial(es) Iter. #1 Iter. #2 Iter. #3 Iter. #4 Iter. #5 Iter. #6 Iter. #7 (Adaptado de Jacobson, 1999)
Visión general Modelo de análisis Modelo de diseño Modelo de casos de uso Modelo de despliegue Modelo de implementación Modelo de pruebas
Visión general Requisitos Modelo de Casos de Uso Dependencia de traza Análisis Modelo de Análisis Diseño Modelo de Diseño Modelo de Despliegue Implementación Modelo de Implementación Pruebas Modelo de Pruebas
Diagramas UML Modelo de Casos de Uso Modelo de Análisis Modelo de Diseño Modelo de Despliegue Modelo de Implementación Diagramas de Casos de Uso Diagramas de Clases Diagramas de Objetos Diagramas de Secuencia Diagramas de Colaboración Diagramas de Estados Diagramas de Actividad Incluidos subsistemas Diagramas de Interacción Modelo de Pruebas Diagramas de Componentes Diagramas de Despliegue Incluidas clases activas y componentes
Visión general Modelo de Análisis Modelo conceptual Modelo físico Modelo de Diseño Pueden obtenerse varios diseños Específico a una implementación Menos formal Más formal Menos caro de desarrollar Puede eliminarse Más caro (5 veces más) Debe mantenerse durante todo el ciclo de vida
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 Derivar una representación arquitectónica del sistema 8
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 * * Modelo de diseño Subsistemas de diseño * * * * * * Interfaz Clases de diseño Realización en 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...) Realizan interfaces
Artefactos Clases de diseño: Ejemplo Cuenta Transacción cuenta : Cuenta cantidad: Dinero opera 1..2 saldo : Dinero limitediario: Dinero = 300 reintegro(cantidad : Dinero) : Boolean ingreso(cantidad : Dinero) : Boolean
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 <<trace>> Realización en análisis Realización en diseño
Artefactos Realización de los casos de uso en diseño: MODELO DE ANÁLISIS Interfaz del cajero Transacción Cuenta Dispositivo de visualización Expendedor Dinero Cuenta Teclado Recogedor Dinero.. MODELO DE DISEÑO Lector de Tarjetas Gestor de Cliente Gestor de Transacciones Gestor de Cuentas
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 Realización en diseño (from Use Case View) participante Clase de diseño participante Subsistema de diseño 14
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. Lector de Tarjetas Reintegro Gestor de Transacciones Cliente Dispositivo de visualización Teclado Gestor de Cliente Expendedor Dinero Gestor de Cuentas Cuenta
Diagramas de interacción Diseño Artefactos 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 Se pueden incluir subsistemas y las interfaces que proporcionan
Artefactos Diagramas de interacción diagramas de secuencia :Cliente del Banco :Lector de Tarjetas :Dispositivo de visualización :Teclado :Gestor de Cliente :Expendedor Dinero :Gestor de Transacciones 1: Introducir tarjeta 2: Tarjeta introducida (ID) 4: Mostrar petición 3: Solicitar PIN 5: Especificar código PIN 6: Código PIN (PIN) 7: Solicitar Validación de PIN (PIN)
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, operaciones, atributos, asociaciones, etc.
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 Proporciona 1 * Subsistemas de diseño * * * Interfaz Clases de diseño Realización en diseño 1.- representa la funcionalidad que exporta en términos de operaciones
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. Interfaz * realiza * Clases de diseño realiza Subsistemas de diseño
Ejemplo Para ilustrar las actividades, utilizaremos el ejemplo del cajero automático Sacar dinero <<include>> Cliente del banco Ingresar dinero Transferencia <<include>> <<include>> Validar usuario
Actividades Actividades de diseño Diseño de los casos de uso Diseño de las clases Diseño de subsistemas
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
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
Actividades Diseño de los casos de uso Identificar las clases de diseño Validar usuario Realización en diseño LectorDeTarjetas GestorDeCliente UsuariosDelBanco Pantalla Teclado Transacción
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.)
Actividades Diseño del c.u. Validar usuario : secuencia correcta : Cliente del banco :LectorDeTarjetas : Pantalla : Teclado : Transacción : GestorDeCliente : UsuariosDelBanco 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 13: visualizar (opciones) 12: visualizar (opciones) 11: presenta (opciones) 10: almacenadatos (datos)
Actividades Diseño del c.u. Validar usuario : código incorrecto : Cliente del banco :LectorDeTarjetas : Pantalla : Teclado : Transacción : GestorDeCliente : UsuariosDelBanco 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 13: visualizar (error PIN) 12: visualizar (error PIN) 11: presenta (error PIN)
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 Transacción Cuenta GestorDeCliente Cuentas
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. 1: ingreso (numerodecuenta, importe) : Transacción : Cuentas Vista parcial del diagrama (modelo de análisis) 2: ingreso (importe) : Cuenta
Actividades Refinando el caso de uso Sacar dinero 1 UsuariosDelBanco 1..n autentica opera posee 1..n 1..2 Cliente del banco Interfaz de cajero Transacción Cuentas Cuenta
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) 11: OK 10: OK 8: reintegro (importe) 9: OK 13: visualizar (Retire su tarjeta) 16: visualizar (Retire su dinero) 12: visualizar (Retire su tarjeta) 14: expulsa (importe) 15: visualizar (Retire su dinero) Qué pasa con la impresora?
Actividades Refinando el c. u. Sacar dinero : no hay fondos : Cliente del banco : Teclado : Pantalla : ExpDinero : Impresora : GestorDeCliente : Transacción : Cuentas : Cuenta 1: opcion (sacar dinero) 2: sacardinero 3: visualizar (Teclee importe) 4: IntroducirImporte 13: visualizar (No dispone de saldo suficiente) 5: importe 12: visualizar (No hay saldo) 6: retirardinero (importe) 7: reintegro (cuenta, importe) 8: reintegro (importe) 9: no hay saldo 10: no hay saldo 11: no hay saldo 15: visualizar (Retire su dinero) 14: visualizar (Retire su dinero) Falta: - se ha superado el límite diario - en el cajero no hay dinero
Modelo de clases de diseño Diseño Actividades Recogedor Dinero UsuariosDelBanco Impresora Cliente del banco LectorDeTarjetas GestorDeCliente Transacción Pantalla Cuentas Teclado ExpDinero Cuenta
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
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
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
Modelo de clases de diseño: Diseño Actividades Pantalla LectorDeTarjetas visualizar(mensaje : String) crearpantalla() : Pantalla crearlector() : LectorDeTarjetas leertarjeta() : datostarjeta Teclado crearteclado() : Teclado leerpin() : unpin leeropcion() : unaopcion leercantidad() : Dinero leernumcuenta() : unidcuenta GestorDeCliente crear() : GestorDeCliente iniciarsesion() Impresora crearimpresora() : Impresora imprimir(mensaje : String) ExpendedorDinero crear() : ExpendedorDinero expulsar(importe : Dinero) RecogedorDinero crearcajon() : CajonDinero abrircajon() cerrarcajon() contarcantidad() : Dinero
Modelo de clases de diseño: Diseño Actividades micliente : GestorDeCliente datostarjeta : DatosTarjeta numintentosfallidos : 1..3 = 0 cuentas : Cuentas usuarios : UsuariosDelBanco Transacción 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 GestorDeCliente mitransaccion : Transacción crear() : GestorDeCliente iniciarsesion() visualizar(resultados : String) Cuentas cuentas : Dictionary reintegro(cuenta : Cuenta, importe : Dinero) : Boolean ingreso(cuenta : Cuenta, importe : Dinero) : Boolean UsuariosDelBanco usuarios : Dictionary validar(datos : DatosTarjeta, PIN : UnPIN) : Boolean Cuenta datos : DatosCuenta limitediario : Dinero = 300 reintegro(importe : Dinero) : Boolean ingreso(importe : Dinero) : Boolean
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
Actividades Diseño de una clase: tarjeta introducida Esperando tarjeta Leyendo tarjeta PIN introducido( PIN ) Esperando PIN Recogiendo tarjeta [ > 3 intentos ] Validando PIN [ correcto ] [ incorrecto ] Ingresando ingreso( importe ) Esperando opción reintegro (importe ) Reintegrando transferencia( cuenta, importe ) Transferencia [ Not OK ] [ OK ] Expulsando dinero dinero retirado Expulsar tarjeta
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
Ejemplo Refinando el c. u. Ingresar dinero : Ingresar dinero Realización en diseño Pantalla Teclado RecogedorDinero Cuenta Transacción Cuentas GestorDeCliente
Ejemplo Refinando el c. u. Ingresar dinero : secuencia correcta : Cliente del banco 1: opcion (ingresar dinero) : Teclado : Pantalla : Recogedor Dinero 2: ingresardinero : GestorDeCliente : Transacción : Cuentas : Cuenta 3: visualizar (Teclee importe) 4: IntroducirImporte 8: IntroduceDinero 5: importe 6: visualizar (introducir dinero) 7: abrircajon 9: ContarDinero (cantidad) 10: validar (importe, cantidad) 11: ingresardinero (importe) 18: visualizar (Dinero ingresado) 20: visualizar (Retire su tarjeta) 17: visualizar (Dinero ingresado) 19: visualizar (Retire su tarjeta) 16: OK 12: ingreso (cuenta, importe) 15: OK 13: ingreso (importe) 14: OK
Ejemplo Refinando el c. u. Ingresar dinero : cantidad incorrecta : Cliente del banco : Teclado : Pantalla : Recogedor Dinero :GestorDeCliente 1: opcion (ingresar dinero) 2: ingresardinero 4: IntroducirImporte 8: recogerdinero 3: visualizar (Teclee importe) 5: importe 6: visualizar (introducir dinero) 7: abrircajon 9: dinero (cantidad) 10: validar (importe, cantidad) 14: dinerorecogido 11: visualizar (Cantidad errónea) 12: visualizar (Retire su dinero) 13: abrircajon 15: recogido 16: cerrarcajon 17: visualizar (Retire su tarjeta)
Ejemplo Refinando el c. u. Transferencia : Transferencia Realización en diseño, transferencia Teclado Pantalla Transacción Cuenta GestorDeCliente Cuentas
Ejemplo Refinando el c. u. Transferencia : secuencia correcta : Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas : Cuenta 1: opcion (transferencia) 2: transferencia 3: visualizar (Teclee importe) 4: IntroducirImporte 7: cuentadestino (cuenta) 5: importe 6: visualizar (Teclee cuenta destino) 8: cuentadestino (cuenta) 9: transferencia (cuentaorigen, cuentadestino,importe) 10: reintegro (cuentaorigen, importe) 13: OK 11: reintegro (importe) 12: OK 14: ingreso (cuentadestino, importe) 15: ingreso (importe) 17: OK 16: OK 18: OK 19: visualizar (Transferencia realizada) 20: visualizar (Retire su tarjeta)
Ejemplo Refinando el c. u. Transferencia : no hay fondos : Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas : Cuenta 1: opcion (transferencia) 2: transferencia 3: visualizar (Teclee importe) 4: IntroducirImporte 7: cuentadestino (cuenta) 5: importe 6: visualizar (Teclee cuenta destino) 8: cuentadestino (cuenta) 9: transferencia (cuentaorigen, cuentadestino,importe) 10: reintegro (cuentaorigen, importe) 11: reintegro (importe) 12: no hay saldo 14: no hay fondos 13: no hay saldo 15: visualizar (No hay fondos) 16: visualizar (Retire su tarjeta)