Casos y Cosas de los Casos de Uso

Reordenando racimos de uvas

Es común encontrar sistemas con varias decenas o incluso cientos de casos de uso. Intentar representar todos estos casos en unos pocos diagramas no es muy útil ya que debido al exceso de elementos se complica el entendimiento del alcance. Los diagramas dan la apariencia de contener racimos de uvas que amenazan derramarse de tanto peso.

Para solventar esta situación, una estrategia es establecer un criterio de subdivisión del modelo y fragmentar los diagramas saturados. El criterio normalmente proviene del negocio, y pueden ser roles, áreas de la empresa, áreas de proceso, prioridades, etc. Por ejemplo, si el criterio fuera “Roles” y como tales hubiera “Cajero”, “Contador”, etc., por cada uno de ellos se crea un paquete y en él se colocan los elementos que le correspondan. Este mecanismo facilita la comprensión del alcance, enfoca las revisiones con usuarios, permite establecer prioridades y simplifica las búsquedas de elementos.

Un hermoso martillo dorado

Un “martillo dorado” se refiere a abusar del uso de cierto recurso o herramienta, queriendo aplicarla incluso en problemas para los que no está diseñada. Veamos el siguiente caso de uso:

Caso de Uso: Generar Reporte X.
Objetivo: Generar y desplegar el reporte X.
Actores: Actor X.
Flujo Básico:


1. El actor X indica al sistema que desea consultar el reporte X.
2. El sistema permite al actor X indicar los valores para filtrar el reporte.
3. El actor X proporciona los valores a usar para filtrar el reporte.
4. El actor X solicita al sistema que genere el reporte.
5. El sistema genera el reporte y lo muestra al actor X.
Flujo Alterno: Información no existente

 5.1 El sistema determina que no hay información y lo notifica al actor X.

 5.2 Regresa al paso 3 del flujo básico.

¿Qué tiene de malo el caso de uso anterior? Describe la interacción completa de un usuario con el sistema, el objetivo es claro, y la secuencia de pasos parece lógica. El problema es que en casos como este, lo más importante es la información que debe contener el reporte, cómo se obtiene y se despliega, y el caso de uso no dice nada sobre esto.

El siguiente ejemplo muestra un extremo de esta situación:

Caso de Uso: Ejecutar Proceso Z
Objetivo: Que el proceso Z sea ejecutado.
Actores: Actor X
Flujo Básico:


1. El actor X indica al sistema que ejecute el proceso Z.
2. El sistema ejecuta el proceso Z.

¿En situaciones como estas agrega algún valor tener casos de uso? Los casos de uso son útiles cuando hay gran interacción entre el actor y el sistema, pero cuando no es así o la cantidad de reglas es abrumadora (ej. procesos batch, interfaces B2B), es mejor considerar otras alternativas. Gottesdiener proporciona una lista de opciones para documentar diferentes tipos de requerimientos tales como diagramas de estado, mapas de procesos, prototipos y modelos de datos. Para situaciones donde hay una gran cantidad de reglas, la opción es extraerlas de la narrativa y colocarlas en anexos o documentos separados, dejando en la narrativa las correspondientes referencias.

A ritmo de “copy-paste”

Imaginemos un caso de uso de registro de elementos en un catálogo, que tendría un flujo básico similar al siguiente:

1. El actor X indica al sistema que desea registrar un elemento X.
2. El sistema despliega la forma de registro para un elemento X.
3. El actor X llena la forma de registro e indica al sistema que desea proceder con el registro.
4. El sistema revisa que la información proporcionada sea válida.
5. El sistema registra el elemento X.

Es muy posible que para todos los catálogos simples el proceso de inserción sea muy similar al descrito, por lo que el equipo seguramente tomará la decisión de usarlo como “plantilla base”. Por tanto, si el sistema comprende 50 catálogos, se generarán 49 clones donde lo único que difiere es el nombre del “elemento X”. Esto se repetirá para consulta, modificación y eliminación, por lo que se tendrán 196 narrativas creadas a partir de las 4 base, para un total de 200 elementos.

Más que cuestionar la validez del tratamiento anterior, la pregunta es ¿realmente será útil para el equipo lidiar con 200 documentos que dicen prácticamente lo mismo? ¿Y para el cliente? ¿Ese tipo de documentación realmente le sirve?

