LECTURA

Lectura 1. 1. El modelo de casos de uso

El modelo de casos de uso est conformado por un conjunto de diagramas y descripciones
de texto que especifican cmo se espera que los usuarios interacten con el sistema que se
est desarrollando. Las descripciones se orientan a la descripcin de las funcionalidades
esperadas de la aplicacin, lo que ofrece una manera de especificar la ubicacin de los
requerimientos, definidos con anterioridad para el sistema.
Este enfoque orientado a las funcionalidades ofrece un nmero de ventajas que resultan
evidentes, ms adelante en el proceso. Por un lado, es ms sencillo describir la aplicacin
tanto al interior de la compaa, como de manera ms importante, hacia el exterior, en los
dilogos con el cliente. Se obtiene as una visin compartida ms clara y hecha explcita en
un lenguaje comn, de tal forma que se tenga certeza de estar comunicando los mismos
hechos y consideraciones, lo que a futuro mejora el proceso de desarrollo y reduce la
probabilidad de cambios.
Resulta importante anotar que el enfoque del modelo de casos de uso, brinda una
importancia muy alta al cumplimiento de objetivos, ms que al proceso que se sigue para
alcanzarlos. A pesar de que, como se ver ms adelante, existen medidas y mecanismos para
documentar el proceso, en su visin ms general, el modelo de casos de uso pretende
ofrecer una perspectiva amplia de los objetivos a cumplir y las relaciones que existen entre los
mismos.
En trminos de los elementos que componen el modelo de casos de uso, pueden identificarse
tres diferentes: el diagrama de casos de uso, la descripcin interna de los casos de uso y la
descripcin de los escenarios dentro de un caso de uso. La descripcin interna de un
diagrama de uso es un tema que se toc en el mdulo de Ingeniera de Software I; por otro
lado, un escenario es una ruta cualquiera que puede seguirse dentro de un caso de uso.
Como ya es sabido, dentro de un caso de uso pueden existir extensiones y subvariaciones
que definen rutas alternativas para llegar a las condiciones de xito o fracaso del caso de
uso. Un escenario describe de manera independiente y separada una de dichas rutas.
El diagrama de casos de uso es, adems, el nico elemento del modelo que es descrito de
manera formal por el estndar UML. Es una representacin muy simple, que busca describir de
una manera general (sin entrar en los detalles del cmo se harn las cosas) las
funcionalidades ofrecidas por el sistema, a travs de las interacciones con sus usuarios. Los
elementos definidos por el estndar UML para construir un diagrama de casos de uso son
presentados en el siguiente diagrama y descritos a continuacin:

En alianza con

Colombia


Figura 1. Elementos bsicos de un diagrama de casos de uso

Sistema: el sistema en un caso de uso, describe la frontera entre los actores (externos a la
aplicacin) y las funcionalidades y casos de uso (internos a la aplicacin). Es una manera de
diferenciar los dos mundos y especificar, de una manera ms clara, las relaciones entre ellos.
Representa la distincin bsica entre aquello que pertenece a la aplicacin o sistema que se
est modelando y aquello que interacta con el sistema desde el mundo exterior, y a travs
de qu interfaces se lleva a cabo dicha interaccin. En aras de mantener la simplicidad del
diagrama y la claridad en la representacin de los elementos que lo constituyen, se trata
simplemente de un rectngulo con el nombre del sistema como etiqueta, o de manera ms
simple an, con la palabra Sistema o System como identificador. La eleccin de una u otra
opcin depende en muchos de los casos de la herramienta particular que se est utilizando
para la elaboracin del diagrama. En el caso del ejemplo la herramienta utilizada, StarUML1,
automticamente asigna la etiqueta al elemento.
Actor: el actor en un caso de uso, representa a una persona, sistema, o en general, al ente
que participa en el desarrollo del caso de uso (inicindolo en la mayor parte de las
ocasiones) y que tiene inters en que su finalizacin sea exitosa. En su forma ms sencilla, son
los usuarios del sistema. Sin embargo, es vlido y necesario hacer algunas anotaciones al
respecto:
Los usuarios representados por los actores de un caso de uso son en realidad
definidos por los roles de las personas que interactan con el software. No debe
caerse en la tentacin de asumir que cada persona debe tener un actor asociado.
Juan, Mara, el cajero de la caja # 1, el cajero de la caja #4 no son actores
identificados de manera adecuada. Cliente, cajero, supervisor, estibador, son actores

1
HerramientagratuitaopensourceparalaelaboracindediagramasUML.Puededescargarseen
http://staruml.sourceforge.net/en/

En alianza con

Colombia


