Creación del modelo de diseño a partir del modelo de análisis

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

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