Uses vs.

Extends
Roberto Barriga Rodrguez
Aitana Giner Martn
Facultad de Informtica Universidad Politcnica de Valencia
Email: robarrod@inf.upv.es, aigimar@inf.upv.es

1. Resumen
Un caso de uso es una tpica interaccin entre un usuario y un
sistema de computador. La esencia de los casos de uso es capturar
los requerimientos de un sistema, detallando todos los escenarios que
el usuario construya.
Se pueden organizar casos de uso especificando relaciones de
generalizacin, include y extend entre otros. Se aplican esas
relaciones para factorizar un comportamiento comn (tomando tal
comportamiento de otros casos de uso que lo incluyan) y variantes
(asignando tal comportamiento en otros casos de uso que lo
extiendan).
2. Introduccin
Durante mucho tiempo en todos los desarrollos OO las personas
usaban los escenarios para ayudarse a entender los requerimientos.
Sin embargo los escenarios eran tratados muy informalmente.
Jacobson es conocido por cambiar esto. Mejor la visibilidad del
caso de uso (su nombre para el escenario) hacia el extends que lleg
a ser un elemento fundamental en el desarrollo de proyectos y en la
planificacin.

1
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

El objetivo de este trabajo es aclarar las diferencias que existen

entre el uses y el extends y conocer otros nuevos conceptos como
son el invokes y el precedes.
En primer lugar se describe brevemente el concepto de caso de
uso para centrar al lector en el tema. A continuacin se expone el
tema, desde el punto de vista de varios autores, mediante ejemplos:
Martin Fowler con Kendall Scott y Doug Rosenberg con Kendall Scott.
Al final del trabajo se ha incluido la opinin de otros autores
3. Qu es un caso de uso?
Un caso de uso es una secuencia de acciones que ejecuta un
actor dentro de un sistema para lograr un objetivo particular. El
resultado de la modelizacin de un caso de uso debe ser que todos
los requerimientos funcionales del sistema queden descritos.
Un factor importante al crear casos de uso, es que se realizan
sin

detallar

como

se

implementaron.

Por

ejemplo,

se

puede

especificar como un sistema ATM se comportara estableciendo en los

casos de uso la manera en la que los usuarios van a interactuar; no es
necesario tener conocimiento sobre la parte interna. Los casos de uso
especifican el comportamiento deseado, no determinan como se
llevar a cabo. Algo muy importante acerca de esto es que permiten
(al usuario final y experto del dominio) comunicarse con los
desarrolladores (quien construye los sistemas que satisfagan los
requerimientos) sin caer en detalles; los casos de uso permiten
enfocarse a los resultados.
Un actor representa un papel que un usuario puede jugar dentro
de un sistema o una entidad. El conjunto de actores dentro de un
modelo de caso de uso refleja todo lo que se necesita para
intercambiar informacin con el sistema. Por ejemplo en un hospital
algunos actores podran ser: Mdicos, Administrativos...
2
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

Un usuario puede ser ms de un tipo de actor. Por ejemplo, una

enfermera puede hacer tambin el trabajo de un administrativo. Del
mismo modo ms de un usuario puede aparecer como un actor.
Dentro de un diagrama de casos de uso, los casos de uso
aparecen como valos, generalmente en medio del diagrama; los
actores aparecen como figuras a la derecha y a la izquierda.
Durante la elaboracin, esto es todo lo que se necesita para
empezar, no hay que tratar de capturar al principio todos los detalles
correctamente, slo cuando se necesiten. Si se cree que el caso de
uso dado tiene grandes ramificaciones arquitectnicas ser necesario
dar ms detalles. Muchos casos de uso pueden ser detallados cuando
se construyen.

3
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

4. Uses y Extend por Martin Fowler y Kendall Scott

Adems de las relaciones entre actores y casos de uso, hay
otros dos tipos, las que existen entre el uses/extends y los casos de
uso.
Se utiliza la relacin extends cuando se tiene un caso de uso
que es similar a otro pero hace algo ms.

Analyz
e Risk
Price
Dela

Trader

Actor

<<Usses>>

<<Usses>>

Valuatio
n

Captur
e Deal

<<Extends>>

Caso de uso

Limits
Exceede
d

Figura 1
En el ejemplo de la figura 1, el caso de uso bsico es Capture
Deal. Este es el caso en el que todo va bien , sin embargo hay cosas
que pueden alterar el buen funcionamiento. Una de estas cosas es
cuando se exceden algunos lmites Limits Exceeded. Aqu no se
representa el comportamiento usual asociado con el caso de uso
dado; se ha llevado a cabo una variacin.
4
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

Podemos poner esta variacin dentro del caso de uso Capture

Deal. Sin embargo esto puede abarrotarlo con mucha lgica, que
oscurecera el flujo normal.
Otra

manera

de

introducir

la

variacin

es

poner

el

comportamiento normal en un caso de uso y el comportamiento

inusual en otro sitio. Los pasos a seguir son los siguientes:

1. Capturar primero el caso de uso bsico.

