Modelo de Casos de Uso

MODELO DE CASOS DE USO

El modelo de casos de uso describe un sistema en términos de sus distintas formas de utilización, cada una de las cuales se conoce como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario. Dado que los casos de uso describen el sistema a desarrollarse, los cambios en los requisitos significarán cambios en los casos de uso. Por ejemplo, un caso de uso para manejar un automóvil sería la consecuencia de eventos desde que el conductor entra al coche y enciende el motor hasta llegar a su destino final. Por tanto, para comprender los casos de uso de un sistema primero es necesario saber quiénes son sus usuarios; por ejemplo, conducir un automóvil es distinto de arreglarlo, pues los usuarios también son diferentes: el dueño del automóvil y el mecánico, respectivamente. Para ello, se define el concepto de actor, que es el tipo de usuario que está involucrado en la utilización de un sistema, y que además es una entidad externa al propio sistema. Juntos, el actor y el caso de uso, representan los dos elementos básicos de este modelo, lo cual se muestra de manera gráfica en la figura 6.3 de acuerdo con la notación UML.

Figura 6.3 El actor y el caso de uso son las entidades básicas del modelo de casos de uso.

Los casos de uso son ideas simples y prácticas que no requieren muchas habilidades tecnológicas para ser utilizadas (a diferencia de las demás actividades del desarrollo). Por el contrario, si se volvieran muy complejas se perdería su utilidad. Dado que el modelo de requisitos es la primera actividad del desarrollo del sistema, permite hacer muchos cambios en su especificación sin afectar al resto del sistema. Cuando se identifican y describen los casos de uso, habrá ciertas imprecisiones que se irán resolviendo de manera gradual. 

De esta manera, se pueden desarrollar de forma independiente los distintos casos de uso, habrá ciertas imprecisiones que se irán resolviendo de manera gradual. De esta manera, se pueden desarrollar de forma independiente los distintos casos de uso para después integrarlos y formar el modelo de requisitos completo. Esta habilidad de tomar parte de la funcionalidad permite un desarrollo más flexible, incluso concurrente.

6.2.1 Actores

Los actores son entidades distintas a los usuarios, en el sentido de que éstos son las personas reales que utilizarán el sistema, mientras que los actores representan cierta función que una persona real realiza. En la terminología orientada a objetos, se considera al actor una clase  de usuario, mientras que los usuarios se consideran como objetos o instancias de esa clase. Incluso, una misma persona puede aparecer como diversas instancias de diferentes actores.

Los actores modelan cualquier entidad externa que necesite intercambiar información con el sistema. No están restringidos a ser personas físicas, por lo que pueden representar otros sistemas externos al actual. Lo esencial es que los actores representen entidades externas al sistema. Además, cada uno de estos actores podrá ejecutar una o más tareas del sistema.

Antes de identificar los casos de uso, se identifican los actores del sistema, esto es para que éstos sean la herramienta principal que permita encontrar los casos de uso en el sistema. Una vez definidos todos los actores y casos de uso en el sistema, se establece la funcionalidad completa de éste.

Encontrar actores implica trabajo y raramente se encuentran todos los actores de una vez. Por ejemplo, un sistema de computación  puede tener diferentes tipos de usuarios: programadores, operadores, administradores o usuarios generales. Cada uno de estos tipos de usuario corresponde a un actor diferente y, como mencionamos anteriormente, una misma persona puede desempeñar la función de programador u operador.

Para especificar los actores de un sistema, se dibuja un diagrama correspondiente a la delimitación del sistema, la cual representa al sistema como “una caja negra”, y a los diferentes actores, como entidades externas a ésta, como se muestra en la figura 6.4.

Figura 6.4 Delimitación de un sistema según los actores

En general, no se describen los actores con demasiado detalle por ser externos al sistema, además de que sus acciones no son deterministas; en otras palabras, un actor – a diferencia del propio sistema – en cada momento puede decidir entre múltiples opciones. Por otro lado, el sistema y los casos de usos correspondientes deben ser deterministas, de lo contrario, el sistema y los casos de uso correspondientes deben ser deterministas, de lo contrario, el sistema hará lo que crea conveniente, lo cual no es aceptable. Sin embargo, para reconocer los casos de uso, es necesario identificar primero a los actores del sistema, comenzando por aquellos que son la razón principal del sistema, conocidos como actores primarios. Estos actores típicamente rigen la secuencia lógica de ejecución del sistema. Además de los actores primarios, existen actores supervisando y manteniendo el sistema, a los que se les llama actores secundarios y existen primordialmente como complemento a los actores primarios, siendo esta distinción importante para dedicarle el esfuerzo principal a las necesidades de los actores primarios.

Al contrario de éstos, que típicamente pertenecen a personas físicas, los actores secundarios corresponden, por lo general a máquinas o sistemas externos (éstos últimos son más difíciles de identificar). Los actores secundarios tienden a responder a secuencias lógicas del sistema y no tanto a inicializarlas de manera propia. En particular, existe siempre la duda, por ejemplo, de si el sistema operativo o una base de datos serían actores. La decisión depende de la función que desempeñen con respecto al sistema en desarrollo, si desempeñan una función activa entonces deben modelarse como actores.

Retomando la descripción del Sistema de Reservaciones de Vuelos, se puede identificar al menos un actor, el Usuario; quien está encargado de hacer las consultas y reservaciones en el sistema. Si se analiza un poco más, se puede identificar que las bases de datos de los sistemas externos de reservaciones tienen una función muy activa con respecto al sistema en desarrollo. A este actor lo llamaremos la Base de Datos de Reservaciones, el cual mantiene la información sobre los vuelos y reservaciones. Más aún, podemos identificar un actor adicional, representando una segunda base de datos, que se involucre en la información de los usuarios más que de las reservaciones.

A este actor lo llamaremos la Base de Datos de Registros, encargado de mantener la información de los usuarios sobre la utilización del sistema. El diagrama de delimitación del sistema con los actores correspondientes se muestra en la figura 6.5

Figura 6.5 Delimitación del sistema de reservaciones de vuelo.

Volviendo a la distinción entre actor y persona, una misma persona puede desempeñar la función del actor Usuario cuando hace reservaciones, y además puede trabajar para el mismo sistema de reservaciones, por ejemplo como operador, que correspondería a otro actor no mostrado en nuestro ejemplo.

El actor Usuario se considera un actor primario, ya que el sistema se construye pensando en sus usuarios, mientras que Base de datos de Reservaciones y Base de Datos de Registros son ambos actores secundarios, ya que si no existieran usuarios no habría necesidad del sistema.

Cuando diferentes actores realizan roles similares, pueden heredar de un actor abstracto común, como lo muestra el actor abstracto Base de Datos en el ejemplo de la figura 6.6 El resto de los actores se conoce como actores concretos, y utilizan terminología similar a la de herencia.

Figura 6.5 Delimitación del sistema de reservaciones de vuelo.

Volviendo a la distinción entre actor y persona, una misma persona puede desempeñar la función del actor Usuario cuando hace reservaciones, y además puede trabajar para el mismo sistema de reservaciones, por ejemplo como operador, que correspondería a otro actor no mostrado en nuestro ejemplo.

El actor Usuario se considera un actor primario, ya que el sistema se construye pensando en sus usuarios, mientras que Base de datos de Reservaciones y Base de Datos de Registros son ambos actores secundarios, ya que si no existieran usuarios no habría necesidad del sistema.

Cuando diferentes actores realizan roles similares, pueden heredar de un actor abstracto común, como lo muestra el actor abstracto Base de Datos en el ejemplo de la figura 6.6 El resto de los actores se conoce como actores concretos, y utilizan terminología similar a la de herencia.

Figura 6.6 Delimitación del sistema de reservaciones de vuelo con ejemplo de herencia entre actores.

La ventaja de modelar actores abstractos es que expresan similitudes entre casos de uso. Si el mismo o parte del mismo caso de uso se puede ejecutar por varios actores diferentes, el caso de uso necesita ser especificado sólo con respecto a un actor en lugar de varios. Por otro lado, los actores abstractos también pueden utilizarse para especificar privilegios comunes a múltiples actores en un sistema.