Lectura # 3
Casos de Uso: Del Todo y de sus Partes
Consideremos el siguiente caso de uso típico de un sistema de reservaciones:
Caso de Uso: Reservar Vuelo
Actor: Pasajero Aerolínea
Descripción: este caso de uso permite a una persona reservar un vuelo de ida y regreso entre dos ciudades distintas en las fechas de su elección. El sistema valida la disponibilidad de un asiento de las características que el Pasajero especifique. La reservación se hace vía Internet. La aerolínea sólo tiene aviones con asientos estándar.
Precondiciones: El Pasajero debe estar plenamente identificado ante el sistema de reservas (Cuenta de Pasajero Frecuente, Identificación, Nombre y otros datos básicos).
Secuencia Básica:
1. El caso de uso inicia cuando el Pasajero opta por Hacer 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 valida que las ciudades Origen y Destino sean distintas, que haya al menos un vuelo entre esas ciudades y solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso
6. El sistema valida que la fecha de regreso sea superior a la fecha de ida y pide seleccionar una opción de la lista de vuelos disponibles para las fechas y ciudades establecidas
7. El Pasajero selecciona una opción de vuelo
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema asigna un asiento al Pasajero, genera y muestra un código de reserva
11. El caso de uso termina
Secuencia Alternativa 1:
4A. No hay vuelos entre las ciudades seleccionadas
4A1. El sistema muestra el mensaje: “No hay vuelos entre las ciudades seleccionadas. Verifique.” 4A2. El caso de uso termina
Secuencia Alternativa 2:
6A. No hay vuelos disponibles en las fechas especificadas
6A1. El sistema muestra el mensaje: “No hay vuelos disponibles en las fechas seleccionadas. Verifique.”
6A2. El caso de uso termina
Poscondiciones: El Pasajero puede consultar el estado de su reserva. El Pasajero puede modificar o cancelar su reserva.
Requisitos Especiales: El sistema sólo muestra y permite seleccionar pares de vuelos disponibles en las fechas y entre las ciudades establecidas. El sistema de reservas es solo para el tipo de Pasajeros Frecuentes de la aerolínea.
Advertencia: este sigue siendo un caso de uso de una situación simulada, no intente usarlo en ningún proyecto en curso. Además, no es un caso de uso “Terminado”.
Definición 6: La descripción breve o simplemente descripción del caso de uso es un compendio informativo –tres o cuatro líneas a lo sumo- sobre el caso de uso. Resume las principales características del caso de uso pero en ningún momento hace parte de la especificación funcional del mismo. En esta sección se pueden considerar algunas condiciones bajo y para las cuales se ejecuta el caso de uso, se pueden enumerar algunos requisitos no funcionales y otros detalles relevantes. Las descripciones breves surgen durante la fase de Concepción del proyecto, cuando se identifica el caso de uso y no reemplazan el bosquejo o borrador del caso de uso, que surge a continuación de ésta. Un indicador de que hemos entendido el caso de uso o la funcionalidad requerida es cuando escribimos esta descripción en menos de un minuto y a “lápiz alzado” como dicen los dibujantes. Sin embargo, esta es una práctica que toma tiempo y se puede lograr después de muchos casos de uso documentados.
Definición 7: Las precondiciones constituyen el estado en el que debe estar el sistema para que el caso de uso se ejecute. Esto quiere decir, lo que debe ocurrir en el sistema para que sea posible “habilitar” el caso de uso y que este se pueda ejecutar. Pensemos, por ejemplo, en una funcionalidad ampliamente usada por todos: Copiar y Pegar texto. Un prerrequisito de Copiar es Seleccionar el texto; y un prerrequisito de Pegar es Copiar el texto.
Una precondición se fija en prosa, como en nuestro caso de uso en demostración. O en términos de otros casos de uso, es decir, enumerando el o los casos de uso que deben ejecutarse para correr este. O usando una combinación de las dos. Esto último ocurre porque es posible que no hayamos identificado los casos de uso condicionantes, o porque no está claro de estos casos de uso cual es la precondición establecida y porque también hay un conjunto de especificaciones funcionales que no quedan escritas en términos de casos de uso y alguna de ellas puede ser un prerrequisito. Además, porque es mejor para el usuario que usemos su terminología y le evitemos leer un caso de uso completo para que entienda el estado final del mismo.
Las precondiciones son a la vez una forma de validación, ya que esas “condiciones” deben cumplirse antes de crear la instancia del caso de uso. Esto disminuye el número de validaciones que debe hacer dicho caso de uso una vez ha iniciado su secuencia de acciones.
La precondición del ejemplo se refiere al proceso o módulo donde el Pasajero se identifica ante el sistema: debe proporcionar su identificación y su número de pasajero frecuente para que el sistema conozca de quien se trata.
Las precondiciones además le hablan al desarrollador al oído. Le cuentan del mecanismo que debe usar o tener en cuenta para habilitar o deshabilitar opciones de la aplicación. En el ejemplo: si un pasajero no se ha identificado ante el sistema como Cliente o Pasajero Frecuente, la opción Hacer una Reserva Aérea estará deshabilitada o invisible al usuario.
Ahora bien, los tres errores más comunes que cometemos al definir una precondición son:
· Incluir una precondición “lejana en el contexto del proceso” al caso de uso, es decir, algo que no tiene relación directa con el caso de uso en cuestión. En el ejemplo, una precondición así sería “Las ciudades hacía y desde donde se originan los vuelos deben estar matriculadas en el sistema.” Ciertamente ésta podría ser una precondición del caso de uso, en cuyo caso lo afectaría indirectamente; En particular, ésta es una precondición de todo el sistema: sin las ciudades origen y destino registradas, el sistema no puede arrancar.
Aquí es importante precisar que una precondición no depende de esquemas temporales del proceso o del orden de ejecución en el tiempo. La precondición debería ser agnóstica de ello, desligándose del momento en que ocurre; lo que interesa es que se cumpla el estado, no el momento en que ese estado es establecido.
· Incluir una precondición que, en vez de serlo, es una condición que el sistema debe validar durante la ejecución del caso de uso. En el ejemplo, decir que “Debe haber vuelos disponibles” no es una precondición porque es algo que el caso de uso debe verificar a medida que se establecen las condiciones del vuelo. Tampoco lo es: “El Pasajero debe estar matriculado como Pasajero Frecuente en el sistema.” Esta es más bien una condición que se debe verificar en el caso de uso “Validar Pasajero”, el cual sí es una precondición del caso de uso.
Aquí también es importante aclarar que a veces una precondición puede convertirse en una validación en las primeras de cambio del caso de uso. Es decir, si no es compleja, entre otras características, la precondición bien podría incluirse como parte de las acciones del caso de uso.
· Incluir una precondición “no funcional”. Por ejemplo: “El Pasajero debe tener conexión a Internet” o “El Navegador debe soportar el protocolo SSL.” Aquí realmente estamos hablando de recursos físicos o de ciertas condiciones con las que el usuario no tiene que lidiar en lo absoluto.
Finalmente, las precondiciones son opcionales. Es posible, y ocurre muchas veces, que un caso de uso simplemente no tenga precondiciones.
Definición 8: La secuencia básica, llamada también Secuencia Principal, está formada por el conjunto de acciones que más ocurren en el caso de uso. Normalmente es la única que se describe por completo, es decir, de principio a fin.
Ahora bien, las acciones de un caso de uso, son acciones “planas” y, muchas veces, simples. En la Lectura 2 dije que no incluyen aspectos técnicos ni de diseño de pantallas ni otros detalles que pueden hacer difícil de leer y entender el caso de uso. Por lo general, un caso de uso inicia por una acción directa de un usuario o Actor del sistema. Esa acción casi siempre significa que el usuario decide u opta por hacer algo en el sistema para lo que tiene privilegios.
La elección de nombres, tanto de casos de uso como de otros elementos del proceso: Actores, datos y documentos, no debe hacerse a la ligera y mucho menos debe tomarse como algo sin importancia. Recuerden que eso afectará, al menos, la vida laboral de muchas personas. Como técnicos somos muy dados a seleccionar nombres ostentosos, adornados de tecnicismos innecesarios o incomprensibles para el usuario final; o, entre un grupo posible de nombres “del negocio” escogemos el menos usado en el entorno del usuario o alguno que tenga connotaciones distintas en el contexto de ese usuario: Reservar Vuelo, Hacer Reserva, Hacer una Reserva Aérea, Reservar, Hacer Reservación de Vuelo y Apartar un Viaje son algunos posibles nombres para el caso de uso.
Debemos indagar por las costumbres del actor, su perfil, su experiencia, su conocimiento, el entorno donde se mueve. En el caso de InterGrupo, con oficinas y clientes en varios países (aún en nuestro propio país un término puede llegar a tener connotación diferente en Bogotá que en Barranquilla), no está de más hacer este trabajo, no vaya a ser que usemos una expresión ofensiva para alguien. Quienes hemos viajado por distintas ciudades y países atendiendo clientes de la empresa somos testigo de ello.
Volviendo al nombre: Reservar y Hacer Reserva quizás sean muy cortos, sobre todo si hay distintos tipos de reserva; Reservar Vuelo quizás quiera decir un único trayecto, mientras que Hacer una Reserva Aérea puede significar reservar en ambos sentidos. En fin, las posibilidades pueden ser muchas. Por eso también es importante documentar el Glosario del sistema.
Para terminar, dos anécdotas: hace poco le preguntaba a un aspirante a Analista en InterGrupo que si sabía español. Evidentemente le llamó la atención y me dijo: “inglés, sí, a un 75%”. Yo le aclaré que no, y parafraseándolo le insistí que cuál era su porcentaje de español. Finalmente me dijo que no me entendía, creo que se ofendió, pero yo inmediatamente lo descarté.
Sí, es muy curioso que siempre nos exijan saber inglés sin siquiera indagar por nuestro nivel de español. Recuerdo que alguien, muy sincera, durante uno de los cursos que tomé de inglés hace muchos años me pidió ayuda cuando veíamos las distintas formas de conjugación en pasado. Ella me dijo que su problema era que no las dominaba en español y por eso se le dificultaba aprenderlas en inglés. Imagínense lo que pasó cuando llegamos al pretérito pluscuamperfecto: ese curso lo reprobó y nunca más la volví a ver.
De vuelta al caso de uso: las acciones no deben dar pie a ambigüedades, ni en el proceso del negocio ni en el del sistema. A primera vista, el paso 7 del caso de uso es anfibológico[i]. Seleccionar una opción de vuelo quizás quiera decir escoger un único trayecto y hasta bien podría sacarse de contexto y significar que el Pasajero seleccione un tipo de pasillo (Fumador, No Fumador, Ventana, No Ventana, entre otras); sin embargo, en la sección de Requisitos Especiales se aclara un poco el panorama.
Bueno, en otras lecturas volveremos a la secuencia básica.
Definición 9: Una secuencia alternativa está constituida por un conjunto de acciones que ocurren si se cumple una condición específica en el caso de uso, normalmente en la secuencia básica, aunque también puede ser en otra secuencia alternativa.
Cuando me refería a que la especificación de una acción o evento era más bien plana, hacía alusión a que la acción era una sentencia algorítmica básica, es decir, no era una decisión lógica o un ciclo predefinido, o una selección múltiple, que bien pueden existir en un caso de uso, pero que lo hacen complejo de entender.
El mecanismo que usamos para definir las decisiones en un caso de uso es precisamente el de las secuencias alternativas. Estas hacen más claro y preciso el caso de uso.
Una secuencia alternativa siempre debe iniciar detallando el paso o la acción en que se produce (el número del paso en la secuencia que la acarrea) y porqué se produce poniendo de manifiesto la condición que se cumplió para llegar a ese punto del caso de uso. A continuación se enumeran las acciones de la secuencia y por último se finaliza la secuencia bien sea retornando a la secuencia que la originó o terminando el caso de uso.
En nuestro ejemplo, es probable que falten algunas secuencias para terminar el caso de uso.
En conjunto, las secuencias básica y alternativas componen el cuerpo del caso de uso, la funcionalidad que el usuario requiere para resolver su problema de manejo de información: son lo implementable del caso de uso.
En general, un caso de uso se ejecuta para un elemento, en singular, del proceso. Por ejemplo, para un cliente decimos Registrar Cliente y no Registrar Clientes (a no ser que las condiciones así lo exijan); en nuestro caso, Reservar Vuelo: estamos reservando un vuelo de ida y regreso entre dos ciudades y fechas dadas, no son varios vuelos. El juego de palabras puede ser truculento, pero se debe aclarar lo mejor posible.
Definición 10: las poscondiciones describen el estado en el que queda el sistema una vez se ha ejecutado el caso de uso de manera exitosa, es decir, cuando no han surgido excepciones indeseables del sistema. Aquí, de manera exitosa quiere decir que se completó activamente un escenario del caso de uso sin que el sistema fallara por una caída de la base de datos, una sobrecarga de memoria o una mala implementación del caso de uso, entre otros.
Precisando, una poscondición no es el final de un caso de uso, está fuera del caso de uso. Por ejemplo, una poscondición no es que “la información del vuelo queda almacenada en la base de datos.” Esta es más bien una consecuencia lógica del caso de uso.
En el ejemplo, otra poscondición bien podría ser: “el pasajero puede Pagar su reservación con tarjeta de crédito, tarjeta débito o C.E.F.”
Como con las precondiciones, las poscondiciones pueden expresarse en términos de casos de uso o en prosa, si involucra a muchos casos de uso. Aunque la primera opción es la preferida porque no se deja espacio para malos entendidos, podría ocurrir lo mismo que expliqué sobre las precondiciones sentenciadas como casos de uso; por tal motivo, podría ser mejor usar la prosa: sí ven que es importante conocer mejor nuestro idioma.
Y al igual que las precondiciones, las poscondiciones son opcionales, aunque es difícil pensar en la ejecución de un caso de uso, que no sea la generación de un reporte o consulta, que no tenga un impacto directo sobre otro u otros casos de uso del sistema.
Definición 11: En principio, los requisitos especiales se refieren a requisitos de corte no funcional que deben tenerse en cuenta para la implementación de este caso de uso en particular y que no pueden ser descritas fácilmente en el flujo de eventos del caso de uso o lo convierten en un caso de uso enmarañado o sencillamente ilegible. Pero también pueden referirse a algunos requisitos funcionales si con ellos complementamos o precisamos el flujo del caso de uso, sobre todo, cuando no queremos adicionar detalles a ese flujo que también podrían hacerlo indescifrable.
Ahora bien, aunque los requisitos no funcionales se detallan en el documento de Especificaciones Suplementarias, si un requisito especial se refiere a una especificación previamente dictada, primará la que se encuentre en el caso de uso.
Para recordar, los requisitos no funcionales o el modelo URSP+ (por sus siglas en inglés): Usabilidad, Confiabilidad, Soportabilidad, Desempeño, Restricciones de diseño e implementación, Documentación, entre otros.
Bien, así son las piezas constituyentes de un caso de uso, al menos las más usadas. El grado de “adornamiento” de un caso de uso lo delimita el Analista de acuerdo a factores como complejidad, perfil del usuario, tiempo disponible para la especificación, experiencia de los equipos de diseño y de desarrollo, entre otros.
Escribir un caso de uso no es una tarea cándida, terminarlo puede llegar a ser extenuante. Pero ese será el tema de nuestra próxima lectura fundamental.
Hasta entonces.
Lectura Fundamental Siguiente: “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación?”
[i]
anfibológico, ca.
1. adj. Que tiene o implica anfibología.
Real Academia Española © Todos los derechos reservados
anfibología.
(Del lat. amphibologĭa, y este del gr. ἀμφίβολος, ambiguo, equívoco).
1. f. Doble sentido, vicio de la palabra, cláusula o manera de hablar a que puede darse más de una interpretación.
2. f. Ret. Figura que consiste en emplear adrede voces o cláusulas de doble sentido.
Real Academia Española © Todos los derechos reservados