¿Qué son los Casos de Uso?
Los casos de uso son una técnica para especificar el comportamiento de un sistema:
“Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus
servicios.”
Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios. Un caso de uso es
una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos “alguien o algo”
hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de
hardware y software.
Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo
pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso
de uso ingresando pedido.
HISTORIA
Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Sin embargo, la idea de
especificar un sistema a partir de su interacción con el entorno es original de Mc Menamin y Palmer, dos
precursores del análisis estructurado, que escribieron en 1984 un excelente libro cuya lectura recomendamos
[McMenamin84]. En ese libro, se define un concepto muy parecido al del caso de uso: el evento. Para Mc
Menamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe
responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de ventas tendrá un evento “Cliente hace
Pedido”. En este caso el sistema deberá responder al estimulo que recibe –el pedido– procesándolo.
Casos de Uso – Un Método Práctico para Explorar Requerimientos
Cátedra de Ingeniería del Software I Pág. 2
Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las principales son:
1) Los eventos se centran en describir qué hace el sistema cuando el evento ocurre, mientras que los casos
de uso se centran en describir cómo es el diálogo entre el usuario y el sistema.
2) Los eventos son “atómicos”: se recibe una entrada, se la procesa, y se genera una salida, mientras que los
casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema.
De esta forma, un caso de uso puede agrupar a varios eventos.
3) Para los eventos, lo importante es qué datos ingresan al sistema o salen de él cuando ocurre el evento
(estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle
sobre la información que se intercambia es secundaria. Según esta técnica, ya habrá tiempo más adelante
en el desarrollo del sistema para ocuparse de este tema.
Los casos de uso combinan el concepto de evento del análisis estructurado con otra técnica de especificación
de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los
requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta técnica, si bien ganó
pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al
sistema desde el punto de vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a
construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos
requerimientos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados.
Tipos de Casos de Uso
Esenciales o de Trazo Grueso vs. de Implementación o de Trazo Fino: Uno de los modelos de ciclo de vida de desarrollo de sistemas que más popularidad ha ganado en los últimos
años es el llamado “modelo incremental”, en el cual se van entregando versiones parciales del sistema, que
implementan una parte de su funcionalidad. La recomendación en este caso pasa siempre por identificar todos
los requerimientos que uno pueda, definir sus prioridades, y seleccionar cuáles se van a ir implementado en
cada versión. Sin embargo, no se pueden especificar en detalle todos los requerimientos: debemos tener
apenas el nivel de detalle suficiente para poder definir sus prioridades y comprenderlos en términos generales.
Para aplicar los casos de uso a desarrollos incrementales, empezamos por identificar todos los casos de uso
del sistema, sólo al nivel de su nombre. Una vez que los identificamos, los expresamos en “trazo grueso”, esto
es:
· Ignoramos detalles sobre la forma de la interacción entre el actor y el sistema.
· Sólo incluimos las alternativas más relevantes, ignorando la mayoría de los errores que aparecen en el
uso del sistema.
· No entramos en detalle sobre las acciones que realiza el sistema cuando el usuario interactúa con él. Por
ejemplo, si la empresa tuviera una política de descuentos para sus clientes, no es necesario especificar
cómo es esa política: nos alcanza con saber que existe una y que debe ser tenida en cuenta.
De esta forma, terminamos con una descripción “gruesa” de todos los casos de uso. Esto me sirve para tomar
mejores decisiones, junto con los usuarios, sobre qué casos de uso implementar en cada fase. Por otro lado,
permite analizar los principales aspectos de todos los casos que afectan al diseño.
Casos de Uso Temporales: Los casos de uso tienen un actor que los inicia, y uno o más actores que participan de él. En muchos casos, el
inicio de una determinada funcionalidad del sistema es provocado exclusivamente por el paso del tiempo.
Supongamos que nuestro sistema de ventas debe generar en forma automática un conjunto de estadísticas para
ser entregadas al directorio de la empresa el último día hábil de cada mes. En este caso, el paso del tiempo es
el que inicia el caso de uso, y el directorio es el actor del sistema. Sin embargo, para expresar claramente que
es el paso del tiempo el que inicia el caso, podemos incluir un símbolo representando un reloj en el gráfico de
casos de uso, o usar una línea punteada en el borde del óvalo del caso.
Casos Primarios Vs. Casos Secundarios:
Jacobson hace referencia a la diferencia entre los casos de uso primarios del sistema y aquellos que no se
corresponden con procesos del negocio y cuya ejecución sólo es necesaria para que el sistema funcione
normalmente.
Supongamos que nuestro sistema requiere de un proceso de depuración de los pedidos que ya han sido
cumplidos hace más de 5 años, para evitar que se acumulen indefinidamente. El caso de uso por el cual se
depuran estos pedidos, cuyo actor es un Administrador del Sistema, es considerado un caso secundario, ya
que no es central al sistema, sino que es necesario para que el sistema pueda funcionar sin problemas. En la
experiencia se ve que no todos los casos de uso secundarios se pueden identificar en la etapa de
requerimientos, ya que muchos de ellos dependen de decisiones de implementación que se toman en la etapa
de diseño. De todas formas, los casos de uso pueden ser actualizados a medida que progresa el desarrollo del
sistema, ya que al estar expresados desde el punto de vista del usuario, son una excelente base para construir
del manual de usuario.
Organización de la Especificación
En esta sección discutimos la mejor forma de organizar una especificación de requerimientos en la que se
aplicó la técnica de casos de uso.
Gráficos a Utilizar
Dependiendo del tamaño del sistema,
es probable que un único gráfico con todos los casos de uso nos quede
chico. No olvidemos que los modelos gráficos son para aclarar el texto, y no para confundir. Si el gráfico de
casos de uso es una maraña indescifrable, no está cumpliendo su objetivo. Por lo tanto, podemos usar las
siguientes reglas, como siempre con criterio y sentido común:
1) Un gráfico de casos de uso no debe mostrar más de 15 casos
2) Si debo particionar mi gráfico, puedo hacerlo por actor. La primera partición debe ser separar los casos
centrales de los casos auxiliares, ya que probablemente les interesen a personas distintas.
3) Si las relaciones de uso y las extensiones entran en el diagrama principal, sin dejar de cumplir con la
regla 1), debo dejarlas ahí. Lo mismo se aplica a los actores abstractos.
4) Si las relaciones de uso no entran en el diagrama principal, debo mostrarlas en gráficos teniendo en
cuenta que siempre debo mostrar todos los casos de uso que usan a otro en un mismo diagrama.
5) Si tengo un caso de uso que es usado por gran parte de los otros casos, como por ejemplo el caso de uso
Identificándose ante el sistema, debo evitar mostrarlo en el gráfico principal, ya que las flechas serán
imposibles de organizar. Es probable que no haga falta mostrar esta relación de uso en un gráfico.
Secciones de la especificación
Sugerimos el siguiente orden para una especificación de requerimientos utilizando casos de uso:
1) Propósito del sistema: un breve párrafo, de 4 o 5 líneas, que responde a la pregunta ¿Para qué estamos
haciendo este sistema?
2) Gráfico(s) de casos de uso
3) Descripción de los casos con sus alternativas
4) Prototipos para los principales casos de uso
Esta no es obviamente una especificación de requerimientos completa: estamos incluyendo sólo la parte
referida a los casos de uso.
