LECTURA SEMANAL

LECTURA DOS: CASOS DE USO. UNA HERRAMIENTA FUNDAMENTAL

En cualquier sistema de software, debe satisfacerse la nocin de que los usuarios puedan, a
travs del uso de la aplicacin, alcanzar ciertos objetivos. El proceso de utilizacin del
software podra entonces descomponerse en diferentes momentos, en cada uno de los
cuales el usuario tiene la intencin de alcanzar una meta particular y lo hace a travs de una
secuencia de pasos e interacciones con la aplicacin que en conjunto, le permiten alcanzar
dicho objetivo. De la manera ms simple posible, puede decirse que un caso de uso es la
descripcin de uno de estos procesos de interaccin. En otras palabras, un caso de uso es
la historia de cmo se usa una parte del sistema.
Una versin corta e informal de un caso de uso podra ser:
Compra de CDs: el cliente llega a la caja con los CDs que desea comprar. El cajero los
recibe y uno por uno los registra en el sistema para obtener la informacin de precios. Al
terminar este proceso, el cliente escoge la forma de pago y realiza el pago. Despus, el
sistema actualiza el inventario y genera un recibo por la compra, que es entregado al cliente
por el cajero. El cliente sale del establecimiento con los CDs.
En muchas ocasiones se requiere una descripcin ms detallada de los casos de uso. Sin
embargo, la esencia sigue siendo la misma: registrar el proceso de uso del sistema de una
forma clara. Este registro debe contener las diferentes rutas o alternativas de interaccin
dentro del proceso de uso (Por ejemplo, en el ejemplo anterior es posible pagar en efectivo
o utilizando una tarjeta de crdito). Cada una de estas alternativas se conoce como un
escenario. De esta manera, una definicin ms formal de lo que es un caso de uso podra ser:
Un caso de uso es el conjunto de escenarios, exitosos o de fracaso, que describen la
interaccin de un usuario con un sistema en busca de alcanzar un objetivo.
Es importante resaltar en este punto la relacin entre los casos de uso y los requerimientos
funcionales: los casos de uso son un mecanismo para registrar en incluso descubrir
requerimientos funcionales de un sistema particular. Su utilidad es innegable, pero depende
de su claridad y de que describan interacciones a un nivel de detalle adecuado. La
deteccin de cul es el nivel de detalle adecuado es uno de los retos que se presenta
cuando se trata de determinar los casos de uso de un sistema particular. Es posible penar en
diferentes niveles de complejidad que describan interacciones de usuarios con el sistema y en
teora en todos ellos podran describirse casos de uso. Por ejemplo:
Hacer log in
Generar reportes contables
En alianza con

Colombia
Comprar CDs

Son todos ejemplos de diferentes niveles de complejidad en la interaccin con un sistema. Sin
embargo, no todos son viables y realmente tiles a la hora de considerar la documentacin
utilizando casos de uso. Dependiendo de qu nivel se escoja, podra terminarse con un
sistema descrito por una multitud de casos de uso de funcionalidad muy limitada y
granularidad muy fina, o por un conjunto pequeo de casos de uso gordos que contengan
mucha funcionalidad y sean extremadamente complejos. A primera vista y utilizando lo visto en
este texto, se puede decir que el caso de la lista presentada, la tercera alternativa es
adecuada para la documentacin utilizando casos de uso, sin embargo, cul es el criterio
para definir esto?
Alistair Cockburn, uno de los estudiosos ms influyentes del tema de los casos de uso, creador
de una de las plantillas de documentacin ms populares (Una variacin de la cual vamos a
usar en este mdulo), recomienda tratar de ubicar los casos de uso en el nivel de Proceso
Elemental de Negocio (EBP por su sigla en ingls). Ahora bien, en el marco de la propuesta
de Cockburn, si se quisiera decantar una definicin, podra decirse que un Proceso Elemental
de Negocio es una tarea realizada por una persona en un lugar y en un momento
determinados, respondiendo a un evento del negocio, de tal manera que se genere valor al
negocio y se dejen los datos en un estado consistente.
En otras palabras, un caso de uso debera describir una actividad que tiene sentido dentro
del proceso de uso del software, esto es, que cumple un objetivo particular a travs de la
correcta manipulacin de la informacin y que tiene una complejidad suficiente para que se
requiera un nmero significativo de pasos para lograr el objetivo esperado (un caso de uso
por lo general tiene ms de dos pasos). Los casos de uso son iniciados por un actor, que
puede definirse como algo que inicia el comportamiento, por ejemplo una persona
(identificada mediante un rol en el proceso), un sistema de software, una organizacin o
incluso un momento determinado en el tiempo (El ltimo da de cada mes, por ejemplo puede
iniciar un caso de uso llamado calcular nmina)
En cualquier caso, la recomendacin de mantener los casos de uso en el nivel de los
procesos elementales de negocio es una recomendacin y una buena prctica. Claramente
es posible documentar casos de uso en niveles de mayor o menor complejidad, pero
enfocarse en el nivel recomendado suele generar mejores resultados.
Ahora bien, la documentacin de los casos de uso puede verse desde dos ngulos: la
documentacin mediante diagramas de casos de uso (Siguiendo los estndares UML) que
ofrece una aproximacin general desde una perspectiva elevada de las relaciones entre los
diferentes procesos de interaccin de los usuarios con el sistema, o la documentacin de la
estructura interna de los casos de uso, que no es una aproximacin grfica sino escrita y
que ofrece informacin respecto al funcionamiento detallado de cada una de esas
interacciones y los diferentes escenarios que comprenden. El inters de este mdulo se centra
en la segunda alternativa, aunque no se pretende descartar la utilidad de tener una
representacin visual de la interaccin entre los casos de uso de un sistema dado. (De
hecho, este tema se aborda con detalle en el mdulo nfasis en UML).
Habiendo dicho esto, es posible comenzar a definir los elementos que definen la estructura
de un caso de uso:
Precondicin: la precondicin describe el estado necesario del sistema y los actores para
que el caso de uso pueda ser arrancado. En otras palabras, la precondicin describe qu
condiciones deben cumplirse antes de que el caso de uso arranque, para que ste pueda
ser iniciado. Siguiendo con el ejemplo de la compra de CDs, la precondicin podra ser:
Precondicin: El cajero debe haberse autenticado en el sistema.

