Los casos de uso (I)

Los casos de uso son un soporte excelente para discutir con el cliente qué debe hacer un sistema ya que se centran en los objetivos de los usuarios adoptando su perspectiva. Un sistema nunca será útil si no puede proporcionar los servicios requeridos por los usuarios y no cumple con los objetivos del cliente. Los casos de uso recogen los servicios fundamentales que los usuarios necesitan del sistema, lo que provocará que el cliente obtenga un beneficio económico, bien de forma directa, bien por un aumento de la productividad y la mejora de los procesos del negocio.

Los casos de uso son requisitos que describen qué hace el sistema, pero también son la unidad más pequeña de actividad que proporciona un resultado significativo para el usuario. En otras palabras, los caso de usos ─además de requisitos funcionales─ son la base para el análisis, diseño, programación y pruebas de un pequeño fragmento de funcionalidad. Esta característica es especialmente significativa en el Proceso Unificado.

La definición de caso de uso ha ido variando ligeramente desde que Ivar Jacobson los presentara por primera vez en la conferencia Sistemas, lenguajes y aplicaciones basados en la programación orientada a objetos de 1987, los incorporara como uno de los pilares del proceso Objectory [1] y realizara la última revisión [2] en 2011. En cualquier caso, pese a la ampliación semántica efectuada en el siglo XXI, un caso de uso esencialmente es una secuencia de acciones realizadas por un sistema que produce un resultado observable y de interés para un actor determinado. Para explicar la definición se partirá del siguiente ejemplo básico relacionado con el desarrollo de un cajero automático:

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.

Los pasos del caso de uso forman la secuencia de acciones que realiza el sistema, la cual es una interacción entre el actor y el propio sistema: una acción del actor conduce a una reacción del sistema. Todos los pasos se numeran para dejar claro su orden, siendo el primero el que habitualmente desencadena el caso de uso, es decir, el cajero se prepara para realizar la secuencia descrita si y sólo si el usuario introduce la tarjeta.

Las secuencias de acciones nada tienen que ver con los textos que aparecen en los clásicos pliegos de requisitos, donde cada uno de ellos suele empezar con la frase «El sistema hará…». Mientras que los casos de uso son un un especie de juego donde el actor pasa la pelota al sistema y éste la devuelve, los pliegos se centran exclusivamente en las acciones que debe realizar el sistema.

Dicho esto, cabe preguntarse por qué el actor realiza los pasos que forman la secuencia. La respuesta es sencilla: utiliza el sistema para cumplir con un objetivo ─un resultado observable y de interés─ como la obtención de dinero de un cajero automático. Por tanto, un actor es cualquier persona física, jurídica o sistema externo interesado en el comportamiento del sistema que tiene un objetivo que éste le ayuda a cumplir.

Las secuencias de acciones no son la única forma de especificación. Una de las grandes ventajas de los casos de uso es que pueden adaptarse a diferentes niveles de formalidad: desde un mero relato del objetivo del actor hasta una muy formal secuencia, pasando por multitud de formas intermedias. Igualmente, son tanto aptos para pequeños proyectos como para proyectos gigantescos, pues los principios de redacción son iguales para ambos casos.

Aunque la forma más común de detallar un caso de uso es escribir texto, no es la única. Dependiendo del caso puede ser mejor emplear algún tipo de diagrama UML, tal y como el diagrama de estados, actividad o secuencias. La forma textual suele ser trivial de entender para todas las partes y, en consecuencia, la mejor. No obstante, la compresión de los diagramas UML mencionados está al alcance de cualquier persona. Tan solo necesitará de una breve explicación para poder comprenderlos tal y como se verá más adelante.

Dado que el objetivo fundamental de los casos de uso, dentro del proceso de desarrollo de software, es servir de medio de comunicación eficaz entre el cliente y los miembros del equipo técnico, a la hora de elegir la mejor forma de detallar los casos es importante decantarse por aquella que sea la más sencilla de entender por el cliente.

Trabajando con casos de uso

No sólo los ingenieros tienen interés en los casos de uso. Una empresa tiene muchos grupos de personas interesados en la misión del sistema y la ven desde puntos de vista diferentes. Es obvio que la visión de los usuarios, ingenieros, responsables del producto o los miembros del departamento de calidad es distinta. Si no cumplimos con sus necesidades, no quedarán satisfechos por muy bueno que sea el resultado.

