D IRIGIDO POR C ASOS DE U SO

Í NDICE El Usuario Los Casos de Uso, su importancia El aspecto “dirigido-por-casos-de-uso” Todos los modelos se relacionan El Modelo de Casos de Uso El Modelo de Análisis El modelo de diseño Ejemplo

E L U SUARIO Un sistema software ve la luz para dar servicio a sus usuarios. Por tanto, para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan. El término usuario no sólo hace referencia a usuarios humanos sino a otros sistemas. El término usuario representa alguien o algo (como otro sistema fuera del sistema en consideración) que interactúa con el sistema que estamos desarrollando. Un ejemplo de interacción sería una persona que utiliza un cajero automático. Él usuario inserta la tarjeta de plástico, responde a las preguntas que le hace la máquina en su pantalla, y recibe una suma de dinero. En respuesta a la tarjeta del usuario y a sus contestaciones, el sistema lleva a cabo una secuencia de acciones que proporcionan al usuario un resultado importante, (la retirada del efectivo).

E L U SUARIO Una interacción de este tipo es un caso de uso (Capítulo 3). Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos crean el modelo de casos de uso (Sección 2.3), el cual describe la funcionalidad total del sistema. Puede decirse que una especificación funcional (el modelo) contesta a la pregunta: ¿Qué debe hacer el sistema? añadiendo tres palabras al final de esta pregunta: ¿...para cada usuario? Regresar

L OS C ASOS DE U SO, SU IMPORTANCIA Estas tres palabras tienen un significado importante. Nos fuerzan a pensar en términos de importancia para el usuario y no sólo en términos de funciones que serían bueno tener. Los casos de uso no son sólo una herramienta para especificar los requisitos de un sistema. También guían su diseño, implementación, y prueba; esto es, guían el proceso de desarrollo. Basándose en el modelo de casos de uso, los desarrolladores crean una serie de modelos, de diseño e implementación que llevan a cabo los casos de uso. Los desarrolladores revisan cada uno de los sucesivos modelos para que sean conformes al modelo de casos de uso. Los ingenieros de prueba prueban la implementación para garantizar que los componentes del modelo de implementación implementan correctamente los casos de uso. De este modo, los casos de uso no sólo inician el proceso de desarrollo sino que le proporcionan un hilo conductor.

L OS C ASOS DE U SO, SU IMPORTANCIA Dirigido por casos de uso quiere decir que el proceso de desarrollo sigue un hilo —avanza a través de una serie de flujos de trabajo que parten de los casos de uso. Los casos de uso se especifican, se diseñan, y los casos de uso finales son la fuente a partir de la cual los ingenieros de prueba construyen sus casos de prueba. Aunque es cierto que los casos de uso guían el proceso, no se desarrollan aisladamente. Se desarrollan a la vez que la arquitectura del sistema. Es decir, los casos de uso guían la arquitectura del sistema y la arquitectura del sistema influye en la selección de los casos de uso. Por tanto, tanto la arquitectura del sistema como los casos de uso maduran según avanza el ciclo de desarrollo. Regresar

E L OBJETIVO DEL P ROCESO U NIFICADO Guiar a los desarrolladores en la implementación y distribución eficiente de sistemas que se ajusten a las necesidades de los clientes. La eficiencia se mide en términos de coste, calidad, y tiempo de desarrollo. El paso desde la determinación de las necesidades del cliente hasta la implementación no es trivial. En primer lugar, las necesidades del cliente no son fáciles de discernir. Esto nos obliga a tener algún modo para capturar las necesidades del usuario de forma que puedan comunicarse fácilmente a todas las personas implicadas en el proyecto.

E L ASPECTO “ DIRIGIDO - POR - CASOS - DE - USO ” La Figura 3.1 muestra la serie de flujos de trabajo y modelos del Proceso Unificado. Los desarrolladores comienzan capturando los requisitos del cliente en la forma de casos de uso en el modelo de casos de uso. Después analizan y diseñan el sistema para cumplir los casos de uso, creando en primer lugar un modelo de análisis, después uno de diseño y después otro de implementación, el cual incluye todo el código, es decir, los componentes. Por último, los desarrolladores preparan un modelo de prueba que les permite verificar que el sistema proporciona la funcionalidad descrita en los casos de uso. Regresar

T ODOS LOS MODELOS SE RELACIONAN Los casos de uso se utilizan casi universalmente para la captura de requisitos de sistemas software, y de sistemas basados en componentes en particular. Los casos de uso son mucho más que una herramienta para capturar requisitos. Dirigen el proceso de desarrollo en su totalidad. Los casos de uso son la entrada fundamental cuando se identifican y especifican clases, subsistemas e interfaces, cuando se identifican y especifican casos de prueba, y cuando se planifican las iteraciones del desarrollo y la integración del sistema (Capítulo 10). Para cada iteración, nos guían a través del conjunto completo de flujos de trabajo, desde la captura de requisitos, pasando por el análisis, diseño e implementación, hasta la prueba, enlazando estos diferentes flujos de trabajo.

F IGURA 3.1 E L P ROCESO U NIFICADO CONSISTE EN UNA SERIE DE FLUJOS DE TRABAJO QUE VAN DESDE LOS REQUISITOS HASTA LAS PRUEBAS ( DE IZQUIERDA A DERECHA Y DE ARRIBA HACIA ABAJO ). L OS FLUJOS DE TRABAJO DESARROLLAN MODELOS, DESDE EL MODELO DE CASOS DE USO HASTA EL MODELO DE PRUEBA. Regresar

E L M ODELO DE C ASOS DE U SO La captura de requisitos tiene dos objetivos: a) encontrar los verdaderos requisitos (véase Capítulo 6), y b) representarlos de un modo adecuado para los usuarios, clientes y desarrolladores. Entendemos por “verdaderos requisitos” aquellos que cuando se implementen añadirán el valor esperado para los usuarios. Con “representarlos de un modo adecuado para los usuarios, clientes y desarrolladores” queremos decir que la descripción obtenida de los requisitos debe ser comprensible por usuarios y clientes. Éste es uno de los retos principales del flujo de trabajo de los requisitos. Regresar

E L M ODELO DE A NÁLISIS Tanto el modelo de análisis como el modelo de diseño son estructuras compuestas por clasificadores y por un conjunto de realizaciones de casos de uso (Capítulos 8 y 9) que describen cómo esa estructura hace realidad los casos de uso. Los clasificadores son, en general, elementos “parecidos a clases”. Por ejemplo, tienen atributos y operaciones, se les puede describir con diagramas de estados, algunos de ellos pueden instanciarse, pueden ser participantes en colaboraciones, etc. UML define muchos tipos de clasificadores, como son los Subsistemas, clases e interfaces. También son clasificadores los actores, casos de uso, componentes y nodos (Sección 9.3.7).

E L M ODELO DE A NÁLISIS El modelo de análisis es una especificación detallada de los requisitos y funciona como primera aproximación del modelo de diseño, aunque es un modelo con entidad propia. Los desarrolladores lo utilizan para comprender de manera más precisa los casos de uso descritos en el flujo de trabajo de los requisitos, refinándolos en forma de colaboraciones entre clasificadores conceptuales (diferentes de los clasificadores de diseño que serán objeto de implementación). El modelo de análisis también se utiliza para crear un sistema robusto y flexible (incluyendo una arquitectura) que emplea la reutilización de componentes de manera considerable.

E L M ODELO DE A NÁLISIS El modelo de análisis es un modelo conceptual, el modelo de diseño es un esquema de la implementación. El modelo de análisis puede ser transitorio y sobrevivir sólo al primer par de iteraciones. En algunos casos, especialmente para sistemas grandes y complejos, el modelo de análisis debe mantenerse durante toda la vida del sistema. Es estos casos, existe una relación directa (mediante dependencias de traza) entre una realización de caso de uso en el modelo de análisis y la correspondiente realización de caso de uso en el modelo de diseño. Cada elemento del modelo de análisis es trazable a partir de elementos del modelo de diseño que lo realizan. Regresar

N OTAS (El modelo de análisis, su propósito y su relación con el modelo de diseño se explican en profundidad en las Secciones 8.1 a 8.3).

E L MODELO DE DISEÑO El modelo de diseño es jerárquico, pero también contiene relaciones que atraviesan la jerarquía. Las relaciones son las habituales en UML: asociaciones, generalizaciones, y dependencias. Las realizaciones de los casos de uso son estereotipos de colaboraciones. Una colaboración representa cómo los clasificadores participan y desempeñan papeles en hacer algo útil, como la realización de un caso de uso. El modelo de diseño es también un esquema de la implementación. Existe una correspondencia directa entre subsistemas del modelo de diseño y componentes del modelo de implementación.

