Requerimientos basados en casos de uso

Los usuarios, cuando utilizan una aplicación lo hacen con un propósito en mente. Siempre esperan obtener algo concreto de la aplicación como:

  • Registrar un nuevo pedido
  • Calcular el total vencido
  • Ver la colección de canciones
  • Enviar un correo, etc.

Actores

Los usuarios se pueden clasificar, desde el punto de vista de un software, en roles o grupos de personas que esperan cosas particulares de la aplicación. Un Actor representa un rol de un usuario. Identificar los Actores es el primer paso para identificar qué se espera de la aplicación.

Un actor puede ser cualquier cosa con comportamiento, como una persona (identificada por un rol), un sistema informatizado o una organización. La misma persona física puede interpretar varios roles como actores distintos. Es importante que el nombre del actor describa el papel desempeñado.

Identificación de los Actores

Para identificar los actores, es útil hacerse las siguientes preguntas:

  • ¿Cuáles usuarios el sistema apoya para desarrollar su trabajo?
  • ¿Cuáles usuarios ejecutan las funciones principales del sistema?
  • ¿Cuáles usuarios desempeñan funciones secundarias, como mantenimiento y administración?
  • ¿El sistema interactua con algún sistema externo o software?

Ejemplo

Este ejemplo, ilustra los actores principales que utilizan el sistema Banner en la Uniandes. Cada actor tiene propósitos distintos. Por ejemplo, el usuario en el rol de Estudiante (actor Estudiante) está interesado en ver sus notas de un curso, mientras que el actor Profesor está interesado en registrar las notas de sus estudiantes:

Caso de uso

El objetivo de un caso de uso es el de capturar el comportamiento deseado del sistema en desarrollo sin tener que especificar cómo se implementa este comportamiento. Un caso de uso es una interacción especifica entre un usuario y la aplicación para que el usuario obtenga un resultado concreto. Para que un servicio de la aplicación sea considerado un caso de uso, debe haber interacción entre un Actor y el sistema. En esta interacción hay un intercambio de información y al final debe ser claro qué obtuvo el usuario

Los casos de uso proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una comprensión común del sistema.

Diagrama de casos de uso

El objetivo es identificar los casos de uso por actor y representarlos en un diagrama de casos de uso. Un caso de uso se representa con un circulo y su nombre en él. Un actor se representa con una figura que representa el actor.

El nombre del caso de uso debe ser claro y permitir identificar el servicio que ofrece el sistema.

El siguiente es tal vez el ejemplo más popular de casos de uso: Un cajero automático. En el diagrama de casos de uso hay tres actores: el banco, el cliente del banco y alguien de mantenimiento. Tanto el banco como el cliente del banco utilizan el sistema para retirar dinero en efectivo, transferir fondos y depositar fondos.

El nombre un caso de uso debe comenzar por un verbo en infinitivo y luego tener palabras complementarias definidas en el contexto del problema que aclaren el propósito del caso de uso. Ejemplos de malos nombres de casos de uso porque no dan una idea clara del propósito concreto del caso de uso:

  • Manejar datos: qué es manejar y a qué datos se refiere?
  • Reportar información: reportar a quién, qué, cuál información?

Ejemplos de buenos nombres de casos de uso:

  • Registrar las notas finales de un curso (Banner. Actor: Profesor)
  • Retirar dinero de un cajero automático
  • Comprar un libro

Especificación de los Casos de Uso

Nombre del Caso de Uso

Como ya mencionamos, para el nombre del caso de uso, se utilizan verbos en infinitivo que representan las acciones del usuario con el sistema. Siempre debe existir un tipo de usuario (Actor) que lo utilice (al menos uno).

Actor o Actores

Rol de los usuarios que ejecutan el caso de uso.

Resumen

Es una frase que aclara el resultado que obtendrá el actor al finalizar el caso de uso.

Curso básico de eventos

La especificación del caso de uso es una descripción de un conjunto de secuencias de acciones, incluyendo escenarios o variantes, que ejecuta un sistema y un Actor para producir un resultado observable de valor para el Actor. Puede haber distintos tipos de secuencias en el mismo caso de uso, se pueden clasificar en dos grupos:

  1. Todo sale bien y el caso de uso se termina con éxito o
  2. Algo no sale bien y el caso de uso debe interrumpirse con una excepción.

En el flujo de eventos o secuencia de acciones, en cada paso debe ser claro quién realiza la acción: el Actor o el sistema.

El Flujo de eventos principal o curso básico de eventos, se refiere a la secuencia de interacciones entre el Actor y el sistema y donde el caso de uso termina con éxito. El siguiente ejemplo muestra la especificación de un curso básico de eventos o escenario de un caso de uso exitoso. Contiene un Nombre, Actor, Resumen y el curso básico de eventos:

Nombre del escenario Consultar listado de estudiantes de un curso
Actor Profesor
Resumen Dando el semestre y el código del curso, el profesor obtiene la lista de estudiantes inscritos en él.
Curso básico de eventos
1. El Profesor ingresa al sistema indicando sus datos.
2. El sistema despliega cada una de las posibilidades del sistema.
3. El Profesor indica que quiere sacar un listado de un curso.
4. El sistema solicita ingresar la información del código, sección y semestre de la materia.
5. El Profesor ingresa 21251, 02, 2018-1.
6. El sistema devuelve la información correspondiente al curso indican el nombre, carnet, carrera y correo electrónico de cada uno de los alumnos.

