Casos de Uso

Los Casos de Uso

Los Casos de Uso son los escenarios que se pueden presentar en el sistema, son el corazón del diseño y se obtienen de la especificación funcional.

La especificación funcional es platicada, cómo contarle a un colega como funciona el sitema. Los Casos de Uso son tables, separando esta plática en partes, manteniendo simplicidad.

Los Casos de Uso son escenarios, desde el punto de vista del usuario, sobre lo que puede hacer en el sistema, el orden en el que acontecen los eventos y los diferentes caminos que se pueden tomar. Simplemente los escribes o bocetas y luego los vacías en tablas.

Tal como la especificación funcional, responde las seis preguntas maestras:

¿Que? ¿Quién? ¿Cómo? ¿Cuándo? ¿Dónde? ¿Por qué?

¿Qué? es el título, el nombre del escenario, del Caso de Uso, ¿Qué está haciendo el usuario?

¿Quién? es el rol del usuario que está realizando las acciones (el administrador, el cliente, el que solo ve reportes, etc.)

¿Cómo? Son los pasos que tiene que realizar para llevar a cabo la actividad.

¿Cuándo? y ¿Dónde? Son las condiciones que se tienen que cumplir para que se lleve a cabo el Caso de Uso, les llamaremos Pre Condiciones.

¿Por qué? es la razón escencial por la cuál se lleva a cabo el caso de uso, es el resumen, la descripción del mismo.

Los Diagramas

Son los clásicos “monitos”, simplemente es un garabato representando a una persona con sus acciones en forma de globos y una flechita para indicar que el usuario puede utilizarlos.

Una línea punteada de un caso de uso a otro significa “extender” y es un flujo alternativo del mismo. Un flujo alternativo es otro camino que puede tomar el caso de uso, cuando ocurre una desición. En el ejemplo, al dar de alta un usuario, puede ser que el usuario ya exista, entonces el sistema responde al usuario de diferente manera.

Por simplicidad, el primer caso de uso, del cual se extienden los demás, es el conocido “happy path”, en el que todo sale bien y sin contratiempos. Todo lo que pueda salir mal, causar contratiempo o tenga dependencia de una desición es una extensión del caso de uso inicial, un flujo alternativo.

El ejemplo

Los casos de uso no solo son los diagramas, lo importante es escribirlos de forma tabular para que sean fáciles de leer.

El punto fundamental aqui es la lista de pasos a seguir en el caso de uso, estos deben estar listados y escribirse en forma protocolaria, es decir, una comunicación entre dos partes: El usuario y el sistema. Se entiende mejor con un ejemplo:

Caso de Uso

Título	Alta de usuario
Actor	Administrador de Sistema
Resumen	El administrador necesita dar de alta un nuevo usuario
Precondiciones	El administrador ha iniciado sesión con sus credenciales.
Pasos
1	Administrador: Elije la opción “Nuevo usuario”
2	Sistema: Solicita se capture la información del usuario: Email, Nombre, Rol.
3	Administrador: Captura la información solicitada
4	Sistema: Valida la información registrada.
5	Sistema: Registra al nuevo usuario.
6	Sistema: Muestra al usuario administrador un mensaje de éxito.
Resultado	El administrador ha creado un nuevo usuario con éxito

Flujo Alternativo 1: El usuario ya está dado de alta.

Título	Alta de usuario: Usuario ya se encuentra en el sistema.
Actor	Administrador de Sistema
Resumen	El administrador necesita dar de alta un nuevo usuario, sin embargo, este ya se encuentra registrado en el sistema.
Precondiciones	El administrador ha iniciado sesión con sus credenciales.
Pasos
4.1	Sistema: Encuentra que el usuario ya ha sido registrado.
4.2	Sistema: Informa del error al usuario mediante un mensaje.
4.3	Administrador: Cancela la operación
Resultado	El administrador no pudo crear un nuevo usuario, este ya se encontraba registrado en el sistema

Como podemos ver, el flujo alternativo es una extensión del flujo principal, en el cual por una condición podemos llegar a otro resultado.

Hacer los diagramas es muy sencillo, puedes usar cualquier programa de gráficos, desde Power Point hasta MS Visio. Mi favorito es Dia, para hacer diagramas, tiene muchas preplantillas, hay versión portable, es ligero y sencillo.

Sin embargo, no es necesario instalar nada, el pequeño diagrama que ves lo realicé con Google Docs.

Un punto muy importante a destacar es que documentar normalmente es percibido como un proceso doloroso. Yo mismo lo sufrí mucho tiempo, pero no tiene que ser así, lo mejor es expresarte lo más sencillo que puedas y mantener el foco en el resultado final: La comunicación de ideas.

Esto es especialmente difícil cuando trabajas en una empresa altamente burocratizada donde tienes que seguir formatos que parecen hechos por tu peor enemigo, en donde todo, desde tablas hasta documentos y gráficos los tienes que poner en Excel.

Créeme, esto lo sufrí sobremanera. Pero siempre es mejor tener documentación a no tenerla, y nada facilita más el trabajo de los programadores que unos casos de usos completos y detallados pero simples.