1
Por qué Casos de Uso?
2
Índice

• Por qué Casos de Uso?
• Para capturar los requisitos que aportan valor
  añadido
• Para dirigir el proceso
• Para idear la arquitectura y más...
• La captura de casos de uso

3
Por qué casos de uso?

• Existen varios motivos por los cuales los casos
  de uso son buenos, se han hecho populares y se
  han adoptado universalmente.
• Las dos razones fundamentales son
• Proporcionan un medio sistemático e intuitivo de
  capturar requisitos funcionales (Capítulos 6 y 7)
  centrándose en el valor añadido para el usuario.
• Dirigen todo el proceso de desarrollo debido a
  que la mayoría de las actividades como
  elanálisis, diseño y prueba se llevan a cabo
  partiendo de los casos de uso.

4
Por qué casos de uso?

• El diseño y la prueba pueden también
  planificarse y coordinarse en términos de casos
  de uso.
• Esta característica es aún más evidente cuando la
  arquitectura se ha estabilizado en el proyecto,
  después del primer conjunto de iteraciones.
• Según Karl Wieger, la perspectiva que
  proporcionan los casos de uso refuerza el
  objetivo último de la ingeniería del software la
  creación de productos que permitan a los clientes
  realizar un trabajo útil.

5
Para capturar los requisitos que aportan
valor añadido

• Existen varias razones por las cuales esto es
  cierto.
• En primer lugar, la idea de caso de uso permite
  la identificación del software que cumple con los
  objetivos del usuario.
• Los casos de uso son las funciones que
  proporciona un sistema para añadir valor a sus
  usuarios.
• Tomando la perspectiva de cada tipo de usuario,
  podemos capturar los casos de uso que necesitan
  para hacer su trabajo.

Regresar
6
Para capturar los requisitos que aportan valor
añadido

• Por otro lado, si comenzamos pensando en un
  conjunto de buenas funciones del sistema sin
  pensar en los casos de uso que emplean los
  usuarios concretos, será difícil decir si esas
  funciones son importantes o incluso si son
  buenas.
• A quién ayudan?
• Qué necesidades del negocio satisfacen?
• Cuánto valor añaden al negocio?
• Los mejores casos de uso son aquellos que añaden
  el mayor valor al negocio que implanta el
  sistema.

7
Para capturar los requisitos que aportan valor
añadido

• Un caso de uso que aporta un valor negativo o que
  permite hacer al usuario cosas que no debería
  poder hacer no es un caso de uso. Podríamos
  llamarlo un caso de abuso, ya que especifica
  formas de utilizar el sistema que deben
  prohibirse.
• Un ejemplo de un caso de uso de este tipo sería
  permitir a un cliente de un banco transferir
  dinero de la cuenta de otro a la suya.
• Los casos de uso que aportan poco o ningún valor
  se utilizarán con menos frecuencia son casos
  sin-uso superfluos.

8
Para capturar los requisitos que aportan
valor añadido

• Se ha llegado a la conclusión de que preguntarse
  a sí mismos sobre qué quieren que haga el sistema
  no les ayuda a obtener las respuestas correctas.
• En su lugar, obtienen una lista de funciones del
  sistema, que a primera vista puede parecer
  valiosa, pero cuando se examina más en
  profundidad se ve que no necesariamente está
  relacionada con las necesidades del usuario.
• Puede parecer que la estrategia de los casos de
  uso que reformula la pregunta añadiendo tres
  palabras al final qué se quiere que haga el
  sistema para cada usuario? es sólo un poco
  diferente, pero obtiene un resultado muy
  distinto.

9
Para capturar los requisitos que aportan valor
añadido

• Nos mantiene centrados en la comprensión de cómo
  el sistema debe dar soporte a cada uno de sus
  usuarios. Nos guía en la identificación de las
  funciones que cada usuario necesita.
• También nos ayuda a abstenernos de sugerir
  funciones superfinas que ninguno de los usuarios
  necesita.
• Además, los casos de uso son intuitivos. Los
  usuarios y los clientes no tienen que aprender
  una notación compleja. En su lugar, se puede usar
  simple castellano (es decir, lenguaje natural) la
  mayor parte del tiempo, lo que hace más fácil la
  lectura de los casos de uso y la propuesta de
  cambios.
