Lecturas Fundamentales 2

Lectura Fundamental Anterior: “Casos de Uso: De Vuelta a lo Fundamental”

Lectura # 2
Casos de Uso: Origen, Especificación y Evolución

Los casos de uso detallan la funcionalidad del software en construcción. Aunque no tiene que usarse siempre, la técnica de casos de uso es una muy buena práctica a la hora de capturar, documentar, revisar y aprobar requisitos funcionales. Pero ¿a partir de qué elementos, en qué momento del ciclo de vida, surgen los casos de uso?

Los casos de uso, como la materia, no se crean ni se destruyen, se transforman. Están allí, esperando ingresar al conjunto de entidades que conforman un modelo, en este caso, como la materia prima fundamental de un producto de software.

En un principio están las necesidades, el espacio del problema. Aquí atendemos diligentemente la exposición del usuario, sus dificultades, la manera como las resuelve, si lo hace; escuchamos lo que necesita, las causas (el problema raíz o el problema detrás del problema), el impacto de convivir con esos inconvenientes, el costo asociado, entre otros aspectos.

Conocer al detalle la dimensión del problema es el primer gran paso hacia el diseño e implementación de un sistema útil y lleno de bondades para los usuarios. Durante esta parte del proceso, identificamos, sino a todos, a la mayoría de las personas involucradas o impactadas por el proyecto o el producto objeto del proyecto; por supuesto, también a otros sistemas o herramientas con los que nuestro sistema tendrá algún tipo de comunicación directa o indirecta.

Todos estos son insumos para identificar luego las características, ya en el espacio de la solución, del software a construir. Si hemos sido juiciosos consignando las palabras del usuario y confrontándolas con él, podremos empezar, por ejemplo, haciendo un análisis gramatical, una técnica antiquísima que separa los verbos, o las frases verbales, de los sustantivos: los primeros son casos de uso potenciales, o partes de un caso de uso; los segundos son actores u otras entidades relacionadas con el proceso. Es probable, inclusive, que de este análisis, apenas podamos tener una aproximación a un modelo de casos de uso del negocio.

Definición 4: un caso de uso del negocio representa un macro-proceso, un proceso, un subproceso o una actividad del negocio que no necesariamente es llevada a cabo por herramientas automatizadas, en el que intervienen una o más personas (llamadas entonces Actores del Negocio) y en el que se intercambia información relativa al proceso. Como con un caso de uso “normal”, al que llamaremos entonces caso de uso del sistema, o simplemente, caso de uso, el caso de uso del negocio termina con un resultado de valor observable para los actores del negocio. Ahora bien, de un caso de uso del negocio se pueden derivar uno o más casos de uso del sistema. Sin embargo, en ocasiones, un caso de uso del negocio permanece en su estado natural, es decir, ninguna de sus partes es automatizada. Un ejemplo típico de un caso de uso del negocio es la Recepción de una Solicitud de “algo”: Aquí, un actor del negocio, El Cliente, entrega a otro Actor del negocio, Recepcionista, Archivador o Empleado, uno o más documentos; este último, revisa, pone un sello con fecha y número (opcional) y firma una copia que es devuelta al Cliente; este simplemente se retira con su copia y el proceso, el caso de uso del negocio, termina.

Un Actor del Negocio representa un papel “actuado” en relación al negocio por alguien o algo en el entorno de ese negocio. Los siguientes tipos de usuarios del negocio son ejemplos de actores potenciales del negocio[1]:

• Clientes
• Proveedores
• Socios de negocio
• Clientes potenciales (el “mercado objetivo”)
• Autoridades locales
• Colegas

Un término íntimamente relacionado con el Actor del Negocio es el Trabajador del Negocio y muchas veces se confunde uno con otro, pero dejaré los detalles de este tema para una próxima entrega. Lo que nos interesa aquí es que los casos de uso del negocio son también fuentes de los casos de uso del sistema.

En este punto resolvamos más inquietudes:

