Patrones de Casos de Uso.

Al desarrollar o construir algo, como por ejemplo una casa o una máquina, es muy útil apoyarse en la experiencia anterior, ya sea de uno mismo o de otros. De esta manera sabremos que la solución va a funcionar, y tendremos identificados los problemas potenciales, así como soluciones para éstos. Estas soluciones a problemas comunes se conocen como patrones, y se utilizan en diversos aspectos del desarrollo de software. Ya en un artículo anterior de SG se habló sobre patrones de diseño, específicamente del patrón Modelo-Vista-Controlador. En esta ocasión, estudiaremos la aplicación de patrones al modelado de casos de uso, y en específico abordaremos el patrón CRUD.

Contrario a lo que se pudiera pensar, un patrón de casos de uso no describe un uso particular de un sistema. Más bien, captura técnicas para que el modelo sea mantenible, reusable, y entendible. Entonces, podemos decir que los patrones de casos de uso capturan mejores prácticas para modelar casos de uso.

La aplicación de patrones de casos de uso nos trae los siguientes beneficios:
• Aumentar la productividad.
• Reutilizar elementos existentes (en este caso fragmentos de modelos).
• Evitar el retrabajo por errores.
• No invertir tiempo en resolver problemas ya resueltos.
• Aplicar la teoría al trabajo práctico.
• Habilitar las herramientas de soporte para modelar el desarrollo.

Captura y Organización de Patrones

Para capturar y organizar los patrones de caso de uso, recomiendo ampliamente generar un repositorio de patrones donde capturen al menos la siguiente información para cada patrón:

• Nombre: el nombre descriptivo del patrón.
• Intento: captura cuál es el objetivo de aplicar el patrón.
• Características: estados de los patrones, si son simples o complejos, comunes o infrecuentes.
•Palabras claves: palabras clave que caractericen al patrón para facilitar su búsqueda.
• Tipo: si el patrón afecta la estructura del modelo o la descripción de un caso de uso.
•Modelo: un modelo de caso de uso a aplicar.
•Descripción: la descripción del modelo.
•Aplicabilidad: cuándo y cómo aplicar el patrón.
•Discusión: completa discusión sobre el patrón.
•Ejemplo: un ejemplo donde uno o más de los patrones se aplica.
•Modelo de análisis: diagrama con clases de análisis que proporciona una realización de los casos de uso.

Una vez que hemos hablado sobre lo que es un patrón de caso de uso, y la forma de documentarlos, estudiemos el patrón conocido como CRUD, en sus variantes completa y parcial.

Nombre: CRUD
Intento: este patrón se utiliza en los casos donde se quiere realizar altas, bajas, cambios y consultas a alguna entidad del sistema. Su nombre es un acrónimo de las palabras en inglés Create, Read, Update, Delete. Palabras clave: Creación, altas, bajas, cambios, catálogo

Modelo 1: CRUD Completo

Descripción: el patrón CRUD Completo consiste en un caso de uso para administrar la información (CRUD Información), nos permite modelar las diferentes operaciones para administrar una entidad de información, tales como crear, leer, cambiar y dar de baja.

Aplicabilidad: este patrón deberá ser usado cuando todas las operaciones contribuyen al mismo valor de negocio y todas son cortas y simples.

Modelo 2: CRUD parcial

Descripción: alguna de las alternativas del caso de uso puede ser modelada como caso de uso independiente.
Aplicabilidad: este patrón es preferible cuando uno de los flujos alternativos del caso del uso es más significativo, muy largo, o mucho más complejo que el patrón completo.
Discusión: muy a menudo los sistemas manejan información que, del punto de vista del sistema, se crea muy fácilmente. Después de un chequeo de sintaxis, o quizás un cierto chequeo sin importancia de un cálculo o regla de negocio, la información se almacena simplemente en el sistema. No es necesario realizar cálculos, verificaciones complejas, o recuperación avanzada de datos. La descripción del flujo es pequeña, y probablemente sólo haya una o dos trayectorias alternativas de menor importancia en el flujo. Las consultas, cambios, o bajas son operaciones igualmente simples.

¿Deben tales operaciones ser modeladas como un caso de uso? ¿Y deben incluirse en el modelo del sistema completo? La respuesta a ambas preguntas es sí. Son casos de uso porque son funciones que debe ser capaz de realizar el sistema. Alguien utilizará el sistema para administrar esa información. Por otra parte, deben ser incluidos en el modelo, ya que de otra manera estará incompleto. Y esto puede provocar que el proyecto no se lleve a cabo adecuadamente.

Afortunadamente, esto no significa que necesariamente cada operación se debe expresar como casos de usos separados. Según el patrón CRUD, los podemos agrupar. Este procedimiento tiene algunas ventajas obvias. Primero, el tamaño del modelo será reducido, hará más fácil de entender el modelo porque tiene menos casos. En segundo lugar, nadie estará interesado en un sistema que contiene solamente un subconjunto de estos casos de uso, ya que no generan el valor completo (por ejemplo, leer y dar de baja, pero no crear y cambiar). Agrupar estos flujos juntos en un caso como Administrar X se asegura de que las cuatro operaciones estarán incluidas en el modelo, y lo hace claro para el lector del modelo. Tercero, el valor de cada uno de los flujos por separado es muy pequeño, y podríamos estar cayendo en descomposición funcional; es la colección entera de estas operaciones la que da valor a los interesados.

