Diagramas de Caso de

Uso
 Objetivos

Establecer los requisitos funcionales, pero no permiten

determinar los requisitos no funcionales.
La funcionalidad de un sistema, se define por medio de
casos de uso diferentes, donde cada uno de ellos
representa un flujo de eventos especfico.
Capturar el comportamiento del sistema necesario
desde la perspectiva del usuario final para alcanzar uno
o ms objetivos deseados, sin especificar la estructura
interna del sistema
 Concepto : Caso de Uso

Un caso de uso es una secuencia de acciones que lleva

a cabo un sistema que producen un resultado
observable de valor para un actor concreto.
La notacin UML para representar a un caso de uso es:
 Beneficios

Ponen en contexto los requisitos:

Especifican los requisitos en secuencias lgicas
Justifican por qu es necesario el sistema
Son fciles de comprender:
Utilizan una terminologa y estructura fcil de comprender por todos los
stakeholders
Describen historias concretas de cmo funciona el sistema
Facilitan el acuerdo con los usuarios finales, al ponerse en el lugar de
ellos (actores)
Facilitan la creacin posterior de casos de prueba, documentacin y otras
fases de diseo.
Facilitan la reutilizacin
 Actor

Un actor representa un conjunto de roles que un

humano, dispositivo o cualquier sistema externo puede
desempear cuando interactan con el sistema.
Un actor es siempre externo al sistema y no siempre
coincide con un usuario ya que un usuario puede
interpretar diferentes roles (y por tanto puede ser
diferentes actores).
La notacin UML para representar a un actor es:
 Diagrama de Casos de Uso

Un diagrama de casos de uso es

un modelo de las funciones
deseadas para el sistema y su
entorno en forma de relaciones
entre casos de uso y actores.
Un diagrama de casos de uso se
representa visualmente por un
diagrama que muestra las
relaciones entre casos de uso y
actores que comprenden la
funcionalidad completa del
 Especificaciones de Caso de Uso
Nombre: nombre del caso de uso.
Descripcin: breve descripcin del propsito del caso de uso.
Flujo principal de eventos: descripcin textual del flujo bsico de eventos para realizar la
funcionalidad especificada por el caso de uso cuando no ocurre ninguna situacin anmala.
Flujos alternativos de eventos: descripcin textual de la secuencia de acciones a realizar cuando
durante el flujo principal de eventos se produce alguna circunstancia anmala. Los flujos alternativos
se pueden considerar como desvos del flujo de eventos principal.
Requisitos especiales: descripcin textual que recopila los requisitos no funcionales sobre el caso de
uso que no se han detallado ni considerado durante la especificacin de los flujos de eventos pero que
deben tenerse en cuenta durante el diseo o implementacin del sistema.
Precondiciones: descripcin textual que define una restriccin en el sistema cuando el caso de uso
puede empezar.
Poscondiciones: descripcin textual que define una restriccin en el sistema que debe cumplirse
cuando el caso de uso haya terminado.
Puntos de ampliacin: lista de ubicaciones dentro del flujo de eventos del caso de uso en el que se
puede insertar un comportamiento adicional utilizando relaciones de ampliacin entre casos de uso.
Diagramas de casos de uso: diagramas en los que se encuentra implicado el caso de uso que se
est describiendo.
 Modelo de Casos de Uso

Es el entregable que incluye los diagramas de casos de

uso del sistema y la especificacin detallada de los
casos de uso.
Tareas a Realizar
Tarea :Buscar Actores y Casos de Uso

Descripcin
En esta tarea se identifican los actores y los casos de uso que dan soporte a los requisitos
del sistema que se estn implementando. La identificacin explcita de los actores y los
casos de uso define el mbito del sistema. Tambin se modelar visualmente cmo
interactan los actores y casos de uso identificados previamente en el diagrama de casos
de uso.
Objetivo
El objetivo de esta tarea es:
Definir el mbito del sistema: qu manejar el sistema y qu se manejar fuera del sistema.
Definir quin y qu interactuar con el sistema (actores).
Esquematizar la funcionalidad del sistema (casos de uso).
Mostrar de forma grfica cmo interactan los actores y casos de uso del sistema para
proporcionar la funcionalidad deseada.
Rol Responsable
Analista Funcional
Tarea :Buscar Actores y Casos de Uso