• La captura de los casos de uso implica a los
  usuarios, a los clientes y a los desarrolladores.

10
Para capturar los requisitos que aportan valor
añadido

• Los usuarios y los clientes son los expertos en
  los requisitos. El papel de los desarrolladores
  es el de facilitar las discusiones y ayudar a los
  usuarios y a los clientes a comunicar sus
  necesidades.
• El modelo de casos de uso se utiliza para
  conseguir un acuerdo con los usuarios y clientes
  sobre qué debería hacer el sistema para los
  usuarios. Podemos pensar en el modelo de casos de
  uso como en una especificación completa de todas
  las formas posibles de utilizar el sistema (los
  casos de uso).
• Esta especificación puede utilizarse como parte
  del contrato con el cliente.
• El modelo de casos de uso nos ayuda a delimitar
  el sistema definiendo todo lo que debe hacer para
  sus usuarios.

Regresar
11
Para dirigir el proceso

• Como hemos dicho, el que un proyecto de
  desarrollo esté dirigido por los casos de uso
  significa que progresa a través de una serie de
  flujos de trabajo que se inician a partir de los
  casos de uso.
• Los casos de uso ayudan a los desarrolladores a
  encontrar las clases.
• Las clases se recogen de las descripciones de los
  casos de uso a medida que las leen los
  desarrolladores, buscando clases que sean
  adecuadas para la realización de los casos de
  uso2.
• Los casos de uso también nos ayudan a desarrollar
  interfaces de usuario que hacen más fácil a los
  usuarios el desempeño de sus tareas.

12
Para dirigir el proceso

• Más adelante, las realizaciones de los casos de
  uso se prueban para verificar que las instancias
  de las clases pueden llevar a cabo los casos de
  uso.
• Los casos de uso no sólo inician un proceso de
  desarrollo sino que lo enlazan, como se muestra
  en la Figura 3.2.
• También tenemos que estar seguros de que
  capturamos los casos de uso correctos de forma
  que los usuarios obtengan los que realmente
  quieren.
• La mejor forma de conseguir esto es, por
  supuesto, hacer un buen trabajo durante el flujo
  de los requisitos.
• Pero con frecuencia no es suficiente.
• Un sistema en ejecución nos permite una
  validación adicional de los casos de uso con las
  necesidades reales del usuario.

13
Para dirigir el proceso

• Los casos de uso ayudan a los jefes de proyecto a
  planificar, asignar y controlar muchas de las
  tareas que los desarrolladores realizan.
• Por cada caso de uso, un jefe de proyecto puede
  identificar unas cuantas tareas.
• Cada caso de uso a especificar es una tarea, cada
  caso de uso a diseñar es una tarea, y cada caso
  de uso a probar es una tarea.
• El jefe de proyecto puede incluso estimar el
  esfuerzo y el tiempo necesario para llevar a cabo
  esas tareas.
• Las tareas identificadas a partir de los casos de
  uso ayudan a los jefes a estimar el tamaño del
  proyecto y los recursos necesarios.

14
Para dirigir el proceso

• Entonces esas tareas pueden asignarse a
  desarrolladores concretos que se hacen
  responsables de ellas.
• Un jefe de proyecto podría hacer responsable de
  la especificación de cinco casos de uso a una
  persona durante el flujo de requisitos, a otra
  responsable de diseñar tres casos de uso y a un
  tercero responsable de especificar los casos de
  prueba para dos casos de uso.

15
Para dirigir el proceso

• Los casos de uso son un importante mecanismo para
  dar soporte a la trazabilidad a través de todos
  los modelos. Un caso de uso en el modelo de
  requisitos es trazable a su realización en el
  análisis y en el diseño, a todas las clases
  participantes en su realización, a componentes
  (indirectamente), y finalmente, a los casos de
  prueba que lo verifican.
• Esta trazabilidad es un aspecto importante de la
  gestión de un proyecto.
• Cuando se cambia un caso de uso, las
  realizaciones, clases, componentes y casos de
  prueba correspondientes tienen que comprobarse
  para ser actualizadas.

16
Para dirigir el proceso

• De igual forma, cuando un componente de
  fichero(código fuente) se modifica, las clases,
  casos de uso y casos de prueba correspondientes
  que se ven afectados también deben comprobarse.
