En UML, un caso de uso se representa mediante un óvalo cuyo nombre aparece debajo o dentro de él. Por el contrario, los actores se simbolizan mediante monigotes. La relación entre un actor y un caso de uso se establece mediante una flecha que parte del actor, tal y como se puede ver en la siguiente figura:

Por el contrario, la flecha parte del caso de uso para expresar una relación entre un caso de uso y un actor de apoyo.

Los diagramas UML que muestran la relación entre los actores y los casos de uso se denominan diagramas de casos de uso y son una alternativa gráfica a la representación tabular.

En lugar de trazar ocho flechas desde el actor principal hasta los casos de uso y otras ocho desde los casos de uso hasta el actor de apoyo, es posible encerrar los casos de uso en un rectángulo que representa el límite del sistema y emplear únicamente un par de flechas.

Especificación de los casos de uso

Una vez que se han identificado los actores y los casos de uso, se procede a detallarlos. Al detallar un caso de uso se explica qué hace el sistema al interactuar con un actor determinado y puede hacerse de tres modos distintos: el modo resumen, el modo ordinario y el modo formal. El primero permite una especificación más relajada y los dos siguientes se tornan más estrictos y serios, especialmente el último. La elección de un modo u otro dependerá del tipo de proyecto y del caso de uso seleccionado.

Aunque homogeneizar la forma de detallar los casos de uso facilita la comunicación ─pues el equipo aprende más rápidamente qué debe escribir─ no es la vía más productiva. El formato de un caso de uso debe elegirse de acuerdo a los riesgos y las preferencias del cliente y el equipo.

Si se trabaja en un proyecto donde el producto es de carácter crítico ─podría poner en riesgo la vida de las personas─, parece obvio que todos los casos de uso deberían detallarse empleando el modo formal. Dominios como la aviación civil o la energía nuclear son típicos para esta elección. La especificación formal de un caso de uso puede requerir de tres a cinco semanas de trabajo, pero este alto coste merecerá la pena. Lo cierto es que para proyectos de esta índole habrá poco o ningún margen de duda para elegir el modo, pues el cliente no aceptará un formato menos riguroso.

Por el contrario, al trabajar en un pequeño proyecto cuyo dominio es familiar a todos los miembros del equipo, un equipo formado por cuatro o cinco personas que tienen una gran experiencia desarrollando software similar, es perfectamente viable optar por el modo resumen. El coste adicional de los otros dos modos en absoluto merecerá la pena. Es un gran error obsesionarse con detallar casos de uso de forma rigurosa cuando no hace falta; supondrá un desperdicio de tiempo y dinero para el proyecto.

Entre estos dos tipos extremos de proyectos están aquellos de tamaño mediano y complejidad media. En casos así, el modo ordinario puede ser más el más eficiente. No obstante, el modo seleccionado no tiene por qué ser el único empleado en todo el proyecto, pues también depende del caso de uso que se esté detallando.

Puede ser una buena opción detallar formalmente aquellos casos que se identifiquen como un riesgo para el desarrollo del sistema o para esos otros que sean claves para definir la arquitectura, es decir, los casos de uso principales. Para el resto puede rebajarse el nivel de formalismo. Si hay que detallar casos cuando la arquitectura ha alcanzado un nivel aceptable de estabilidad o si pertenecen a una «familia» donde el primero de ellos ya está especificado formalmente, el modo resumen puede ser más que suficiente.

No se debe desperdiciar tiempo y energía en detallar casos de uso de manera formal cuando el equipo puede llegar a tener claro cómo realizarlos con una breve descripción. Si al detallar un caso en modo resumen, surgen dudas o no queda suficientemente claro, siempre se puede aumentar su rigor adoptando alguno de los otros dos.

Antes de entrar a explicar los diferentes modos es necesario exponer dos conceptos muy importantes vinculados a los casos de uso: los escenarios y las extensiones.

Escenarios y extensiones

Se denomina escenario a una secuencia concreta de acciones y escenario principal a aquel que sirve al actor para alcanzar su objetivo. En el ejemplo del caso de uso «Efectuar reintegro», los pasos 1 al 12 comprenden el escenario principal.

Sin embargo, un caso de uso suele tener más escenarios porque es necesario considerar los posibles fallos y variantes que pudieran acaecer. A este tipo de escenarios se les denomina extensiones. Un caso de uso puede tener muchas extensiones y es conveniente realizar un esfuerzo importante para tenerlas todas en cuenta. No hacerlo podría implicar que los ingenieros malinterpretasen la forma en que funciona el sistema.

