¿Dónde está el flujo en los diagramas de casos de uso?

Autor: Carlos M. Macías Medina

Alias: Charlie Macías (México)

Nivel: Básico

La respuesta corta es: en ningún lado, no hay flujo en un diagrama de casos de uso. La argumentación es el resto de esta entrada.

Quizá sea una predisposición mental la que nos lleva a buscar flujo en cualquier diagrama que usa símbolos más o menos abstractos y, sobre todo, donde existen flechas; sí, seguro las flechas son las culpables de todo. Considere el siguiente diagrama:

Imaginando lo que tenía en mente el modelador podríamos decir que: El “Usuario” inicia el caso de uso “Entrada al Sistema” y después de eso podría hacer un “Cambio de NIP”, una “Solicitud de Saldo”, un “Retiro de Efectivo” o un “Pago de Servicios”. Cabe resaltar que los últimos cuatro casos de uso mencionados son todos extensiones de la “Entrada al Sistema”.

Con base en los conceptos que expuse en el artículo UML y el Modelo de Casos de Uso (de Sistema) me gustaría hacer algunas observaciones sobre el modelo que se muestra arriba:

Nombre de los Actores. En el artículo antes mencionado escribí que las “buenas prácticas” recomiendan que el nombre de los actores debería reflejar el rol que asume al interactuar con el sujeto (sistema) y que, en la medida de lo posible, dicho rol correspondiese con uno del negocio. El nombre “Usuario” en términos generales es una mala idea como nombre para el actor, sobre todo cuando este es un actor primario como el que se muestra en el diagrama de arriba. Pensémoslo un momento, cualquiera que use un sistema es un usuario, el pecado de este nombre es ser demasiado genérico. Un mejor nombre podría ser “Cuentahabiente” o incluso “Cliente”. Yo en lo personal me inclino más por el primero porque tiene el nivel de especialización adecuado en el contexto de lo que parece ser un sistema de cajero automático. Entonces los que usan a los cajeros automáticos para “Entrar al Sistema” juegan el papel de cuentahabientes. Espero que sea obvio que en el caso de que el verdadero cuentahabiente le prestara su medio de acceso y le diera a conocer su NIP a otra persona y ésta última interactúa con el cajero en nombre del primero entonces esa otra persona estaría asumiendo el papel de cuentahabiente desde la perspectiva del sujeto (sistema).

En cuanto al nombre de “Switch” para el actor de soporte, bueno es adecuado siempre y cuando a los interesados les haga sentido. Prosa e eGlobal en México se autodenominas “Switches Inteligentes” y entre sus responsabilidades se encuentran darle soporte a las transacciones que se realizan en la red de Cajeros Automáticos. En caso contrario podríamos sugerir por ejemplo el nombre de “Banco”.

Nombre de los Casos de Uso. La mayoría de los expertos coincidimos J en que el mejor nombre para un caso de uso es el que sigue el estándar nominativo para los procesos, es decir, que su nombre comience con un: “strong active verb” (en inglés); verbo en infinitivo (en español) y que su nombre, más que responder a la pregunta ¿para qué usa el sistema el actor?, refleje un objetivo que el actor alcanza cuando usa al sistema y que por consiguiente le resulta valiosa la interacción con dicho sistema. Con base en lo anterior podríamos recomendar mejores nombres para los casos de uso. Para aquellos casos de uso que representan los servicios bancarios que ofrece el cajero sólo vamos a recomendar que su nombre comience con infinitivo y para el hasta ahora llamado “Entrar al Sistema” vamos a proponer “Acceder a los Servicios Bancarios”.

Siguiendo las recomendaciones nominativas la nueva versión del modelo quedaría así:

Pero aún no está del todo bien. En el artículo UML y el Modelo de Casos de Uso (de Sistema) también acordamos que un caso de uso es un procedimiento completo que le permite alcanzar un objetivo valioso a un actor en una sola interacción (una sesión continua de tiempo), este último criterio es cubierto por el diagrama en su última versión. Sin embargo el uso de exagerado de las relaciones de extensión es sumamente cuestionable. Por un lado (Alistair Cockburn está de acuerdo conmigo) en la medida de lo posible, y lógicamente esto aplica a la primera versión de un modelo de casos de uso, las relaciones entre casos de uso deberían evitarse. Conforme el modelo va madurando y en caso de que las relaciones entre casos de uso sean necesarias, siempre hay que favorecer a las inclusiones por encima de las extensiones y generalizaciones. Si no está familiarizado con los conceptos básicos relacionados con las relaciones entre casos de uso le invito a leer esta entrada.

Preguntémonos, porque el modelador usó extensiones para relacionar a los casos de uso. Seguramente su línea de razonamiento fue que como la entrada al sistema es un prerrequisito para conducir cualquier transacción bancaria y el proceso de ingreso sólo se ejecuta una vez la mejor representación, usando la semántica del lenguaje, era esta. Sin embargo, este modelo incurre en dos pecados mortales: en primer lugar, no respeta el espíritu ni la intención de un modelo de casos de uso y, en segundo lugar, se entrampa en la semántica del lenguaje plasmando una idea basada en flujos.

Abordemos el primer punto. ¿Cuáles serian los probables objetivos de un cuentahabiente al interactuar con un cajero automático?, seguramente: retirar efectivo, conocer el saldo, cambiar el NIP o pagar un servicio todos con relación a la cuenta bancaria asociada a su medio de acceso. Estos son los procesos base no las extensiones. ¿Cuántos de nosotros acudimos a un cajero con el objetivo de acceder a los servicios bancarios?, yo no. La nueva versión del modelo luciría así:

Consideremos el segundo punto. Si el modelo anterior es correcto ¿entonces cómo digo que primero tengo que acceder a los servicios bancarios antes de poder usarlos? La respuesta es: a través de las precondiciones y las post-condiciones, ¡ahí es donde se produce la “conexión” entre los casos de uso! y, por supuesto, esa “conexión” no tiene representación gráfica.

Si le escarbamos más al asunto, podríamos insistir que el proceso para acceder a los servicios bancarios es en realidad una extensión de la conducción de una transacción bancaria y entonces el modelo podría terminar pareciéndose a algo como esto.

Esto me cae de perlas cuando me encuentro un conjunto de actividades (v. g. imprimir un comprobante, preguntar si se desea realizar otra transacción) que se tienen que realizar después de alcanzar los objetivos de cada servicio bancario. En esta última versión se incorporan relaciones de extensión y generalización ya que desgraciadamente la inclusión no es una opción debido a la regla de simetría asociada.

En fin, lo importante es mantener el modelo simple y efectivo. Los modelos de casos de uso siempre deben reflejar los objetivos de uso (el valor) sin entramparse en la semántica del lenguaje. La secuencia entre los procesos del sistema no tiene representación gráfica en un modelo de casos de uso.