Dirigido por Casos de Uso-4.ppt

CREACIÓN DEL MODELO DE DISEÑO
A PARTIR DEL MODELO DE
ANÁLISIS
ÍNDICE
 Introducción
 Ejemplo.
Realizaciones de casos de
uso en los modelos de análisis y
diseño
 Creación del modelo de diseño a partir
del modelo de análisis
 Los subsistemas agrupan a las clases
 Prueba de los casos de uso
 Resumen
INTRODUCCIÓN



El modelo de diseño se crea tomando el modelo de
análisis como entrada principal, pero se adapta al
entorno de implementación elegido, por ejemplo, a un
object request broker, un kit de construcción de IGU,
o a un sistema de gestión de bases de datos.
También debe adaptarse para reutilizar sistemas
heredados u otros marcos de trabajo desarrollados
para el proyecto.
Por tanto, mientras que el modelo de análisis sirve
como una primera aproximación del modelo de
diseño, el modelo de diseño funciona como esquema
para la implementación.
INTRODUCCIÓN



De igual forma que el modelo de análisis, el modelo de
diseño también define clasificadores (clases, subsistemas e
interfaces), relaciones entre esos clasificadores, y
colaboraciones que llevan a cabo los casos de uso (las
realizaciones de casos de uso).
Sin embargo, los elementos definidos en el modelo de
diseño son las “contrapartidas de diseño” de los elementos,
más conceptuales, definidos en el modelo de análisis, en el
sentido de que los primeros (diseño) se adaptan al entorno
de la implementación mientras que los últimos (análisis) no.
Dicho de otra forma, el modelo de diseño es más “físico” por
naturaleza, mientras que el modelo de análisis es más
“conceptual”.
Regresar
EJEMPLO. REALIZACIONES
DE CASOS DE USO EN
LOS MODELOS DE ANÁLISIS Y DISEÑO
En la Figura 3.7 describimos cómo el caso de uso Sacar Dinero
se lleva a cabo mediante una realización de caso de uso tanto
en el modelo de análisis como en el modelo de diseño.
Figura 3.7 Realizaciones de caso de uso en diferentes
modelos
EJEMPLO. REALIZACIONES
DE CASOS DE
USO EN LOS MODELOS DE ANÁLISIS Y
DISEÑO



Las realizaciones de caso de uso en los diferentes
modelos sirven para cosas distintas.
Recuérdese de la Sección 3.4.1 (Figura 3.4) que las
clases de análisis Interfaz del Cajero, Retirada de
Efectivo, Cuenta, y Salida participan en la realización
del caso de uso Sacar Dinero en el modelo de análisis.
Sin embargo, cuando se diseñan esas clases del
análisis, todas ellas especifican y hacen surgir clases
de diseño más refinadas que se adaptan al entorno de
implementación, como se ejemplifica en la Figura 3.8.
Regresar
FIGURA 3.8 CLASES DE DISEÑO DEL MODELO
DE DISEÑO CON SUS TRAZAS HACIA CLASES DEL
MODELO DE ANÁLISIS.
CREACIÓN
DEL MODELO DE DISEÑO A
PARTIR DEL MODELO DE ANÁLISIS



Por ejemplo, la clase del análisis llamada Interfaz del
Cajero se diseña mediante cuatro clases del diseño:
Dispositivo de visualización, Teclado, Lector de
Tarjetas, y Gestor de Cliente (ésta última es una clase
activa y por tanto se dibuja con borde grueso).
Obsérvese en la Figura 3.8 que la mayoría de las
clases de diseño normalmente tienen una sola traza a
una clase de análisis.
Esto es habitual para las clases de diseño que son
específicas de la aplicación, diseñadas para dar
soporte a una aplicación o a un conjunto de ellas.
CREACIÓN
DEL MODELO DE DISEÑO A
PARTIR DEL MODELO DE ANÁLISIS


Por tanto, la estructura del sistema definida por el
modelo de análisis se conserva de forma natural
durante el diseño, aunque pueden ser necesarios
algunos cambios (como por ejemplo, el Gestor de
Cliente que participa en el diseño de las dos clases
Interfaz del Cajero y Salida).
Además, las clases activas (Gestor de Cliente, Gestor
de Transacciones y Gestor de Cuentas) representan
procesos que organizan el trabajo de las otras clases
(no activas) cuando el sistema es distribuido (Sección
4.5.3).
CREACIÓN
DEL MODELO DE DISEÑO A
PARTIR DEL MODELO DE ANÁLISIS





Como consecuencia, la realización del caso de uso Sacar
Dinero en el modelo de diseño debe describir cómo se
realiza el caso de uso en términos de las clases de diseño
correspondientes.
La Figura 3.9 muestra un diagrama de clases que es parte
de la realización del caso de uso.
Es evidente que este diagrama de clases incluye más
detalles que el diagrama de clases del modelo de análisis
(Figura 3.5).
Este detalle es necesario debido a la adaptación del modelo
de diseño al entorno de la implementación.
De manera parecida a cómo lo hacíamos en el análisis
(Figura 3.6), debemos identificar la interacción detallada
entre los objetos de diseño que tiene lugar cuando se lleva a
cabo el caso de uso en el modelo de diseño.
CREACIÓN
DEL MODELO DE DISEÑO A
PARTIR DEL MODELO DE ANÁLISIS



Utilizamos principalmente diagramas de secuencia
para modelar las interacciones entre objetos del
diseño, como se muestra en la Figura 3.10.
El diagrama de secuencia muestra cómo el control —
que comienza en la esquina superior izquierda— pasa
de un objeto a otro a medida que se ejecuta el caso
de uso y a medida que se envían mensajes entre
objetos.
Un mensaje enviado por un objeto dispara la toma del
control en el objeto receptor y la realización de las
operaciones de su clase.
FIGURA 3.9.
UN
DIAGRAMA DE CLASES QUE ES PARTE DE LA
REALIZACIÓN DEL CASO USO
SACAR DINERO EN EL MODELO DE
DISEÑO. CADA CLASE DE DISEÑO PARTICIPA Y ASUME ROLES EN LA
REALIZACIÓN DEL CASO DE USO.
CREACIÓN
DEL MODELO DE DISEÑO A
PARTIR DEL MODELO DE ANÁLISIS



Es un ejercicio interesante comparar este diagrama de
secuencia con su “contrapartida de análisis” —es decir,
el diagrama de colaboración— de la Figura 3.6.
Como puede comprobarse, los dos primeros mensajes
del diagrama de colaboración (”1: Identificación” y “2:
solicitar retirada”) se diseñan mediante todos los
mensajes en el diagrama de secuencia de la Figura
3.10.
Esto nos proporciona una idea de la complejidad y de
la cantidad de detalle que se incluye en el modelo de
diseño en comparación con la del modelo de análisis.
FIGURA 3.10.
UN DIAGRAMA DE SECUENCIA QUE ES PARTE DE LA
REALIZACIÓN DEL CASO DE USO SACAR DINERO EN EL MODELO DE
DISEÑO.
CREACIÓN
DEL MODELO DE DISEÑO A
PARTIR DEL MODELO DE ANÁLISIS
De igual forma que en los diagramas de colaboración,
los desarrolladores pueden también utilizar texto
como complemento a los diagramas de secuencia —
explicando cómo interactúan los objetos de diseño
para llevar a cabo el flujo de eventos del caso de uso.
 Como puede observarse en este ejemplo, el modelo
de diseño contendrá probablemente muchas clases.
Por tanto, es necesaria una forma de organizarlas.

Regresar
LOS
SUBSISTEMAS AGRUPAN A LAS
CLASES




Es imposible utilizar sólo clases para realizar los casos
de uso en un sistema grande con cientos o miles de
clases: el sistema es demasiado grande para poder
comprenderlo sin una organización de más alto nivel.
Un subsistema es un agrupamiento semánticamente
útil de clases o de otros subsistemas.
Un subsistema posee un conjunto de interfaces que
ofrece a sus usuarios.
Estas interfaces definen el contexto del subsistema
(actores y otros subsistemas y clases).
LOS





