Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: XI

"Los buenos consejos no son tomados en cuenta generalmente, pero eso no es motivo para no darlos."

Agatha Christie

Consejo Adicional: ¿Cómo luce un caso de uso inefectivo?

Caso de Uso: Apertura de Productos y Servicios

Secuencia Básica:

1.     Muestre una lista de productos y servicios de la siguiente forma:

•         La ventana izquierda lista todas las categorías de productos y servicios de la compañía (Ahorro e Inversión, Crédito Hipotecario, Otros Créditos)
•         La ventana inferior muestra los datos que se solicitan para el producto seleccionado
•         La tercera ventana muestra todos los productos y servicios que tiene actualmente el cliente

2.     Haga:

3.     El usuario hace clic en una categoría de producto o servicio

4.     Muestre los productos disponibles en esa categoría en orden alfabético

5.     El usuario hace clic en un producto

6.     Se actualiza la ventana inferior para solicitar los datos necesarios para la apertura del producto y el usuario hace clic en el botón “Solicitar Producto”.

7.     Chequee si el usuario cumple los requisitos necesarios para solicitar ese producto y que el producto esté disponible para su “tipo de persona” (Natural o Jurídica)

8.     Si el producto está disponible y el usuario cumple los requisitos necesarios, adicione el producto al usuario. Muestre la lista actualizada de productos del usuario, con el nuevo producto en estado “Solicitado”. Si no, muestre el mensaje “El cliente no cumple los requisitos necesarios. Seleccione otro producto.”

9.     Repita desde 3 hasta que el usuario haga clic en “Terminar Solicitud”

10.   Almacene la solicitud y regrese a la pantalla principal.

¿Y cómo luce un caso de uso efectivo?

Caso de Uso: Solicitar Producto

Actor: Cliente

Secuencia Básica:

1.     El Cliente solicita abrir un producto

2.     El sistema muestra la lista de productos actuales del cliente y muestra una lista de productos disponibles

3.     El Cliente selecciona el producto a solicitar

4.     El sistema verifica que el Cliente cumple con los requisitos necesarios y adiciona el producto a la lista de productos del cliente, en estado “Solicitado”.

5.     El sistema almacena la solicitud

Veamos algunos aspectos importantes de estas dos versiones:

Versión Inefectiva	Versión Efectiva
El nombre del caso de uso no es apropiado	El nombre está escrito como una frase verbal simple (en el formato “hacer algo”)
No tiene un actor definido	Tiene un actor principal, el Cliente.
El caso de uso se refiere a “el usuario” como actor del mismo. “Usuario” no es un concepto formal, es un humano, puede actuar como diferentes instancias de varios actores distintos.	El caso de uso se refiere a “el cliente” como actor del mismo. “Actor” es un concepto formal, puede ser un humano o un sistema, existe sólo si un usuario hace algo.
Está escrita en una especie de pseudocódigo y en lenguaje técnico.	Está escrita en prosa
Relaciona muchos aspectos de la interfaz de usuario. Orientado al Sistema.	Está escrito en términos del negocio (del usuario). Orientado al Negocio.
Aborda elementos que pueden ser disímiles en su tratamiento (productos y servicios, categorías de productos)	Aborda sólo productos. Incluso, los casos de uso deberían especificarse para un único producto a la vez.
Algunos pasos son complejos, difíciles de leer o muy largos. (Pasos 1 y 8).	Los pasos son claros, en el formato “el sistema hace…el actor hace”
La secuencia básica parece abarcar todos los escenarios posibles del caso de uso	La secuencia básica deja muchos escenarios para secuencias alternativas, como la solicitud de servicios o cuando el cliente no cumpla con las condiciones exigidas.
Parece haber sido especificado por completo en una sola pasada.	Le faltan detalles, pero estimula la creación iterativa de casos de uso.
Algunos pasos describen acciones consecutivas ejecutadas por el sistema y por el usuario a la vez.	Todos los pasos están escritos como expresiones verbales simples.

El verdadero truco con los casos de uso es mantenerlos simples. No nos preocupemos acerca de las formas del caso de uso, solo procuremos garabatearlos en una hoja de papel en blanco o en una página en blanco de un procesador de palabras simple, o en unas tarjetas indexadas blancas. No nos preocupemos por cubrir todos los detalles de inmediato. Los detalles no son importantes hasta mucho después. No nos preocupemos por capturar todos los casos de uso desde el principio; esa es una tarea imposible.