2. En todos los pasos que se realicen en este caso de uso
preguntarse qu puede ir mal aqu? y cmo afecta a
la forma de trabajar?
3. Dibujar todas las variaciones como extensiones. Pueden
ser un nmero bastante grande.
El caso de uso se puede hacer en dos fases, la de elaboracin y
la de construccin. En la elaboracin, a menudo se parte de cualquier
caso de uso que sea complicado. Sin embargo, hay casos de uso cuya
complejidad es muy grande, y entonces no se introducen hasta la
construccin.
Si no se puede construir completamente el caso de uso en una
sola iteracin hay que separar, en la construccin, el proyecto en
etapas. Se divide un caso de uso complejo en un caso de uso normal
y unas pocas extensiones y luego se construye el caso de uso normal
en una iteracin y las extensiones como parte de una o ms
iteraciones siguientes.
Las relaciones uses ocurren cuando se tiene una buena parte
del comportamiento que es similar que alcanza ms de un caso de
5
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

uso y no se quiere

conservar copias

de la descripcin

del

comportamiento. Por ejemplo, tanto en Analyze Risk como en Price

Deal se realizan operaciones similares. La descripcin de estas
operaciones es muy extensa, y resulta odioso copiar y pegar. As que
lo mejor es derivar un caso de uso separado Valuation para esta
situacin y hacer referencia a l desde el caso de uso original.
Existen semejanzas y diferencias entre extends y uses. En
ambos hay que sacar fuera el comportamiento comn de la mayora
de los casos de uso a un caso de uso simple que es usado, o
extendido por otros muchos casos de uso. Sin embargo, el propsito
es diferente.
Los dos tipos de relaciones implican diferentes cosas en sus
conexiones con los actores. En el caso del extends, los actores tienen
una relacin con el caso de uso que est siendo extendido. Se asume
que el actor podr trabajar con el caso de uso base y con todas las
extensiones. Con una relacin de uses, a menudo no hay actores
asociados con el caso de uso comn.
Para saber cuando hay que utilizar uses y cuando extends
aplicar las siguientes regla:
1. Usar extends cuando se describa una variacin en un
comportamiento normal.
2. Usar uses cuando se produzca una repeticin en dos o
ms casos de uso separados y se quiera evitar.

5. Invokes y Revokes por Doug Rosenberg y Kendall Scott

UML ( United Modeling Language ) establece la relacin uses
vista anteriormente con el nombre de includes, de cuyo contenido
6
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

semntico obtenemos que un caso de uso es incluido en otro. Este

constructor es predefinido como un estereotipo que podemos aadir a
nuestro diagrama de casos de uso. Existe cierta confusin respecto el
nombre de este estereotipo, algunos autores como por ejemplo Doug
Rosenberg, nombran al estereotipo con el nombre de uses, en vez de
includes ya que dice que includes fue el nombre que se le dio en el
libro original de Jacobson en las tempranas versiones de UML[2].
La relacin extends permite extender un caso de uso dentro de
otro. La idea principal detrs de este constructor es que podemos
usarlo para definir comportamientos opcionales del sistema o
comportamientos bajo ciertas condiciones. Extends tambin es
predefinido como un estereotipo.
UML define un caso de uso como un formulario de una clase
generalizada. Sin embargo, existen diversos autores que no
generalizan los casos de uso, debido a que la generalizacin es usado
por casos de uso abstractos, es decir, para organizar requerimientos
que no estn enlazados directamente, estos autores prefieren el uso
de otros estereotipos debido a que tanto uses como includes, o
extends, guardan una estrecha relacin en su significado semntico,
de manera que es ms fcil cometer una equivocacin a la hora de
decidir que estructura usar en nuestros casos de uso.
A diferencia de UML, OML (Open Modeling Language) no utiliza
los estereotipos uses o (includes), ni extends, OML define nuevos
conceptos como el invokes y el precedes. Estos nuevos conceptos,
toman la forma de estereotipo definido por el usuario en los
diagramas de caso de uso.
En OML, la idea de invokes est basada en que un caso de uso
llama a otro caso de uso, de la misma manera que una funcin
principal llama a una subfuncin. Por otra parte, precedes es definido
por OML para indicar que un caso de uso necesita preceder a otro
dentro de una secuencia lgica en un diagrama de casos de uso. El
uso de precedes nos ayuda a mantener el foco en lo que hay dentro
del caso de uso. Es decir, que accin o acciones se deben llevar a
cabo antes un caso de uso en concreto, as como invokes ayuda a
7
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

especificar en nuestro diagrama de casos de usos que casos deben

ser invocados por al realizar un determinado caso de uso.
Existe mucha controversia dentro del campo de casos de uso
sobre que es mas eficiente a la hora de disear un diagrama de casos
de uso, si la utilizacin de los estereotipos uses / extendes, o los
nuevos estereotipos definidos por OML invokes y precedes. Veamos
un ejemplo de invokes / precedes en un diagrama de casos de uso
para poder establecer mejor criterios de comparacin.

Precedes

Entrada Orden
Compra

Ejecutar
Entrada Orden

Precedes
Figura 2

