Creaci

1
Creación del modelo de diseño a partir del modelo
de análisis
2
Í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

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

4
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
5
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
6
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
7
Figura 3.8 Clases de diseño del Modelo de Diseño
con sus trazas hacia clases del modelo de
análisis.
8
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.

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

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

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

12
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.
13
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.

14
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. 
15
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
16
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).

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

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

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

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

21
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.
22
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.

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

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

25
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
26
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.

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

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

29
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.
30
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.

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

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

33
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
34
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.

35
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