¿Cómo nombramos un caso de uso? Con frases verbales simples. Verbos como Registrar, Generar, Consultar, Matricular, acompañados de expresiones sustantivadas de una sola parte son ampliamente usados. Y muchos otros. Algunos verbos que debemos evitar son Procesar, Hacer, Ejecutar, Establecer, Administrar o Gestionar, por lo genérico o ambiguo de los términos, al igual que el sustantivo Evento, que además para nosotros significa muchas otras cosas. Tampoco redundemos, como en Generar Reporte de Solicitudes Recibidas: Generar y Consultar normalmente se refieren a eso, a reportes y consultas, a no ser que se especifique otra cosa. El nombre de un caso de uso debe despedir cierto halito de grandeza, de verdad, de seguridad: en lo sucesivo, se convertirá en parte integral del vocabulario de muchas personas, quizás de toda una corporación, eso es motivo suficiente para que sea así.

El nombre, además de usar los verbos y sustantivos, debe dar a conocer la intención que tiene el actor al usarlo en el sistema.

En conclusión, Los nombres de los casos de uso traen orden y sentido a un proceso y a las personas involucradas en el mismo, allí radica su importancia.

¿Cómo especificamos un caso de uso? Cuáles son sus partes? Un caso de uso siempre es ejecutado por un Actor y eso es lo primero que debemos identificar del caso de uso.

Definición 5: un Actor es una entidad externa al sistema, normalmente una persona, pero también puede ser otro sistema o una máquina con la que nuestro sistema tenga algún tipo de contacto. Cuando se trata de personas, el Actor no identifica a alguien en particular; en cambio, señala un grupo o un perfil de usuarios del sistema. Todos los usuarios caracterizados por ese actor, ven el sistema de la misma forma, ninguno ve más o menos que otro. Eso sí, un individuo puede jugar a ser más de un actor en momentos distintos y en estados distintos de la aplicación. El mito más grande que hay con los Actores Personas es que representan cargos dentro de la compañía para la cual se construye el software, lo cual apenas sería una afortunada coincidencia. Hasta es probable que los actores del negocio, más cercanos a la compañía, no signifiquen cargos de trabajo. Ejemplos de actores son: Analista de Crédito, Vendedor de Licencias, Habilitador de Servicios de Salud, Supervisor de Producción, Administrador de Usuarios, entre muchos otros.

En estos ejemplos hay una constante: el contexto. Un actor lo es dentro de un contexto particular. Analista, Vendedor, Habilitador, Supervisor o Administrador son actores bastante genéricos y podrían representar a toda una compañía, que nunca se modela en un sistema. Siempre debemos limitar el alcance de las actividades de un actor (los casos de uso que ejecuta) vía contextualización. Un actor ampliamente usado en los sistemas punto com es el Cliente. Muchas veces, la sola denominación Cliente es bastante amplia y no permite delimitar el ámbito en el que se mueve. Podríamos bien decir: Pasajero Aerolínea, Tarjeta-Habiente, Comprador Minorista, Asegurado, Solicitante de Crédito, entre muchos otros apelativos.

Por supuesto, el otro componente importante de un caso de uso es el conjunto de secuencias, los flujos de tareas. Las tareas dicen qué hace el caso de uso, no cómo lo hace, es decir, no hay detalles técnicos en un caso de uso, al menos, no en principio, mientras se revisa y se aprueba con el usuario, quien es la última línea de defensa en materia de casos de uso. Tampoco hay referencias al diseño de la interfaz gráfica de usuario.

Además, en un caso de uso no se escribe el código fuente ni el manual de usuario. Para ello existen otros artefactos, tratados en otras disciplinas e instancias, que requieren de un conocimiento más profundo y detallado del adquirido durante el período de la especificación de requisitos.

Ejemplo, Ejemplo, Ejemplo.

