Guías de desarrollo
Patrones CRUD para 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. En esta entrada, 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:
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: 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.  (*) Considere el modelo solo de forma referencial.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ásicoEl caso de uso tiene cuatro diversos flujos básicos:
Registrar tarea nueva
Modificar tarea
Cancelar tarea
Consultar tarea fallida
Flujos alternativos
Existen varios patrones adicionales al CRUD que son utilizados para modelar sistemas. Esta es una lista de los más importantes:
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
Acerca del autor Saúl Cuesta Rodríguez es consultor de ITERA especializado en las prácticas de requerimientos y modelado de negocios. Es graduado de la Universidad Tecnológica de Panamá como Ing. en Sistemas. |
1-1 of 1