Para trabajar con casos de uso es esencial contar con el conocimiento de los expertos en el dominio y la experiencia de los usuarios que utilizarán el sistema. El desarrollo de un gran sistema puede implicar la participación de muchos tipos diferentes de usuarios, pero realizar reuniones de requisitos con un número excesivo de personas tiende a ser tremendamente improductivo para la mayoría de los asistentes. Emplear demasiada gente en la especificación de los casos de uso es ineficiente porque resulta difícil conjugar todos sus puntos de vista y, normalmente, da lugar a casos de uso mal detallados.

Sin embargo, no se pueden colmar las expectativas del cliente si se ignoran sus opiniones. Al fin y al cabo, él y los usuarios son quienes realmente saben qué necesitan del nuevo sistema. Debe hacerse lo posible para implicarles en el proceso y hacerlo desde el principio.

Cuando resulte difícil acceder al cliente, pueden enviársele cuestionarios concretos y concisos, apoyarse en manuales de sistemas antiguos o sistemas similares y hablar con el personal de mercadotecnia o del servicio de asistencia técnica de la empresa del cliente. Como último recurso, se puede intentar adoptar la perspectiva de los usuarios para discernir qué debe hacer el sistema. Esto último siempre es difícil y puede dar lugar a realizar asunciones erróneas.

El equipo de especificación de los casos de uso debe ser pequeño pero estar compuesto por personas con diferentes perfiles. Como mínimo, el equipo debería estar formado por los ingenieros y los usuarios finales o representes de éstos. Siendo así, se evitarán futuros problemas derivados del desconocimiento del objetivo del sistema, de lo contrario, el resultado no satisfará a nadie.

Por todo lo expuesto, realizar una revisión de los casos de uso es fundamental para validar su contenido. Nuevamente, no se puede pretender contar con todos los interesados en las reuniones de revisión porque requerirían mucho tiempo. Deben seleccionarse unas pocas personas que representen a todas las partes. Lo más conveniente es realizar dos tipos de revisiones: la primera hecha por un equipo interno y pequeño que puede repetirse las veces que sean necesarias, la segunda por un grupo más amplio ─que incluya a todas las partes─ a realizar una única vez.

Búsqueda de actores

La búsqueda de los actores del sistema se realiza en equipo en la primera reunión sobre requisitos, una actividad de crucial importancia pues ayuda a establecer un límite claro entre el sistema y su entorno. Si dicho límite es difuso, es posible que el alcance del sistema crezca de manera descontrolada. Sin embargo, es imposible trazar el límite de manera clara tras esa primera reunión. Lo normal es que al principio surjan dudas y vayan resolviéndose según se avanza con la especificación de los casos de uso.

En esa primera reunión enseguida aparecerán actores obvios, pero otros darán lugar a interesantes debates que pueden ser de ayuda a todo el equipo. Como alternativa a la participación de un equipo demasiado grande, se puede encargar la búsqueda de los actores a dos o tres personas y realizar una reunión posterior ─seguramente más breve─ para una puesta en común.

Una de las mejores formas de hallar actores es pensar en sus objetivos, es decir, qué esperan conseguir del sistema. Cuando los actores sean evidentes se puede replantear la pregunta desde el lado opuesto: qué servicios debe ofrecer el sistema a esos actores. Adicionalmente, pensar en el mantenimiento del sistema suele ser una buena fuente de información para encontrar actores: quién lo pone en marcha y lo para, quién lo administra, quién inspecciona los registros de actividad, quién controla la seguridad, quién realiza las actualizaciones, quién supervisa el rendimiento, etc.

Volviendo al ejemplo del cajero automático, el usuario es un actor obvio. Los cajeros están disponibles en la inmensa mayoría de las entidades bancarias para ofrecer un conjunto de servicios a sus clientes, unos servicios que hace cincuenta años realizaban los empleados de banca exclusivamente. Por el contrario, hay actores no tan evidentes que también usan un cajero automático. Por ejemplo, ¿quién se encarga de reponer el efectivo? Está claro que no es el usuario. Parece razonable asignar dicho objetivo a un empleado de la entidad que desempeñe ese rol.

El concepto de rol es importante en los casos de uso. Es un error pensar que hay una correspondencia unívoca entre un actor y una persona, lo correcto es establecer una relación entre un actor y una persona que desempeña un rol concreto. Una misma persona puede reponer el efectivo a las ocho de la mañana y usar el cajero a las seis de la tarde, pero como asume roles diferentes da lugar a dos actores distintos.

Centrarse únicamente en los usuarios del sistema e ignorar los roles que asumen puede omitir aspectos importantes de su comportamiento, incluir comportamiento redundante y dar lugar a un sistema con interfaces distintas que realicen las mismas operaciones. Bien es cierto que los roles son más abstractos y más difíciles de ver, algo que cuesta especialmente a los expertos. Hay que ser precavidos con la visión de los expertos pues pueden centrarse en aquello que conocen ignorando otras consideraciones, lo que conducirá a difuminar los servicios requeridos por los usuarios.