que tienen sentido dentro del contexto de un caso de uso. Pensar de esta manera,
permite mantener el foco del proceso en cmo se usar la aplicacin, en lugar de
atarse a la estructura particular de la compaa o las personas que utilizarn el
software.
En lnea con lo anterior y a manera de refuerzo, es importante notar que una persona
dada puede, en diferentes momentos, desempear varios roles dentro de la
interaccin con el sistema. Es por esto que es importante definir los actores desde
esta perspectiva, pues de lo contrario, funcionalidades y capacidades seran
agrupadas por personas y no por perfiles o roles, causando confusin y dificulta al
interpretar la funcionalidad del sistema.
Los actores no tienen por qu ser personas. En muchas ocasiones, las aplicaciones
pueden interactuar con otras aplicaciones, sistemas, o dispositivos fsicos, ubicados
todos fuera de las fronteras del sistema que se est modelando a travs del
diagrama de casos de uso. En este caso, cada uno de estos elementos externos que
interactan con la aplicacin es un actor. En la Figura 2 se presentan ejemplos de
distintos tipos de actores. Ntese que las interacciones de los actores con el sistema
vienen definidas por su tipo. El cajero puede disparar funcionalidades a travs de la
interaccin con la interfaz grfica de la aplicacin, mientras que el software de
contabilidad y el robot explorador se comunicarn a travs de flujos de datos
definidos, recibidos a travs de otro tipo de interfaces.

Cajero Software de Contabilidad Robot explorador

Figura 2. Tipos de actores

Caso de uso: identifica los objetivos que el sistema debe cumplir, a travs de funcionalidades
bsicas e importantes del mismo. La suma de estas funcionalidades resultan en el cumplimiento
de los requerimientos definidos por, y para los usuarios. De la misma manera, el no cumplir
alguna de estas funcionalidades implica la carencia, en el sistema, de una parte
imprescindible de su funcionalidad esperada. Es necesario tener en cuenta, sin embargo, que
un diagrama de casos de uso describe qu debe hacer el sistema, pero sin preocuparse por
cmo lo conseguir. El foco est en los objetivos, no en los procesos (la descripcin interna
de cada caso de uso est ms orientada a esto ltimo). De la misma forma, los casos de uso
describen las funcionalidades que son visibles, tiles y significativas para los usuarios que
interactan con el sistema. Igualmente, es posible y de hecho sencillo determinar y
documentar el alcance del sistema de una manera altamente legible, lo que facilita no solo la
estimacin de tiempo, esfuerzo y trabajo sino tambin, la comunicacin con el cliente.
En trminos de nomenclatura, usualmente se sugiere utilizar una frase que gire alrededor de un
verbo para nombrar los casos de uso. De una manera que no difiere mucho de la utilizada
para nombrar los mtodos de un programa de software. De esta forma, se refuerza la

En alianza con

Colombia


simplicidad del proceso y se recalca la importancia de decantar la documentacin hacia el

enfoque orientado por objetivos. A continuacin se presentan algunos ejemplos de casos de
uso correctamente nombrados:

Agregar tem a inventario Imprimir factura Generar reporte de ventas

Figura 3. Ejemplos de casos de uso

Relaciones entre los casos de uso

Asociacin: una asociacin describe una relacin existente entre un actor y un caso de uso
particular. Esta relacin toma la forma de una serie de interacciones y mensajes transmitidos
entre el actor y el sistema, con el fin de satisfacer el objetivo descrito por el caso de uso en
cuestin. Los detalles de estos mensajes son especificados en la descripcin del caso de uso.
La relacin de asociacin es el nico tipo de relacin que puede existir entre un caso de uso
y un actor. En el caso de la figura que se muestra a continuacin, el actor tiene comunicacin
con los casos Caso de Uso 1 y Caso de Uso 2, indicando que puede iniciarlos de manera
directa.

Caso de Uso 1

Actor
Caso de Uso 2

Figura 4. Asociacin entre un actor y los casos de uso

Dependencia: una dependencia indica y describe la relacin que existe entre dos casos de
uso, al interior del sistema. Existen dos tipos de relaciones de dependencia que se examinan a
continuacin.
Relacin de inclusin <<include>>. Es una relacin de dependencia entre casos de
uso, describe una situacin en la que un caso de uso necesita la funcionalidad
descrita por otro para completar sus propios objetivos. Es decir, el caso de uso que
incluye en algn punto de su proceso necesita ejecutar el caso de uso incluido y no
puede terminar, de manera adecuada, si dicho caso de uso incluido no termina
tambin de forma satisfactoria las labores a l delegadas. Existe aqu una semejanza
marcada con la situacin presente cuando en un desarrollo de software, un mtodo
invoca a otro, delegndole acciones necesarias para su propio funcionamiento. Es
de notar tambin, que la relacin no es opcional, es decir, el caso de uso que incluye
siempre va a requerir llamar la ejecucin de la funcionalidad del caso de uso incluido.

En alianza con

Colombia