Como el objetivo de especificar el caso de uso es entender cuál es el servicio que se debe desarrollar, es importante que en las acciones del flujo de eventos se defina claramente la información que se intercambia. Si, por ejemplo, en el paso 4 especificáramos: "solicita ingresar la información" , el caso de uso estaría mal especificado por incompleto porque no hay forma de saber a cuál información se refiere.

Un error común al definir los casos de uso es utilizar frases como "El usuario ingresa los datos". Está mal porque no se puede saber a qué datos se refiere ni cuáles son las características de esos datos.

Eventos de excepción

Un evento de excepción durante un flujo de eventos implica que el caso de uso se termina sin que el usuario obtenga lo esperado. Esto puede ocurrir porque el Actor cancela el caso de uso o porque ingresa información inválida que no permite continuar. En este caso, se debe indicar claramente qué sucede en el caso de uso. En el ejemplo anterior, en el paso 5, si el Profesor no ingresa un semestre y sección válidos y un código de curso válidos, el sistema debe informar el error hasta que sea corregido o hasta que el Actor cancele el caso de uso. Se especifica de la siguiente forma:

Nombre del escenario Consultar listado de estudiantes de un curso
Actor Profesor
Resumen Dando el semestre y el código del curso, el profesor obtiene la lista de estudiantes inscritos en él.
Curso básico de eventos
1. El Profesor ingresa al sistema indicando sus datos.
2. El sistema despliega cada una de las posibilidades del sistema.
3. El Profesor indica que quiere sacar un listado de un curso.
4. El sistema solicita ingresar la información del código, sección y semestre de la materia.
5. El Profesor ingresa 21251, 02, 2018-1.
6. El sistema devuelve la información correspondiente al curso indican el nombre, carnet, carrera y correo electrónico de cada uno de los alumnos.
Caminos de excepción En el paso 4. Si el Actor ingresa información del semestre, curso o sección inválidos, el sistema debe informar claramente el error y pedir de nuevo la información.

Otro ejemplo de un camino de excepción lo tenemos en un caso de uso del cajero automático donde podemos especificar el comportamiento del sistema de la siguiente forma:

... ...
Flujo de eventos excepcional
Paso 4: Si el cliente introduce un código de seguridad inválido, el caso de uso vuelve a empezar.
Paso 4: Si el cliente introduce tres veces seguidas un código de seguridad inválido, el sistema cancela la transacción completa, impidiendo que el Cliente utilice el cajero durante 24 horas.

El propósito de especificar los caminos de excepción es aclarar cómo se manejarán las acciones erróneas del usuario en la aplicación; cómo responder y cómo debe comportarse la aplicación a partir de ese momento. Esta información será muy útil en la etapa de diseño para considerar adecuadamente la realimentación que se le da al usuario en caso de problemas en la interacción con la aplicación.

Pre-condiciones en los casos de uso

Muchas veces es importante definir el estado de la aplicación antes de iniciar el caso de uso. Este estado o más bien, lo que es válido en este estado es lo que llamamos pre condición. Son supuestos que de no ser válidos el caso de uso no podrá tener lugar.

En la siguiente tabla modificamos el caso de uso de banner para incluir como supuesto o pre condición que el profesor ya se encuentra autenticado correctamente en el sistema y tiene permisos para ejecutar este caso de uso.

Nombre del escenario Consultar listado de estudiantes de un curso
Actor Profesor
Resumen Dando el semestre y el código del curso, el profesor obtiene la lista de estudiantes inscritos en él.
Pre condición El profesor ya se encuentra autenticado correctamente en el sistema y tiene permisos para ejecutar este caso de uso.
Curso básico de eventos
...

Post condiciones en los casos de uso

Las post condiciones sirven para precisar el estado de la aplicación cuando el caso de uso termina de manera exitosa. Es importante definirlas cuando el caso de uso cambia el estado de la aplicación.

Relaciones entre casos de uso

Relación include

Indica que en el flujo de eventos del caso de uso base se incluye el comportamiento del otro caso de uso. Esta relación sirve para Factorizar comportamiento común (NO hacer descomposición funcional) SOLAMENTE se hace cuando la parte común es utilizada por otro caso de uso o cuando es utilizada por otro actor.

Relación extend

Un caso de uso extiende otro caso de uso, si el caso de uso extendido incluye el comportamiento del otro bajo ciertas condiciones. Se utiliza para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. Por ejemplo cuando retiramos dinero de un cajero automático, el caso de uso "Pedir Donación" extiende el caso de uso "Retirar Dinero".

Más información.

Generalizar/especializar casos de uso

Esta relación se utiliza cuando tenemos distintas formas de implementar en la interfaz usuario un caso de uso esto es, hay una interacción distinta en cada caso entre el sistema y el Actor. Por ejemplo en el caso de uso " Autenticar un usuario en el sistema", esta autenticación puede hacerse de maneras distintas: con un password, con la lectura de la huella digital. Esto se representa en el diagrama así:

Decimos que el caso de uso Autenticar Usuario es una generalización de los casos de uso Autenticar usuario con password y de Autenticar usuario con huella digital. También decimos que Autenticar usuario con password es una especialización de Autenticar Usuario.

results matching ""

    No results matching ""