Casos de Uso

CASOS DE USO 

Definiciones Básicas
Como mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y
alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese
momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese
caso de uso.

El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal
objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Es importante notar que el nombre del caso siempre está expresado desde el punto de vista del actor y no
desde el punto de vista del sistema. Por eso el segundo caso de uso se llama Recibiendo información de
pedidos y no Generando información de pedidos.

Los casos de uso tienen las siguientes características:
1) Están expresados desde el punto de vista del actor.
2) Se documentan con texto informal.
3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el
énfasis está puesto en la interacción.
4) Son iniciados por un único actor.
5) Están acotados al uso de una determinada funcionalidad –claramente diferenciada– del sistema.
El último punto es tal vez el más difícil de definir. Uno podría, después de todo, decir que todo sistema tiene
un único caso de uso Usando el Sistema.  Sin embargo, la especificación resultante sería de poco utilidad para
entenderlo; sería como implementar un gran sistema escribiendo un único programa.

La pregunta importante es: ¿Qué es una “funcionalidad claramente diferenciada”? Por ejemplo, ¿ingresar
pedidos es un caso de uso y autorizarlos es otro? ¿Cancelar los pedidos, es otro caso de uso, o es parte del
caso de uso referido al ingreso de pedidos? Si bien se pueden encontrar argumentos válidos para cualquiera de
las dos alternativas, en principio la respuesta a todas estas preguntas es que son todos casos de uso distintos.
Lamentablemente, si en la programación los criterios para dividir la funcionalidad en programas suelen ser
difusos, los criterios para dividir la funcionalidad de un sistema en casos de uso son aún más difusos, y por
esto se hace importante usar el sentido común en estas decisiones.    Casos de Uso – Un Método Práctico para Explorar Requerimientos
Cátedra de Ingeniería del Software I Pág. 6
En principio podríamos decir que la regla general es: una función del sistema es un caso de uso si se debe
indicar explícitamente al sistema que uno quiere acceder a esa función. Por ejemplo, si uno quiere dar de alta
un pedido, accederá a la funcionalidad de alta de pedidos del sistema. Sin embargo, si uno quiere dar de alta
un campo del pedido, no debe indicar al sistema que quiere acceder a esa función. Dar de alta un campo de un
pedido es una función que forma parte de un caso de uso mayor: dar de alta un pedido.
Esta regla, si bien puede ser útil, no debe seguirse al pie de la letra, ya que se puede prestar a confusiones. Por
ejemplo, supongamos que uno quiere especificar un sistema en el cual los usuarios pueden ver un pedido, y
tienen disponibles funciones para ver el siguiente pedido, el anterior, el último y el primero. El actor debe
indicar al sistema que quiere acceder a cada una de esas funciones, y según nuestra regla serían todas ellas
casos de uso distintos. Sin embargo, en esta situación es mucho más práctico definir un único caso de uso
navegando pedidos, que especificarlos todos como casos de uso distintos.
Cuando pensamos en el grado de detalle de la división de los casos de uso también resulta útil imaginar que
uno está escribiendo el manual del usuario del sistema. A nadie se le ocurriría escribir un manual de usuario
con un solo capítulo en el que se describe toda su funcionalidad. De la misma forma, no se debe escribir una
especificación con un solo caso de uso. A pesar de saber que uno se quiere mantener lejos de este extremo, la
cantidad de capítulos del manual es variable dependiendo de la persona que lo escriba.
Para dar una idea aproximada del nivel de detalle de la división de los casos de uso en casos menores, también
podemos pensar que un trabajo práctico de Ingeniería del Software I debiera tener alrededor de 8 casos de uso
primarios.
Descripción de los Casos de Uso

Los casos de uso se documentan con texto informal. En general, se usa una lista numerada de los pasos que
sigue el actor para interactuar con el sistema. A continuación se muestra una parte simplificada de la
descripción del caso de uso “Ingresando Pedido”.