Entradas
Documento de Visin: el documento de Visin ser una de las salidas del Modelo de
Negocio. Este documento describir las principales necesidades de los usuarios en
referencia al sistema a desarrollar, incluyendo:
Requisitos funcionales: describen las funcionalidades que el usuario quiere que haga el
sistema desde el punto de vista de negocio.
Requisitos no funcionales: describen las restricciones que han de cumplirse en el entorno
del sistema y describirn propiedades como restricciones tecnolgicas de implementacin,
requisitos de rendimiento, dependencias de plataforma, seguridad, usabilidad, fiabilidad.
Salidas
Identificacin de actores y casos de uso del sistema (con una descripcin breve y un
esquema del flujo de eventos)
Diagramas de casos de uso
Paquetes o agrupaciones de casos de uso
Tarea :Buscar Actores y Casos de Uso

Pasos
Encontrar y nombrar los actores
Encontrar los actores es uno de los primeros pasos en el Diseo Funcional del
sistema. Cada tipo de entidad externa con el que debe interactuar el sistema est
representado por un actor.
Para encontrar los actores podemos realizarnos las siguientes preguntas:
Quin utilizar el sistema?
Quin proporcionar, utilizar o eliminar la informacin?
Dnde se utilizar el sistema dentro de una empresa?
Cules son los recursos externos al sistema?
Qu grupos de usuarios son necesarios para ejecutar funciones secundarias
como, por ejemplo, el mantenimiento y la administracin del sistema?
Interactuar el sistema con algn sistema de hardware o software externo?
Deber interactuar con algn sistema heredado?
 Tarea :Buscar Actores y Casos de Uso

La diferencia entre un actor y un usuario de

sistema individual es que un actor representa un
rol en lugar de un usuario real. Varios usuarios
pueden tener el mismo rol, lo que significa que
pueden ser el mismo actor. En este caso, cada
usuario constituye una instancia del actor. Por
ejemplo, Juan y Marcos son usuarios diferentes
que quieren contratar un seguro de coches a una
compaa aseguradora. Cuando contratan el
seguro, cada uno est representado con una
instancia del actor Tomador del Seguro
 Tarea :Buscar Actores y Casos de Uso

El mismo usuario tambin puede actuar

como varios actores (es decir, la misma
persona puede desempear diferentes
roles). Por ejemplo, Carlos, que trabaja en
una compaa aseguradora, utiliza el
Sistema de contratacin de seguros
principalmente como Tomador del Seguro,
pero en algunas ocasiones tambin utiliza
el Sistema de contratacin de seguros
como Administrador del sistema
 Tarea :Buscar Actores y Casos de Uso
Slo debern considerarse como actores los que se comunican directamente con el sistema.

Por ejemplo, en un sistema de contratacin de seguros de automvil, quin sera el actor?

Esto depende de si el sistema de contratacin de seguros se est creando para que para que el
sistema se utilice por un agente de seguros o si se est creando para que el tomador del seguro
pueda contratar el seguro directamente a travs de Internet. Si est creando un sistema de
contratacin de seguros que se utilizar por el agente de seguros, el actor ser el agente de
seguros (el tomador del seguro no interacta directamente con el sistema y por lo tanto no es un
actor):
 Tarea :Buscar Actores y Casos de Uso

Sin embargo, si el sistema permite la contratacin directa

del seguro por Internet para el tomador, ste interactuar
directamente con el sistema y por lo tanto ser un actor:

Cuando un requisito funcional a modelar con casos de

uso se refiera a un proceso batch, el actor que iniciar el
caso de uso que identificar el proceso batch ser
siempre un actor de nombre Planificador:
 Tarea :Buscar Actores y Casos de Uso
