Lecturas Fundamentales 4 (1 de 2)

Lectura Fundamental Anterior: “Casos de Uso: Del Todo y de Sus Partes”
Lectura # 4
Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 1 de 2
Volvamos a considerar el siguiente caso de uso típico de un sistema de reservaciones:
Caso de Uso: Reservar Vuelo
Actor: Pasajero Frecuente
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.
Objetivo: Proporcionar un mecanismo rápido y seguro a un Pasajero Frecuente para hacer reservas en vuelos nacionales o internacionales de ida y regreso. No se incluye la funcionalidad de pagar o cambiar el estado de la reserva.
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 decide 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, incluyendo la hora de ambos viajes
6. El sistema valida que la fecha de regreso, incluyendo la hora, sea superior a la fecha de ida, incluyendo la hora, 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
Secuencia Alternativa 3:
6B. La fecha/hora de regreso es inferior a la fecha/hora de ida
6A1. El sistema muestra el mensaje: “La fecha de regreso es inferior a la fecha de ida. Especifíquelas nuevamente.”
6A2. El caso de uso continúa en el paso 5 de la secuencia básica
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: todavía este continua siendo un caso de uso de una situación simulada, no intente usarlo en ningún proyecto en curso.
Voy a cerrar este primer ciclo de lecturas fundamentales sobre casos de uso basándome precisamente en una corta pero sustanciosa lista de chequeo para revisar casos de uso. Vale la pena decir que esta lista hace parte del proceso de Ingeniería de Requisitos institucionalizado en InterGrupo hace ya algún tiempo y que a su vez está cimentada en RUP.
Ley de la Terminación de un Caso de Uso
Un caso de uso está terminado cuando se cumplen al menos diez de las siguientes trece condiciones:
1. ¿El caso de uso tiene especificado el Actor que lo inicia?
2. ¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
3. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
4. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
5. ¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
6. ¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
7. ¿Las interacciones del actor y la información intercambiada están claras?
8. ¿La descripción breve ofrece un cuadro verdadero del caso de uso?
9. ¿La secuencia básica del caso de uso tiene un número de pasos pequeño? (menos de 20)
10. ¿Está claro que el caso de uso no se puede dividir en dos o más casos de uso?
11. ¿Para un caso de uso incluido: se probó que si se modifica el caso de uso que lo incluye, el caso de uso incluido no se afecta?
12. ¿Cada caso de uso es independiente del resto?
13. ¿Este caso de uso hace algo muy parecido a otro caso de uso? De ser así, quizás deberían convertirse ambos en un único caso de uso.
¿El caso de uso tiene especificado el Actor que lo inicia?
No habría mucho que decir de este control si la búsqueda y posterior definición de los actores de un sistema no estuviera hoy tan desestimada. En principio tengo que decir que intentar definir un sistema sin conocer sus actores es un error bastante común. Antes que cualquier otra cosa es importante conocer para quien construimos el sistema, luego procedemos a documentar lo que hace cada uno de esos actores.
Debemos indagar por el perfil del actor y sus responsabilidades en el sistema. Recordemos que un actor bien podría ser alguien “abstracto” para el negocio, es decir, no equivale a un rol desempeñado por una persona o un grupo de personas dentro del negocio, razón por la cual, luego de hacer la abstracción, hay que mirarlo desde el punto de vista del sistema.
Con ese perfil, evaluamos si las actividades descritas en el caso de uso pueden ser ejecutadas por ese actor. Este es realmente el punto de chequeo, no simplemente asegurarnos de que haya un nombre cualquiera en la sección Actor del caso de uso.
Ahora bien, un caso de uso normalmente tiene un único actor que lo inicia; sin embargo, el caso de uso puede tener más actores. En este caso, los demás actores son pasivos, es decir, o simplemente reciben información, como en el caso de un sistema o un dispositivo externo, o son espectadores participes del proceso del negocio que envuelve el caso de uso, como en el caso de un cliente en un punto de venta. En cualquier caso, es importante enumerar a todos los actores que intervienen en el caso de uso por el horizonte que se extiende tanto para los analistas como para los desarrolladores y probadores del producto, en cuanto al entendimiento del mismo.
En el ejemplo, un “simple” Pasajero puede significar un cliente casual de la aerolínea, mientras que un Pasajero Frecuente es precisamente una persona que toma vuelos con una frecuencia uniforme o que, al menos, está registrado como tal ante la compañía.
¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
Los usuarios son la última línea de defensa del caso de uso, son quienes confirman que está terminado, son quienes lo aprueban. Es tarea del Especificador de Requisitos obtener de ellos la información suficiente y necesaria para terminar el caso de uso. Siempre tenemos a la mano el “¿Qué más debo saber acerca de esta funcionalidad?” Otras preguntas importantes son: ¿Quién más está interesado en este caso de uso? ¿Quién debería leerlo? ¿Quién debería aprobarlo?
Una vez se tiene esa información, el revisor del caso de uso, si existe, puede indagar sobre el número de personas que leyeron y aprobaron el caso de uso para establecer si eso constituye una muestra representativa para dar por terminado el caso de uso.
En el ejemplo, puesto que el Pasajero es un actor externo a la compañía, alguien dentro de ésta es quien lo representa, es decir, es quien decide cómo quiere que los clientes de la aerolínea perciban el sistema. Por ello es importante documentar desde el principio del proyecto, no solo quienes son los usuarios finales, sino quienes serán sus representantes a lo largo del ciclo de vida.
¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
Es más que evidente. Otra vez, es sólo el usuario y nadie más que el usuario, quien decreta la correcta finalización del caso de uso. Por ello el caso de uso no debe incluir aspectos técnicos o detalles del diseño o implementación del mismo.
Se evidencia la participación dinámica y constante del usuario o de un grupo de usuarios durante la Ingeniería de Requisitos (por supuesto, también durante el resto del ciclo de vida, pero sin duda es esta etapa donde se hace más evidente la necesidad de contar con el mayor número de usuarios del producto).
El usuario regular no está interesado en conocer lo que ocurre “detrás del telón” del sistema. Para él sólo es importante el grupo de acciones donde él participa activamente, donde interactúa con el software y finalmente es quien indica si está satisfecho con lo que está documentado en el caso de uso.
Si, por ejemplo en el paso 6, dijéramos que la lista de vuelos se busca haciendo una intercalación multivía seguida de una selección por reemplazamiento, estaríamos adicionando detalles que confundirían innecesariamente al usuario común y corriente. Es más, ni siquiera tendríamos que mencionar las tablas y mucho menos los componentes involucrados en dicha búsqueda y selección.
¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
Si mantenemos el caso de uso en su estado más simple, aunque con el suficiente detalle para pasar al siguiente estado, los momentos de inicio y finalización de cada secuencia de acciones deberían estar a la vista de todos.
Los errores más comunes se encuentran en las secuencias alternativas, al decidir si la acción retorna a la secuencia básica o si el caso de uso termina. También pasa que si el caso de uso tiene varios escenarios a partir de una misma acción, luego de escribir dos o tres de ellos perdamos el foco de la “horizontalidad” del caso de uso y empezamos a cubrir detalles que nos podrían llevar, desde el punto de vista del usuario, por caminos insubstanciales del caso de uso.
¿Los subflujos en el caso de uso están modelados con precisión?
Luego de mi lectura fundamental # 1 no volví a mencionar la palabra modelo. No es que cuando estamos documentando casos de uso no estamos modelando, es que precisamente a veces perdemos la conciencia de que es eso lo que estamos haciendo, aunque sea puramente texto lo que escribamos. De hecho, el modelo de casos de uso es mayormente texto.
Así que cuando hablo de modelar subflujos del caso de uso con precisión, me refiero a que proporcionemos toda la información necesaria al modelo: lugar donde se inicia el subflujo, motivo del subflujo, acciones del subflujo y método de terminación del subflujo.
Cabe decir que los subflujos no son sólo secuencias alternativas, también pueden ser “porciones” de la secuencia básica, normalmente, porciones pequeñas y extremadamente simples.
Sí, el concepto clave es simplicidad.
¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
Una cosa es especificar un actor y otra es si ese actor representa adecuadamente al grupo de usuarios que ejecutará el caso de uso. Es posible que haya diferencias entre lo que piensa el representante de los usuarios asignado para proporcionar la información de, revisar y aprobar el caso de uso, y lo que finalmente quede documentado.
Un trabajo de campo, donde aseguremos que varios usuarios lean y acuerden el caso de uso ayuda mucho en estos casos. Así evitamos esa escena de terror que más de uno hemos vivido cuando mucho tiempo después de la especificación, probablemente durante las pruebas de certificación o ya en producción, nos preguntan “¿Quién dijo eso?”
De otro lado, el propósito puede estar implícito a lo largo y ancho de la declaración del caso de uso, o bien puede estar explícito en una sección inicial del mismo. Esta última opción es mi favorita porque permite verificar la consistencia del caso de uso lo mismo que medir su valor para el sistema y para los usuarios.
El propósito, si se especifica, debe escribirse a priori, quizás durante la etapa de descubrimiento del caso de uso, para que posea la menos subjetividad posible. Por supuesto, siempre podemos afinarla, aún antes de presentar el caso de uso para su última revisión.
El propósito debe incluir lo que el actor consigue del caso de uso y también lo que no consigue. Esto ayuda en las etapas posteriores al resto del equipo de desarrollo del proyecto a construir un sistema de alta usabilidad y gran aceptación.
Lo que Falta
Bien, hasta aquí la exploración a los primeros aspectos fundamentales que nos ayudan a decidir cuando un caso de uso está terminado. En la siguiente entrega volveré con el final de este artículo.
Esta lectura #4 continuará. Hasta entonces.
Lectura Fundamental Siguiente: “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2”

