Análisis, diseño e implementación para realizar los casos de uso

Índice Introducción Creación del modelo de análisis a partir de los casos de uso

Introducción Durante el análisis y el diseño, transformamos el modelo de casos de uso mediante un modelo de análisis en un modelo de diseño, es decir, en una estructura de clasificadores y realizaciones de casos de uso. El objetivo es realizar los casos de uso de una forma económica de manera que el sistema ofrezca un rendimiento adecuado y pueda evolucionar en el futuro. En esta sección, veremos cómo pasar por un modelo de análisis para desarrollar un diseño que realice los casos de uso. Regresar

Notas En los Capítulos 4 y 5, examinaremos cómo la arquitectura y el desarrollo iterativo e incremental nos ayudan a desarrollar un sistema económico que pueda incorporar nuevos requisitos.

Creación del modelo de análisis a partir de los casos de uso El modelo de análisis crece incrementalmente a medida que se analizan más y más casos de uso. En cada iteración, elegimos un conjunto de casos de uso y los reflejamos en el modelo de análisis. Construimos el sistema como una estructura de clasificadores (clases de análisis) y relaciones entre ellas. También describimos las colaboraciones que llevan a cabo los casos de uso, es decir, las realizaciones de los casos de uso. Después, en la siguiente iteración, tomamos otro conjunto de casos de uso para desarrollar, y los añadimos a la iteración anterior.

Notas En las Secciones 5.3 y 12.6, discutiremos cómo identificar y seleccionar los conjuntos más "importantes" de casos de uso para las primeras iteraciones con el objetivo de construir pronto una arquitectura estable dentro del ciclo de vida del sistema.

Creación del modelo de análisis a partir de los casos de uso Una forma práctica de trabajar es identificar y describir en primer lugar los casos de uso para una iteración, después leer la descripción de cada caso de uso (Sección 3.3.3), y proponer los clasificadores y asociaciones necesarios para llevar a cabo el caso de uso. Lo hacemos para todos los casos de uso de una iteración a modo de esfuerzo coordinado. Dependiendo de dónde nos encontremos en el ciclo de vida y del tipo de iteración que estemos tratando, puede que haya ya una arquitectura establecida para guiarnos en la identificación de nuevos clasificadores y en la reutilización de los existentes (Sección 4.3). Cada clasificador desempeña uno o varios roles en una realización de caso de uso.

Creación del modelo de análisis a partir de los casos de uso Cada papel de un clasificador especifica las responsabilidades, atributos y demás que el clasificador debe tener para participar en la realización del caso de uso. Podemos pensar en esos roles como en "embriones" de clasificadores. De hecho, un rol en UML es un clasificador en sí mismo. Por ejemplo, podemos pensar que un rol de una clase es una vista de la clase. Por tanto, incluye lo que incluya la clase, es decir, sus responsabilidades, atributos y demás —pero sólo aquellos que sean de interés para el rol en una realización de caso de uso.

Notas Este concepto de rol se describe brevemente en este capítulo, aunque por simplicidad no se desarrolla completamente hasta la Parte II de este libro donde se explican todos los clasificadores en detalle.

Creación del modelo de análisis a partir de los casos de uso Otra forma de describir un rol de una clase es verlo como lo que queda de la clase cuando se le pone un filtro, un filtro que bloquea el resto de los roles de la clase que no tienen responsabilidades comunes.

Ejemplo. La realización de un caso de uso en el modelo de análisis En la Figura 3.4 describimos cómo se lleva a cabo el caso de uso Sacar Dinero mediante una colaboración (es decir, una realización de caso de uso) con una dependencia de “traza” (una traza es un estereotipo de dependencia que se indica mediante las comillas « y ») entre ellos, y cómo cuatro clases participan y desempeñan roles en la realización del caso de uso. Como puede verse en la figura, la notación para una realización de caso de uso o colaboración es una elipse con una línea de trazo continuo. Comenzamos normalmente examinando unos pocos casos de uso, creando sus realizaciones, e identificando los roles de los clasificadores.

Ejemplo. La realización de un caso de uso en el modelo de análisis Después hacemos lo mismo para más casos de uso y proponemos nuevos roles de clasificador. Algunos de estos últimos pueden especificarse como roles nuevos o modificados de clasificadores ya identificados, mientras que otros roles necesitarán nuevos clasificadores. Después observamos de nuevo los primeros casos de uso, alternando de esta forma entre los casos de uso y construyendo gradualmente un modelo de análisis estable. Al final, cada clasificador puede participar y desempeñar papeles en varías realizaciones de caso de uso.

Ejemplo. La realización de un caso de uso en el modelo de análisis