E L MODELO DE DISEÑO Los desarrolladores crean un modelo de análisis que utiliza el modelo de casos de uso como entrada. Cada caso de uso en el modelo de casos de uso se traducirá en una realización de caso de uso en el modelo de análisis. La dualidad caso de uso/realización de caso de uso es la base de una trazabilidad directa entre los requisitos y el análisis. Tomando los casos de uso uno a uno, los desarrolladores pueden identificar las clases que participan en la realización de los casos de uso. Regresar

E JEMPLO, EL CASO DE USO S ACAR D INERO Por ejemplo, el caso de uso Sacar Dinero puede realizarse por parte de las clases de análisis Retirada de Efectivo. Cuenta, Cajero, y otras que no necesitamos identificar para esta explicación. Los desarrolladores asignan responsabilidades definidas en el caso de uso a responsabilidades de las clases. En nuestro ejemplo, la clase Cuenta podría tener responsabilidades como “restar cantidad de la cuenta”. De esta forma, podemos garantizar que obtenemos un conjunto de clases que juntas realizan los casos de uso y son verdaderamente necesarias para los usuarios.

E JEMPLO, EL CASO DE USO S ACAR D INERO Después, los desarrolladores diseñan las clases y las realizaciones de casos de uso para obtener mejor partido de los productos y tecnologías (object request brokers, kits de construcción de IGU, y sistemas de gestión de base de datos) que se utilizarán para implementar el sistema. Las clases de diseño se agrupan en subsistemas, y pueden definirse interfaces entre ellos. Los desarrolladores también preparan el modelo de despliegue, donde definen la organización física del sistema en términos de nodos de cómputo, y verifican que los casos de uso pueden implementarse como componentes que se ejecutan en esos nodos.

E JEMPLO, EL CASO DE USO S ACAR D INERO A continuación, los desarrolladores implementan las clases diseñadas mediante un conjunto de ficheros (código fuente) en el modelo de implementación, a partir de los cuales se pueden producir (compilar y enlazar) ejecutables, como DLL’s, JavaBeans, y componentes ActiveX. Los casos de uso ayudan a los desarrolladores a determinar el orden de implementación e integración de los componentes.

E JEMPLO, EL CASO DE USO S ACAR D INERO Por último, durante el flujo de trabajo de prueba los ingenieros de prueba verifican que el sistema implementa de verdad la funcionalidad descrita en los casos de uso y que satisface los requisitos del sistema. El modelo de prueba se compone de casos de prueba (y otros elementos que explicaremos más adelante en el Capítulo 11). Un caso de prueba define una colección de entradas, condiciones de ejecución, y resultados. Muchos de los casos de prueba se pueden obtener directamente de los casos de uso y por tanto tenemos una dependencia de traza entre el caso de prueba y el caso de uso correspondiente.

E JEMPLO, EL CASO DE USO S ACAR D INERO Esto significa que los ingenieros de prueba verificarán que el sistema puede hacer lo que los usuarios quieren que haga, es decir, que ejecuta los casos de uso. Cualquiera que haya probado software en el pasado en realidad ha probado casos de uso — incluso si su trabajo no los describía en esos términos en su momento. Lo novedoso y diferente del Proceso Unificado es que la prueba puede planificarse al principio del ciclo de desarrollo. Tan pronto como se hayan capturado los casos de uso, es posible especificar los casos de prueba (pruebas de caja negra”) y determinar el orden en el cual realizarlos, integrarlos y probarlos.

E JEMPLO, EL CASO DE USO S ACAR D INERO Más adelante, según se vayan realizando los casos de uso en el diseño, pueden detallarse las pruebas de los casos de uso (pruebas de “caja blanca”). Cada forma de ejecutar un caso de uso — es decir, cada camino a través de una realización de un caso de uso — es un caso de prueba candidato. Hasta aquí, hemos presentado el Proceso Unificado como una secuencia de pasos, muy parecida al antiguo método en cascada. Pero lo hemos hecho así sólo para mantener la simplicidad hasta este momento. En el Capítulo 5 veremos cómo estos pasos pueden desarrollarse de una forma mucho más interesante mediante una aproximación iterativa e incremental.

E JEMPLO, EL CASO DE USO S ACAR D INERO Realmente, lo que hemos descrito hasta aquí es una sola iteración. Un proyecto de desarrollo completo será una serie de iteraciones, en la cual cada una de ellas (con la posible excepción de la primera) consiste en una pasada a través de los flujos de trabajo de requisitos, análisis, diseño, implementación y prueba. Vamos a examinar con más detalle los beneficios de los casos de uso antes de estudiar los flujos de trabajo más en profundidad. Regresar