Lecturas Fundamentales 3

Lectura Fundamental Anterior: “Casos de Uso: Origen, Especificación y Evolución”

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

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.

Lecturas Fundamentales

Lectura # 1
Casos de Uso: De Vuelta a lo Fundamental

Volvamos a lo básico: un caso de uso es un conjunto de secuencias de actividades ejecutadas, normalmente por la interacción entre un ser Humano y una máquina. Las actividades son iniciadas por una entidad externa llamada Actor y las actividades terminan con un resultado de valor observable para ese Actor.

Desde otra perspectiva, la del usuario que usa el sistema, un caso de uso es una pieza de funcionalidad de software, casi siempre, una pieza indivisible, que tiene:

• Uno o más datos de entrada, el estímulo
• Uno o más datos de salida, la respuesta
• Un número finito de pasos o tareas, el proceso
• En principio, cada uno de esos pasos bien podría realizarse usando “sólo lápiz y papel”, la simplicidad
• Un comienzo, la orientación
• Un fin, el éxito.

¿Alguien recuerda a qué se parece esa definición?

Un caso de uso es el primer peldaño en la conversión de las necesidades de los usuarios a un sistema automatizado. Es el primero, el cimiento: para llegar al cielo todavía se requieren muchos otros elementos (léase análisis, arquitectura, diseño, implementación…)

