Caso de Uso

En la ingeniería de desarrollo de software, el Caso de uso (Use case) es la especificación por excelencia que se utiliza para comunicar los requerimientos funcionales del cliente hacia los equipos de desarrollo y pruebas, teniendo como autor de ello a los Analistas de Sistemas.

Historia

Ivar Jacobson utilizaba una técnica para capturar los escenarios de negocio; estos escenarios describen la interacción entre el actor y el sistema para cumplir un objetivo de negocio.

En 1986 con la integración de Rational Unified Process se establecieron los Casos de uso como estándar para especificación de los requerimientos funcionalidades de un sistema, eventualmente hubieron otros autores que colaboraron en la mejora de esta técnica, en los cuales se incluyen Kurt Bittner, Alistair Cockburn, Gunnar Overgaard y Geri Schneider.

Enfoque del Caso de Uso

El Caso de uso se enfoca a describir una actividad o funcionalidad del dominio(negocio), que es llevada a cabo dentro de un sistema de software.

La narrativa describe paso a paso la comunicación que tiene un actor y las respuestas que provee el sistema, con el fin de conseguir el objetivo

La actividad del dominio, también se le puede señalar como transacción de negocio, con ello se pueden establecer el alcance que deberá de especificarse en el Caso de uso.

Al narrar un escenario de negocio, es evidente que dicha narrativa deberá de estar expresada en lenguaje natural del dominio, por lo que deberá de ser entendible para el actor quien ejecuta, el caso de uso debe de estar libre de cualquier detalle de implementación, solución tecnológica o de usabilidad.

Un escenario o flujo de negocio persigue una y sola una actividad específica dentro del contexto del dominio, dentro de este flujo se incorporan los conceptos de negocio (entidades), relaciones y detalles que el propio domino establece para alcanzar el objetivo.

El flujo principal describe los pasos que el actor sigue para lograr el objetivo de una actividad, sin tener problema alguno para alcanzarlo.

Los flujos alternos serán aquellos pasos requeridos para completar la misma tarea, pero que por ciertas condiciones o restricciones, requieren de un tratamiento especial para lograr el objetivo

Los flujos de excepción son todos aquellos pasos que se realizan a consecuencia del incumplimiento de reglas de negocio, y por lo cual no permiten concluir la tarea, terminando en un punto distinto al planteado por la actividad de negocio.

El estilo con el que especifica el Caso de uso puede variar, en cuanto su redacción y terminología utilizada, esto se debe principalmente a las habilidades y destreza que tiene el analista para plasmar en el Caso de uso, como los requerimientos del negocio.

Sin embargo esta diversidad de redacción puede presentar dudosas interpretaciones a los diferentes tipos de audiencia que utiliza la información.

Por otro lado el nivel de abstracción puede variar, estando a juicio de la persona que lo especifica, sin embargo el nivel de detalle esperado, para cuando la información pase a los equipos de desarrollo y pruebas, debe de ser completa y sin ambigüedad de términos

Condiciones Inicíales

Condición previa que debe cumplirse para que pueda llevarse la ejecución del Caso de uso, recordando que el Caso de uso describe el escenario de una actividad de dominio, por lo que, las condiciones deberán de establecerse con el mismo enfoque.

Las condiciones establecen el estado previo de los conceptos de dominio que serán utilizados dentro de la narrativa de los flujos que describe el Caso de uso

Por ejemplo que el actor este autenticado en el sistema, puede quedar como parte de las guías de uso del sistema, ya que puede no tener valor respecto a la actividad de dominio que pueda describir.

Si por algún motivo no se puede establecer una condición previa desde el contexto de negocio, podrá ser valido el colocar:

"El sistema se encuentra en espera de... " (ver Ejemplo).

Condiciones Finales

Las condiciones finales, son aquellas que están delimitadas por el objetivo propio del Caso de uso, en particular la condición deberá de proveer un valor al actor que lo ejecuta, en estás se incluyen los estados finales de los conceptos de dominio.

Para el caso de los flujos que terminen en algo diferente que el objetivo, como son los flujos de excepción, se deberá indicar en la narrativa.

Flujos

Describen las posibles rutas por las cuales se logra el objetivo o se indican las excepciones