• La trazabilidad entre los casos de uso y el resto
  de los elementos del modelo hace más fácil
  mantener la integridad del sistema y conservar
  actualizado al sistema en su conjunto cuando
  tenemos requisitos cambiantes.

Regresar
17
Para idear la arquitectura y más...

• Para idear la arquitectura y más...
• Los casos de uso nos ayudan a llevar a cabo el
  desarrollo iterativo.
• Cada iteración, excepto quizá la primera de todas
  en un proyecto, se dirige por los casos de uso a
  través de todos los flujos de trabajo, de los
  requisitos al diseño y a la prueba, obteniendo un
  incremento.
• Cada incremento del desarrollo es por tanto una
  realización funcional de un conjunto de casos de
  uso.
• En otras palabras, en cada iteración se
  identifican e implementan unos cuantos casos de
  uso.

18
Para idear la arquitectura y más...
19
Para idear la arquitectura y más...

• Los casos de uso también nos ayudan a idear la
  arquitectura.
• Mediante la selección del conjunto correcto de
  casos de uso los casos de uso significativos
  arquitectónicamente para llevarlo a cabo durante
  las primeras iteraciones, podemos implementar un
  sistema con una arquitectura estable, que pueda
  utilizarse en muchos ciclos de desarrollo
  subsiguientes. (Capítulo 4).
• Los casos de uso también se utilizan como punto
  de partida para escribir el manual de usuario. Ya
  que cada caso de uso describe una forma de
  utilizar el sistema, son el punto de partida
  ideal para explicar cómo puede el usuario
  interactuar con el sistema.

20
Para idear la arquitectura y más...

• Mediante la estimación de la frecuencia de uso de
  los diferentes caminos en los casos de uso,
  podemos estimar qué caminos necesitan el mejor
  rendimiento.
• Esas estimaciones pueden utilizarse para
  dimensionar la capacidad de proceso del hardware
  subyacente o para optimizar el diseño de la base
  de datos para ciertos usos.
• Pueden utilizarse estimaciones parecidas para
  conseguir una buena facilidad de uso,
  seleccionando los caminos más importantes para
  centrarnos en ellos durante el diseño de la
  interfaz de usuario.

Regresar
21
La captura de casos de uso

• Durante el flujo de trabajo de los requisitos
  identificamos las necesidades de usuarios y
  clientes como requisitos.
• Los requisitos funcionales se expresan como casos
  de uso en un modelo de casos de uso, y los demás
  requisitos o bien se "adjuntan" a los casos de
  uso a los que afectan, o bien se guardan en una
  lista aparte o se describen de alguna otra forma.

22
La captura de casos de uso

• El modelo de casos de uso representa los
  requisitos funcionales
• El modelo de casos de uso ayuda al cliente, a los
  usuarios y a los desarrolladores a llegar a un
  acuerdo sobre cómo utilizar el sistema.
• La mayoría de los sistemas tienen muchos tipos de
  usuarios.
• Cada tipo de usuario se representa mediante un
  actor. Los actores utilizan el sistema al
  interactuar con los casos de uso.
• Todos los actores y casos de uso del sistema
  forman un modelo de casos de uso.

23
La captura de casos de uso

• Un diagrama de casos de uso (Sección 7.4.1)
  describe parte del modelo de casos de uso y
  muestra un conjunto de casos de uso y actores con
  una asociación entre cada par actor/caso de uso
  que interactúan (véase la Figura 3.3).

Regresar
24
Ejemplo, Un modelo de casos de uso para un
sistema de cajero automático (CA)
El actor Cliente de Banco utiliza un sistema CA
para retirar e ingresar dinero desde y en
cuentas, y para transferir dinero entre cuentas.
Esto se representa por los tres casos de uso que
se muestran en la Figura 3.3, que poseen
asociaciones con el actor para indicar su
interacción.
Regresar
25
La captura de casos de uso

• Los actores son el entorno del sistema
• No todos los actores representan a personas.
  Pueden ser actores otros sistemas o hardware
  externo que interactuará con el sistema.
• Cada actor asume un conjunto coherente de papeles
  cuando interactúa con el sistema.
• Un usuario físico puede actuar como uno o varios
  actores, desempeñando los papeles de esos actores
  en su interacción con el sistema.