Caso de Uso: Reservar Vuelo
Actor: Pasajero Aerolínea
Secuencia:
1. El caso de uso inicia cuando el Pasajero solicita una Reserva Aérea
2. El sistema solicita las ciudades origen y destino del vuelo
3. El Pasajero selecciona las ciudades origen y destino del vuelo
4. El sistema solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso
6. El sistema verifica que haya un asiento disponible para las condiciones establecidas y solicita las preferencias de silla al Pasajero
7. El Pasajero indica sus preferencias
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema genera y muestra un código de reserva
11. El caso de uso termina

Advertencia: este es un caso de uso en estado de especificación, no intente usarlo en ningún proyecto en curso.

Esta primerísima versión está medianamente lejos de la versión definitiva. Sin embargo, sirve para indicar varios aspectos:

1. La interacción Usuario-Sistema. El caso de uso siempre debe señalar lo que es obvio para el usuario, lo que él puede ver del sistema. Para el usuario es importante el estímulo que reciba del sistema, ya sea a través de solicitudes o de respuestas. El detalle del mecanismo algorítmico o técnico que use el sistema para enviar esas solicitudes o encontrar esas respuestas debe omitirse del caso de uso. En el ejemplo, el algoritmo de verificación del asiento disponible, si la búsqueda se hace secuencial o binaria, si se usan procedimientos almacenados o si se invoca a un Web Service para lograrlo, son especificaciones que están lejos del alcance del caso de uso (aún en la versión final del caso de uso, la que aprobará el usuario, no existirán).

2. Las formas lingüísticas, en este caso, los verbos y sustantivos usados deben ser un indicador de los mecanismos de implementación a usar: cuando el caso de uso especifica “el Pasajero selecciona[2]…” está diciendo claramente: elegir, escoger de un grupo de posibles opciones. Es evidente que el sistema debe entonces utilizar los medios necesarios para mostrar la lista de opciones y permitir que el usuario decida entre ellas mediante la “Acción y efecto de elegir a una o varias personas o cosas entre otras, separándolas de ellas y prefiriéndolas.” (Significado de Selección, Diccionario de la RAE, XXII Edición).

Vamos un poco más allá: cuando el caso de uso dice: “5. El pasajero especifica…” igual está lejos de señalar el mecanismo de implementación; no obstante, dejamos una puerta abierta para que el Programador use uno o más elementos de interfase de usuario: un cuadro de texto para digitar, un control especializado que permita seleccionar la fecha, un calendario compuesto por listas de días, de meses y de años donde también el usuario pueda “armar” la fecha requerida o una combinación de algunos de ellos.

Por supuesto, es posible que más adelante, durante las fases de análisis y diseño, cuando se suplemente el caso de uso, los posibles medios de implementación se particularicen de acuerdo a otros aspectos como los estándares de diseño gráfico, aspectos de usabilidad, restricciones de la aplicación, entre otros.

3. El versionamiento y el involucramiento del usuario. Es importante tener una versión del caso de uso tan pronto como sea posible, empezar a discutirla con el usuario, refinar la versión y congelarla tan tarde como sea posible, eso sí, antes de que finalice la etapa de especificación de requisitos, ya sea para una iteración en particular o para una fase determinada del proceso. (De Iteraciones y de Fases será otro tema para una lectura fundamental futura).

Ahora bien, el usuario nunca especifica o documenta casos de uso, pero sí los revisa, propone cambios y los aprueba. Hay un tiempo para todo. Si el cambio propuesto ocurre después de finalizada la etapa de especificación, es tarea del Analista de reportarlo como lo que llamamos comúnmente un control de cambio.

¿Y sobre la evolución del caso de uso? Por evolución me refiero aquí a lo que sucede con un caso de uso una vez está aprobado (versión 1.0) por el usuario. Se trata del análisis, el diseño, la implementación, la integración, las pruebas, la puesta en operación del caso de uso. Son temas extensos, motivo de más lecturas fundamentales por hacer.

Lectura Fundamental Siguiente: “Casos de Uso: Del Todo y de Sus Partes”

[1] IBM Rational Unified Process –RUP
[2] seleccionar. tr. Elegir, escoger por medio de una selección. Real Academia Española © Todos los derechos reservados.