Limitaciones del Caso de uso

El caso de uso se enfoca a detallar la interacción que tiene un actor vs el sistema, desde una perspectiva de negocio, por ende, no provee de manera explícita las cualidades de servicios (Requerimientos no funcionales), además, con el nivel de abstracción que debe de tener el Caso de uso, no se espera que haya especificación de formulas, algoritmos, transformaciones, contratos de comunicación entre sistemas y otros. Para todo lo anterior el proyecto deberá de crear un documento suplementario, con el objetivo de completar los comportamientos y características del sistema esperados por el cliente.

• Plantilla de Caso de uso: la plantilla no asegura la legibilidad o entendimiento de lo que se requiere transmitir, esto tiene una dependencia directa con las habilidades de quien escribe los flujos del caso de uso, además de la mecánica para acotar la operación que se pretende describir.

• Interpretación del Caso de uso: existe una curva de aprendizaje por parte, tanto de los usuarios como de las personas que no hayan seguido un estándar; dejando a cada grupo de lectores su propia interpretación lo que dificulta el entendimiento del negocio.

• Completitud de requerimiento del sistema: El caso de uso provee un 60% de los requerimientos a implementarse, considerando que el nivel de abstracción esta orientado a la perspectiva del negocio. Debido a ello, los equipos de trabajo (Desarrollo, Pruebas) deben de complementar las funcionalidades observadas en el Caso de uso, con la información de los anexos, modelos de dominio, diagramas e información suplementaria; y con esto cumplir con las expectativas del cliente. El Caso de uso será el artefacto a utilizar para encontrar toda la información que está asocia (relacionada); esto está dado por la trazabilidad.

Ejemplo

Caso de Uso	Retirar efectivo del ATM (Automatic Teller Machine)
Objetivo	El actor retira efectivo de su cuenta de bancaria
Pre-condición	El ATM se encuentra en estado de espera de una nueva transacción
	1.- El Casos de uso inicia cuando el cliente inserta su tarjeta en la ranura del ATM. 2.- El ATM lee el código de la cinta magnética de la tarjeta del cliente. 3.- El ATM solicita al cliente que ingrese su clave de identificación. 4.- El cliente ingresa los dígitos de su clave personal. 5.- El ATM verifica que la clave del cliente es correcta 6.- El ATM solicita al cliente que seleccione la transacción de una lista dada. 7.- El cliente solicita "retirar de efectivo". 8.- El ATM solicita al cliente que escoja de una lista la cantidad que desea retirar. 9.- El cliente selecciona la cantidad desea para retirar. 10.- El cliente confirma el retiro de efectivo al ATM. 11.- El ATM verifica que la cantidad a retirar no excede a saldo de la cuenta bancaria. 12.- El ATM dispensa la cantidad del efectivo solicitada por la ranura de salida de efectivo. 13.- El ATM registra el nuevo saldo de la cuenta bancaria del cliente por disposición de efectivo. 14.- El ATM imprime el recibo de retiro al cliente. 15.- El ATM solicita al cliente la terminación de operación de una lista de opciones 16.- El cliente selecciona el cierre de operación en el ATM. 17.- EL ATM regresa la tarjeta del cliente. Fin de Caso de Uso
	Flujos Alternos 2a.- El lector del ATM, no reconoce el código de la tarjeta introducida por el cliente. (Flujo de Excepción) 2a.1 El ATM regresa la tarjeta del cliente. Fin de Flujo 5a.- El ATM detecta que el código ingresado por el cliente no es válido (Flujo de Alterno) 5a.1.- El ATM llevará la contabilidad de intentos de validación de la clave que ha ingresado el cliente. 5a.2.- El flujo continúa en el paso 3 del flujo principal. 5a.1a.- EL ATM detecta que se há realizado el tercer intento en la validación de la Clave del cliente sin exito (Flujo de Excepción) 5a.1a.1.- El ATM envía al cliente un mensaje de que la tarjeta fue retenida 5a.1a.2.- El ATM envía al cliente un mensaje con un número telefónico para seguimiento de retención de tarjeta Fin de Flujo . . . (Continúan otros flujos )

Lecturas recomendadas:

Requerimientos Arquitectónicos

Writing Good Use Case

Directriz para CU