Encontrar y nombrar los casos de uso
La mejor forma de encontrar casos de uso es considerar qu necesita cada actor del sistema. El sistema slo existe para los
usuarios y por lo tanto debe basarse en las necesidades de stos. Para cada actor, ya sea una persona o un sistema externo,
hazte las siguientes preguntas:

Cules son las tareas principales que el actor desea que realice el sistema?

El actor crear, almacenar, cambiar, eliminar o leer datos del sistema?

Debe informar el actor sobre cambios externos repentinos al sistema?

Se debe informar al actor sobre ciertas apariciones en el sistema?

El actor realizar un arranque o una conclusin del sistema?

Las respuestas a estas preguntas representan los flujos de eventos que identifican los casos de uso candidatos
Para cada caso de uso debes definir:

Un nombre que indique lo que se ha conseguido por medio de sus interacciones con los actores. Dos casos de uso no pueden

tener el mismo nombre. El nombre del caso de uso deber comenzar por el identificador CUn seguido por el nombre del

mismo con la inicial en mayscula (la numeracin asignada deber ser correlativa y nica). El nombre se iniciar con el infinitivo

del verbo que describa la funcionalidad principal del caso de uso como por ejemplo CU 1 Contratar seguro. Evita verbos

generales como hacer, realizar.. y utiliza verbos ms precisos que describan con ms detalle el propsito del caso de uso.

Una breve descripcin que indique el propsito principal del caso de uso desde el punto de vista del usuario final.
 Tarea :Buscar Actores y Casos de Uso
Esquematizar el flujo de eventos
Identifica y esquematiza el flujo principal y empieza a pensar en los posibles flujos
alternativos:
El flujo de eventos principal describe la secuencia de acciones a realizar para completar el
caso de uso de manera secuencial.
Los flujos alternativos, por el contrario, describen la secuencia de acciones a realizar cuando
durante el flujo bsico se produce alguna circunstancia anmala. Los flujos alternativos se
pueden considerar como desvos del flujo de eventos principal, algunos de los cuales
vuelven al flujo de sucesos principal y otros finalizan la ejecucin del caso de uso como se
muestra en la siguiente figura en la que la flecha recta representa el flujo principal de
eventos y las curvas representan ejecuciones alternativas en relacin con los normal:
Algunas preguntas que te pueden ayudar a identificar flujos de eventos alternativos son:
qu situaciones extraas se pueden producir mientras se est ejecutando el caso de uso?
qu variaciones pueden suceder?
qu puede ir mal durante la ejecucin del caso de uso?
qu puede no suceder durante la ejecucin del caso de uso?
qu tipo de recursos o sistemas externos se pueden bloquear o dejar de funcionar durante la
ejecucin del caso e uso?
Tarea :Buscar Actores y Casos de Uso
Ejemplo
La descripcin inicial del flujo de eventos principal del caso de uso Contratar seguro de
automvil en el Sistema de contratacin de seguros ser parecida a la siguiente:
El cliente selecciona la opcin de Contratar seguro
El cliente selecciona el tipo de seguro de automvil a contratar.
El cliente especifica los datos del seguro de automvil a contratar.
El cliente solicita el clculo del seguro.
El sistema muestra las condiciones y precio del seguro de automvil y el cliente las acepta.
El cliente especifica los datos de facturacin.
El sistema valida los datos del cliente y muestra el nmero de pliza de contratacin.
El cliente imprime el recibo.
Como posibles flujos alternativos a identificar en esta fase para el ejemplo anterior podran
ser:
El automvil que el cliente quiere asegurar no se encuentra catalogado.
El cliente es menor de 25 aos y no cumple con las condiciones impuestas por la compaa
aseguradora.
El cliente no acepta las condiciones del seguro
El sistema de contratacin de seguros no tiene conexin con la red del sistema bancario y no puede
validar los datos del asegurado.
Tarea :Buscar Actores y Casos de Uso

Segn los flujos de eventos principal y alternativos que

