Índice
n Visión general
n Artefactos ¨ Modelo de diseño ¨ Clases de diseño ¨ Realización en diseño de los casos de uso ¨ Subsistemas en diseño ¨ Interfaz
n Ac=vidades ¨ Diseño de los casos de uso ¨ Diseño de las clases ¨ Diseño de subsistemas
Diseño Visión general
Requisitos
Diseño
Implementación
Prueba
Análisis
Planificación Anál. Riesgos Preparación
Elaboración Construcción Verificación Transición
Fases Flujos de
trabajo
Iteración(es) Inicial(es)
Iter. #1
Iter. #2
Iter. #3
Iter. #4
Iter. #5
Iter. #6
Iter. #7
(Adaptado de Jacobson, 1999)
Modelo de análisis
Modelo de diseño
Modelo de despliegue
Modelo de implementación
Modelo de pruebas
Modelo de casos de uso
Soportado por
Distribuido por
Diseño Visión general
Requisitos
Pruebas
Implementación
Diseño
Análisis
Modelo de Despliegue
Modelo de Análisis
Modelo de Diseño
Modelo de Implementación
Modelo de Pruebas
Modelo de Casos de Uso
Dependencia de traza
Diseño Visión general
Diseño Diagramas UML
Modelo de Diseño
Modelo de
Pruebas
Modelo de Despliegue
Modelo de
Implementación
Diagramas de Casos de Uso
Diagramas de Clases
Diagramas de Componentes
Diagramas de Secuencia
Diagramas de Colaboración
Diagramas de Estados
Diagramas de Actividad
Diagramas de Objetos
Incluidos subsistemas
Modelo de
Casos de Uso
Diagramas de Interacción
Modelo de
Análisis
Diagramas de Despliegue
Incluidas clases activas y componentes
Diseño Visión general
Modelo de Análisis Modelo de Diseño
Modelo conceptual Modelo Ksico
Pueden obtenerse varios diseños Específico a una implementación
Menos formal Más formal
Menos caro de desarrollar Más caro (5 veces más)
Puede eliminarse Debe mantenerse durante todo el ciclo de vida
Diseño Visión general
n Obje=vos del diseño: ¨ Acercar el modelo de análisis al modelo de implementación
n Los milagros más comunes de la ingeniería del so2ware son las transiciones desde el análisis hasta el diseño y desde el diseño al código. Richard Due
¨ Iden=ficar requisitos no funcionales y restricciones en relación a: n Lenguajes de programación, reu=lización de componentes, sistemas
opera=vos, tecnologías de distribución, concurrencia, bases de datos, interfaces de usuario, ges=ón de transacciones, etc.
¨ Descomponer el modelo de análisis en subsistemas que puedan desarrollarse en paralelo
¨ Definir la interfaz de cada subsistema
¨ Derivar una representación arquitectónica del sistema
8
Índice
n Visión general
n Artefactos ¨ Modelo de diseño ¨ Clases de diseño ¨ Realización en diseño de los casos de uso ¨ Subsistemas en diseño ¨ Interfaz
n Ac=vidades ¨ Diseño de los casos de uso ¨ Diseño de las clases ¨ Diseño de subsistemas
Diseño Artefactos
n Modelo de diseño ¨ Casos de uso en el dominio de la solución ¨ Cómo soportar requisitos funcionales/no funcionales y otras
restricciones en el entorno de implementación ¨ Entrada fundamental para ac=vidades de implementación
*
Subsistemas de diseño
Realización en diseño
*
* * * *
Clases de diseño Interfaz
* *
Modelo de diseño
Diseño Artefactos
n Clases de diseño ¨ Una clase de diseño es una abstracción de una clase de
implementación ¨ Las operaciones, atributos, =pos, visibilidad (public, protected, private,
etc...), se pueden especificar con la sintaxis del lenguaje elegido ¨ Las relaciones entre clases de diseño se traducen de manera directa al
lenguaje: n Generalización à herencia n Asociaciones, agregaciones à atributos
¨ Se pueden postergar algunos requisitos a implementación (manera de nombrar los atributos, operaciones, etc...)
¨ Realizan interfaces
Diseño Artefactos
n Clases de diseño: Ejemplo
Transacción cuenta : Cuenta cantidad: Dinero ……………
1..2 1..2
opera
Cuenta
reintegro(cantidad : Dinero) : Boolean ingreso(cantidad : Dinero) : Boolean
saldo : Dinero limiteDiario: Dinero = 300
Diseño Artefactos
n Realización de los casos de uso en diseño: ¨ Es una colaboración que describe cómo se realiza en diseño un caso de
uso en términos de clases de diseño y sus interacciones
Modelo de análisis
Realización en análisis
Modelo de diseño
Realización en diseño
<<trace>>
n Realización de los casos de uso en diseño:
Diseño Artefactos
Transacción Cuenta Interfaz del cajero
Dispositivo de visualización
Teclado
Lector de Tarjetas
Expendedor Dinero
Recogedor Dinero
Gestor de Cliente
Cuenta
Gestor de Cuentas
Gestor de Transacciones
MODELO DE ANÁLISIS
MODELO DE DISEÑO
…..
Diseño Artefactos
n La realización en diseño de un caso de uso incluye: ¨ Diagramas de clases: clases par=cipantes ¨ Diagramas de interacción: escenarios del caso de uso ¨ Descripción textual del flujo de eventos ¨ Requisitos de implementación ¨ Opcionalmente: subsistemas e interfaces
Subsistema de diseño
Clase de diseño
Realización en diseño (from Use Case View)
participante participante
Diseño Artefactos
n Diagramas de clase ¨ Una clase de diseño puede par=cipar en varios casos de uso ¨ Algunas responsabilidades, atributos y asociaciones suelen ser
específicos de un sólo caso de uso.
Dispositivo de visualización
Teclado
Lector de Tarjetas
Expendedor Dinero
Gestor de Cliente
Cuenta Gestor
de Cuentas
Gestor de Transacciones
Reintegro
Cliente
Diseño Artefactos
n Diagramas de interacción
¨ La secuencia de acciones en un caso de uso comienza cuando un actor envía un mensaje a un objeto de diseño
¨ U=lizar mejor diagramas de secuencia que de colaboración: interesa la secuencia cronológica de las interacciones
¨ Se pueden incluir subsistemas y las interfaces que proporcionan
Diseño Artefactos
n Diagramas de interacción à diagramas de secuencia
Validarse
:Dispositivo de visualización
:Teclado
:Lector de Tarjetas
:Gestor de Cliente
:Gestor de Transacciones
:Cliente del Banco
…
UsuariosDelBanco Autenticar Interfaz de cajero
RESOLVER EN CLASE
n LifeLine: Línea vertical punteada que representa la vida del objeto durante la interacción
n Barra de activación: Período en el cual el objeto se encuentra realizando una operación.
n Mensaje: Línea sólida dirigida a otro objeto. n Retorno: Línea punteada de mensaje de retorno al objeto
que llama (no se usa). n Mensaje a sí mismos: Métodos recursivos o llamadas a si
mismos n Destrucción del Objeto: Se representa con una X
19
Diseño Artefactos
Diagramas de secuencia
20
Diseño Artefactos
Diagramas de secuencia Fragmentos Combinados: Una o mas secuencias de procesos incluidas en un marco
Alt Alternativa: Divide la interacción mediante la condición opt Alternativa simple: Solo si cumple la condición loop Bucle: Se ejecuta varias veces según indica la restricción sd Diagrama de secuencia: Representa un diagrama de secuencia
completo …
Permiten agregar lógica de procedimientos complejos
Diseño Artefactos
n Flujo de eventos ¨ Para clarificar los diagramas de secuencia: descripción textual ¨ Una descripción no =ene que ser local a un diagrama. Puede englobar
a varios e indicar cómo se relacionan.
n Requisitos de implementación ¨ Requisitos a ges=onar en implementación ¨ Quizás durante esta fase de diseño se obtengan algunos nuevos ¨ Representarlos con restricciones {...} asignadas a las clases de diseño,
operaciones, atributos, asociaciones, etc.
Diseño Artefactos n Subsistemas de diseño
¨ Para organizar los artefactos de diseño: clases de diseño, realización de casos de uso, interfaces y otros subsistemas
¨ Fuertemente cohesionados y débilmente acoplados ¨ Representan una separación de aspectos de diseño: Desarrollo por
separado
*
Subsistemas de diseño
Realización en diseño
* *
Clases de diseño Interfaz
*
Proporciona 1
1.- representa la funcionalidad que exporta en términos de operaciones
Diseño Artefactos n Interfaces
¨ Las interfaces se u=lizan para especificar las operaciones de las clases y los subsistemas de diseño.
¨ Las clases de diseño soportan las operaciones de su interfaz mediante métodos.
¨ Los subsistemas de diseño soportan las operaciones de su interfaz mediante las clases de diseño (o subsistemas) que con=ene.
¨ Separar la especificación de la funcionalidad.
Subsistemas de diseño
* Clases de diseño
Interfaz *
realiza
realiza
Diseño Ejemplo
n Para ilustrar las ac=vidades, u=lizaremos el ejemplo del cajero automá=co
Sacar dinero
Ingresar dinero
Transferencia
Cliente del banco
Validar usuario
<<include>>
<<include>>
<<include>>
Índice
n Visión general
n Artefactos ¨ Modelo de diseño ¨ Clases de diseño ¨ Realización en diseño de los casos de uso ¨ Subsistemas en diseño ¨ Interfaz
n Ac=vidades ¨ Diseño de los casos de uso ¨ Diseño de las clases ¨ Diseño de subsistemas
Diseño Ac=vidades
n Diseño de los casos de uso ¨ Iden=ficar las clases de diseño y/o subsistemas necesarios para la realización del caso de uso
¨ Distribuir el comportamiento del caso de uso entre las clases y/o subsistemas de diseño
Diseño Ac=vidades
n Diseño de los casos de uso ¨ Iden=ficar las clases de diseño
n Derivar las clases de diseño de las correspondientes clases de análisis que par=cipan en el caso de uso
n Estudiar los requisitos especiales del caso de uso: realizarlos con los mecanismos genéricos de diseño o con clases de diseño
n Asignar responsabilidades a las clases iden=ficadas n Realizar un diagrama de clases que muestre las clases de diseño que intervienen en la realización del caso de uso y las relaciones entre ellas
Diseño Ac=vidades n Diseño de los casos de uso
¨ Iden=ficar las clases de diseño
Validar usuario Realización en diseño
LectorDeTarjetas
Pantalla
Teclado
GestorDeCliente
Transacción
UsuariosDelBanco
Diseño Ac=vidades
n Diseño de los casos de uso ¨ Describir interacciones entre objetos de diseño
n U=lizar diagramas de secuencia ¨ objetos, instancias de actores, enlaces
n Comenzar estudiando la realización en análisis del caso de uso n Sobre los diagramas de secuencia:
¨ el caso de uso comienza cuando una instancia de un actor envía un mensaje a un objeto interfaz
¨ cada clase de diseño iden=ficada debería tener al menos un objeto par=cipando en el diagrama de secuencia
n En esta fase ges=onar excepciones y errores (entradas incorrectas, situaciones anormales, etc.)
Diseño Ac=vidades
n Diseño del c.u. “Validar usuario” – Error Pin
: Teclado : Cliente del banco :LectorDeTarjetas : Pantalla
1: introducirTarjeta 2: datosTarjeta (datos)
3: visualizar (Introducir PIN)
5: introducirPIN (PIN) 6: datosPIN (PIN)
7: autentica (datos, PIN)
8: valida (datos, PIN)
9: error
11: presenta (error PIN) 12: visualizar (error PIN)
: Transacción : GestorDeCliente : UsuariosDelBanco
13: visualizar (error PIN)
4: visualizar (Introducir PIN)
10: almacenaDatos (datos)
Diseño Ac=vidades
n Diseño del caso de uso “Sacar dinero” ¨ Suponemos que el usuario ya ha sido iden=ficado (se ha ejecutado el
caso de uso anterior) ¨ Ahora selecciona la opción “sacar dinero”
Sacar dinero Realización en diseño
Pantalla Teclado Expendedor
Dinero
GestorDeCliente
Transacción
Cuentas
Cuenta
Diseño Ac=vidades
n Diseño del c.u. “Sacar dinero” ¨ Añadimos la clase Cuentas que asocia número de cuenta con una
instancia de la clase Cuenta. ¨ La clase Transacción ya no actuará directamente sobre Cuenta.
: Transacción : Cuentas
1: ingreso (numeroDeCuenta, importe)
: Cuenta
2: ingreso (importe) Vista parcial del diagrama (modelo de análisis)
Diseño Ac=vidades
n Refinando el caso de uso “Sacar dinero”
Cliente del banco Interfaz de cajero
Cuenta
UsuariosDelBanco
Transacción
1
autentica
Cuentas
1..n
1..n
1..n
1..n posee
1..2
opera
1..2
1
Diseño Ac=vidades n Refinando el c. u. “Sacar dinero”: secuencia correcta
¿Qué pasa con la impresora?
: Cliente del banco : Teclado : Pantalla : ExpDinero : GestorDeCliente : Transacción : Cuentas : Cuenta : Impresora
1: opcion (sacar dinero) 2: sacarDinero
3: visualizar (Teclee importe)
4: IntroducirImporte 5: importe
6: retirarDinero (importe)
7: reintegro (cuenta, importe)
8: reintegro (importe) 9: OK
10: OK 11: OK
12: visualizar (Retire su tarjeta)
14: expulsa (importe)
15: visualizar (Retire su dinero)
13: visualizar (Retire su tarjeta)
16: visualizar (Retire su dinero)
Diseño Ac=vidades n Refinando el c. u. “Sacar dinero”: no hay fondos
Falta: [retirar tarjeta] - se ha superado el límite diario - en el cajero no hay dinero
: Cliente del banco : Teclado : Pantalla : Impresora
1: opcion (sacar dinero)
4: IntroducirImporte
2: sacarDinero
3: visualizar (Teclee importe)
5: importe
6: retirarDinero (importe)
7: reintegro (cuenta, importe)
8: reintegro (importe) 9: no hay saldo
10: no hay saldo 11: no hay saldo
: GestorDeCliente : Transacción : Cuentas : Cuenta
12: visualizar (No hay saldo) 13: visualizar (No dispone de saldo suficiente)
: ExpDinero
Diseño Ac=vidades n Modelo de clases de diseño
Impresora
LectorDeTarjetas
Pantalla
Teclado
Cliente del banco
GestorDeCliente
Cuenta
UsuariosDelBanco
Transacción
Cuentas
Recogedor Dinero
ExpDinero
Diseño Ac=vidades
n Diseño de las clases ¨ Iden=ficar las responsabilidades de las clases de diseño (papeles en los
casos de uso) ¨ Iden=ficar:
n operaciones n atributos n relaciones en las que par=cipa n estados (diagramas de estados) n métodos que soportan sus operaciones n requisitos nuevos…
Diseño Ac=vidades
n Diseño de las clases: ¨ Iden=ficar operaciones
n En el lenguaje de implementación n Mirar responsabilidades que =ene en los casos de uso
¨ Iden=ficar atributos n Describirlos en el lenguaje de programación n Considerar los atributos de las clases de análisis de las que se derivan
¨ Iden=ficar asociaciones y agregaciones n Las interacciones en los diagramas de secuencia precisan de asociaciones entre las
clases que interactúan n Minimizar el número de relaciones entre clases (disminuir el acoplamiento) n Refinar mul=plicidad, papeles, etc. n Refinar la navegabilidad (dirección) de las asociaciones en base a los diagramas de
secuencia n Iden=ficar generalizaciones-‐especializaciones
Diseño Ac=vidades
n Diseño de las clases: ¨ Describir métodos
n Algoritmos para implementar alguna operación (lenguaje natural) n Esqueletos de métodos generado por la herramienta n En general, esto se suele hacer en implementación
¨ Describir estados n Algunos objetos reaccionan en función de su estado actual n U=lizar diagramas de transición de estados
Diseño Ac=vidades
n Diseño de una clase: ¨ La única clase que =ene un comportamiento parecido a una máquina
de estados es GestorDeCliente
¨ Realizar el diagrama de transición de estados del sistema Cajero Automá=co
Diseño Ac=vidades
n Diseño de una clase: Esperando
tarjeta
Leyendo tarjeta
tarjeta introducida
Esperando PIN
Validando PIN
PIN introducido( PIN )
Recogiendo tarjeta
Esperando opción
[ incorrecto ] [ > 3 intentos ] [ correcto ]
Ingresando
ingreso( importe )
Reintegrando
reintegro (importe ) Transferencia
transferencia( cuenta, importe )
Expulsando dinero
[ OK ]
Expulsar tarjeta
dinero retirado
[ Not OK ]
Diseño Ac=vidades
n Diseño de los subsistemas: ¨ Intentar que los subsistemas de diseño estén débilmente acoplados ¨ Intentar que las clases dentro de los subsistemas tengan una alta
cohesión ¨ Describir las dependencias entre los subsistemas ¨ Determinar qué clases de unos subsistemas interactúan con qué otras
clases de otros subsistemas ¨ Asegurarse que el subsistema soporta sus interfaces ¨ Obje=vos:
n Subsistemas independientes n Garan=zar corrección de interfaces n Garan=zar la realización de dichas interfaces
Diseño Ejemplo
n Refinando el c. u. “Ingresar dinero”:
Ingresar dinero Realización en diseño
Pantalla Teclado
RecogedorDinero
GestorDeCliente
Transacción
Cuentas
Cuenta
Diseño Ejemplo
n Refinando el c. u. “Ingresar dinero”: secuencia correcta
: Cliente del banco : Teclado : Pantalla : Recogedor
Dinero 1: opcion (ingresar dinero)
5: IntroduceImporte
2: ingresarDinero 3: visualizar (Teclee importe)
6: importe
19: visualizar (Dinero ingresado) 21: visualizar (Retire su tarjeta)
13: ingresarDinero (importe) 14: ingreso (cuenta, importe)
15: ingreso (importe) 16: OK
17: OK 18: OK
7: visualizar (introducir dinero) 9: abrirCajon
10: IntroduceDinero 11: ContarDinero (cantidad)
12: validar (importe, cantidad)
: GestorDeCliente : Transacción : Cuenta : Cuentas
20: visualizar (Dinero ingresado)
22: visualizar (Retire su tarjeta)
4: visualizar (Teclee importe)
¿Qué podríamos agregar o modificar?
8: visualizar (introducir dinero)
Diseño Ejemplo
n Refinando el c. u. “Ingresar dinero”: can=dad incorrecta
: Cliente del banco : Teclado : Pantalla
1: opcion (ingresar dinero)
4: IntroducirImporte
2: ingresarDinero
3: visualizar (Teclee importe)
5: importe
11: visualizar (Cantidad errónea)
17: visualizar (Retire su tarjeta)
6: visualizar (introducir dinero)
10: validar (importe, cantidad)
7: abrirCajon 8: ingresarDinero
9: dinero (cantidad)
12: visualizar (Retire su dinero)
13: abrirCajon 14: dineroRecogido
15: recogido
16: cerrarCajon
:GestorDeCliente : Recogedor Dinero
¿Mensajes desde la Pantalla hacia el usuario?
Diseño Ejemplo
n Refinando el c. u. “Transferencia”:
Cuenta
Transferencia Realización en diseño, transferencia
Teclado
Pantalla
GestorDeCliente
Transacción
Cuentas
Diseño Ejemplo n Refinando el c. u. “Transferencia”: secuencia correcta
: Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas : Cuenta
1: opcion (transferencia)
4: IntroducirImporte
2: transferencia
3: visualizar (Teclee importe)
5: importe
19: visualizar (Transferencia realizada)
20: visualizar (Retire su tarjeta)
6: visualizar (Teclee cuenta destino)
9: transferencia (cuentaOrigen, cuentaDestino,importe) 10: reintegro (cuentaOrigen, importe)
11: reintegro (importe) 12: OK
13: OK
18: OK
7: cuentaDestino (cuenta) 8: cuentaDestino (cuenta)
14: ingreso (cuentaDestino, importe) 15: ingreso (importe)
16: OK 17: OK
Diseño Ejemplo n Refinando el c. u. “Transferencia”: no hay fondos
: Pantalla : Cliente del banco
1: opcion (transferencia)
4: IntroducirImporte
7: cuentaDestino (cuenta)
2: transferencia
3: visualizar (Teclee importe)
5: importe
15: visualizar (No hay fondos)
16: visualizar (Retire su tarjeta)
6: visualizar (Teclee cuenta destino)
8: cuentaDestino (cuenta)
9: transferencia (cuentaOrigen, cuentaDestino,importe)
14: no hay fondos
10: reintegro (cuentaOrigen, importe)
13: no hay saldo
11: reintegro (importe)
12: no hay saldo
: Teclado : GestorDeCliente : Transacción : Cuentas : Cuenta
Top Related