La única cosa para recordar sobre casos de uso es: mañana van a cambiar. Sin importar que tan diligente seamos a la hora de capturarlos, sin importar que tan meticulosamente registremos los detalles, sin importar que tan sistemáticamente pensemos acerca de los casos de uso, sin importar el mucho esfuerzo que hagamos para explorar y analizar los requisitos, mañana los casos de uso cambiarán.

Después vendrán las herramientas sofisticadas de apoyo. Las herramientas aumentan nuestra productividad, nos ayudan a clasificar, a buscar, a estimar, pero no hacen el trabajo por nosotros.

Esta es una visión minimalista del proceso, algunos la llaman ágil. Simplemente es una manera de hacer las cosas, una manera efectiva en ciertos casos. Ese es el verdadero sentido de esto: para cada proyecto, para cada actividad, debemos buscar o construir el mejor camino para ir de principio a fin y entregar el mejor de los resultados, el único posible.

W953BAF3WB56

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: X

Consejo 10

No usemos expresiones del tipo: “el sistema verifica si se cumple tal condición” y más adelante: “si se cumple la condición, haga esto”, y para terminar: “si no se cumple la condición, haga esto otro.” Este es un patrón que viene de la programación de computadores, es más bien pseudocódigo y la primera de las acciones no cumple con una de las premisas importantes de un caso de uso y es que cada acción lleve la secuencia del caso de uso un paso más adelante que el anterior. Vemos claramente que “el sistema verifica si se cumple tal condición” no avanza en el proceso, en cambio, debemos esperar hasta la siguiente operación: “si se cumple…” para continuar la secuencia.

En cambio, escribamos el caso de uso en términos de escenarios:

n. El sistema verifica que tal condición se cumple y hace…

n+1. El actor hace…

En una secuencia alterna especificamos lo que ocurre cuando la condición no se cumple:

nA1. El sistema verifica que tal condición no se cumple y hace…

(n+1)A2. El actor hace…

Como en:

4. El sistema verifica que el Cliente tiene capacidad de endeudamiento y solicita el valor del crédito

5. El actor ingresa el valor del crédito

Y en la secuencia alterna:

4A1. El sistema verifica que el Cliente no tiene capacidad de endeudamiento y solicita la identificación del avalista

4A2. El actor ingresa la identificación del avalista

Ejemplo

Consideremos este fragmento de caso de uso para verificar los fondos de una cuenta bancaria con miras a hacer efectivo un cheque.

Caso de Uso: Verificar fondos cuenta

Actor: Cajero

Secuencia Básica:

1.     El caso de uso inicia cuando el Cajero decide verificar los fondos disponibles para un cheque

2.     El sistema solicita el tipo y número de cuenta

3.     El Cajero ingresa el tipo y número de cuenta

4.     El sistema verifica que el número de cuenta existe y que está Activa y solicita el número del cheque

5.     El cajero ingresa el número del cheque

6.     El sistema valida que el número del cheque está dentro del rango autorizado y que no está contraordenado, y solicita el valor del cheque

7.     El cajero ingresa el valor del cheque

8.     El sistema verifica que hay fondos suficientes para pagar el cheque

9.     El caso de uso termina

Secuencia Alterna 1:

4A. El número de cuenta no existe

4A.1. El sistema verifica que el número de cuenta no existe y muestra el mensaje: “El número de cuenta dado no existe. Verifique.”

4A.2. El caso de uso continúa en el paso 2 de la secuencia básica.

Secuencia Alterna 2:

6A. El número del cheque no está dentro del rango autorizado

6A.1. El sistema verifica que el número del cheque no está dentro del rango autorizado y muestra el mensaje “El número del cheque no está autorizado. Verifique.”

6A.2. El caso de uso continúa en el paso 5 de la secuencia básica

Secuencia Alterna 3:

8A. No hay fondos suficientes para pagar el cheque

8A.1. El sistema verifica que la cuenta no tiene fondos suficientes para pagar el cheque y muestra el mensaje “Fondos insuficientes. Verifique.”

8A.2. El caso de uso continúa en el paso 7 de la secuencia básica

La escritura limpia del caso de uso lo hace claro, preciso y consistente, entre otros atributos deseables en un caso de uso. Nótese que es posible que haya más secuencias alternas.

