Casos de Uso (Use Case)

Introduccin
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, adems de la forma,
tipo y orden en como los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicacin.
Elementos
Actor:
Una definicin preia, es !ue un Actor es un rol !ue un usuario "uega con respecto al sistema. Es importante destacar el uso
de la pala#ra rol, pues con esto se especifica !ue un Actor no necesariamente representa a una persona en particular, sino
ms #ien la la#or !ue reali$a frente al sistema.
Como e"emplo a la definicin anterior, tenemos el caso de un sistema de entas en !ue el rol de %endedor con respecto al
sistema puede ser reali$ado por un %endedor o #ien por el &efe de 'ocal.
Caso de Uso:
Es una operacin(tarea espec)fica !ue se reali$a tras una orden de alg*n agente e+terno, sea desde una peticin de un actor
o #ien desde la inocacin desde otro caso de uso.
Relaciones:
o Asociacin
Es el tipo de relacin ms #sica !ue indica la inocacin desde un actor o caso de uso a otra operacin (caso de
uso). ,ic-a relacin se denota con una flec-a simple.
o Dependencia o Instanciacin
Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se
crea). ,ic-a relacin se denota con una flec-a punteada.
o Generalizacin
Este tipo de relacin es uno de los ms utili$ados, cumple una do#le funcin dependiendo de su estereotipo, !ue
puede ser de Uso (..uses//) o de Herencia (..e+tends//).
Este tipo de relacin esta orientado e+clusiamente para casos de uso (y no para actores).
extends: 0e recomienda utili$ar cuando un caso de uso es similar a otro (caracter)sticas).
uses: 0e recomienda utili$ar cuando se tiene un con"unto de caracter)sticas !ue son similares en ms de un caso de
uso y no se desea mantener copiada la descripcin de la caracter)stica.
,e lo anterior ca#e mencionar !ue tiene el mismo paradigma en dise1o y modelamiento de clases, en donde esta la
duda clsica de usar o heredar.
Ejemplo:
Como e"emplo esta el caso de una 2!uina Recicladora:
0istema !ue controla una m!uina de reciclamiento de #otellas, tarros y "a#as. El sistema de#e controlar y(o aceptar:
Registrar el n*mero de )temes ingresados.
3mprimir un reci#o cuando el usuario lo solicita:
a. ,escri#e lo depositado
#. El alor de cada item
c. 4otal
El usuario(cliente presiona el #otn de comien$o
E+iste un operador !ue desea sa#er lo siguiente:
a. Cuantos )temes -an sido retornados en el d)a.
#. Al final de cada d)a el operador solicita un resumen de todo lo depositado en el d)a.
El operador de#e adems poder cam#iar:
a. 3nformacin asociada a )temes.
#. ,ar una alarma en el caso de !ue:
i. 3tem se atora.
ii. 5o -ay ms papel.
Como una primera apro+imacin identificamos a los actores !ue interactuan con el sistema:
'uego, tenemos !ue un Cliente puede ,epositar 3temes y un 6perador puede cam#iar la informacin de un 3tem o #ien puede
3mprimir un informe:
Adems podemos notar !ue un item puede ser una 7otella, un 4arro o una &a#a.
6tro aspecto es la impresin de compro#antes, !ue puede ser reali$ada despu8s de depositar alg*n item por un cliente o #ien puede
ser reali$ada a peticin de un operador.
Entonces, el dise1o completo del diagrama Use Case es: