Un caso de uso es una descripción de los pasos o las actividades que
deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades
que participarán en un caso de uso se denominan actores. En el contexto de
ingeniería del software, un caso de uso es una secuencia de interacciones que
se desarrollarán entre un sistema y sus actores en respuesta a un evento que
inicia un actor principal sobre el propio sistema. Los diagramas de casos de
uso sirven para especificar la comunicación y el comportamiento de un sistema
mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual,
un diagrama que muestra la relación entre los actores y los casos de uso en un
sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo,
la especialización y la generalización son relaciones. Los diagramas de casos
de uso se utilizan para ilustrar los requisitos del sistema al mostrar cómo
reacciona a eventos que se producen en su ámbito o en él mismo.
Su uso es común para la captura de requisitos funcionales, especialmente
con el paradigma de la programación orientada a objetos, donde se originaron,
si bien puede utilizarse con resultados igualmente satisfactorios con otros
paradigmas de programación.
El diagrama de casos de uso representa la forma en como un Cliente
(Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en
como los elementos interactúan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Actor:
Una definición previa, es que un Actor es un rol que un usuario juega
con respecto al sistema. Es importante destacar el uso de la palabra rol, pues
con esto se especifica que un Actor no necesariamente representa a una persona
en particular, sino más bien la labor que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de
ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por
un Vendedor o bien por el Jefe de Local.
Caso de
uso:
Es una operación/tarea específica que se realiza tras una orden de algún
agente externo, sea desde una petición de un actor o bien desde la invocación
desde otro caso de uso.
Relaciones:
-
Asociación:
Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. - Dependencia o instanciacion:
Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada. - Generalizacion:
Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde está la duda clásica de usar o heredar.
Ejemplo:
Como ejemplo está el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y
jabas. El sistema debe controlar y/o aceptar:
- Registrar el número de ítems ingresados.
- Imprimir un recibo cuando el usuario lo solicita:2.1. Describe lo depositado.
2.2. El valor de cada ítem.
2.3. Total. - El usuario/cliente presiona el botón de comienzo.
- Existe un operador que desea saber lo siguiente: 4.1. Cuantos ítems han sido retornados en el día.
4.2. Al final de cada día el operador solicita un resumen de todo lo depositado en el día. - El operador debe además poder cambiar:
5.1.Información asociada a ítems.
5.2. Dar una alarma en el caso de que:
5.2.1. Item se atora.
5.2.2. No hay más papel.
Como una primera aproximación identificamos a los actores que interactúan
con el sistema:
Luego, tenemos que un Cliente puede Depositar Ítems y un Operador puede
cambiar la información de un Item o bien puede Imprimir un informe:
Además, podemos notar que un ítem puede ser una Botella, un Tarro o una
Jaba.
Otro aspecto es la impresión de comprobantes, que puede ser realizada
después de depositar algún ítem por un cliente o bien puede ser realizada a
petición de un operador.
Entonces, el diseño completo del diagrama Caso de uso es:
