Casos De Uso

Casos de Uso Avanzados: El Tiempo como Actor
Un actor es cualquier entidad externa al sistema que demanda una funcionalidad de este. Con esta definición en la mano uno puede pensar que todos los operadores, administradores, supervisores y gerentes de la tierra han sido incluidos; ciertamente así ha sido, pero resulta curioso observar que se incluyen también entidades no humanas, como el tiempo.Aunque claramente el tiempo es una entidad externa al sistema (por lo que cumple con la primera mitad de la definición) difícilmente podremos pensar que el tiempo se encuentra interesado en una funcionalidad de nuestro sistema.
Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas endeterminados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de casos de uso.
La técnica es introducir al actor “Tiempo”, quien esta asociado a casos de uso que capturen la funcionalidad que debamos disparar en el momento especificado. De esta forma resulta por completo natural el expresar nuestrasfuncionalidad automáticas por medio de los casos de uso, incluso cuando no hay un actor claro involucrado en la operación. De cierta forma, aquí la expresión sistema interactivo cobra un nuevo significado pero una vez aceptado, el resultado es enteramente comprensible y aceptable.
El siguiente diagrama de casos de uso ilustra el punto:Fig. 1 – Diagrama UML de Casos de Uso con el Tiempo como Actor

La generación de reportes, la creación de copias de datos, la eliminación de archivos temporales, entre otras cosas, pueden ahora salir del documento de requisitos suplementarios y ser capturadas ahí donde son más visibles para nosotros: justo en nuestro modelador de UML.

Casos a incluír y casos a extender
Un tema que generamucha polémica entre la gente que modela casos de uso es la elección entre la relación de <<include>> y <<extend>>. Lo peor es que muchas de esas discusiones generan muy poco valor en el resultado final en el modelo y en cambio quitan tiempo valioso del proyecto. Esto se debe a que dichas relaciones, muchas veces no son del todo comprendidas por la persona que la modela, ymucho menos son comprendidas por las personas que leen el modelo. Así que al final no se le saca el provecho que en todo caso debería de tener dicha elección.
Es mejor mantener el modelo simple, incluso si esto significa utilizar menos elementos gráficos de UML, si eso va a facilitar el modelado y la comunicación en el proyecto. Pero, después de todo este tiempo y de los diferentes temas que hemosvenido tratando, es importante avanzar y adentrarnos en algunos pormenores del lenguaje unificado.
Antes que todo, ¿qué es el “include” y el “extend”?

Gráficamente lo que mostramos es una relación de dependencia entre el par de casos de uso, con el nombre correspondiente al tipo de relación de la que se trate: ya sea <<include>> o <<extend>>.
Estas, son relaciones queusamos para ligar gráficamente dos casos de uso, cuyos flujos de eventos están unidos, normalmente en una sola sesión del usuario. En otras palabras, un caso de uso que está ligado, por medio de una de estas dos relaciones, a otro caso de uso; también podría leerse o ejecutarse como un sólo caso de uso en lugar de dos. Obviamente, hay una razón por la cual decidimos separarlos en dos, lo cualexplicaremos más adelante.
Imagina el conjunto de pasos que ocurren al realizar una compra en una tienda departamental. Seguramente no tendrás problema en visualizar el conjunto de pasos para solicitar la autorización de la tarjeta de crédito con la que vas a pagar, ligado a los pasos donde el vendedor registra los productos a comprar. Es decir, los flujos de eventos de ambos procesos forman una...