Caso de Uso: Ingresando Pedido.
Actor: Empleado de Ventas.
1) El cliente se comunica con la oficina de ventas, e informa su número de cliente
2) El oficial de ventas ingresa el número de cliente en el sistema
3) El sistema obtiene la información básica sobre el cliente
4) El cliente informa el producto que quiere comprar, indicando la cantidad
5) El sistema obtiene la información sobre el producto solicitado, y confirma su
disponibilidad.
6) Se repite el paso 4) hasta que el cliente no informa más productos



Relaciones de Extensión
Muchas veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren sólo en algunas
oportunidades. Supongamos que estamos especificando un sistema en el cual los clientes pueden ingresar
pedidos interactivamente, y que dentro de la funcionalidad del ingreso de pedidos el usuario puede solicitar al sistema que le haga una presentación sobre los nuevos productos disponibles, sus características y sus precios.


Las extensiones tienen las siguientes características:
1) Representan una parte de la funcionalidad del caso que no siempre ocurre.
2) Son un caso de uso en sí mismas.
3) No necesariamente provienen de un error o excepción. En su libro, Jacobson ejemplifica los casos de uso
con ir a cenar a un restaurant. Para él, tomar café después de cenar es un ejemplo de una extensión.

La pregunta que surge claramente es ¿cuál es la diferencia entre una alternativa y una extensión? La respuestapuede derivarse de las características de cada uno:

· Una extensión es un caso de uso en sí mismo, mientras que una alternativa no.
· Una alternativa es un error o excepción, mientras que una extensión puede no serlo.

Es común que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso. Por ejemplo, la funcionalidad de buscar un producto puede ser accedida desde el ingreso de pedidos, desde las consultas de productos, o desde los reportes de ventas por producto. ¿Cómo hago para no repetir el texto de esta
funcionalidad en todos los casos de uso que la acceden? La respuesta es simple: sacando esta funcionalidad a un nuevo caso de uso, que es usado por los casos de los cuales fue sacada. Este tipo de relaciones se llama relaciones de uso y se representa por una línea punteada desde el caso que ‘usa a’ al caso que es ‘usado’.

Al modularizar la especificación, identificando relaciones de uso y extensión, puede pasar que extraigamos
casos de uso que son accedidos por varios actores. Por ejemplo, el caso de uso buscando datos de producto es accedido por muchos actores (el empleado de ventas que ingresa un pedido, el gerente que quiere obtener estadísticas por producto, el supervisor que quiere consultar la información de algún producto, etc.). Ahora bien, como el caso de uso nunca se ejecuta fuera del contexto de otro caso de uso, decimos que es un caso de uso abstracto. Lo llamamos abstracto porque no es implementable por sí mismo: sólo tiene sentido como parte de otros casos.

De la misma forma, el actor que participa de este caso de uso, que reúne características comunes a todos los actores de los casos de uso que lo usan, es un actor abstracto. En nuestro ejemplo, si bien el nombre suena poco elegante, podemos decir que tenemos un actor abstracto “Buscador de Datos de Producto”. Los actores abstractos, entonces, son necesarios para no “dejar sin actores” a los casos de uso abstractos.

La duda ahora es cómo relacionar este actor abstracto con los actores concretos: los que sí existen en la
realidad y ejecutan casos de uso concretos, como ingresando pedido y obteniendo estadísticas de ventas.
Para esto podemos usar el concepto de herencia, uno de los conceptos básicos de la orientación a objetos.
Como todos los actores concretos también ejecutan el caso buscando datos de producto, a través de la
relación de uso, podemos decir que los actores concretos heredan al actor abstracto.

La relación de herencia no necesariamente implica la existencia de un caso abstracto. Puede ocurrir que un
actor ejecute todos los casos que ejecuta otro actor, y algunos más. En nuestro sistema, el supervisor de ventas puede hacer todo lo que hace el empleado de ventas, pero además puede autorizar pedidos. En este caso, podemos decir que el Supervisor de Ventas hereda al Empleado de Ventas, aunque el Empleado de Ventas no sea un actor abstracto. De esta forma, toda la funcionalidad que está habilitada para el Empleado de Ventas también lo está para el Supervisor