MODELADO DE CASOS DE USO

Aunque en un principio se presentaron como un diagrama para usarlo en el UML orientado

a objetos, ahora los casos de uso se utilizan sin importar la metodología para el desarrollo
de sistemas. Se pueden utilizar como parte del SDLC o en el modelado ágil. Un modelo de
caso de uso describe qué hace un sistema sin describir cómo lo hace; es decir, es un
modelo lógico del sistema. El modelo de caso de uso presenta al sistema desde la
perspectiva de un usuario fuera del mismo (por ejemplo, los requerimientos del sistema).
Un analista desarrolla casos de uso en un esfuerzo de cooperación con los expertos de
negocios que ayudan a definir los requerimientos del sistema. El modelo de caso de uso
provee un medio efectivo de comunicación entre el equipo de negocios y el equipo de
desarrollo. Un modelo de caso de uso particiona la forma en que trabaja el sistema en
comportamientos, servicios y respuestas (los casos de uso) que sean importantes para los
usuarios del sistema.
Desde la perspectiva de un actor (o usuario), un caso de uso debe producir algo de valor.
Por lo tanto, el analista debe determinar qué es importante para el usuario y debe
recordar incluirlo en el diagrama del caso de uso. Por ejemplo, ¿introducir una contraseña
es algo de valor para el usuario? Tal vez se deba incluir si al usuario le preocupa la
seguridad o si es algo imprescindible para el éxito del proyecto.

Símbolos de los casos de uso

Un diagrama de caso de uso contiene los símbolos del actor y del caso de uso, junto con
líneas conectoras. Los actores son similares a las entidades externas; existen fuera del
sistema. El término actor se refiere a un rol específico de un usuario del sistema. Por
ejemplo, un actor puede ser un empleado, pero también puede ser un cliente en la tienda
de la empresa. Incluso cuando es la misma persona en el mundo real, se representa como
dos símbolos distintos en un diagrama de caso de uso, ya que la persona interactúa con el
sistema en distintos roles. El actor existe fuera del sistema e interactúa con éste de una
manera específica. Un actor puede ser un humano, otro sistema o un dispositivo como un
teclado o una conexión Web. Los actores pueden iniciar una instancia de un caso de uso.
Un actor puede interactuar con uno o más casos de uso; un caso de uso puede involucrar
a uno o más actores.
Los actores se pueden dividir en grupos. Los actores principales suministran datos o
reciben información del sistema. Algunos usuarios interactúan en forma directa con el
sistema (actores del sistema), pero los actores principales también pueden ser personas
de negocios que no interactúen directamente con el sistema, sino que participen en cierta
forma. Los actores principales son importantes ya que son las personas que usan el sistema
y pueden proveer los detalles acerca de lo que debería hacer el caso de uso. También
pueden proveer una lista de objetivos y prioridades. Los actores de soporte (también
conocidos como actores secundarios) ayudan a mantener el sistema en funcionamiento o
a proveer otros servicios; son las personas que operan el departamento de soporte técnico,
los analistas, los programadores, etcétera.
Algunas veces es conveniente crear un perfil de actor que enliste a los actores, su historial
y sus habilidades en un formato de tabla. Esto puede ser útil para entender cómo
interactúa el actor con el sistema. Por ejemplo, el perfil del Especialista de procesamiento
de pedidos sería: “Un usuario rutinario del software, familiarizado con las características
menores, las excepciones de los pedidos y la personalización de pedidos”. También es
conveniente hacer una lista de los actores junto con sus objetivos y prioridades. Cada
objetivo se puede convertir en un caso de uso.
Un caso de uso provee a los desarrolladores una perspectiva de lo que quieren los usuarios,
sin detalles técnicos o implementación. Podemos considerar un caso de uso como una
secuencia de transacciones en un sistema. El modelo de casos de uso se basa en las
interacciones y relaciones de casos de uso individuales.
Un caso de uso siempre describe tres cosas: un actor que inicia un evento, el evento que
desencadena un caso de uso y el caso de uso que realiza las acciones desencadenado por
el evento. En un caso de uso, un actor que utiliza el sistema inicia un evento que comienza
una serie relacionada de interacciones en el sistema. Los casos de uso se utilizan para
documentar una transacción o evento únicos. Un evento es una entrada para el sistema
que ocurre a una hora y lugar específicos, y provoca que el sistema haga algo.
Es mejor crear menos casos de uso que un exceso de ellos. A menudo no se incluyen las
consultas y los informes; 20 casos de uso (y no más de 40 o 50) son suficientes para un
sistema grande. Los casos de uso también se pueden anidar, si es necesario. Algunos casos
de uso utilizan el verbo administrar para agrupar casos de uso de manera que se puedan
agregar, eliminar y cambiar a otro diagrama de casos de uso de menor nivel. Usted puede
incluir un caso de uso en varios diagramas, pero el verdadero caso de uso está definido
sólo una vez en el repositorio. El nombre de un caso de uso consta de un verbo y un
sustantivo.

Relaciones de los casos de uso

Las relaciones activas se conocen como relaciones de comportamiento y se utilizan
principalmente en los diagramas de casos de uso. Hay cuatro tipos básicos de relaciones
de comportamiento: comunica, incluye, extiende y generaliza. Observe que todos estos
términos son verbos. En la figura 2.6 se muestran las flechas y líneas que se utilizan para
dibujar diagramas de cada uno de los cuatro tipos de relaciones de comportamiento. A
continuación, describiremos estas cuatro relaciones.