hayas definido tendrs diferentes escenarios en el caso
de uso. El escenario de un caso de uso es una
instancia del caso de uso, es decir, es la secuencia
ordenada de eventos desde el comienzo de un caso de
uso hasta la finalizacin en uno de sus puntos de fin.
La diferencia entre flujo de eventos y escenario se
representa en la siguiente figura:
Tarea :Buscar Actores y Casos de Uso
Describir cmo interactan actores y casos de uso: Diagramas de casos de uso
Debers realizar diagramas de casos de uso que muestren las relaciones entre los
actores y los casos de uso identificados. Una lnea o flecha entre un actor y un caso de uso
indica que interactan enviando seales entre s. Aunque la comunicacin entre un actor y
un caso de uso implique varias secuencias de comunicacin debers definir como mximo
una asociacin de comunicacin para cada pareja actor-caso de uso:
Un actor comunica con un caso de uso por varios motivos, entre los que se incluyen:
Para invocar un caso de uso.
Para solicitar algunos datos almacenados en el sistema, que el caso de uso busca y
presenta al actor.
Para cambiar los datos almacenados en el sistema mediante un dilogo con el sistema.
Para informar de que ha sucedido algo especial en el entorno del sistema que debe
tenerse en cuenta
Los casos de uso comunican con los actores por varios motivos, entre los que se incluyen:
Si ha ocurrido algo en el sistema es posible que el actor necesite saberlo para estar
informado.
Un caso de uso puede necesitar la ayuda de un actor para tomar una decisin o realizar
ciertas acciones
 Tarea :Buscar Actores y Casos de Uso
Empaquetar actores, casos de uso y diagramas
Si el nmero de actores, casos de uso y/o diagramas es demasiado grande, divdelos en paquetes para simplificar su mantenimiento. Esto

tambin te facilitar la comprensin del modelo de casos de uso y simplificar la asignacin de responsabilidades, al permitir que puedas asignar

responsables de los paquetes identificados.

La divisin en paquetes debe seguir una estrategia clara aunque no existe una regla concreta de cmo realizar esta divisin ni del nmero de

niveles de paquetes que se van a utilizar. Algunos criterios que puedes utilizar para realizar esta divisin son:

Empaquetar en un mismo paquete todos los actores

Empaquetar en un mismo paquete todos los casos de uso que interactan con el mismo actor.

Empaquetar en un mismo paquete todos los casos de uso que proporcionan una funcionalidad similar.

Empaquetar en un mismo paquete todos los casos de uso opcionales.

Una norma general es que cada paquete debera contener aproximadamente de 3 a 10 unidades ms pequeas
(actores, casos de uso, diagramas de casos de uso u otros paquetes). La siguiente tabla proporciona algunas
sugerencias acerca del nmero de paquetes que deberas utilizar en funcin del nmero de casos de uso y actores (las
cantidades se solapan porque es imposible proporcionar directrices exactas):
 Tarea :Buscar Actores y Casos de Uso
Guas-Listas de comprobacin
Lista de comprobacin para la identificacin de actores
Para comprobar que hemos identificado correctamente los actores del sistema deberemos
hacernos las siguientes preguntas:
Tienen los actores nombres intuitivos y descriptivos? Es importante que los nombres de los
actores correspondan a sus roles, no a nombres concretos de usuarios. Si no es as,
cmbialos.
Cada actor est relacionado al menos con un caso de uso? Elimina los actores que no se
relacionen con ningn caso de uso.
Conoces al menos dos personas que puedan desempear el rol de un actor concreto? Si no,
comprueba si puedes fusionar este actor con otro actor.
Hay actores que desempeen roles similares en relacin al sistema? Si es as, fusinalos en
un nico actor.
Hay dos actores que desempean el mismo rol en relacin con un caso de uso? Si es as
utiliza generalizaciones de actor (ver tarea Estructurar modelo de casos de uso).
Va un actor determinado a utilizar el sistema de formas completamente diferentes o utiliza
el caso de uso con funcionalidades completamente diferentes? Si es as, utiliza actores
diferentes.
Tarea :Buscar Actores y Casos de Uso
Lista de comprobacin para la identificacin de casos de uso
Para comprobar que hemos identificado correctamente los casos de uso del sistema deberemos hacernos las siguientes preguntas:

Tienen los casos de uso un identificador nico y nombre descriptivo que permita conocer el propsito del caso de uso slo con su nombre? Si

no es as cmbialo para que el nombre del caso de uso sea lo suficientemente descriptivo.

Los casos de uso identificados cubren todos los requisitos funcionales especificados en el documento de Visin de entrada? Si no es as define

nuevos casos de uso para los requisitos funcionales que no estn cubiertos.

Hay casos de uso que no se trazan con ningn requisito funcional del documento de Visin? Si es as elimina estos casos de uso porque no son

necesarios para el sistema.

Proporciona el caso de uso un resultado con valor para un actor? Si no es as el caso de uso no tiene entidad por s misma y debes incluir su

funcionalidad dentro de otro caso de uso que s proporcione valor para un actor. Para estar seguro que el caso de uso proporciona valor a un

actor hazte preguntas como: Qu quiere conseguir el actor al ejecutar el caso de uso?

Cada caso de uso (excluyendo los casos de uso abstractos resultado de relaciones de ampliacin, generalizacin y/o inclusin) se relaciona al

menos con un actor? Si no es as, es que el caso de uso no proporciona funcionalidad a los usuarios y debera ser eliminado.

Representa el caso de uso requisitos no funcionales? Si es as elimnalo y pasa su contenido al documento de Especificaciones

suplementarias porque los casos de uso deben representar requisitos funcionales del sistema.

Se ejecutan dos casos de uso siempre en la misma secuencia? Si es as deberan ser fusionados en un solo caso de uso que incluya la

funcionalidad de ambos de manera secuencial.

Tarea :Buscar Actores y Casos de Uso
Directrices
Definicin de actores
Preguntas que te puedes plantear:
Quin utilizar este sistema?
A qu otros sistemas va a enviar informacin este sistema?
De qu otros sistemas va a recibir informacin?
Quin inicia el sistema?
Quin va a mantener la informacin de usuario?
Instancia o clase?
Es posible que se te planteen preguntas tales como "Por qu no es Tom el actor? Tom
es el que siempre se ocupa de hacerlo". A continuacin, debes plantear ms
preguntas para que se comprenda el rol de Tom. El nombre del actor debe reflejar el
rol.
Cul es el rol de Tom?
Quin ms puede ejecutar este rol?
Por qu tiene Tom este rol?
Tarea :Buscar Actores y Casos de Uso
Identificacin de los casos de uso
Preguntas que plantear:
Cada actor debe tener, como mnimo, un caso de uso. Si no es as, se
puede deber a que el actor es un duplicado (otro actor juega el mismo rol)
o debido a que el actor no es, en realidad, un usuario directo del sistema.
En estos casos, si en una discusin sobre la necesidad de mantener al
actor conducen a motivos poco importantes, se puede eliminar al actor
Descripcin breve para cada caso de uso
Tarea :Buscar Actores y Casos de Uso

Descripcin paso a paso del flujo de

eventos para cada caso de uso
El procedimiento para empezar a escribir un
caso de uso es, en primer lugar, estructurar
el texto.
Trazabilidad de requisitos con casos de
uso
 Detallar especificacin del Caso de
Uso
Descripcin
En esta tarea se aadirn los detalles a los casos de uso identificados completando el
documento de Especificacin de Caso de Uso para cada uno de ellos.
Objetivo
El objetivo de esta tarea es:
Detallar el caso de uso para aumentar la comprensin de ste.
Describir los flujos de eventos o escenarios de utilizacin del caso de uso con el detalle
suficiente para que se pueda comenzar con el desarrollo del sistema.
Rol Responsable
Analista Funcional
Entradas
Identificacin de actores y casos de uso (con una descripcin breve y un esquema del flujo de
eventos)
Diagramas de casos de uso
Paquetes de casos de uso
Salidas
Especificacin de casos de uso
 Pasos
