Documentos de Académico
Documentos de Profesional
Documentos de Cultura
CasosDeUso PDF
CasosDeUso PDF
Casos de Uso
Un Mtodo Prctico para Explorar Requerimientos
Santiago Ceria
Casos de Uso Un Mtodo Prctico para Explorar Requerimientos
1. Introduccin
1.3. Historia
Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Sin embargo, la idea de
especificar un sistema a partir de su interaccin con el entorno es original de Mc Menamin y Palmer, dos
precursores del anlisis 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 lmites 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 procesndolo.
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 cmo es el dilogo entre el usuario y el sistema.
2) Los eventos son atmicos: 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 interaccin 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 informacin que se intercambia es secundaria. Segn esta tcnica, ya habr tiempo ms adelante
en el desarrollo del sistema para ocuparse de este tema.
Los casos de uso combinan el concepto de evento del anlisis estructurado con otra tcnica de especificacin
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 tcnica, 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 aqul que lo va a usar, y no desde el punto de vista del que lo va a
construir. De esta forma, es ms fcil validar que los requerimientos documentados son los verdaderos
requerimientos de los usuarios, ya que stos comprendern fcilmente la forma en la que estn expresados.
2. Definiciones Bsicas
2.1. Actores
Un actor es una agrupacin uniforme de personas, sistemas o mquinas que interactan con el sistema que
estamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma
telefnica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer
las mismas cosas con el sistema, son considerados un nico actor: Empleado de Ventas.
Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos
empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer
objetivo de todo analista, ya que un proyecto sin alcance definido nunca podr alcanzar sus objetivos.
Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un
usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al
sistema como distintos actores. La forma ms simple de entender esto es pensar en perfiles de usuario de un
sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer
cosas distintas. Los perfiles son en este caso equivalentes a los actores.
Otro sistema que interacta con el que estamos construyendo tambin es un actor. Por ejemplo, si nuestro
sistema deber generar asientos contables para ser procesados por el sistema de contabilidad, este ltimo
sistema ser un actor, que usa los servicios de nuestro sistema.
Tambin puede ocurrir que el actor sea una mquina, en el caso en que el software controle sus movimientos,
o sea operado por una mquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo de un
robot, el hardware del robot ser un actor, asumiendo que dentro de nuestro sistema estn las rutinas de bajo
nivel que controlan al hardware.
Los actores se representan con dibujos simplificados de personas, llamados en ingls stick man (hombres de
palo).
Sistema de Ventas
Empleado
de Ventas
Figura 1 El empleado de ventas es un actor del sistema de ventas
Si bien en UML los actores siempre se representan con hombres de palo, a veces resulta til representar a
otros sistemas con alguna representacin ms clara.
Sistema de Ventas
Empleado
de Ventas
Sistema de
Produccin
Las flechas, que existan en la propuesta original de Jacobson pero desaparecieron del modelo semntico de
UML, pueden usarse para indicar el flujo de informacin entre el sistema y el actor. Si la flecha apunta desde
el actor hacia el sistema, esto indica que el actor est ingresando informacin en el sistema. Si la flecha apunta
desde el sistema hacia el actor, el sistema est generando informacin para el actor.
Identificar a los actores es el primer paso para usar la tcnica de casos de uso. Por ejemplo, en el sistema de
pedidos nombrado anteriormente, sin conocer prcticamente ningn detalle sobre cmo funcionar, podemos
decir que:
1) El grupo de usuarios que ingrese pedidos al sistema ser un actor.
2) El grupo de usuarios que haga otras operaciones con los pedidos, como por ejemplo autorizarlos,
cancelarlos y modificar sus plazos de entrega, ser un actor.
3) Todo grupo de usuarios que reciba ciertos informes del sistema, como por ejemplo estadsticas de ventas,
ser un actor.
Es comn que los distintos actores coincidan con distintas reas de la empresa en la que se implementar el
sistema, o con jerarquas dentro de la organizacin (empleado, supervisor y gerente son distintos actores, si
realizan tareas distintas).
Todos los actores participan de los casos de uso. Ahora bien, es lgico que existan intersecciones entre lo que
hacen los distintos actores. Por ejemplo, un supervisor puede autorizar pedidos, pero tambin puede
ingresarlos. Veremos ms adelante cmo, definiendo actores abstractos, podemos especificar este
comportamiento comn para evitar redundancia.
Definiciones Bsicas
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. Grficamente, los casos de uso se representan con un
valo, con el nombre del caso en su interior.
Sistema de Ventas
Ingresando pedido
Recibiendo
Empleado informacin de
de Ventas pedidos
Sistema de
Produccin
En principio podramos decir que la regla general es: una funcin del sistema es un caso de uso si se debe
indicar explcitamente al sistema que uno quiere acceder a esa funcin. 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 funcin. Dar de alta un campo de un
pedido es una funcin 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 segn nuestra regla seran todas ellas
casos de uso distintos. Sin embargo, en esta situacin es mucho ms prctico 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 divisin de los casos de uso tambin resulta til imaginar que
uno est escribiendo el manual del usuario del sistema. A nadie se le ocurrira escribir un manual de usuario
con un solo captulo en el que se describe toda su funcionalidad. De la misma forma, no se debe escribir una
especificacin con un solo caso de uso. A pesar de saber que uno se quiere mantener lejos de este extremo, la
cantidad de captulos del manual es variable dependiendo de la persona que lo escriba.
Para dar una idea aproximada del nivel de detalle de la divisin de los casos de uso en casos menores, tambin
podemos pensar que un trabajo prctico de Ingeniera del Software I debiera tener alrededor de 8 casos de uso
primarios.
Otra de las limitaciones de los casos de uso es que no hay una sintaxis clara para indicar, dentro de la
descripcin del caso, las decisiones e iteraciones. De esta forma, es comn que en las descripciones de los
casos se deba recurrir a frases como Se repite el paso X hasta que ocurre C, o Si ocurre C se pasa al paso
X. En estas situaciones lo importante no es la forma en la que se expresan las condiciones e iteraciones, sino
hacerlo de una forma consistente. Si la descripcin del caso fuera muy compleja, es conveniente usar
notaciones grficas, por ejemplo los diagramas de actividad.
2.3. Alternativas
Durante la ejecucin de un caso de uso, suelen aparecer errores o excepciones. Por ejemplo, mientras se
ingresa un pedido, el cliente puede solicitar un producto que est discontinuado. El sistema deber en este
caso informar esta situacin al empleado que ingresa el pedido. Esas desviaciones del curso normal del caso
de uso se llaman alternativas. Las alternativas tienen las siguientes caractersticas:
1) Representan un error o excepcin en el curso normal del caso de uso.
2) No tienen sentido por s mismas, fuera del contexto del caso de uso en el que ocurren.
Si bien en la bibliografa las alternativas se documentan al final del caso de uso, la experiencia demuestra que
resulta til documentar los casos en tablas, mostrando el curso principal en la primera columna, y las
alternativas en una segunda columna, como lo muestra el siguiente ejemplo:
Sistema de Ventas II
Ingresando pedido
Extiende
Empleado
de Ventas Revisando Presentacin
de nuevos Productos
Sistema de Ventas
Buscando Datos
de Producto
Usa
Usa
Ingresando pedido
Obteniendo Reporte de
Ventas por Producto
Empleado
Gerente
de Ventas
Figura 7 Relaciones de Uso entre Casos de Uso
Este concepto no es novedoso, es simplemente el concepto de la subrutina o subprograma usado en un nivel
ms alto de abstraccin.
Las caractersticas de las relaciones de uso son:
1) Aparecen como funcionalidad comn, luego de haber especificado varios casos de uso.
2) Los casos usados son casos de uso en s mismos.
3) El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las
extensiones, que son opcionales.
La definicin de las relaciones de uso y extensin deja una zona sin definir:
Qu pasa con la funcionalidad que es comn a varios casos de uso, pero al mismo tiempo es opcional? Por
ejemplo, pensemos en la impresin de un comprobante, algo que el usuario de un sistema puede o no hacer en
distintos casos de uso. Si uno se gua por la funcionalidad comn a varios casos, piensa que el caso de uso
imprimiendo comprobante es usado por otros casos, pero si se gua por la opcionalidad, piensa que extiende a
otros casos. Como esto no queda claro a partir de la bibliografa, creemos conveniente que este tipo de
situaciones se especifiquen como extensiones, ya que de esta forma podemos remarcar grficamente la
opcionalidad de la relacin.
De la misma forma, el actor que participa de este caso de uso, que rene caractersticas 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.
Sistema de Ventas
Buscando Datos de
Producto
"Buscador de
Datos de
Producto"
"Buscador de Datos
de Producto"
Hereda Hereda
Empleado de
Ventas Gerente
Sistema de Ventas
Ingresando pedido
Hereda Empleado
de Ventas
Autorizando
Pedido
Supervisor
de Ventas
Los casos de uso de trazo fino son aquellos que se especifican una vez que se ha tomado la decisin de
implementarlos. En este momento debemos completar todos los detalles que dejamos pasar:
A medida que vamos haciendo prototipos de las interfaces con los usuarios, incluimos detalles sobre la
forma de la interfaz en la descripcin del caso. Por ejemplo, podemos incluir detalles como: el operador
puede en cualquier momento pasar de la ventana de datos del cliente a la ventana de datos del pedido.
Si bien esto implica anticiparse al diseo, esto no es negativo, ya que es prcticamente imposible y
perjudicial hablar con los usuarios siempre en trminos de un sistema abstracto.
Incluimos otras alternativas. En particular especificamos todos los errores o excepciones que provienen
de requerimientos de los usuarios. Para esto debemos tener en cuenta que un sistema tiene dos tipos de
errores o excepciones: las que provienen de las definiciones del negocio y las que provienen del
procesamiento interno del sistema. Por ejemplo, pensemos en un requerimiento del tipo: si un cliente
hace un pedido por un monto mayor al autorizado, se debe rechazar el pedido. Esta excepcin es
claramente un requerimiento, y debe ser incluida en las alternativas de los casos de uso. Por el contrario,
una excepcin del tipo: Si el usuario ingresa una letra en el lugar del cdigo del producto se le informa
que el cdigo de producto debe ser numrico no debe ser incluida en esta etapa del anlisis.
Especificamos con ms detalle el comportamiento interno del sistema. En nuestro ejemplo de los
descuentos, deberamos especificar cmo es esa poltica, en un nivel de detalle suficiente para luego
poder disear una forma de implementarla dentro del sistema.
Sistema de Ventas
Recibiendo Estadstica
Mensual de Ventas
Directorio
Asumiendo que la respuesta a la primera pregunta es si, lo prximo que debemos preguntarnos es si el sistema
ejecuta acciones distintas en funcin del tipo de cliente. Tal vez la respuesta sea que existen clientes locales y
clientes del exterior, y que en estos dos casos el procesamiento es totalmente diferente, ya que los pedidos del
exterior deben ser procesados por le Gerencia de Comercio Exterior. Tal vez estemos frente a un nuevo caso
de uso, Ingresando Pedido de Cliente del Exterior, que es distinto del caso de uso Ingresando Pedido de
Cliente Local. Tal vez tengamos dudas sobre si estos son dos casos de uso o uno solo, porque el proceso
puede tener puntos en comn y puntos que los distinguen. En esta ltima situacin me veo obligado a usar
nuevamente el sentido comn. Tal vez aplicando la modularizacin de casos de uso a travs de las relaciones
de uso, puedo factorizar la funcionalidad comn y expresar claramente, incluso grficamente, la funcionalidad
que los distingue.
Por supuesto que si la respuesta a la primera pregunta es no, estamos en el caso en que no vamos a encontrar
un nuevo caso de uso a partir de este anlisis.
Supongamos ahora que la respuesta a la segunda pregunta es s. En este caso, nuevamente podemos encontrar
un nuevo caso de uso. Por ejemplo, podemos encontrar que hay muchas diferencias entre el procesamiento de
pedidos de ciertos tipos de productos. En este caso, nuevamente debemos decidir si la funcionalidad
diferenciada es lo suficientemente relevante como para especificar un nuevo caso. Para hacer este anlisis,
debemos tener en cuenta lo siguiente:
1) Si especificamos dos casos de uso similares como un nico caso de uso, en el texto del caso tendremos
muchos Si pasa X, hago A, si no, hago B. Este hace un poco ms difcil de seguir la especificacin.
2) Si especifico dos casos de uso con funcionalidad en comn como dos casos de uso distintos, la relacin
de uso me puede ayudar a evitar la redundancia.
De todas formas, no debo llevar estas reglas al extremo, como por ejemplo buscar que todos los casos sean
lineales (sin decisiones), ya que de esta forma lo nico que voy a conseguir es una maraa incomprensible de
casos de uso.
6. Organizacin de la Especificacin
En esta seccin discutimos la mejor forma de organizar una especificacin de requerimientos en la que se
aplic la tcnica de casos de uso.
7. Bibliografa
[Brooks87] Frederik P. Brooks - No Silver Bullet. Essence and Accidents in Software Engineering.
IEEE Computer. Abril 1987.
[Jacobson92] Ivar Jacobson y otros. Object Oriented Software Engineering. A Use Case Driven
Approach. Addison Wesley, 1992.
[McMenamin84] Steve Mc. Menamin y John Palmer. Essential Systems Analysis. Prentice Hall, Yourdon
Press, 1984.