En alianza con

Colombia
La precondicin debe definir las condiciones mnimas para que el caso de uso arranque.
Existe la tentacin de incluir en la precondicin mucha informacin, y cubrir la mayor parte de
las posibilidades, pero debe evitarse hacer esto. La razn es que si la precondicin requiere
demasiada informacin (en el ejemplo podra pensarse en incluir adems que el cliente tenga
dinero suficiente, o que sus tarjetas de crdito estn al da y tengan cupo), el caso de uso no
contemplar posibilidades que resultan importantes (el cliente no puede comprar los CDs
porque sus tarjetas de crdito no tienen cupo), que no sern documentadas y por tanto no
sern tenidas en cuenta durante la codificacin del sistema. Esto puede producir
comportamientos inesperados durante la ejecucin del sistema, ya que el software no tendr
en cuenta posibles alternativas del flujo de informacin y no ofrecer por tanto soluciones
adecuadas. En el caso particular, un cliente llegar algn da con la intencin de comprar
algunos CDs, pero sin cupo en sus tarjetas. Ya que el caso de uso no tuvo en cuenta esta
eventualidad, el software no ofrecer alternativas para, por ejemplo, cancelar la compra y
deshacer los cambios al inventario, si es del caso.
Flujo normal de eventos: el flujo normal de eventos describe los pasos necesarios para
llegar al xito del caso de uso, partiendo de la precondicin. El flujo normal refleja los pasos y
actividades que no contemplan ninguna falla ni error a lo largo del proceso. Es lo que se
conoce en software como el camino feliz, en el que nada falla, no hay contratiempos, las
actividades se realizan sin demora y sin inconvenientes y se llega al final del caso de uso de
manera exitosa, sin desviarse en ningn punto y sin la presencia de dudas o alternativas. En el
caso del ejemplo que se viene trabajando, el flujo normal se vera de la siguiente forma:
El cliente llega a la caja con los CDs que desea comprar.
Para cada CD que el cliente presenta, el cajero ingresa la informacin de identificacin
correspondiente.
Para cada CD que el cliente presenta, el sistema muestra la informacin del CD, incluyendo
su valor.
El sistema actualiza el total de la compra.
El cajero solicita el pago al cliente.
El cliente realiza el pago.
El sistema registra el pago.
El sistema registra la venta completada.
El sistema actualiza el inventario.
El sistema imprime un recibo.
El cajero entrega el recibo y los CDs al cliente, quien abandona el establecimiento con
ellos.
Como una recomendacin, el flujo normal del caso de uso no se ocupa de describir la
interfaz de la aplicacin, ni la manera detallada como el usuario interactuar con esta (no se
detalla por ejemplo si la informacin de cada CD ser ingresada utilizando un teclado, un
lector de cdigos de barras o cualquier otro proceso). Tampoco es de inters de un caso
de uso describir el funcionamiento interno de la aplicacin (no se dice entonces, cules son
las tablas a actualizar dentro del inventario, ni a travs de qu sentencias SQL se har dicha
actualizacin). Se asume en su lugar, que la aplicacin tiene responsabilidades que cumplir,
puesto que en este punto no es necesario y a veces tampoco prudente detallar procesos y
funcionalidades internas que pueden ni siquiera haber sido definidas.
Condicin de xito: la condicin de xito del caso de uso describe el estado del sistema,
de los actores y de la informacin una vez que el caso de uso ha terminado de manera
exitosa. En el caso del ejemplo que nos ocupa, la condicin de xito sera:
Condicin de xito: el sistema registra la venta. Los valores de la venta, incluyendo
correspondientes a impuestos han sido calculados correctamente. El recibo correspondiente
a la venta hasido generado.El pago ha sido procesado exitosamente.
En alianza con