Detallar el flujo de eventos
principal
Para describir el flujo de eventos
principal sigue las siguientes
recomendaciones:
Describe cmo se inicia y finaliza el
caso de uso.
Divide la descripcin del flujo de
eventos en subsecciones numeradas y
con un nombre. Los nmeros permiten
hacer referencia fcilmente a una
subseccin cuando se describan los
flujos alternativos y los nombres
permiten que el lector disponga de una
visin general rpida del flujo de
eventos examinando el texto y leyendo
slo las cabeceras.
Evita tener varios niveles de
subsecciones: el texto resulta ms
complejo y difcil de comprender.
Describe los datos que se intercambian
el actor y el caso de uso pero sin
describir los detalles de la interface de
usuario.
Utiliza un lenguaje natural y sencillo,
entendible por cualquier usuario
externo al sistema.
Escribe frases breves y precisas
 Tarea :Buscar Actores y Casos de Uso
Detallar los flujos de eventos alternativos
Para describir los flujos de eventos alternativos sigue las siguientes recomendaciones:
Aclara en qu lugares del flujo de eventos principal se incluye cada uno de los flujos de
eventos alternativos. Para ello describe claramente la subseccin del flujo bsico en la que
se produce el flujo alternativo y la condicin que se debe cumplir para que se inicie el
comportamiento alternativo.
Aclara cmo acaba cada uno de los flujos alternativos: si al acabar se reanuda el flujo de
eventos principal (indicando cmo y en qu subseccin) o bien cmo finaliza el caso de uso.
Utiliza un lenguaje natural y sencillo, entendible por cualquier usuario externo al sistema.
Escribe frases breves y precisas
Describir los requisitos especiales
En este apartado debers describir los requisitos no funcionales relacionados con el caso de
uso pero que no se han tenido en cuenta al describir los flujos de eventos.
Describir condiciones previas (precondiciones)
Puedes utilizar el apartado de Precondiciones en la plantilla Especificacin de caso de
uso para explicar el estado en el que debe estar el sistema para que se pueda iniciar el
caso de uso.
Tarea :Buscar Actores y Casos de Uso

Describir condiciones posteriores (poscondiciones)

Puedes utilizar el apartado de Poscondiciones en la plantilla
Especificacin de caso de uso para explicar los estados en
los que se puede encontrar el sistema una vez que ha
finalizado el caso de uso.
La poscondicin debe ser vlida para todos los flujos del caso
de uso, no slo para el principal
 Tarea :Buscar Actores y Casos de Uso
Guas-Listas de comprobacin
Lista de comprobacin para la especificacin detallada de casos de uso
Para comprobar que hemos especificado correctamente los casos de uso del sistema deberemos hacernos las siguientes preguntas:

La especificacin est libre de detalles de diseo e implementacin? La especificacin del caso de uso debe describir qu hace el
sistema, no cmo se debe implementarse el sistema para proporcionar la funcionalidad deseada.
Las descripciones de los flujos de eventos estn hechas desde el punto de vista del sistema? Si es as, cambia las descripciones y
ponlas desde el punto de vista del actor que utiliza y recibe valor del sistema. Este es uno de los principales objetivos y beneficios
del los casos de uso frente a una especificacin tradicional de requisitos: expresar la funcionalidad del sistema desde el punto de
vista del usuario final.
Cubre la especificacin del caso de uso tanto el comportamiento normal como flujos alternativos de comportamiento cuando se
produce alguna circunstancia anmala?
Se han identificado y nombrado claramente cada uno de las subsecciones del flujo principal y los flujos de eventos alternativos?
Cada flujo de eventos alternativo identifica en qu subseccin del flujo de eventos principal se inserta?
Son las descripciones de los flujos de eventos claras, no ambiguas y completas?
Es verificable cada uno de los flujos (principal y alternativos) del caso de uso?
Est claro cmo comienza y finaliza el caso de uso?
No confundas la especificacin de un caso de uso con el diseo del prototipo de la interface de usuario. Aunque los casos de uso
deben describir los requisitos desde el punto de vista del usuario final no es el lugar ms ptimo de detallar el diseo de la
interface de usuario. Es mejor diferenciar ambos entregables puesto que si no la verificacin y validacin de los casos de uso sera
muy extensa (ya que tambin estara sujeta a la validacin del diseo de la interface de usuario que puede variar con facilidad).
 Tarea : Estructurar Modelo de Caso
de Uso
Objetivo
El objetivo de esta tarea es:
Extraer el comportamiento comn, opcional y excepcional en casos de uso abstracto mediante
relaciones de inclusin, ampliacin y/o generalizacin.
Encontrar nuevos actores abstractos que definan roles que estn compartidos por varios actores.
Rol Responsable
Analista Funcional
Entradas
Identificacin de actores y casos de uso
Diagramas de casos de uso
Paquetes de casos de uso
Especificacin de casos de uso
Salidas
Identificacin de actores y casos de uso
Diagramas de casos de uso
Paquetes de casos de uso
Especificacin de casos de uso
 Tarea : Estructurar Modelo de Caso
de Uso
Pasos
Identificar requisitos comunes y establecer relaciones de inclusin y/o
generalizacin entre casos de uso
Relacin de inclusin
Si hay comportamiento comn a dos o ms casos de uso o si un caso de uso contiene un
segmento de comportamiento en el que slo el resultado, no el mtodo para obtener el
resultado, es importante para el resto del caso de uso, este comportamiento se puede
descomponer en un nuevo caso de uso de inclusin (caso de uso abstracto ya que por s solo
no tiene entidad y no proporciona valor al usuario final. No necesita tener un actor asociado).
El caso de uso original se convierte entonces en el caso de uso base y el comportamiento
extrado se convierte en el caso de uso de inclusin y entre ellos se estable una relacin de
inclusin.
Grficamente la relacin de inclusin se representa como una flecha entre el caso de uso base y
el caso de uso de inclusin (en la especificacin detallada del caso de uso base deberemos
especificar el punto concreto del flujo de eventos en el que se realizar la inclusin del caso de
uso de inclusin) con el estereotipo <<incluir>>:
Ejemplo
En un sistema de cajero automtico, los casos de uso Retirar dinero,
Ingresar dinero en efectivo y Transferir fondos necesitan incluir
cmo se identifica el cliente en el sistema. Este comportamiento se
puede extraer en un nuevo caso de uso de inclusin llamado
Identificar cliente, que incluyen los tres casos de uso de base. Los
casos de uso de base son independientes del mtodo que se utiliza
para la identificacin y, por este motivo, se encapsula en el caso de
uso de inclusin. Desde la perspectiva de los casos de uso de base,
no importa si el mtodo para la identificacin va a leer una tarjeta
bancaria magntica, o bien, si va a realizar un reconocimiento de
retina. Slo dependen del resultado de Identificar cliente, que es la
identidad del cliente. Y viceversa, desde la perspectiva del caso de
uso Identificar cliente, no importa cmo utiliza el caso de uso de
base la identidad del cliente ni lo que sucede en el mismo antes de
ejecutar la inclusin; el mtodo para la identificacin sigue siendo
exactamente el mismo.
El comportamiento de la inclusin se inserta en una ubicacin del
caso de uso base determinada. Cuando durante la ejecucin del
caso de uso base se llega a donde se ha definido la relacin de
inclusin se ejecuta el caso de uso de inclusin y una vez ejecutado
su flujo de eventos se reanuda la ejecucin a partir del punto en el
que el se dej el caso de uso base como muestra la siguiente figura:
Tarea : Estructurar Modelo de Caso
de Uso
Relacin de generalizacin
Si dos o ms casos de uso tienen similitudes en comportamiento, estructura
y objetivo puedes crear un caso de uso padre (a veces abstracto porque
no tiene sentido su ejecucin aislada y no proporciona valor para ningn
actor) con el compartimiento comn a los casos de uso originales, y los
casos de uso originales se convertirn en casos de uso hijos con
relaciones de generalizacin con el caso de uso padre. Estos casos de uso
hijos heredarn todo el comportamiento descrito para el caso de uso padre.
Grficamente la relacin de generalizacin se representa como una
asociacin de generalizacin entre el caso de uso hijo y el caso de uso padre
(en la especificacin detallada del caso hijo deberemos especificar el punto
concreto del flujo de eventos en el que se realizar la inclusin del caso de
uso padre):
Ejemplo
Los casos de uso Pedido telefnico y Pedido por
Internet son especializaciones del caso de uso
padre Realizar pedido.
En un sistema de Gestin de pedidos, los casos de
uso Pedido por telfono y Pedido por Internet
comparten mucho en cuanto a estructura y
comportamiento. Un caso uso general Realizar
pedido se define porque se ha identificado una
estructura y el comportamiento comn. El caso de
uso padre Realizar pedido no tiene que
completarse por s mismo, pero proporciona una
infraestructura de comportamiento general que
pueden completar los casos de uso hijos:
El caso de uso hijo depende de la estructura del
caso de uso padre, pero el hijo puede modificar o
ampliar contenido el contenido especificado en el
caso de uso padre como se muestra en la
siguiente figura:
Tarea : Estructurar Modelo de Caso
de Uso
Diferencias entre relacin de inclusin y generalizacin
Tanto las relaciones inclusin como la generalizacin de casos de uso se
pueden utilizar para reutilizar comportamiento entre casos de uso. La
diferencia es que con la generalizacin de casos de uso, la ejecucin de
los hijos depende de la estructura y el comportamiento del padre (la parte
reutilizada), mientras que en una relacin de inclusin, la ejecucin del
caso de uso de base slo depende del resultado de la funcin que lleva a
cabo el caso de uso de inclusin (la parte reutilizada).
Otra diferencia es que en una generalizacin, los hijos comparten
similitudes en cuanto al objetivo y la estructura, mientras que en la
relacin de inclusin, los casos de uso de base que reutilizan la misma
inclusin pueden tener objetivos totalmente diferentes, pero necesitan
que se lleve a cabo la misma funcin.
 Tarea : Estructurar Modelo de Caso