Esta situacin puede presentarse principalmente en dos casos: el primero, implica que
ya exista un caso de uso que describe una funcionalidad determinada. Entonces, en
lugar de reescribir los procesos descritos por dicho caso de uso, se usa una relacin
de tipo <<include>> desde el caso de uso que se requiera. La segunda, tiene que
ver con el concepto de reutilizacin. Si varios casos de uso requieren llevar a cabo la
misma secuencia de pasos, resulta mucho ms eficiente crear un caso de uso que
contenga dichos pasos y utilizar relaciones<<include>>, desde todos los casos de
uso que requieran utilizarlo.
En el ejemplo que se presenta en la figura siguiente, para que el actor (un cajero)
pueda realizar, de manera adecuada, la secuencia descrita por el caso de uso
Registrar compra, es necesario que se complete de manera adecuada el caso de
uso Actualizar inventario. De esta manera, existe una relacin de tipo <<include>>
en la que el caso de uso Registrar compra incluye al caso de uso Actualizar
inventario. El primero requiere de la funcionalidad descrita por el segundo para
finalizar de manera adecuada.

<<include>>
Registrar compra Actualizar inventario

Cajero

Figura 5 Relacin de tipo <<include>>

Ntese que en una relacin de tipo <<include>>, la flecha que describe la existencia
de la misma va desde el caso de uso que incluye, hacia el caso de uso incluido. Es
muy importante tener en cuenta este hecho, pues la correcta lectura del diagrama de
casos de uso depende, fuertemente, del respeto que se tenga por este tipo de
convenciones.
Relacin de extensin <<extend>>. Describe una situacin en la que un caso de
uso puede necesitar de la ayuda de otro. Esto quiere decir, que dentro de la
descripcin de los pasos del caso de uso inicial, existe un punto en el que se
determina si es necesario invocar al caso de uso que extiende. Si este es el caso, se
invoca dicho caso de uso. De lo contrario, el caso de uso base contina su
ejecucin normalmente. Es muy importante notar este componente de eleccin en la
relacin <<extend>>, pues es uno de los principales puntos de diferencia con la
relacin <<include>>, descrita con anterioridad.
La relacin <<extend>> presenta un caso en que la funcionalidad del caso de uso
base puede ser aumentada o extendida por la funcionalidad del caso de uso que lo
extiende. A diferencia de la relacin planteada por <<include>>, aqu el caso de uso
base puede ejecutarse perfectamente sin la ayuda del caso de uso que lo extiende.
Su funcionalidad est completa y, solo en circunstancias especiales, puede requerirse
aumentarla a travs de la funcionalidad descrita por el caso de uso que extiende.
En la figura que se muestra a continuacin se describe una relacin de tipo
<<extend>> entre los casos de uso Registrar compra y Registrar puntos

En alianza con

Colombia


acumulados. En este ejemplo, el caso de uso base, Registrar compra, puede cumplir
sus objetivos de manera independiente, sin que esto implique la ejecucin del caso
de uso que lo extiende, Registrar puntos acumulados. Sin embargo, bajo ciertas
circunstancias (el cliente que realiza la compra est afiliado al plan de puntos del
almacn) puede ser necesario invocar el caso de uso Registrar puntos acumulados.
En esta situacin, la funcionalidad del caso de uso base se ve aumentada o
extendida por el caso de uso con quien mantiene la relacin <<extend>>.

<<include>>
Registrar compra Actualizar inventario

Cajero

<<extend>>

Registrar puntos acumulados

Figura 6. Relacin de tipo <<extend>>

Un punto importante a notar en la relacin <<extend>> es que la direccin de la
flecha que une los dos casos de uso es inversa a la presentada en el caso de la
relacin <<include>>. En el caso del <<extend>>, la flecha va desde el caso de uso
que extiende hacia el caso de uso base. De nuevo, resulta muy importante tener en
cuenta este hecho, pues determina de manera decisiva la lectura que se pueda
hacer del diagrama.

Generalizacin/herencia: la generalizacin define una relacin que existe entre dos casos
de uso o incluso dos actores, que es semejante a la herencia entre dos clases. Uno de los
elementos recibe o hereda caractersticas del otro, pudiendo cambiarlas o agregando las
suyas propias sobre la base existente. Su utilizacin, al igual que el uso de la herencia en la
programacin orientada por objetos, busca no tener que redefinir propiedades o
caractersticas en un caso de uso o actor, cuando dichas propiedades o caractersticas
pueden ser apropiadas de otros actores o casos de uso que ya han sido definidas.
En la figura que se muestra luego de este prrafo, se representa una relacin de
generalizacin entre los casos de uso Registrar compra y Registrar compra con tarjeta de
crdito. El segundo describe la implementacin de un requerimiento ms detallado que el
primero, a pesar de que se apoya y ampla el caso de uso inicial.

En alianza con

Colombia


<<include>>
Registrar compra Actualizar inventario

Cajero
<<extend>>

Registrar puntos acumulados

Registrar compra con tarjeta de crdito

Figura 7. Relacin de generalizacin entre dos casos de uso

Ntese la representacin de la relacin de generalizacin a travs del uso de una lnea con
un tringulo al final. Esta representacin es similar a la utilizada cuando se ilustra una relacin
de herencia entre dos clases, en diseo orientado por objetos. De manera similar que en ese
caso, el tringulo se encuentra en el extremo cercano al caso de uso que est siendo
heredado, en este ejemplo Registrar compra.

En alianza con

Colombia