Figura 2.6

COMUNICACIÓN Esta relación de comportamiento se utiliza para conectar un actor con un

caso de uso. Recuerde que la tarea del caso de uso es proporcionar cierto tipo de resultado
que sea benéfico para el actor en el sistema. Por lo tanto, es importante documentar
estas relaciones entre los actores y los casos de uso. En nuestro primer ejemplo, un
Estudiante se comunica con Inscribir en el curso. En los diagramas de casos de uso de la
figura
2.7 se muestran ejemplos de algunos componentes de un ejemplo de inscripción de
estudiantes.

Figura 2.7

INCLUSIÓN Esta relación (también conocida como relación de usos) describe la situación
en la que un caso de uso contiene comportamiento común para más de un caso de uso. En
otras palabras, el caso de uso común se incluye en los otros casos de uso. Una flecha
punteada que apunta al caso de uso común indica la relación de inclusión. Un ejemplo
sería un caso de uso Pagar cuotas de estudiantes que se incluye en Inscribir en el curso y
Hacer arreglos de hospedaje, ya que en ambos casos los estudiantes deben pagar sus
cuotas. Varios casos de uso pueden usar esto. La flecha apunta hacia el caso de uso común.

EXTENSIÓN Esta relación describe la situación en la que un caso de uso posee el

comportamiento que permite al nuevo caso de uso manejar una variación o excepción a
partir del caso de uso básico. Por ejemplo, el caso de uso extendido Seguro médico de
estudiantes extiende el caso de uso básico Pagar cuotas de estudiantes. La flecha va del
caso de uso extendido al caso de uso básico.

GENERALIZACIÓN Esta relación implica que una cosa es más común que otra. Esta relación
puede existir entre dos actores o dos casos de uso. Por ejemplo, un Estudiante de medio
tiempo generaliza a un Estudiante. De manera similar, algunos de los empleados de la
universidad son profesores. La flecha apunta a la cosa general.

Desarrollo del alcance del sistema

El alcance de un sistema define sus límites, lo que está al alcance (dentro del sistema) y
lo que está fuera de él. Por lo general el proyecto cuenta con un presupuesto que ayuda
a definir el alcance, además del tiempo inicial y final. Los actores siempre están fuera del
alcance del sistema. Las líneas de comunicación que conectan a los actores con los casos
de uso son los límites y definen el alcance. Como un diagrama de caso de uso se crea du-
rante las primeras etapas del ciclo de vida de los sistemas, el presupuesto, tiempo inicial
y final pueden cambiar a medida que avanza el proyecto; a medida que el analista aprende
más sobre el sistema, tal vez cambien los diagramas del caso de uso, el caso de uso y el
alcance.

Desarrollo de diagramas de casos de uso

El caso de uso principal consiste en un flujo estándar de eventos que describe un
comportamiento estándar del sistema. El caso de uso principal representa la terminación
normal, esperada y exitosa del caso de uso.
Para crear un diagrama de un caso de uso, empiece por pedir a los usuarios una lista de
todo lo que el sistema deba hacer por ellos. Esto se puede realizar mediante entrevistas,
en una sesión de diseño de aplicación conjunta o a través de otras sesiones guiadas en
equipo. El analista también puede utilizar sesiones de historias ágiles para desarrollar
casos de uso. Anote quién está involucrado con cada caso de uso y las responsabilidades o
servicios que el caso de uso debe proveer a los actores o a los otros sistemas. En las fases
iniciales, ésta puede ser una lista parcial que se expanda en las fases de análisis
posteriores. Use los siguientes lineamientos:

• Revise las especificaciones de negocios e identifique a los actores involucrados.

• Identifique los eventos de alto nivel y desarrolle los casos de uso principales que
describen a esos eventos junto con la forma en que los actores los inician. Examine
con cuidado los roles que desempeñan los actores para identificar todos los
posibles casos de uso principales iniciados por cada actor. No necesita mostrar los
casos de uso que tengan poca o nula interacción del usuario.
• Revise cada caso de uso principal para determinar las posibles variaciones del flujo
a través del caso de uso. Con base en este análisis establezca las rutas alternativas.
Debido a que generalmente el flujo de eventos es distinto en cada caso, busque
actividades que podrían tener éxito o fracasar. Busque además las ramificaciones
en la lógica del caso de uso en donde sea posible obtener distintos resultados.

Desarrollo de escenarios de casos de uso

Cada caso de uso tiene una descripción. Designaremos a la descripción como un escenario
de caso de uso. Como dijimos antes, el caso de uso principal representa el flujo estándar
de eventos en el sistema y las rutas alternativas escriben variaciones sobre el
comportamiento. Los escenarios de casos de uso pueden describir lo que ocurre al comprar
un artículo agotado, o si una empresa de tarjetas de crédito rechaza la compra solicitada
por un cliente.
No hay un formato estandarizado para los casos de uso, por lo que cada organización tiene
que especificar los estándares a incluir. A menudo, los casos de uso se documentan
mediante una plantilla de documento de caso de uso predeterminada por la organización,
que facilita la lectura de los casos de uso y provee información estandarizada para cada
caso de uso en el modelo.