Ya se ha expuesto que los actores pueden ser máquinas además de individuos. Así las cosas, pregúntese si hay algún sistema que requiera de los servicios del sistema en desarrollo para encontrar más actores. En el caso del cajero parece que no hay ninguno. Sin embargo, si se estuviera desarrollando un servidor web parece indudable que un navegador sería un claro candidato.

Además de personas y máquinas hay un tercer tipo de actor. Cuando el sistema lleva a cabo una secuencia de acciones a una hora determinada o cada cierto tiempo, el actor es el tiempo. Hay quien encuentra extraño que el tiempo sea un actor, pero en casos de uso como realizar una copia de seguridad cada doce horas, no hay duda de que lo es.

Todos los actores vistos hasta el momento son aquellos que recurren al sistema para cumplir con un objetivo. A este tipo de actores ─ya sean personas, máquinas o el tiempo─ se les denomina actores principales. Además, también tienen en común que, normalmente, son los actores que desencadenan los casos de uso.

Por otra parte, hay actores que proporcionan servicios al sistema en desarrollo. Nótese la diferencia: no son actores que usan el sistema para cumplir un objetivo ─los actores principales─, sino actores que el sistema necesita para cumplir los objetivos. Estos actores se llaman actores de apoyo y son, en la inmensa mayoría de los casos, máquinas. Si nuestro sistema no trabaja aisladamente necesitará de algún actor de apoyo. Es el caso del cajero, pues necesita de los servicios de la computadora central de la entidad para leer y actualizar los datos de la cuenta del cliente. Los actores de apoyo ayudan a identificar las interfaces externas del sistema y los protocolos empleados para comunicarse con ellos.

Búsqueda de casos de uso

La falta de una idea clara sobre el propósito del sistema puede crear indecisión y opiniones encontradas durante su desarrollo pudiendo llegar a paralizar el proyecto. Hay varios factores que pueden contribuir a ello:

  • Es frecuente que surjan ideas distintas sobre las necesidades de los actores y sus responsabilidades. En casos así, se puede solicitar la ayuda del cliente, pero cuando se discute sobre matices, el cliente puede ser incapaz de aclarar las cosas.
  • Las prisas puede provocar que el equipo empiece con el desarrollo demasiado pronto y tome decisiones erróneas sobre el comportamiento del sistema.
  • Los ingenieros tienen una tendencia natural a ampliar el alcance del sistema incorporando funcionalidad que no ha pedido explícitamente el cliente, simplemente porque creen que proporcionará valor. La idea del cliente sobre qué es valioso puede ser muy diferente a la de un ingeniero.
  • En proyectos grandes, la falta de una idea clara sobre el propósito del sistema es bastante habitual. Los ingenieros saben qué hace y qué aporta al sistema la parte de la que se ocupan, pero no tienen claro qué hace el sistema en su conjunto y cómo se va a usar.

Para paliar estos problemas, resulta conveniente redactar un pequeño documento donde se exponga la finalidad del sistema, cuáles son sus objetivos, qué problemas va a resolver y cuáles no, quién lo encarga, quién lo usará y cómo beneficiara a todas las partes. Este documento debería hacerse llegar a todos los interesados.

Una vez que se tenga claro el propósito del sistema y se tengan identificados a los actores principales y de apoyo, debe discriminarse qué requisitos son parte de del sistema y cuáles quedan fuera. Esta tarea es relativamente sencilla conociendo los actores implicados. Se debe ir actor por actor pensando en sus objetivos, es decir, qué espera el actor del sistema. Resulta mucho más eficaz pensar en los objetivos de los actores que en las tareas que debe realizar el sistema. Esta es una de las claves de los casos de uso: crear soluciones que produzcan un resultado observable y de interés para los actores. De hecho, el nombre de un caso de uso refleja el objetivo de un actor. Si el objetivo del actor «Usuario» es sacar dinero, el caso de uso debe llamarse «Sacar dinero» o «Efectuar reintegro», entre otros posibles nombres.

Cuando haya nombres distintos para un mismo caso de uso, el cliente y su jerga mandan. Si habla siempre de reintegro entonces el mejor nombre para el caso de uso es «Efectuar reintegro». Solo hay una regla estricta a cumplir a la hora de dar nombre a un caso de uso, regla que incluso el cliente debe respetar: debe empezar con un verbo. Si se piensa, la regla es obvia. Los verbos expresan acciones y los actores lo son porque actúan, realizan acciones.

