Dirigido por Casos de Uso

1
Dirigido por Casos de Uso
2
Í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

3
El Usuario

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

4
El Usuario

• 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
5
Los Casos de Uso, 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.

6
Los Casos de Uso, 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
7
El objetivo del Proceso Unificado

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

8
El 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
9
Todos 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.

10
Figura 3.1 El Proceso Unificado 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). Los flujos de
trabajo desarrollan modelos, desde el modelo de
casos de uso hasta el modelo de prueba.
Regresar
11
El Modelo de Casos de Uso

• 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
12
El Modelo de Aná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).

13
El Modelo de Aná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.

14
El Modelo de Aná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
15
Notas

• (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).

16
El 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.

17
El 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
18
Ejemplo, el caso de uso Sacar Dinero

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

19
Ejemplo, el caso de uso Sacar Dinero

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

20
Ejemplo, el caso de uso Sacar Dinero

• 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
  DLLs, 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.

21
Ejemplo, el caso de uso Sacar Dinero

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

22
Ejemplo, el caso de uso Sacar Dinero

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

23
Ejemplo, el caso de uso Sacar Dinero

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

24
Ejemplo, el caso de uso Sacar Dinero

• 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