• Varios usuarios concretos pueden actuar como
  diferentes ocurrencias del mismo actor. Por
  ejemplo, puede haber miles de personas que actúan
  como el actor Cliente de Banco.

26
La captura de casos de uso

• Los actores se comunican con el sistema mediante
  el envío y recepción de mensajes hacia y desde el
  sistema según éste lleva a cabo los casos de uso.
  
• A medida que definimos lo que hacen los actores y
  lo que hacen los casos de uso, trazaremos una
  clara separación entre las responsabilidades de
  los actores y las del sistema.
• Esta separación nos ayuda a delimitar el alcance
  del sistema.
• Podemos encontrar y especificar todos los actores
  examinando a los usuarios que utilizarán el
  sistema y a otros sistemas que deben interactuar
  con él.
• Cada categoría de usuarios o sistemas que
  interactúan se representan por tanto como actores.

27
La captura de casos de uso

• Los casos de uso especifican el sistema
• Los casos de uso están diseñados para cumplir los
  deseos del usuario cuando utiliza el sistema.
• El modelo de casos de uso captura todos los
  requisitos funcionales del sistema. Definiremos
  un caso de uso de manera precisa como sigue
• Un caso de uso especifica una secuencia de
  acciones, incluyendo variantes que el sistema
  puede llevar a cabo, y que producen un resultado
  observable de valor para un actor concreto.
• Identificamos los casos de uso examinando cómo
  los usuarios necesitan utilizar el sistema para
  realizar su trabajo.

28
La captura de casos de uso

• Cada uno de esos modos de utilizar el sistema que
  añaden valor al usuario es un caso de uso
  candidato.
• Estos candidatos se ampliarán, se cambiarán, se
  dividirán en casos de uso más pequeños, o se
  integrarán en casos de uso más completos.
• El modelo de casos de uso está casi terminado
  cuando recoge todos los requisitos funcionales
  correctamente de un modo que puedan comprender
  los clientes, usuarios y desarrolladores.
• La secuencia de acciones realizada por un caso de
  uso durante su operación (es decir, una instancia
  del caso de uso) es un camino específico a través
  del caso de uso.

29
La captura de casos de uso

• Puede haber muchos caminos, muchos de ellos muy
  parecidos son variantes de la ejecución de la
  secuencia de acciones especificada en el caso de
  uso.
• Para hacer que un modelo de casos de uso sea más
  comprensible, podemos agrupar descripciones de
  caminos variantes parecidas en un solo caso de
  uso. Cuando decimos que identificamos y
  describimos un caso de uso, realmente estamos
  diciendo que identificamos y describimos los
  diferentes caminos que es práctico definir como
  un solo caso de uso.

Regresar
30
Ejemplo, El caso de uso sacar dinero

• La secuencia de acciones para un camino a través
  de este caso de uso es (de forma muy
  simplificada)
• El Cliente del Banco se identifica.
• El Cliente del Banco elige de qué cuenta sacar
  dinero y especifica qué cantidad.
• El sistema deduce la cantidad de la cuenta y
  entrega el dinero.

31
La captura de casos de uso

• Los casos de uso también se utilizan como
  "contenedores" de los requisitos no funcionales
  (Capítulo 6), tales como los requisitos de
  rendimiento, disponibilidad, exactitud y
  seguridad que son específicos de un caso de uso.
• Por ejemplo, puede asociarse al caso de uso Sacar
  Dinero el siguiente requisito el tiempo de
  respuesta para un Cliente de Banco medido desde
  la selección de la cantidad a sacar hasta la
  entrega de los recibos debe ser menor de 30
  segundos en el 95 por ciento de los casos.

32
La captura de casos de uso

• Resumiendo, todos los requisitos funcionales
  quedan atados mediante casos de uso, y muchos de
  los requisitos no funcionales pueden asociarse a
  los casos de uso.
• De hecho, el modelo de casos de uso es un
  vehículo para organizar los requisitos de un modo
  fácil de gestionar.
• Clientes y usuarios pueden comprenderlo y
  utilizarlo para comunicar sus necesidades de un
  modo consistente y no redundante.
• Los desarrolladores pueden dividir el trabajo de
  captura de requisitos entre ellos, y después
  utilizar los resultados (fundamentalmente los
  casos de uso) como entrada para el análisis,
  diseño, implementación y prueba del sistema.

Regresar