SUBSISTEMAS AGRUPAN A LAS CLASES
Los subsistemas de bajo nivel se denominan
subsistemas de servicio (Capítulo 9) debido a que sus
clases llevan a cabo un servicio (pava una descripción
más detallada del concepto de servicio, (Sección
8.4.5.1).
Los subsistemas de servicio constituyen una unidad
manejable
de
funcionalidad
opcional
(o
potencialmente opcional).
Sólo es posible instalar un subsistema en un sistema
del cliente si se hace en su totalidad.
Los subsistemas de servicio también se utilizan para
modelar grupos de clases que tienden a cambiar
juntas.
Los subsistemas pueden diseñarse descendente o
ascendentemente.
LOS
SUBSISTEMAS AGRUPAN A LAS
CLASES



Cuando se hace de manera ascendente, los
desarrolladores proponen subsistemas basados en las
clases que y han identificado; proponen subsistemas
que empaquetan las clases en unidades con unas
funciones claramente definidas.
Si en cambio los desarrolladores eligen un enfoque
descendente el arquitecto identifica los subsistemas
de más alto nivel y las interfaces antes de que se
hayan identificado las clases.
Por tanto, se asigna a los desarrolladores el trabajo
con de terminados subsistemas para identificar y
diseñar las clases dentro de sus subsistemas Capítulos
4 y 9.
EJEMPLO. LOS
SUBSISTEMAS
AGRUPAN CLASES




Los desarrolladores agrupan las clases en los tres
subsistemas que se muestran en la Figura 3.11.
Estos subsistemas se eligieron de forma que todas las clases
que proporcionan la interfaz gráfica se ubican en un
subsistema, todas las que tienen que ver con las cuentas en
otro, y las clases específicas de los casos de uso en un
tercero.
La ventaja de colocar todas las clases de interfaz gráfica en
un subsistema de Interfaz Cajero Automático es que
podemos reemplazar este subsistema por otro que ofrezca
la misma funcionalidad al subsistema de Gestión de
Transacciones.
Un subsistema de Interfaz CA alternativo podría ofrecer una
implementación de la interfaz de usuario muy diferente,
quizá diseñado para aceptar y entregar monedas en lugar
de billetes.
LOS
SUBSISTEMAS AGRUPAN A LAS
CLASES




Cada una de las clases específicas de los casos de uso
en el subsistema de Gestión de Transacciones, como
la clase Retirada de Efectivo, se colocan en un
subsistema de servicio aparte.
Cada uno de estos subsistemas de servicio podría
contener más de una clase en realidad, pero no lo
hemos reflejado en nuestro sencillo ejemplo.
La Figura 3.11 también muestra las interfaces entre
los subsistemas. Un círculo representa una interfaz.
La línea continua de una clase a una interfaz significa
que la clase proporciona la interfaz.
FIGURA 3.11.
TRES SUBSISTEMAS Y UN SUBSISTEMA
DE SERVICIO (EN GRIS DENTRO DEL SUBSISTEMA DE
GESTIÓN DE TRANSACCIONES) PARA NUESTRO
EJEMPLO SENCILLO DEL CA.
LOS
SUBSISTEMAS AGRUPAN A LAS
CLASES

Por ejemplo, el componente fichero salida.c contiene
el código fuente de tres clases (y por tanto las
implementa):
Alimentador de la Salida,
 Gestor de Cliente, y
 Contador de Efectivo.




Este componente fichero se compilará y enlazará
junto con el componente fichero.c para obtener
cliente.exe, que es un ejecutable.
Un componente presupone un contexto de la
arquitectura definido por sus interfaces.
También es reemplazable, es decir, los desarrolladores
pueden intercambiar un componente con otro, quizás
mejor, siempre que el nuevo proporcione y requiera
las mismas interfaces.
LOS
SUBSISTEMAS AGRUPAN A LAS
CLASES




Normalmente
existe
una
forma
directa
de
implementar un subsistema de servicio del modelo de
diseño mediante componentes que pueden asignarse
a nodos del modelo de despliegue.
Cada subsistema de servicio se implementa mediante
un componente si siempre se asigna a un mismo tipo
de nodo en el modelo de despliegue.
Si se asigna a más de un nodo, podemos dividir el
subsistema de servicio —normalmente separando
algunas clases— en tantas partes como tipos de nodo.
En este caso, cada pinte del subsistema de servicio se
implementará como un componente.
EJEMPLO. UN SUBSISTEMA DE SERVICIO
IMPLEMENTADO MEDIANTE COMPONENTES




Supongamos que hemos elegido una solución
cliente/servidor (véase la Sección 9.5.1.1) para
nuestro ejemplo del Cajero Automático.
Podríamos distribuir tanto en el cliente como en el
servidor parte del subsistema de servicio Gestión de
Retirada de Efectivo (Figura 3.11) que contiene a la
clase Retirada.
El subsistema de servicio Gestión de Retirada de
Efectivo
podría
implementarse
mediante
dos
componentes: “Retirada en el Cliente” y “Retirada en
el Servidor”.
Si los componentes se implementan en un lenguaje de
programación orientado a objetos, la implementación
de las clases es también directa.
LOS
SUBSISTEMAS AGRUPAN A LAS
CLASES




Cada clase de diseño se corresponde con una clase en
la implementación, por ejemplo, clases C++ o Java.
Cada componente fichero puede implementar varias
de esas clases, dependiendo de las convenciones del
lenguaje de programación.
Pero la implemento ion es más que el desarrollo del
código para crear un sistema ejecutable.
Los desarrolladores responsables de implementar un
componente son también responsables de hacer su
prueba de unidad antes de enviarlo a las pruebas de
integración y del sistema.
Regresar
PRUEBA



DE LOS CASOS DE USO
Durante la prueba, verificarnos que el sistema
implementa correctamente su especificación.
Desarrollamos un modelo de prueba compuesto por
casos de prueba y procedimientos de prueba
(Capítulo 11) y después ejecutamos los casos de
prueba para estar seguros de que el sistema funciona
como esperamos.
Un caso de prueba es un conjunto de entradas de
prueba, condiciones de ejecución, y resultados
esperados, desarrollados para un objetivo concreto,
tal como probar un camino concreto a través de un
caso de uso, o verificar que se cumple un requisito
específico.
PRUEBA





DE LOS CASOS DE USO
Un procedimiento de prueba es una especificación de
cómo llevar a cabo la preparación, ejecución, y
evaluación de los resultados de un caso de prueba
particular.
Los procedimientos de prueba también pueden
derivarse de los casos de uso.
Los defectos hallados se analizan para localizar el
problema.
Después estos problemas se priorizan y se corrigen
por orden de importancia.
En la Sección 3.3, comenzamos con la captura de los
casos de uso, y después en la Sección 3.4 analizamos,
diseñamos, e implementamos un sistema que llevaba
a cabo los casos de uso.
CÓMO




PROBAR LOS CASOS DE USO
Ahora, describiremos cómo probar que los casos de uso
se han implementado correctamente.
De alguna forma, esto no es nada nuevo. Los
desarrolladores siempre han probado los casos de uso,
incluso antes de que se acuñara el término caso de
111,0.
La forma práctica de probar las funciones de un sistema
es la prueba de que el sistema puede utilizarse de
maneras que tengan sentido para los usuarios.
Sin embargo, por otro lado, ésta es una técnica nueva.
Es nueva ya que identificamos los casos de prueba (como
casos de uso durante el flujo de trabajo de los requisitos)
antes de que tan siquiera comencemos a diseñar el
sistema, y después nos aseguramos de que nuestro
diseño realmente implementa los casos de uso.
EJEMPLO. IDENTIFICACIÓN
DE UN CASO
DE PRUEBA A PARTIR DE UN CASO DE USO
En la Figura 3.13 mostramos un caso de prueba. Sacar
Dinero-Flujo Básico, que especifica cómo probar el flujo
básico del caso de uso Sacar Dinero.
Figura 3.13. Un caso de prueba del modelo de
prueba que especifica cómo probar un cuso de uso
(Sacar Dinero) del modelo de CASOS de uso.
CÓMO
PROBAR LOS CASOS DE USO
Obsérvese el nuevo estereotipo que presentamos aquí para
los casos de prueba, un símbolo de caso de uso con una
cruz dentro. Hacemos esto para poder dibujar los casos de
prueba en los diagramas (capítulo 11)
 El caso de prueba especifica la entrada, los resultados
esperados, y otras condiciones relevantes para verificar el
flujo básico del caso de uso Sacar Dinero:
Entradas:
 La cuenta 12-121-1211 del Cliente de Banco tiene un saldo
de 350 dólares.
 El Cliente de Banco se identifica correctamente.
 El Cliente de Banco solicita la retirada de 200 dólares de la
cuenta 12-121-1211.
 Hay suficiente dinero (por lo menos 200 dólares) en el
Cajero Automático.

CÓMO
PROBAR LOS CASOS DE USO
Resultados:
 El saldo de la cuenta 12-121-1211 del Cliente de
Banco disminuye a 150 dólares.
 El Cliente de Banco recibe 200 dólares del Cajero
Automático.
Condiciones:
 No se permite a ningún otro caso de uso (instancias
de) acceder a la cuenta 12-121-1211 durante la
ejecución del caso de prueba.
CÓMO




PROBAR LOS CASOS DE USO
Obsérvese que este caso de prueba se basa en la
descripción del caso de uso Sacar Dinero que se dio
en la Sección 3.3.3.
Mediante la identificación temprana de los casos de
uso, podemos comenzar pronto la planificación de las
actividades de prueba, y podemos proponer casos de
prueba desde el comienzo.
Estos casos de prueba podrán detallarse más durante
el diseño, cuando sepamos más sobre cómo el
sistema llevará a cabo los casos de uso.
Algunas herramientas generan los casos de prueba a
partir del modelo de diseño —todo lo que hay que
hacer es introducir manualmente los datos necesarios
para ejecutar las pruebas.
CÓMO



PROBAR LOS CASOS DE USO
Las pruebas de los casos de uso pueden llevarse a
cabo bien desde la perspectiva de un actor que
considera el sistema corno una caja negra, o bien
desde una perspectiva de diseño, en la cual el caso de
prueba se construye para verificar que las instancias
de las clases participantes en la realización del caso
de uso hacen lo que deberían hacer.
Las pruebas de caja negra pueden identificarse,
especificarse y planificarse tan pronto como los
requisitos sean algo estables.
También hay otro tipo de pruebas, como las del
sistema, las de aceptación, y las de la documentación
de usuario. Hablaremos más sobre las pruebas en el
Capítulo 11.
Regresar
RESUMEN





Los casos de uso dirigen el proceso.
Durante el flujo de trabajo de los requisitos, los
desarrolladores pueden representar los requisitos en
la forma de casos de uso.
Los jefes de proyecto pueden después planificar el
proyecto en términos de los casos de uso con los
cuales trabajan los desarrolladores.
Durante el análisis y el diseño, los desarrolladores
crean realizaciones de casos de uso en términos de
clases y subsistemas.
Los componentes se incorporan en los incrementos, y
cada uno de ellos realiza un conjunto de casos de uso.
RESUMEN




Por último, los ingenieros de prueba verifican que el
sistema implemento los casos de uso correctos para
los usuarios.
En otras palabras, los casos de uso enlazan todas las
actividades del desarrollo y dirigen el proceso de
desarrollo —éste es quizá el beneficio más importante
de la aproximación dirigida por los casos de uso.
Los casos de uso proporcionan muchos beneficios al
proyecto. Sin embargo, no son todo.
En el siguiente capítulo hablaremos sobre otro aspecto
muy importante del Proceso Unificado —el estar
centrado en la arquitectura.
Regresar