INTRODUCCION

Ningún sistema existe de manera aislada. Todo sistema interesante interacciona

con actores humanos o automatizados que utilizan el sistema con algún
propósito, y esos actores esperan que el sistema se comporte
previsiblemente. Un caso de uso especifica el comportamiento de un sistema o
una parte de él y es la descripción de un conjunto de secuencias de acciones,
incluyendo variaciones, que un sistema realiza para producir un resultado de
valor observable por un actor.

Los casos de uso capturan el comportamiento del sistema que se está

desarrollando, sin tener que especificar cómo se implementa ese
comportamiento. Los casos de uso proporcionan a los desarrolladores una ruta
para lograr un entendimiento común con los usuarios finales del sistema y
expertos del dominio. Además, los casos de uso sirven para validar la
arquitectura y para verificar que el sistema evolucione durante el desarrollo de
manera congruente.
 CASOS DE USO

CONCEPTO

Cuando empezamos a analizar un problema con el propósito de implementar

una solución en software podemos usar los casos de uso como una herramienta
de análisis de los requerimientos. Los casos de uso contestan las preguntas:

 ¿Quiénes son los diferentes usuarios del sistema y qué papeles

desempeñan?
 ¿Qué necesita cada usuario que realice el sistema?
 ¿Cuáles son los pasos que deben seguirse para que el sistema satisfaga
las necesidades de cada usuario?

Un factor importante al crear casos de uso es que se hace sin especificar cómo
el caso de uso se implementa. Por ejemplo, se puede especificar cómo un
sistema de cajero bancario debería comportarse al enunciar en casos de uso de
la manera en que los usuarios interactúan con el sistema. No se necesita saber
nada acerca de los aspectos internos del cajero. Los casos de uso especifican
el comportamiento deseado, no dictan cómo debe llevarse a cabo el
comportamiento. Lo importante de este enfoque es que permite (al usuario final
y experto del dominio) comunicarse con los desarrolladores (quienes construyen
sistemas para satisfacer tus requerimientos) sin quedar atrapado en detalles.
Esos detalles llegarán, pero los casos de uso permiten enfocarse en aspectos
de alto riesgo para desarrollar el sistema.

En el Lenguaje de Modelado Unificado (UML), todo este comportamiento se

modela como casos de uso que pueden ser especificado independientemente
de su cómo se implementarán en código. Un caso de uso es una descripción de
un conjunto de secuencias de acciones, incluyendo variaciones, que un sistema
realiza para lograr un resultado observable de valor para un actor. En esta
definición, existe un número importante de partes.

Un caso de uso describe un conjunto de secuencias, en las cuales cada

secuencia representa la interacción de cosas fuera del sistema (actores) con el
sistema (y sus abstracciones clave). Estos comportamientos son funciones a
nivel del sistema que acostumbra visualizar, especificar, construir y documentar
en la fase de obtención y análisis de los requerimientos. Un caso de uso
representa un (o más) requerimiento funcional completo del sistema. Por
ejemplo, un caso de uso central de un banco es procesar préstamos.

Un caso de uso involucra la interacción de actores con el sistema. Un actor

representa un conjunto de roles coherente que los usuarios del caso de uso
juegan cuando interactúan con el sistema. Los actores pueden ser personas o
sistemas automatizados. Por ejemplo, en el modelado bancario, el
procesamiento de un préstamo involucra, entre otras cosas, la interacción entre
un cliente y el ejecutivo de préstamos.

Un caso de uso puede tener variaciones. En todos los sistemas interesantes, se

encuentran casos de uso que son versiones especializadas de otros casos de
uso, casos de uso que son incluidos como parte de otros casos de uso y casos
de uso que extienden el comportamiento de otros casos de uso centrales. Se
puede separar el comportamiento reutilizable y común de un conjunto de casos
de uso al organizarlos de acuerdo a estas tres clases de relaciones:
generalización, inclusión y extensión. Por ejemplo, en el modelado del banco, se
encuentran muchas variaciones entre el caso de uso básico para procesar un
préstamo, así como la diferencia entre procesar una gran hipoteca contra un
préstamo para un pequeño comercio. En cada caso, sin embargo, estos casos
de uso comparten en algún grado comportamiento común, tal como la
calificación del cliente para el préstamo, un comportamiento que es una parte del
procesamiento de cada clase de préstamo.

Un caso de uso lleva a cabo alguna cantidad de trabajo tangible. Desde la

perspectiva de un actor dado, un caso de uso hace algo que es de valor para el
actor, tal como calcular un resultado, generar un nuevo objeto o cambiar el
estado de otro objeto. Por ejemplo, en el modelo del banco, el procesamiento de
un préstamo resulta en la entrega de un préstamo aprobado, manifestado por el
dinero en las manos del cliente.

Los casos de uso se pueden aplicar al sistema completo, pero también a una
parte del sistema, incluyendo subsistemas y aún clases individuales e interfaces.
En cada caso, estos casos de uso no sólo representan el comportamiento
deseado de estos elementos, sino que también pueden ser usados como una
base para casos de prueba de estos elementos conforme evolucionan en el
desarrollo. Los casos de uso aplicados a subsistemas son fuentes excelentes
de pruebas de regresión. Los casos de uso aplicados a los subsistemas son
fuentes excelentes de pruebas de integración y de sistema. El UML, proporciona
una representación gráfica de un caso de uso y un actor, como lo muestra la
figura 1. Esta notación permite visualizar un caso de uso independiente de su
implementación y en el contexto de otros casos de uso.
ELEMENTOS DE CASO DE USO
LIMITE DEL SISTEMA

agrupa casos de uso dentro de un mismo sistema. Útil cuando tenemos varios
sistemas / subsistemas.

EXTENDED
La polémica al querer seleccionar una de las dos relaciones es que en el “extend”
también podemos ver, desde la perspectiva del usuario, a los dos flujos como si
fueran uno sólo. Y en ciertos escenarios el caso de uso base no podría cumplir
su objetivo si no se ejecutara la extensión. Pero, una de las diferencias básicas
es que en el caso del “extend” hay situaciones en que el caso de uso de
extensión no es indispensable que ocurra, y cuando lo hace ofrece un valor extra
(extiende) al objetivo original del caso de uso base. En cambio, en el “include”
es necesario que ocurra el caso incluído, tan sólo para satisfacer el objetivo del
caso de uso base. Ejemplo: Puedes “Realizar Venta” sin “Acumular Puntos de
Cliente VIP”, cuando no eres un cliente VIP. Pero, si eres un cliente VIP sí
acumularás puntos. Por lo tanto, “Acumular Puntos” es una extensión de
“Realizar Venta” y sólo se ejecuta para cierto tipo de ventas, no para todas.