Un caso de uso es el componente primario del modelo dinámico de un sistema, ese que hace e intenta responder la pregunta: ¿qué hace el software? Ese que juzga (analiza) el sistema por sus acciones. Sí, ese del que se dice es una representación abstracta de lo que hace el software, el que define el comportamiento del sistema.

Ahora bien, habitualmente un caso de uso se escribe en el formato “el actor hace…, el sistema hace…” un diálogo, un guión, una escena, en este caso, de un sistema de software.

Con esto en mente, resolvamos varias preguntas que siempre llegan a mi buzón:

¿Cuántas secuencias forman el “conjunto de secuencias” del caso de uso? Una, dos, tres…, un número pequeño, contable de secuencias. Como en casi todos estos temas, no está escrita la última palabra. Depende del contexto, del proceso de negocio que implementa el caso de uso, del resultado esperado, de la cantidad y calidad de los datos de entrada, de la habilidad de los usuarios del caso de uso, de los escenarios de usabilidad, de…, la lista de es larga.

En breve, un caso de uso de una única secuencia puede ser mucho más complejo que un caso de uso de media docena de secuencias. El asunto es: el número de secuencias de pasos no es el único capricho de un caso de uso.

Entonces ¿cuántas actividades tiene una secuencia? La respuesta es la misma: un número pequeño. Las prácticas contextuales nos dicen que siempre habrá una secuencia “regular”, la que más ocurre, la principal, la básica; y también podrán existir cero, una, dos, tres…, secuencias de menor ocurrencia, secundarias, eventuales, cada una de ellas, quizás, con un número menor de pasos que la primera.

¿Una secuencia es lo mismo que un escenario? Ah, este es un error muy común que cometemos. Apenas es una feliz coincidencia que sean lo mismo; pero de una secuencia, principal o no, pueden surgir uno o más escenarios.

Definición 1: Un escenario es un “camino” de ejecución, una instancia, del caso de uso con datos reales, donde el actor tiene un nombre, los datos tienen un valor específico y donde efectivamente hay un resultado que se puede “ver”. Quienes alguna vez han diseñado casos de prueba conocen bien esta diferencia. De hecho, un escenario puede (y habitualmente lo hace) ir a través de varias secuencias, normalmente, la principal y una o más secundarias. En síntesis, los escenarios son hilos cohesivos de comportamiento del caso de uso ocasionados por el estímulo que este recibe desde el exterior.