Caso de uso: Efectuar reintegro.
Actor principal: Usuario.
Pasos:
 1. El usuario introduce la tarjeta. 
 2. El cajero valida la tarjeta.
 3. El usuario introduce su número de identificación personal (PIN).
 4. El cajero valida el PIN.
 5. El usuario introduce una cantidad de dinero.
 6. El cajero valida la cantidad.
 7. El usuario confirma la cantidad.
 8. El cajero descuenta la cantidad del saldo.
 9. El cajero entrega el dinero.
10. El usuario retira el dinero.
11. El cajero expulsa la tarjeta.
12. El usuario retira la tarjeta.
Extensiones:
4a. El cajero rechaza el PIN.
    4a1. Ir al paso 11.

La extensión formada por los pasos 1, 2, 3, 4a, 4a1 y 10 crea otro escenario. La extensión propiamente dicha, es decir, los pasos 4a y 4a1 realmente es un caso de uso reducido que comienza con un paso que describe la condición que lo hace relevante y que podría darle nombre: «PIN inválido». Tras la condición, se enumeran los pasos que describen lo que sucede terminando con el objetivo de la extensión: devolver la tarjeta al cliente.

Las extensiones son todas las variantes del escenario principal ejecutadas bajo una condición particular. Dicha condición es una que el sistema es capaz de detectar y bajo la cual se comporta de manera diferente. Una extensión se puede leer como «no es cierto que [paso del escenario principal] sino que [primer paso de la extensión]», es decir, «no es cierto que el cajero valida el PIN sino que el cajero rechaza el PIN».

Los requisitos del sistema más interesantes y menos obvios forman parte de las extensiones. El escenario principal suele ser fácil de escribir ─pues lo conocen todos los interesados─ pero no así las condiciones de error, ya que a menudo requieren de una investigación y una participación activa del cliente o usuario. Este ejercicio puede dar lugar a la aparición de nuevos actores o nuevos casos de uso.

El proceso para obtener todas las extensiones de un caso de uso debe realizarse en equipo y con el apoyo del cliente. Cockburn [1] enumera una serie de formas en las que el escenario puede fallar, que he convertido en preguntas a realizar en los talleres o reuniones de requisitos junto con ejemplos relativos al caso del cajero automático:

• ¿Existe algún camino alternativo para cumplir el objetivo del actor? Al usuario del cajero se le puede dar más de una oportunidad para escribir el PIN correctamente.
• ¿Cómo reaccionaría el sistema si el actor se comportara de manera incorrecta? Hay que tratar casos como que el usuario solicite una cantidad de dinero fraccionada como 37 €.
• ¿Qué sucedería si el actor tardara demasiado en actuar? El cajero debe estar preparado por si el usuario introduce la tarjeta y no reacciona.
• ¿Qué pasaría si no se cumplieran los pasos que enuncian validaciones? Este suele ser el punto más obvio para crear una extensión como la que aparece en el ejemplo anterior.
• ¿Qué ocurriría si se produjera un fallo del sistema por causas ajenas al mismo? El cajero debe contemplar un atasco de la tarjeta o la pérdida de conexión con la computadora central.
• ¿Qué sucedería si se produjera un fallo inesperado del sistema? ¿Cómo se van a tratar los errores del software?
• ¿Qué pasaría si de produjera un fallo de rendimiento del sistema? El cajero debe tener en cuenta una posible degradación de la velocidad de conexión con la computadora central.

En resumen, si se tiene la necesidad de escribir en un paso del escenario principal algo como si pasa esto entonces…, eso es una extensión, no un paso. Jamás debe aparecer la conjunción si en un paso de un escenario. Este error es muy común y muy grave pues conduce a detallar incorrectamente los casos de uso.

Teniendo en mente qué son los escenarios y las extensiones, a continuación se expondrán los diferentes modos de detallar los casos.

El modo resumen

Este modo consiste es escribir un párrafo que describa el comportamiento del caso de uso ─el escenario principal─ y, si se cree conveniente, los fallos más significativos.

Caso de uso: Efectuar reintegro
El usuario llega al cajero e inserta la tarjeta que el cajero valida. Una vez ha introducido el PIN correcto, el cliente introduce y confirma la cantidad de dinero deseada que el cajero entrega junto con la tarjeta.

Este modo es útil para hacerse una idea rápida del objetivo del actor o para detallar casos que durante el transcurso del proyecto se convierten en obvios. Puede emplearse tanto para casos de uso secundarios como para un primer acercamiento a los casos de uso principales. En las primeras reuniones de requisitos se pueden escribir resúmenes para discutir con el equipo si un determinado caso de uso debe comportarse ─más o menos─ de la manera descrita. Posteriormente, se podrá aumentar el nivel de formalismo para aquellos casos donde un mero resumen se considere insuficiente, como suele suceder con los casos de uso principales. Se suele tardar solo unos minutos en escribir un resumen.

Referencias

[1] Alistair Cockburn. Writing Effective Use Cases. Addison Wesley, 2001.

Fotografía de la entrada creada por Freepik