Para saber más de casos de uso pueden visitar la sección Lecturas Fundamentales de mi Gazafatonario IT. En particular, pueden leer la Lectura Fundamental 3: Casos de Uso: Del Todo y de sus Partes.

http://www.gazafatonarioit.com/2006/11/lecturas-fundamentales-3.html

Esta serie de consejos útiles para escribir casos de uso inicia en:

http://www.gazafatonarioit.com/2012/10/diez-consejos-utiles-y-simples-para.html

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: VIII y IX

Consejo 8

Cuando se trata de incluir casos de uso se escribe:

• El sistema ejecuta el caso de uso “AQUÍ VIENE EL NOMBRE DEL CASO DE USO INCLUIDO”

O simplemente,

• Se ejecuta el caso de uso “AQUÍ VIENE EL NOMBRE DEL CASO DE USO INCLUIDO”

En este último caso se entiende que el único que ejecuta casos de uso incluidos es el sistema. Como en:

n. El sistema ejecuta el caso de uso “Verificar Lista Clinton”

n+1. Se ejecuta el caso de uso “Hacer Análisis de Riesgo”

Consejo 9

La especificación de un caso de uso incluido se debe iniciar estableciendo los nombres de los casos de uso que incluyen este caso de uso, como en:

1.     Este caso de uso se incluye en los casos de uso:

        a.     Caso de uso base 1

        b.     Caso de uso base 2

        c.     …

        d.     Caso de uso base n

2.     El sistema hace…

3.     El actor hace…

…

n. El caso de uso termina

Donde n es el número del último paso del caso de uso incluido.

Recordemos que esta relación de inclusión se usa cuando queremos:

•      Factorizar o descomponer (en sentido matemático) el comportamiento del caso de uso base que no es necesario para entender el objetivo principal del mismo y donde solamente el resultado del caso de uso incluido es importante.
•      Distribuir en uno o más casos de uso, funcionalidad del caso de uso base que es común para dos o más casos de uso (reusabilidad).

La primera opción se usa especialmente en casos de uso largos o complejos donde algunas partes del mismo no son relevantes para el sentido primordial del caso de uso y no son necesarias, en primera instancia, para entenderlo y aprobarlo. Por ejemplo, un caso de uso para Ingresar un Cliente de Naturaleza Jurídica puede solicitar docenas o cientos de datos que se pueden agrupar de acuerdo a algunos criterios como Datos Generales, Datos del Tipo de Entidad y Naturaleza Jurídica, Datos del Gerente o Representante Legal, Datos de los Contactos, Referencias Comerciales, entre otros. Algunos de estos grupos de datos pueden incluirse en casos de uso complementarios que son ejecutados desde el caso de uso principal.

La segunda posibilidad de inclusión es la reusabilidad de funcionalidad del sistema, es decir, cuando existe un comportamiento del sistema que se ejecuta en dos o más casos de uso de la misma manera, podemos usar un caso de uso incluido que represente ese comportamiento común. Por ejemplo, un caso de uso Verificar Centrales de Riesgo, que se ejecuta desde varios casos de uso de un sistema financiero, como Matricular Cliente, Revisar Solicitud de Crédito, Abrir Cuenta Corriente, entre otros.

Para conocer más acerca de relaciones entre casos de uso, pueden leer la Lectura Fundamental 12 Casos de Uso: de Extensiones y de Inclusiones en mi Gazafatonario IT:

http://www.gazafatonarioit.com/2008/05/lectura-fundamental-12-lectura_8835.html

La serie completa de estos consejos la encuentran en:

http://www.gazafatonarioit.com/2012/10/diez-consejos-utiles-y-simples-para.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para_4.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para_6.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para_8.html

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, IV

Al escribir el caso de uso deben evitarse sinónimos “técnicos” para Sistema como “programa”, “módulo”, “rutina”, “función”, “procedimiento”, “procedimiento almacenado” y “subrutina”. Como en:

n. El programa solicita la fecha de ingreso

n+1. El actor proporciona la fecha de ingreso

n+2. El módulo calcula el número de días laborados hasta la fecha

Algunos de estos términos son usados de manera indistinta donde debemos usar siempre “sistema”, otros se usan en pasos específicos donde normalmente estamos suministrando información técnica que no es responsabilidad de los casos de uso, como cuando hablamos de procedimientos almacenados o de rutinas.

Simplemente usamos el término “sistema”.

Ejemplo