Creación del modelo de análisis a partir de los casos de uso Estereotipos de análisis En el modelo de análisis, se utilizan tres estereotipos diferentes sobre las clases: “boundary class”, “control class”,y “entity class” (traducidos al castellano, clase de interfaz, clase de control y clase de entidad, respectivamente). Salida e Interfaz del Cajero son clases de interfaz que se utilizan generalmente para modelar la interacción entre el sistema y sus actores (es decir, los usuarios y los sistemas externos). Retirada de Efectivo es una clase de control que se utiliza generalmente para representar coordinación, secuenciamiento, transacciones y control de otros objetos — y se utiliza con frecuencia para encapsular el control relativo a un caso de uso (en el ejemplo, el caso de uso Sacar Dinero).

Creación del modelo de análisis a partir de los casos de uso Cuenta es una clase de entidad, que en general se utilizan para modelar información que tiene una vida larga y que a veces es persistente. Por tanto, cada uno de estos estereotipos de clase encapsula un tipo diferente de comportamiento (o funcionalidad, si se quiere). En consecuencia, los estereotipos nos ayudan a construir un sistema robusto, (Capítulo 8). También nos ayudan a encontrar activos reutilizables, ya que las clases de entidad son normalmente genéricas para muchos casos de uso, y por tanto para muchas aplicaciones diferentes.

Ejemplo: Una clase que participa en varias realizaciones de caso de uso en el modelo de análisis En la parte izquierda de la Figura 3.5 tenemos un conjunto de casos de uso para un sistema de Cajero Automático (Figura 3.3), y a la derecha tenemos la correspondiente estructura del sistema, en este caso, las clases de análisis que realizan los casos de uso. La estructura del sistema se modela en un diagrama de clases. Los diagramas de clases se utilizan generalmente para mostrar clases y sus relaciones, pero también pueden utilizarse para mostrar subsistemas e interfaces (Sección 3.4.3). Por sencillez, hemos utilizado diferentes sombreados para indicar en qué realizaciones de caso de uso participa y desempeña algún rol cada clase.

Ejemplo: Una clase que participa en varias realizaciones de caso de uso en el modelo de análisis

Creación del modelo de análisis a partir de los casos de uso El diagrama de clases para el sistema Cajero Automático (Figura 3.5) se obtuvo a partir del estudio de las descripciones de los tres casos de uso y de la posterior búsqueda de formas de llevar a cabo cada uno de ellos. Podríamos haber hecho algo como lo siguiente: La realización de los tres casos de uso, Sacar Dinero, Transferencia entre Cuentas, e Ingresar Dinero implica a la clase Interfaz del Cajero y a la clase de entidad Cuenta. La ejecución de cada caso de uso comienza con un objeto de la clase Interfaz del Cajero. Después, el trabajo continúa en un objeto de control que coordina la mayor parte del caso de uso en cuestión.

Creación del modelo de análisis a partir de los casos de uso La clase de este objeto es específica de cada caso de uso. La clase Retirada de Efectivo participa por tanto en el caso de uso Sacar Dinero, etc. El objeto Retirada de Efectivo pide a la clase Salida que entregue el dinero, y éste pide al objeto Cuenta que disminuya el saldo. El objeto Transferencia pide a los dos objetos Cuenta implicados en la realización del caso de uso Transferencia entre Cuentas que actualicen sus saldos. El objeto Ingreso acepta dinero a través del Receptor de Dinero y pide al objeto Cuenta que incremente el saldo.

Creación del modelo de análisis a partir de los casos de uso Hasta aquí hemos trabajado para obtener una estructura del sistema estable para la iteración en curso. Hemos identificado las responsabilidades de los clasificadores participantes, y hemos encontrado relaciones entre los clasificadores. Sin embargo, no hemos identificado en detalle la interacción que debe tener lugar en el desarrollo de los casos de uso. Hemos encontrado la estructura, pero ahora es necesario sobreponer sobre esa estructura los diferentes patrones de interacción necesarios para la realización de cada caso de uso.

Creación del modelo de análisis a partir de los casos de uso Como dijimos anteriormente, cada caso de uso se desarrolla como una realización de caso de uso, y cada realización de caso de uso tiene un conjunto de clasificadores participantes, que desempeñan diferentes roles. Comprender los patrones de interacción significa que describimos cómo se lleva a cabo o se ejecuta (o se instancia) una realización de caso de uso. Por ejemplo, qué ocurre cuando un Cliente de Banco concreto saca dinero, es decir, cuando él o ella ejecutan un caso de uso Sacar Dinero. Sabemos que las clases Interfaz del Cajero, Retirada de Efectivo, Salida y Cuenta participarán en la realización del caso de uso.

Creación del modelo de análisis a partir de los casos de uso También sabemos las responsabilidades que deberían cumplir. Sin embargo, aún no sabemos cómo ellas — o más correctamente, cómo objetos de esas clases — interactuarán para llevar a cabo la realización del caso de uso. Esto es lo siguiente que debemos averiguar. Utilizamos fundamentalmente diagramas de colaboración para modelar las interacciones entre objetos en el análisis. (UML también proporciona diagramas de secuencia para modelar interacciones, volveremos a hablar de ellos cuando tratemos el diseño en la Sección 3.4.3.)