de Uso
Identificar actores con comportamiento comn y
establecer relaciones de generalizacin entre
actores
Una vez que has identificado los casos de uso y actores del sistema y
relaciones entre ellos debers revisar los actores que realizan el mismo rol en
un caso de uso concreto. Debers modelar estos actores que tengan
caractersticas comunes utilizando relaciones de generalizacin.
Grficamente la relacin de generalizacin entre actores se representa como
una asociacin de generalizacin entre el actor hijo y actor padre:
 Ejemplo:
Un Cajero y un Contable, que comprueban el
balance de una cuenta, se consideran como la
misma entidad externa del caso de uso que
realiza la comprobacin. El rol compartido est
modelado como actor, Supervisor de saldo,
heredado de dos actores originales. Esta
relacin se muestra con las generalizaciones
de actor. Los actores Cajero y Contable
heredan todas las propiedades del Supervisor
de saldos. Por lo tanto, estos actores pueden
actuar como Supervisores de saldos (pero a lo
mejor el actor Contable interacta tambin con
otros casos de uso con los que no interacta el
actor Cajero y viceversa):
 Guas-Listas de comprobacin
Lista de comprobacin para la
estructuracin del modelo de
casos de uso
Para comprobar que hemos estructurado
correctamente el modelo de casos de uso
del sistema deberemos hacernos las
siguientes preguntas:
Hay alguna parte del flujo de eventos de
un caso de uso que se repite en varios
casos de uso? Si es as, saca el flujo de
eventos comn en un nuevo caso de
inclusin y establece una relacin de
inclusin entre los casos de uso base
originales y el nuevo caso de uso de
ampliacin creado.
Hay alguna parte del flujo de eventos de
un caso de uso que es opcional o se
proporciona de manera de manera
excepcional? Si es as, saca esta parte del
flujo de eventos a un nuevo caso de uso de
ampliacin y establece una relacin de
ampliacin entre el caso de uso base
original y el nuevo caso de uso ampliado.