Consideremos el siguiente caso de uso de la Web 2.0, relacionado con la publicación de entradas en un blog:

Caso de Uso: Publicar Artículo

Actor: Bloguero

Descripción: este caso de uso permite crear una entrada para su publicación en un blog específico de la Web.

Precondiciones:

1.     El Bloguero está debidamente acreditado ante el Sistema

Secuencia Básica:

1.     El caso de uso inicia cuando el Bloguero opta por publicar un nuevo artículo

2.     El sistema solicita el título del artículo

3.     El Bloguero ingresa el título del artículo

4.     El sistema solicita el cuerpo del artículo

5.     El Bloguero proporciona el cuerpo del artículo

6.     El sistema solicita las palabras clave con las cuales indexar el artículo

7.     El Bloguero ingresa las palabras clave del artículo

8.     El sistema verifica que el título del artículo no existe y solicita confirmación para publicar la entrada

9.     El Bloguero confirma la publicación del artículo

10.   El sistema publica el artículo

11.   El caso de uso termina

Secuencia Alterna 1: el título de la publicación ya existe

8A. El sistema muestra el mensaje “El título del artículo ya existe. Por favor, verifique.”

8B. El caso de uso continúa en el paso 2 de la secuencia básica

Secuencia Alterna 2: el Bloguero cancela la publicación del artículo

9A. El Bloguero cancela la publicación de la entrada al Blog

9B. El caso de uso termina

Poscondiciones:

1.     La entrada se puede modificar durante los siguientes 30 minutos.

2.     El artículo puede ser leído por los lectores del blog.

Nótese que en todo momento sabemos qué hace el sistema y qué hace el actor.

Diez Consejos Útiles y Simples Para Escribir Efectivamente Casos de Uso Efectivos, III

Puesto que es una buena (mejor) práctica encontrar primero los actores y a continuación los casos de uso, es recomendable también especificar el actor en la descripción de cada paso, en vez del término genérico “actor”, como en:

q. El sistema solicita la fecha de creación de la cuenta

q+1. El Analista de Crédito ingresa la fecha de creación de la cuenta

Recordemos que los actores, humanos o no, son externos a y delimitan el sistema y, por tanto, su funcionalidad. Es a los actores a quienes les interesa el resultado de cada caso de uso, cualquier proceso del sistema, así sea un proceso automático, ocurre porque en algún instante a alguien o a algo consultará o le resultará de vital importancia el resultado de ese proceso. Ningún caso de uso lo sería si no hay un actor involucrado, directa o indirectamente.

Con ello en mente, y ya que vamos a adoptar la rutina de identificar a cada actor del sistema y luego a los casos de uso subyacentes, en estos nombraremos al actor cada que ejecute una acción y no usaremos términos como “usuario”, “usuario final” o “actor”.

Ejemplo

Consideremos un caso de uso simple para consultar el saldo disponible en una cuenta bancaria vía Internet:

Caso de uso: Consultar saldo

Actor: Cuenta-habiente

Precondiciones: El Cuenta-habiente está debidamente autenticado ante el sistema virtual

Secuencia básica:

1.     El caso de uso inicia cuando el Cuenta-habiente quiere consultar el saldo disponible en su cuenta de ahorros

2.     El sistema solicita seleccionar la cuenta

3.     El Cuenta-habiente selecciona la cuenta de la cual consultar el saldo

4.     El sistema consulta la cuenta y muestra el saldo disponible

5.     El caso de uso termina

Poscondiciones: Él Cuenta-habiente puede transferir dinero a otra cuenta. El Cuenta-habiente puede hacer pagos a terceros.

El correcto nombramiento de los actores también ayuda a entender mejor el sistema que vamos a construir. Un banco, por ejemplo, tiene muchos tipos de clientes, algunos de estos tienen abierta una o más cuentas bancarias tradicionales, son los Cuenta-habientes. Al menos en Colombia, una persona puede tener una tarjeta de crédito emitida por un banco o un crédito de consumo y no tener ningún otro producto con la entidad financiera, son otros tipos de clientes, por lo que usar el término genérico Cliente no ayuda mucho.

Nótese en el caso de uso la especificación de precondiciones y poscondiciones que, entre otras características, hacen más clara y corta la especificación y permiten a los involucrados conocer más detalles de la operación que se está describiendo.

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, II

Siempre que sea posible, debemos evitar secuencias de pasos como:

n. El sistema hace…

n+1. El sistema hace…

O

m. El actor hace…

m+1. El actor hace…

Donde n y m son números de pasos de una secuencia cualquiera del caso de uso. Es decir, ni el sistema ni el actor ejecutan dos pasos seguidos en el caso de uso. La escritura de casos de uso debe (ría) obedecer al siguiente patrón de diálogo:

p. El sistema hace…

p+1. El actor hace…

Donde “hace” se debe reemplazar por la acción que uno y otro ente realizan. Normalmente, el sistema “solicita” el ingreso o selección de datos y el actor “proporciona” datos, ya sea ingresándolos (por medio del teclado, en cuyo caso “digita” los datos) o seleccionando uno o más datos disponibles de una lista suministrada por el sistema. Nunca se debe especificar el mecanismo programático (formularios, ventanas, cuadros de texto, listas combinadas, cuadros de chequeo, botones de comando, entre otros) utilizado para crear y mostrar la lista. Ejecutar.

Además, nuestros usuarios siempre esperan que los sorprendamos con algo novedoso y una forma mejor de hacer las cosas. En el futuro cercano, por ejemplo, esperarían no tener que lidiar con la clásica interfaz gráfica de hoy sino con hologramas u otra suerte de mecanismos de comunicación Humano-Máquina. Pero ese es otro asunto.

Volviendo al consejo práctico que nos ocupa, normalmente cuando ocurre que debemos especificar varias actividades seguidas de un actor o del sistema, nos encontramos ante una de estas situaciones: estamos haciendo descomposición funcional que, en principio, es innecesaria. Recordemos que lo esencial en un caso de uso es especificar lo que hace el sistema que es relevante para el negocio o para ese actor en particular. Por ejemplo, para un actor es significativo que el sistema busque y muestre los datos de una factura o le indique que no la encontró, pero no es importante si esa búsqueda ocurre mediante un método secuencial, uno binario, la técnica de Fibonacci o un algoritmo genético, o si usa el mismo método de google para encontrar páginas en Internet.

También puede ocurrir que estamos especificando una funcionalidad del sistema que es posible documentar mejor con otros mecanismos como diagramas de actividad o estado o, si es necesario documentación textual, con requisitos escritos a la usanza tradicional de: “el sistema debe hacer algo…”. También se pueden usar escenarios, tableros de historias (storyboards), prototipos o simuladores, o una combinación de dos o más de estos artilugios.

Ejemplo

El siguiente caso de uso para reservar sillas en un viaje por avión nos ilustra muy bien esta sugerencia:

Caso de Uso: Reservar tiquetes

Actor: Cliente (Aerolínea)

Secuencia Básica:

1.    El caso de uso inicia cuando el Cliente decide reservar tiquetes aéreos

2.    El sistema solicita seleccionar la ciudad origen

3.    El Cliente selecciona la ciudad origen

4.    El sistema solicita seleccionar la ciudad destino

5.    El Cliente selecciona la ciudad destino

6.    El sistema solicita la fecha de ida

7.    El cliente ingresa la fecha de ida

8.    El Sistema solicita la fecha de regreso

9.    El Cliente ingresa la fecha de regreso

10.  El sistema solicita el número de pasajeros

11.  El cliente ingresa el número de pasajeros

12.  El sistema verifica que hay disponibilidad de vuelos entre las ciudades y fechas solicitadas

13.  El sistema verifica que hay disponibilidad de asientos para el número de pasajeros establecidos

14.  El sistema muestra el mensaje “Sí hay disponibilidad de vuelos  entre las ciudades y fechas establecidas”

15.  El sistema genera un número de reserva

16.  El sistema almacena la información de la reserva

17.  El caso de uso termina

Aquí caímos en la típica descomposición funcional que se debe evitar durante la etapa de requisitos. Los pasos 12 a 17 bien pueden reemplazarse por:

12. El sistema verifica que hay asientos disponibles y muestra el número de reserva.

13. El caso de uso termina

¿Y qué se hicieron las otras especificaciones? ¿Será que los programadores son capaces de inferirla? No. Estos otros detalles pueden documentarse como requisitos especiales en el caso de uso o como elementos de diseño (por ejemplo, estableciendo en un diagrama de secuencia cuáles son las entidades de almacenamiento de información o el algoritmo para generar el número de la reserva). Nótese que estos aspectos no son relevantes para el negocio.