Aunque para los diagramas basta con manejar relaciones de generalización, para las narrativas la estrategia es crear un documento base y aislar en un anexo o documento separado las peculiaridades de cada elemento. De esta manera terminará teniéndose una sola narrativa.

Perdidos en el espacio

En un proyecto en el que participé algunos años, nos encontramos con que a pesar de que los desarrolladores eran buenos, estaban teniendo problemas para implementar correctamente el sistema. El problema era que los desarrolladores desconocían la operación del negocio, así que no entendían cómo los casos de uso soportaban el proceso de negocio y por lo tanto no les era obvio el orden en el que se debían realizar las interacciones indicadas en los casos de uso. A pesar de que los casos de uso manejan relaciones de inclusión y extensión, así como el manejo de precondiciones en las narrativas, éstas no son suficientes para establecer el orden de ejecución de escenarios para la consecución de flujos completos. Por ende, cuando un desarrollador trabajaba con un caso de uso, tenía que “descubrir” como funcionaba el proceso completo haciendo ingeniería inversa. Esto, además de ser propenso a errores, consumía demasiado tiempo.

Para corregir esta situación realizamos las siguientes acciones:

• Brindar inducción a los nuevos integrantes del equipo en aspectos de negocio.
• Documentar los flujos a través de diagramas de proceso de negocio, y registrar la rastreabilidad procesos - casos de uso.
• Asignar a recursos experimentados como “coaches” de negocio.
• Manejar matrices de rastreabilidad que documenten qué partes del código corresponden a qué caso de uso, para detectar elementos compartidos.
• Diseñar baterías reutilizables de datos de prueba para consumo de todo el equipo.
• Implementar esquemas de integración continua para detectar impactos laterales lo más rápido posible.

Rompiendo el principio de impenetrabilidad

Extrapolando el principio de impenetrabilidad de física a los casos de uso, se tendría que un caso de uso no puede establecer al mismo tiempo la funcionalidad establecida por otro. Aunque suena lógico, en mantenimiento evolutivo una situación común es que, en lugar de modificar los casos de uso preexistentes, los levantadores de requerimientos prefieren crear nuevos sin avisar que reemplazan o “complementan” otros. Esto típicamente sucede bajo dos modalidades:

• Reemplazo total: Se bosqueja la funcionalidad actual y solo se describe de manera detallada lo que cambia.
• Reemplazo parcial: El caso de uso solo trata de los cambios a la funcionalidad actual.

En el primer caso, los desarrolladores pueden terminar creando duplicados de funcionalidades en lugar de actualizar las existentes. En el segundo caso, el resultado es un Frankenstein de modelo donde para conocer la funcionalidad del sistema es necesario realizar un tour entre entre los casos de originales y los n casos de uso “complementarios”. Adicionalmente, se pueden dar situaciones de choque entre fragmentos de funcionalidad. Esto se vuelve verdaderamente inmanejable.

Las razones más comunes por lo que sucede lo anterior son: partir de un modelo desactualizado, desconocimiento del modelo, o simplemente pereza. Es necesario promover la actualización del modelo, capacitar a los levantadores de requerimientos en el mismo, y establecer un responsable que supervise que las actualizaciones sean congruentes y no rompan la estructura.

Conclusiones

Los casos de uso son y seguirán siendo una muy buena herramienta para documentar y comunicar requerimientos. Sin embargo, es fácil dejarse llevar por la idea de que su uso es trivial y que son adecuados para capturar todo tipo de requerimientos. Una adecuada comprensión de sus limitaciones junto al conocimiento de otras herramientas de levantamiento de requerimientos, aunado a la aplicación de estrategias simples de organización y distribución, traerá como consecuencia requerimientos mejor plasmados, más completos y más sencillos, en beneficio tanto de los equipos de desarrollo como de los usuarios finales y el resto de las áreas involucradas.

Referencias

• [1] S. Ferg. “What's Wrong with Use Cases?” http://swgu.ru/sg39r2
• [2] E. Gottesdiener. “Top Ten Ways Project Teams Misuse Use Cases - and How to Correct Them.” http://swgu.ru/sg39r3
• [3] I. Jacobson et al, Object-Oriented Software Engineering - A Use Case Driven Approach. Addison-Wesley, 1992.