Como ya se he comentado, la mejor manera de encontrar casos de uso es pensar en qué espera cada actor del sistema, de qué manera el sistema será útil a sus futuros usuarios. Las siguientes preguntas pueden ayudar a identificar casos de uso:

  • ¿Cuáles son los objetivos que el actor espera cumplir usando el sistema?
  • ¿El actor va a crear, modificar, eliminar o leer datos del sistema?
  • ¿El actor necesita informar al sistema sobre cambios externos?
  • ¿El sistema necesita informar al actor de ciertos sucesos?
  • ¿El actor pone en marcha o apaga el sistema?

Si los requisitos del sistema no están claros, existirán muchas más dificultades para hallar los casos de uso porque surgirán muchas dudas sobre su cometido. Igualmente, si los objetivos están difusos, pueden surgir dudas sobre dónde empieza un caso de uso y dónde empieza otro. Pero incluso si los requisitos del sistema son buenos, siempre es una buena práctica preguntarse si los casos de uso hallados son correctos y estar en disposición de cambiarlos. Habrá casos de uso que haya que dividir, otros que unir, algunos desaparecerán, surgirán otros nuevos y así sucesivamente hasta llegar a la versión final. Este proceso ─llamado refinado de casos de uso─ sucede a lo largo de todo el proyecto, aunque especialmente en las primeras iteraciones respecto a los casos de uso principales: aquellos que suponen un riesgo técnico o que aportan un gran valor al cliente.

En resumen, hallar la lista definitiva de casos de uso de un sistema ─llamada más formal y correctamente modelo de casos de uso─ tras un par de reuniones de requisitos es una quimera. El modelo de casos de uso se irá depurando a lo largo del proyecto. Obviamente, cuanto antes se acote, mejor. Sin embargo, si aparecen dos casos de uso menores en la última iteración, incorporarlos no será ningún drama si el sistema tiene un buen diseño.

A continuación, se muestran varios ejemplos de búsqueda de casos de uso para el cajero automático.

¿Es responsabilidad del cajero actualizar el saldo de la cuenta del cliente? No, este requisito queda fuera del límite del sistema pues un actor de apoyo como «Computadora central» es el encargado de hacerlo. Cosa distinta es que lo haga a petición del cajero cuando le comunique que el usuario efectúa un reintegro, pero la acción de actualización del saldo no es de su competencia porque, entre otras, el cajero no almacena los datos de las cuentas.

¿Es responsabilidad del cajero la lectura de la tarjeta del cliente? Sí, porque el lector de tarjetas es parte del sistema en desarrollo. El cajero debe encargarse de procesar la información devuelta por el lector.

Ahora bien, ¿es el cajero responsable de leer la banda magnética o el microchip de la tarjeta del cliente? Realmente no, porque hay un dispositivo que, aunque forma parte del sistema, no se va a desarrollar y es el encargado de hacerlo. El sistema se limita a procesar la información que le proporcione. En un caso así, cabría preguntarse si el lector de tarjetas es un actor de apoyo. Para serlo, debería existir un caso de uso como «Leer tarjeta», pero éste no ofrece un resultado observable y de interés a ningún actor. El usuario haría lo siguiente: introduciría la tarjeta, el lector la leería y… fin. Habitualmente, nadie va a acudir a un cajero con el único objetivo de que le lea la tarjeta.

Se buscan casos de uso que satisfagan los objetivos de los actores, centrándose en identificar los servicios de interés que el sistema debe proporcionarles. Estos casos de uso se denominan de caja negra porque ocultan las interioridades del sistema. Cuando llegue el momento de analizar el sistema para determinar sus componentes, se podrá tratar el sistema como una caja blanca. Será entonces cuando aparezcan actores como «Lector de tarjetas», pero en ningún caso serán actores de apoyo, sino actores internos. Los actores de apoyo brindan servicios al sistema en desarrollo, mientras que los actores internos son componentes del propio sistema que brindan servicios a otros componentes.

No debe caerse en el error de identificar casos de uso como «Leer tarjeta». El sistema debe considerarse siempre como una caja negra. El lector de tarjetas, el teclado del cajero o el contador/expendedor de billetes son partes del sistema y, por tanto, no son actores principales ni de apoyo.

Referencias

[1] Ivar Jacobson, Magnus Christerson, Patrik Jonsson y Gunman Övergaard. Object Oriented Software Engineering: A Use Case Driven Approach. Addison Wesley, 1992.

[2] Ivar Jacobson, Ian Spence y Kurt Binner. Use Case 2.0. The Guide to Succesing with Use Cases. Ivar Jacobson International, 2011.

Fotografía de la entrada creada por Freepik

Entradas relacionadas