Colombia
 Subvariaciones: las subvariaciones describen secuencias de pasos que representan flujos
alternos dentro de un caso de uso que conducen a la condicin de xito. Es decir, una
subvariacin describe otras formas mediante las cuales un caso de uso puede ser exitoso y
llegar desde la precondicin a la condicin de xito. En la mayor parte de los casos, un caso
de uso tiene varias subvariaciones. Un ejemplo de una subvariacin para el caso de uso del
ejemplo es:
5.1.1. El cliente indica que es elegible para un descuento en la compra, por tener tarjeta de
afiliacin con el almacn.
5.1.2. El cajero solicita el nmero de la tarjeta de afiliacin.
5.1.3. El cajero ingresa el nmero de afiliacin en el sistema.
5.1.4. El sistema calcula el descuento y actualiza el valor total de la compra.
5.1.5. Vuelve al flujo normal en el paso seis.
La notacin utilizada cuando se documentan subvariaciones est compuesta por tres
nmeros. Para aclarar su significado, se tomar como ejemplo el primer paso de la
subvariacin mostrada:
5.1.1. El cliente indica que es elegible para un descuento en la compra, por tener tarjeta de
afiliacin con el almacn.
El 5 indica el paso del flujo en el que se desprende la subvariacin:
5.1.1. El cliente indica que es elegible para un descuento en la compra, por tener tarjeta de
afiliacin con el almacn.
El primer uno indica que es la primera subvariacin que se desprende del paso cinco del flujo
normal (en el caso en que se presenten otras subvariaciones que salgan de ese paso, como
es enteramente posible, se numerarn de manera acorde: 5.2.1, 5.3.1, etc):
5.1.1. El cliente indica que es elegible para un descuento en la compra, por tener tarjeta de
afiliacin con el almacn.
El segundo uno indica que es el primer paso de la subvariacin en cuestin. Este es el nico
nmero que variar dentro de la documentacin de la subvariacin, indicando los pasos que
la componen:
5.1.1. El cliente indica que es elegible para un descuento en la compra, por tener tarjeta de
afiliacin con el almacn.
Extensiones: las extensiones describen secuencias de pasos que se desprenden del flujo
normal, pero que no conducen a las condiciones de xito. Describen flujos alternativos que
terminan en el fracaso del caso de uso respectivo. En el ejemplo una extensin podra ser:
3.1.1. El cliente solicita la cancelacin de la venta.
3.1.2. El cajero cancela la venta.
3.1.3. El sistema anula el proceso de venta.
Ntese que la notacin utilizada es la misma que se utiliza para la documentacin de las
subvariaciones. Sin embargo, puede suceder que una extensin (o subvariacin se puedan
invocar desde un conjunto de pasos, no solamente desde uno. En ese caso la notacin
puede variar, de la siguiente forma:
3.5.1.1. El cliente solicita la cancelacin de la venta.
3.5.1.2. El cajero cancela la venta.
3.5.1.3. El sistema anula el proceso de venta.
En este caso, la nomenclatura indica que la extensin puede presentarse desde cualquiera
de los pasos 3, 4 o 5.
Existe otra posibilidad y es que una extensin o una subvariacin puedan presentarse en
cualquier punto del proceso. En ese caso la notacin a utilizar es la siguiente:
*.1.1. El sistema falla.
*.1.2. El cajero reinicia el sistema.
*.1.3. El cajero hace log in en el sistema.
En alianza con

Colombia
*.1.4. El cajero reinicia el proceso de venta.
Uniendo las secciones descritas hasta ahora, es posible documentar un caso de uso de una
manera completa y clara. Con el fin de facilitar este proceso, se sugiere la utilizacin de una
plantilla o formato. A este respecto existen mltiples alternativas, sin embargo, dentro del
marco de este mdulo se utilizar una variacin de la plantilla presentada por Alistair
COCKBURN*, tal como se muestra a continuacin, conteniendo la documentacin del caso
de uso utilizado como ejemplo a lo largo de la lectura (la documentacin presentada en
este caso de uso no cubre la totalidad de las posibilidades del caso real, aunque da una
idea bastante clara de lo que representa documentar un caso de uso completo). Ntese
como los flujos alternativos, las extensiones y subvariaciones son sustancialmente ms
complejas que el flujo normal. Esto es completamente natural puesto que el flujo normal
describe el escenario ideal, mientras que las otras dos opciones lidian con las diferentes
alternativas que pueden presentarse a lo largo de la ejecucin del caso de uso, que por
naturaleza sern ms variadas.

Documentacin del caso de uso de ejemplo:

Id. Caso de Procesar compra de

CDU-001 Nombre:
Uso: CDs
Realizar la compra de uno o varios CDs,
Objetivo en Contexto (Resumen): registrando la informacin relevante mediante el
uso de la aplicacin de software.
Actores Participantes Cajero, Cliente.
El cajero debe haberse autenticado en el
Pre-Condiciones
sistema.
El sistema registra la venta. Los valores de la
venta, incluyendo los correspondientes a
impuestos han sido calculados correctamente. El
Condiciones de xito
recibo correspondiente a la venta ha sido
generado. El pago ha sido procesado
exitosamente.
Flujo Normal
El cliente llega a la caja con los CDs que desea comprar.
Para cada CD que el cliente presenta, el cajero ingresa la informacin de
identificacin correspondiente.
Para cada CD que el cliente presenta, el sistema muestra la informacin del CD,
incluyendo su valor.
El sistema actualiza el total de la compra.
El cajero solicita el pago al cliente.
El cliente realiza el pago.
El sistema registra el pago.
El sistema registra la venta completada.
El sistema actualiza el inventario.
El sistema imprime un recibo.
El cajero entrega el recibo y los CDs al cliente, quien abandona el establecimiento con
ellos.

*
ElformatooriginaldelaplantillapropuestoporAlistairCockburnpuedeencontrarseen:
http://alistair.cockburn.us/Basic+use+case+template
En alianza con

Colombia
 Extensiones
*.1.1. El sistema falla.
*.1.2. El cajero reinicia el sistema.
*.1.3. El cajero hace log in en el sistema.
*.1.4. El cajero reinicia el proceso de venta.
3.5.1.1. El cliente solicita la cancelacin de la venta.
3.5.1.2. El cajero cancela la venta.
3.5.1.3. El sistema anula el proceso de venta
Sub-Variaciones
2.1.1. La informacin de identificacin del CD es incorrecta.
2.1.2. El sistema despliega un mensaje solicitando que se ingrese de nuevo la
informacin.
2.1.3. Vuelve al flujo normal en el paso 2.
3.5.1.1. El cliente solicita que se elimine un CD de la compra.
3.5.1.2. El cajero realiza la modificacin den la venta.
3.5.1.3. El sistema actualiza los valores y cantidades correspondientes.
3.5-1.4. Vuelve al flujo normal en el paso siguiente a aquel del que parti.
6.1.1. El cliente realiza el pago en efectivo.
6.1.2. El cajero introduce la suma entregada por el cliente.
6.1.3. El sistema calcula la devolucin si la hay y abre el cajn del dinero en la caja.
6.1.4. El cajero introduce el dinero entregado por el cliente, le entrega al cliente la
devolucin, si la hay, y cierra el cajn de la caja.
6.1.5. El sistema registra la venta.
6.2.1. El cliente realiza el pago con tarjeta dbito.
6.2.2. El cajero desliza la tarjeta por el datafono.
6.2.3. El sistema realiza la consulta de la informacin de la tarjeta dbito a un sistema
externos de verificacin bancaria.
6.2.4. La respuesta recibida autoriza el pago.
6.2.5. El sistema imprime el recibo correspondiente al pago, a travs del datafono y
abre el cajn del dinero.
6.2.6. El cajero solicita al cliente la firma del recibo.
6.2.7. El cliente firma el recibo.
6.2.8. El cajero introduce el recibo en el cajn de la caja y lo cierra.
6.2.9. El sistema registra la venta.
6.3.1. El cliente realiza el pago con tarjeta de crdito.
6.3.2.
6.3.3.

Cuadro 1. Documentacin del caso de uso de ejemplo, utilizando una variacin de la

plantilla propuesta por Cockburn

En alianza con

Colombia