casos de uso

Casos y Cosas de Casos de Uso
Por Efraín Cordero
Whitepaper – Marzo 2013

Introducción
Desde su propuesta original en los trabajos de Ivar Jacobson, los casos de uso se han convertido en una de las
herramientas fundamentales para el levantamiento de requerimientos en la industria de desarrollo de software.
Como apunta Susan Lilly: “una de las bellezas de los casos de uso es su formatoinformal y accesible. Los casos de
uso son fáciles de escribir, y su notación gráfica es trivial”. Sin embargo, también como Lilly deja ver, esa aparente
sencillez puede dar lugar a la idea equivocada de que hacer buenos casos de uso (y buenos modelos de casos de
uso) es una labor simple, y peor aún: que con ellos se puede documentar TODOS los tipos de requerimientos.
Múltiples autores comoAllistair Cockbourn. Ellen Gottesdiener y la misma Susan Lilly se han dado a la tarea de
describir errores típicos que se cometen al desarrollar casos de uso. El objetivo de este Whitepaper es retomar
algunos de los errores que plantean, agregar algunos nuevos y brindar algunas propuestas de solución. Esperemos
que sea de utilidad para el lector. ¡Comencemos!

Primero lo Primero
Antes de entrar enmateria, es necesario hacer algunas precisiones respecto a la terminología de los casos de uso.
He encontrado que algunas personas confunden el término con las representaciones gráficas, lo cual contribuye a
hacer más complicado el entendimiento.
De acuerdo con Wikipedia, un caso de uso es “[...] una lista de pasos, típicamente definiendo interacciones entre un
rol (conocido en UML como un"actor") y un sistema, para lograr un objetivo”. Bajo esta definición:
Esto es un caso de uso:
Caso de Uso: Realizar “X” Acción
Objetivo: ...
Actores: Actor X
Flujo Básico:
1 El actor X hace ...
2 El sistema hace …
3 ---

No esto:

Ni tampoco esto:

(Ícono de caso de uso)

(Diagrama de caso de uso)

Tabla 1. Comparación entre un caso de uso y sus representaciones visuales.
Un casode uso normalmente se maneja como una narrativa1. Los íconos y los diagramas de casos de uso son
representaciones visuales cuyo objetivo es ayudar a formar rápidamente una idea del panorama general del
requerimiento, pero nunca entrando al detalle de cada caso de uso. Es increíble, pero se llega a encontrar quien
dice haber definido los casos de uso de un sistema y entrega únicamente los“diagramas de bolitas” (i.e. los
diagramas de casos de uso). Un diagrama de casos de uso sin las narrativas no es útil. Equivale a tener un simple
listado de funcionalidades.

1

Es posible especificar el detalle de un caso de uso mediante diagramas UML de actividades, de máquina de estados o de interacción.

Casos y Cosas de Casos de Uso
Por Efraín Cordero
Whitepaper – Marzo 2013

Otropunto de confusión es el formato a usar para plasmar la narrativa. A este respecto, es necesario indicar que
no existe un estándar definido. Algunos autores como Allistair Cockburn proponen múltiples formatos
dependiendo del contexto en que el caso de uso se genera. Lo verdaderamente importante en este sentido es que
el equipo de trabajo seleccione desde el inicio el o los formatos a usar y serespeten por todo el ciclo de vida del
sistema. En la mayoría de los sistemas en los que he participado, un solo formato ha sido suficiente.
El último concepto a considerar es el de “modelo de casos de uso”. Un error común (fomentado por usar
exclusivamente las bondades gráficas de las herramientas de modelado UML) es considerar que dicho modelo
comprende únicamente los diagramas de casos de uso.En realidad, dicho modelo está conformado por las
narrativas, las descripciones de los actores (sí, las descripciones. El puro nombre no basta, y menos cuando el
nombre es demasiado genérico como “Empleado” o “Usuario”), los diagramas de casos de uso, y los mecanismos
utilizados para agruparlos (típicamente paquetes de UML). Este último punto se revisará más adelante.

Caso 1: Reordenando...