¿Y esas actividades cómo se escriben? ¿Cuál es el alcance de las mismas? Se escriben en terminología del usuario, sin detalles técnicos; en términos lingüísticos, siempre deberían ser escritas como una expresión verbal simple, sin adornos, sin sinónimos, sin adjetivos, sin comentarios del autor: un caso de uso es “orientado-al-verbo” si quisiéramos parafrasear algunos de los términos más usados por quienes nos movemos por los vericuetos insondables del tratamiento sistémico de la información.

En eso se diferencia un caso de uso de un guión de teatro, por ejemplo. Este último es rico en emociones, en observaciones, en detalles analógicos y puntos de vista subjetivos tanto del autor como de los personajes que intervienen.

¿Y qué hay del nivel de granularidad? Aquí entramos en el dilema del CRUD[1] o no CRUD, esa es la cuestión. Por agilidad deberíamos escribir casos de uso esenciales, no descompuestos funcionalmente, es decir, casos de uso que no entren en el nivel de detalle de la “pantalla” o del “formulario”, de los botones y cuadros de texto. Un caso de uso esencial deja un margen de maniobra al Analista, al Programador, al Arquitecto y aún al Probador. Los detalles de usabilidad, colorido y presentación bien podrían ser consignados en documentos auxiliares, en estándares en los cuales basar su implementación. Escribir casos de uso CRUD y similares aumenta innecesariamente el número de casos de uso, el tiempo de especificación, el tiempo de revisión, el tiempo de aprobación. Sí, quizás disminuya el tiempo de programación, pero este es cada vez más reducido a la luz de las poderosas herramientas con las que contamos hoy para escribir código fuente.

Definición 2: un caso de uso esencial se caracteriza porque: la funcionalidad CRUD es una porción del caso de uso, el actor que lo inicia está bien generalizado, su secuencia básica completa una interacción mayor con el sistema, no está asociado con componentes arquitectónicos o del sistema, es completamente independiente de la implementación de la Interfaz de Usuario, contiene un número mayor de secuencias alternas (hummm, esto podría representar algún tipo de inconveniente a la hora de cualificar la legibilidad del caso de uso), representa muchos ejemplos concretos de interacción, es decir, deriva en muchos escenarios, es bastante útil para pruebas del sistema y de funcionalidad. Finalmente, un caso de uso esencial forma parte de un modelo de casos de uso cuyo número de extensiones e inclusiones es menor al 20% de todo el modelo.

Definición 3: un caso de uso descompuesto funcionalmente es aquel que aborda un solo elemento CRUD a la vez, está vinculado a usuarios concretos específicos, no a actores abstractos, su flujo básico no completa una interacción mayor con el sistema, en cambio, describe funciones primarias del mismo, está completamente ligado a un componente del sistema o a un componente arquitectónico específico, está vinculado a una pantalla o función de usuario determinada y contiene instrucciones concretas de diseño de IU, incluye de cero a dos flujos secundarios frecuentemente relacionados con datos, Los escenarios derivados casi siempre deben invocar varios casos de uso para completar un ejemplo integral y es útil para pruebas unitarias. Para terminar, en un modelo de casos de uso descompuestos funcionalmente más de la mitad de los casos de uso son inclusiones o extensiones.

Una práctica contextual beneficiosa es sacrificar el modelo de los casos de uso descompuestos funcionalmente en aras de un diseño arquitectónico robusto y estable, de un modelo estático consistente y resistente y de una especificación más limpia y clara para quien, en últimas, revisa y aprueba cada caso de uso: el usuario.

Ejemplo # 1: el caso de uso “Hola Mundo”

Este es un caso de uso simple:

1. El caso de uso inicia cuando el Actor ejecuta la aplicación Hola Mundo
2. El sistema muestra el mensaje “Hola Mundo.”
3. El caso de uso termina

Ya tendremos la oportunidad de entrar en detalles acerca de como se escribe un caso de uso.

Lo que viene: bueno, habrá más de estas lecturas fundamentales. ¿De dónde surgen los casos de uso? ¿Y qué hay de los actores? ¿Cuándo un caso de uso está terminado? ¿Hay vida más allá de los casos de uso?

Estas y otras cuestiones nos aguardan en el universo binario de la técnica y la ciencia informática.

Lectura Fundamental Siguiente: “Casos de Uso: Origen, Especificación y Evolución”

Hasta entonces.

[1] CRUD: Create Read Update Delete (Crear, Leer, Actualizar, Eliminar). Operaciones fundamentales de los sistemas de información.

Prolegómenos Sobre el Lenguaje de Modelado Unificado

Este artículo se puede bajar haciendo click a continuación:

Prolegómenos Sobre el Lenguaje de Modelado Unificado

Me puedes contactar en lucho.salazar@gmail.com