Patrones de Casos de Uso

Patrones de Casos de Uso

Los Patrones de Casos de Uso. Son comportamientos que deben existir en el sistema, ayudan a describir qué es lo que el sistema debe hacer, es decir, describen el uso del sistema y cómo este interactúa con los usuarios. Estos patrones son utilizados generalmente como plantillas que describen como debería ser estructurados y organizados los casos de uso. Son patrones que capturan mejores prácticas para modelar casos de uso.

Aplicación

La aplicación de los patrones de casos de uso trae los siguientes beneficios:

• Aumentar la productividad.
• Reutilizar elementos existentes (en este caso fragmentos de modelos)
• Evitar el re trabajo 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.

Patrón CRUD

Nombre: CRUD
Intento: Este patrón 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 ingles Create, Read, Update, Delete.
Palabras Claves: Creación, altas, bajas, cambios.

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 eliminar o 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.

CRUD Parcial

Descripción: Algunas 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 de 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 del 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 solo 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 casos 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 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.

Patrón: Concordancia (Commonality)

Extrae una subsecuencia de acciones que aparecen en diferentes lugares del flujo de Casos de Uso y es expresado por separado. Tiene dos variantes.

Reuso

Consta de 3 casos de uso. El primero llamado subsecuencia común, modela una secuencia de acciones que aparecerán en múltiples casos de uso en el modelo. Los otros casos de uso modelan el uso del sistema que comparte la subsecuencia común de acciones. De manera que deben existir al menos dos de ellos. A continuación se muestra un ejemplo de su uso.

Adición

En el caso de este patrón alternativo, la subsecuencia común de casos de uso, extiende los casos de uso compartiendo la subsecuencia de acciones. Los otros casos de uso modelan el flujo que será expandido con la subsecuencia. Este patrón es preferible usarlo cuando otros casos de uso se encuentran propiamente completos, o sea, que no requieren de una subsecuencia común de acciones para modelar los usos completos del sistema. Ejemplo de su uso, se muestra en la siguiente figura:

Patrón: Extensión Concreta o Inclusión

Este patrón está dividido en concreta extensión o concreta inclusión.

Extensión:

Consiste en dos casos de uso y una relación extendida entre ellos. Puede ser instalado en sí mismo, así como extendido en el caso de uso base. El referente puede ser concreto o abstracto. Este patrón se aplica cuando un flujo puede extender el flujo de otro caso de uso así como ser realizado en sí mismo. Un ejemplo de su uso se evidencia en la siguiente figura:<bt>

Inclusión:

Se incluye una relación del caso de uso base al caso de uso de inclusión. El último puede ser instalado en sí mismo. El caso de uso base puede ser concreto o abstracto. Como ejemplo de su aplicación se puede ver la figura que a continuación se muestra:

Múltiples Actores

A un Caso de Uso ingresan más de dos actores y estos tienen un rol común. Ejemplo: Se tiene el siguiente caso donde en un sistema web dos actores acceden a un mismo caso de uso.

Aplicando el patrón nos quedaría de la siguiente manera

Otros Patrones

• Reglas del Negocio
• Login
• Reportes y explotación de información
• Sistema en capas
• Jerarquía de componentes
• Servicios Opcionales

==Conclusiones==

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 más 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.

Fuentes

• Pan-Wei Ng, Understanding types of use cases and artifacts. IBM Developer works.
• LARMAN, C. UML Y Patrones. Introducción al análisis y diseño orientado a objeto. México 1999.