Entrada Orden
Venta

En la Figura 2 podemos observar el uso de precedes en las

acciones Entrada Orden Compra y

Entrada Orden Venta, las

cuales van precedidas de la opcin Ejecutar Entrada Orden. Esto

nos indica que la ejecucin de una orden, viene precedida por la
entrada de una orden bien sea de compra o de venta, por esta razn
usamos el estereotipo precedes, para indicar dicha precedencia.
Ahora veamos un ejemplo del estereotipo invokes:
Supongamos que al introducir una orden de entrada en nuestro
sistema anterior (figura 2), introdujramos un cliente el cul no existe
en nuestra base de datos, el sistema debera permitir la creacin de
dicho cliente en ese estado de nuestro sistema, es decir, el sistema
debera llamar a la funcin de adicin de clientes. Esto queda
reflejado en la figura 3, lo cual nos indica que no siempre ser
ejecutado el mdulo Definir Clientes, solo cuando el sistema cumpla
8
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

unas determinadas condiciones, en nuestro caso, que el cliente no

exista.

.
Ejecutar
Entrada Orden

invokes
Definir Clientes

Figura 3
Observemos como quedara nuestro diagrama de caso de uso
usando invokes y precedes y aadiendo otro opcin en nuestro
diagrama de caso de uso en la cual el usuario podra optar o bien por
ejecutar una entrada de una orden, o bien por acceder directamente
al mantenimiento de los clientes para poder definir un cliente en el
sistema.

Precedes

.
Ejecutar
Entrada Orden

Precedes

invokes

Entrada Orden
Compra

Entrada Orden
Venta

Definir Clientes
Ejecutar
Mantenimiento
Clientes

Precedes

Figura 4
9
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

En la figura 4, podemos observar la nueva opcin para el

usuario Ejecutar Mantenimiento Clientes, la cual preceder a
Definir Clientes debido a la inclusin de la clusula precedes. Esto
indica que cuando se ejecute Definir Clientes, siempre ir precedido
de Ejecutar Mantenimiento Clientes, excepto cuando sea invocado
por Ejecutar Entrada Orden tal y como est indicado en el diagrama
de casos de uso por la clusula invokes.
6. Otros puntos de vista:

La diferencia entre uses y extends parece muy clara y

relevante, es todo un asunto de integracin. El extends
construye informes de desarrollo para la integracin entre
casos de uso que es uno a uno. Los uses constituyen
informes de desarrollo para la integracin que es uno a
muchos.
Cuando decidimos entre uses y el extends hay que hacerse
una pregunta: Cuntos casos de uso podrn estar llamando
a este caso de uso? si la respuesta es uno, entonces usa
extends, sino uses. Doug Rosenberg con Kendall Scott

Otros sin embargo tienen puntos de vista totalmente diferentes,

por ejemplo:

La eleccin entre uses y extends tiene poco que ver con

cuantos casos de uso estn involucrados. Ms bien tiene que
ver sobre lo que sabe un caso de uso de otro. En el caso de
uses, la utilizacin del caso de uso sabe sobre el caso de uso
utilizado. Esto es como la llamada a una funcin; muchos
casos de uso pueden usarel caso de uso utilizado. En el
caso del extends el caso de uso extendido contiene una serie
de eventos primarios, pero no tiene idea sobre la existencia
de casos de uso extendidos.
10
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

La extensin del caso de uso sobrescribe secciones del caso

de uso extendido. As pues la extensin del caso de uso
acta como una especie de editor, cambiando solo ciertas
partes del caso de uso extendido. As cuando el caso de uso
cambie, todos los casos de uso extendidos heredarn estos
cambios sin ser afectados.
Estas
personas.

razones

son

demasiado

complicadas

para

muchas

Las ltimas dos propuestas llevan al autor a intentar cambiar la

forma de pensar entre precedes e invokes.

La

mayora

de

nosotros

preferimos

las

relaciones

Uses/extends por las siguientes razones:

o Uses/extends llevan asociados mltiples definiciones
de trminos.
o La semntica adicional que diferencia el uses del
extends.
7. Conclusiones
Tras realizar este trabajo hemos comprendido mejor la
diferencia entre que hay entre uses-extends, includes-extends e
invokes-precedes segn cada autor. Adems para centrar el tema
hemos tenido que repasar conceptos bsicos sobre los diagramas de
casos de uso.
Como nuestro trabajo abarca una pequea parte de UML otros
posibles trabajos podran estar centrados en otros aspectos
importantes que ayuden a los alumnos a entender mejor el
funcionamiento de UML, como por ejemplo un estudio sobre
diagramas de clases, diagramas de secuencias, diagramas de
colaboracin, diagramas de distribucin, etc, etc...
8. Referencias

11
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia

[1] Martin Fowler, Kendall Scott, UML Distilled Applying the

Standard Object Modelling Language.
[2] Doug Rosenberg, Kendall Scott, Use Case Driven Object
Modeling With UML A practical Approach.

12
Laboratorio de Sistemas de Informacin
Facultad de Informtica
Universidad Politcnica de Valencia