Las cuatros operaciones no deben ser modeladas como caso de uso independientes.

La variación denominada CRUD: Parcial, indica que en caso de que solo algunas de las cuatro operaciones sean simples mientras que otras son complejas, se puede agrupar las operaciones simples en un caso de uso y dejar las otras modeladas como un caso de uso separado.

Observar también que esto es una situación típica donde un caso de uso no tiene solamente un flujo “básico”. Ninguno de los flujos se puede decir que es más “básico” o “normal” que los otros. Por lo tanto, un caso de uso CRUD tendrá típicamente cuatro flujos básicos, y posiblemente algunos flujos alternativos, como se demuestra en el ejemplo 1.

Una instancia de un caso de uso podrá realizar una de las siguientes operaciones (crear, leer, cambiar y dar de baja), y después dejar de existir. Esta misma instancia del caso de uso no continuará viviendo y esperando la operación siguiente que se realizará. Esta operación debe ser realizada por otra instancia del mismo caso de uso.

Como regla general, cuando no estamos seguros si combinar los diversos casos de usos en uno o crearlos como separados, la recomendación es mantenerlos como uno solo y después cuando se vea el tamaño y complejidad del caso de uso, se deberá tomar la decisión de separarlos si es necesario.

A continuación mostramos un ejemplo de un boceto de caso de uso utilizando el patrón CRUD. Por razones de espacio, no está completo. El objetivo es ejemplificar la aplicación del patrón.

Caso de Uso: Administrar Tarea

Este caso de uso permite registrar, listar, modificar, o eliminar la información de tareas realizadas.

Flujo Básico
El caso de uso tiene cuatro diversos flujos básicos:
Registrar tarea nueva
Modificar una tarea existente
Cancelar tarea
Consultar tarea fallida

Registrar tarea nueva
El caso de uso comienza cuando el usuario elige registrar una nueva tarea.
El sistema presenta una lista de posibles clases de tareas, y pregunta qué clase de tarea debe ser registrada, con qué nombre, y cuando se debe realizar.
El usuario provee la información requerida.
El sistema comprueba que el tiempo especificado es en el futuro y que el nombre de la tarea es único.
El sistema registra la nueva tarea y la marca como activa.
El caso de uso termina.

Modificar tarea
El caso de uso comienza cuando el usuario elige modificar una tarea ya registrada.
El sistema recupera los nombres de todas las tareas no marcadas como activo y las presenta al usuario. El usuario selecciona una de las tareas.
El sistema recupera la información sobre la tarea y la presenta al usuario.
El usuario modifica cualquiera de la información actual excepto el nombre de la tarea.
El usuario acepta la información.
El sistema comprueba si el tiempo especificado es en el futuro y almacena la información modificada.
El caso de caso de uso termina.

Cancelar tarea
El caso de uso comienza cuando el usuario elige cancelar una tarea.
El sistema recupera y despliega todas las tareas futuras.
El usuario selecciona una de las tareas.
El sistema recupera la información sobre la tarea y la presenta al usuario.
El usuario confirma la cancelación, el sistema elimina la tarea; si no se puede, no se hace ninguna modificación.
El caso de uso termina.

Consultar tarea fallida
El caso de uso comienza cuando el usuario elige vista de la lista de todas las tareas que han fallado.
El sistema recoge todas las tareas con el estado fallado y presenta sus nombres al usuario.
El caso de uso termina.

Flujos alternativos
Cancelar la operación
Nombre o Tiempo incorrecto

Otros Patrones de Caso de Uso

Existen varios patrones adicionales al CRUD que son utilizados para modelar sistemas. Esta es una lista de los más importantes:

• Reglas de negocio

• CRUD

• Login

• Reportes y Explotación de información

• Inclusión y Extensión

Conclusión

La técnica de casos de uso nos permite modelar y especificar los requerimientos de nuestro sistema. Tiene muchos beneficios, entre los más importantes: primero nos permite planear nuestro proyecto y segundo ayuda a llegar a acuerdos con los usuarios, para que los casos de uso sean mas claros y mantenibles es importante encontrar patrones y documentarlos, de esta manera cuando nos encontremos con un problema igual o parecido podamos resolverlos en menor tiempo. El concepto de patrones no es algo que solo es aplicable a la práctica de requerimientos. De hecho, la disciplina de requerimientos copia este concepto de la de análisis y diseño. Lo que se busca con los patrones es reutilizar lo aprendido en los nuevos proyectos y usarlos en la organización como estándares.

Referencias
• Pan-Wei Ng, Understanding types of use cases and artifacts. IBM Developerworks.
www-128.ibm.com/developerworks/rational/library/1809.html