Creación del modelo de análisis a partir de los casos de uso Un diagrama de colaboración recuerda a un diagrama de clases, pero contiene instancias y enlaces en lugar de clases y asociaciones. Muestra cómo interactúan los objetos secuencialmente o en paralelo, numerando los mensajes que se envían unos a otros.

Ejemplo: Uso de diagramas de colaboración para describir una realización de caso de uso en el modelo de análisis En la Figura 3.6 utilizamos un diagrama de colaboración para describir cómo una sociedad de objetos de análisis lleva a cabo la realización del caso de uso Sacar Dinero. El diagrama muestra cómo el control pasa de un objeto a otro a medida que se lleva a cabo el caso de uso, y los mensajes que se envían entre los objetos. Un mensaje de un objeto dispara al objeto receptor para que tome el control y lleve a cabo una de las responsabilidades de su clase.

Ejemplo: Uso de diagramas de colaboración para describir una realización de caso de uso en el modelo de análisis El nombre de un mensaje indica el motivo del objeto que realiza la llamada en su interacción con el objeto invocado, Más adelante, en el diseño, estos mensajes se retinarán en una o más operaciones proporcionadas por las clases de diseño correspondientes (Sección 3.4.3). Como complemento a un diagrama de colaboración, los desarrolladores pueden usar también texto para explicar cómo interactúan los objetos para llevar a cabo el flujo de eventos del caso de uso. Existen muchas otras formas de describir una realización, como el texto estructurado o el pseudocódigo.

Figura 3.6 Un diagrama de colaboración para la realización del caso de uso Sacar Dinero en el modelo de análisis.

Ejemplo. Descripción del flujo de sucesos de una realización de uso Describimos ahora la realización del caso de uso Sacar Dinero en términos de objetos y actores que interactúan, como se muestra en la Figura 3.6. Un Cliente de Banco decide sacar dinero y activa el objeto Interfaz del Cajero. El Cliente de Banco se identifica y especifica la cantidad a retirar y la cuenta de la cual hacerlo (1). Interfaz del Cajero verifica la identidad del Cliente de Banco y solicita al objeto Retirada de Efectivo que lleve a cabo la transacción (2).

Ejemplo. Descripción del flujo de sucesos de una realización de uso Si la identidad del Cliente de Banco es válida, se le solicita al objeto Retirada de Efectivo que confirme si el cliente del banco tiene derecho a sacar la cantidad especificada de la Cuenta, El objeto Retirada de Efectivo lo confirma solicitando al objeto Cuenta que valide la petición y: si la petición es válida, que reste la cantidad (3). Después el objeto Retirada de Efectivo autoriza a Salida a que entregue al Cliente de Banco la cantidad solicitada (4). Entonces es cuando el Cliente de Banco recibe la cantidad de dinero solicitada (5).

Ejemplo. Descripción del flujo de sucesos de una realización de uso Obsérvese que este sencillo ejemplo sólo muestra un camino a través de la realización del caso de uso, cuando todo sucede sin complicaciones. Podrían ocurrir complicaciones, por ejemplo, si el saldo de la Cuenta es demasiado bajo para permitir la retirada de efectivo. En este momento, hemos analizado cada caso de uso y por tanto hemos identificado todos los roles de clase que participan en cada realización de caso de uso. Ahora pasamos a cómo analizar cada clase.

Figura 3.6 Un diagrama de colaboración para la realización del caso de uso Sacar Dinero en el modelo de análisis.

Creación del modelo de análisis a partir de los casos de uso Cada clase debe cumplir todos sus roles de colaboración Las responsabilidades de una clase son sencillamente la recopilación de todos los roles que cumple en todas las realizaciones de caso de uso. Juntándolas y eliminando repeticiones entre los roles, obtenernos una especificación de todas las responsabilidades y atributos de la clase. Los desarrolladores responsables de analizar y realizar los casos de uso son los responsables de especificar los roles de las clases. Un desarrollador responsable de una clase agrupa todos los roles de la clase en un conjunto completo de responsabilidades para la clase, y después los integra en un conjunto consistente de responsabilidades.

Creación del modelo de análisis a partir de los casos de uso Los desarrolladores responsables de analizar los casos de uso deben asegurarse de que las clases realizan los casos de uso con la calidad adecuada. Si se cambia una clase, su desarrollador debe verificar que la clase sigue cumpliendo sus roles en las realizaciones de casos de uso. Si se cambia un rol en una realización de caso de uso, el desarrollador del caso de uso debe comunicar el cambio al desarrollado de la clase. Por tanto, los roles ayudan a mantener la integridad del análisis tanto a los desarrolladores de las clases, como a los de los casos de uso. Regresar