Buscar en Gazafatonario IT

jueves, noviembre 09, 2006

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.

No hay comentarios.:

Publicar un comentario