Casos de uso

Qu son los casos de uso

Podemos imaginar el caso de uso como una coleccin de
situaciones respecto al uso de un sistema. Cada escenario describe una
secuencia de eventos. Cada secuencia se inicia por una persona, otro
sistema, una parte del hardware o por el paso del tiempo. A las entidades
que inician secuencias se les conoce como actores. El resultado de la
secuencia debe ser algo utilizable ya sea por el actor que la inici, o por
otro actor.

El caso de uso es una estructura que ayuda a los analistas a trabajar
con los usuarios para determinar la forma en que se usar un sistema. Con
una coleccin de casos de uso se puede hacer el bosquejo de un sistemas
en trminos de lo que los usuario intenten hacer con l.
Construccin de los Casos de Uso
Un caso de uso describe la interaccin entre uno o ms actores y el
sistema, de tal forma que se provea un resultado observable que sea de
valor para el actor participante.

La funcionalidad del sistema est definida por diferentes casos de
uso cada uno representando metas especficas (obtener un resultado
observable y de valor) para un actor en particular.

Este artefacto captura la secuencia de acciones que un sistema realiza y
que genera un resultado observable que es de valor para aquellos que
interactan con el sistema.
Importancia de los Casos de uso
As como el diagrama de clases es un buen medio para estimular a
un cliente a que hable respecto a un sistema desde su propio punto de
vista, el caso de uso es una excelente herramienta
para estimular a que los usuarios potenciales hablen, de un sistema, desde
sus propios puntos de vista. No siempre es fcil para los usuarios explicar
cmo pretenden utilizar un sistema.

La idea es involucrar a los usuarios en las etapas iniciales del anlisis y
diseo del sistema. Esto aumenta la probabilidad de que el sistema sea de
mayor provecho para la gente a la que supuestamente ayudar, en lugar
de ser un manojo de expresiones de computacin incomprensibles e
inmanejables por los usuarios finales.

Un caso de uso establece un conjunto de escenarios para realizar algo til
para un actor.
Propsito
El propsito principal de los Casos de Uso es capturar el comportamiento
requerido del sistema desde la perspectiva del usuario final, alcanzar una o
ms metas. Diferentes usuarios se benefician en diferente forma, por
ejemplo:

Los Clientes los usan para describir, o al menos para aprobar, la
descripcin del comportamiento del sistema.
Los Usuarios Potenciales los usan para entender el comportamiento
del sistema
Los Arquitectos los usan para identificar la funcionalidad
arquitectnicamente significativa.
Los Realizadores de Software los usan para entender los
comportamientos requeridos del sistema de tal manera que ellos
puedan identificar clases desde el flujo de eventos de los casos de
uso.
Los Probadores los usan como una base para identificar un
subconjunto de los Casos de Prueba requeridos.
Los Administradores los usan para planear y evaluar el trabajo para
cada iteracin.
Los Escritores Tcnicos los usan para entender la secuencia del
comportamiento del sistema que ellos necesitan describir en la
documentacin.
Inclusin de los casos de uso

En algunos casos pude existir duplicacin de pasos de un caso de
uso a otro. Para poder eliminarlo la forma de hacerlo es tomar cada
secuencia de pasos en comn y conformar un caso de uso adicional a
partir de ellos.

La inclusin de un caso de uso tambin se conoce como usar un
caso de uso. La ventaja del termino incluir trae dos ventajas. La primera,
los pasos en un caso de uso, incluyen los de otros. La segunda, se evita la
confusin potencial de las palabras usar y uso en un contexto tan
estrecho. As, no tendremos que decir promover el uso mediante el uso
reiterativo de un caso de uso.
Extensin de los casos de uso
Es posible volver a utilizar un caso de uso de una forma distinta a una
inclusin. En ocasiones crearemos un caso de uso agregndole algunos
pasos a un caso de uso existen.
Opciones de Representacin
Decida la extensin de los Casos de Uso que usted elaborara:

Describir nicamente flujos principales?
Describir nicamente los Casos de Uso ms importantes?
Describir completamente las precondiciones y post-condiciones?
Describir escenarios primero, y luego elevar el nivel de abstraccin
describiendo los flujos de los Casos de Uso?

Algunos proyectos aplican Casos de Uso informalmente para ayudar a
descubrir los requisitos, documentar y gestionar estos requisitos en otra
forma tal como unas historias de usuario. La forma como usted presente los
Casos de Uso podra depender del tamao del proyecto, la experiencia
del equipo, su conjunto de herramientas, las relaciones con el cliente, y as
sucesivamente.

Un caso de uso describe las interacciones entre los actores y el sistema en
trminos de un dilogo estructurado como sigue:

1. El actor <<hace algo>>
2. El sistema <<hace algo en respuesta>>
3. El actor <<hace algo ms>>
4. El sistema

Cada dialogo, mostrado de esta forma es llamado un Flujo de eventos.
Debido a que existen muchos flujos de eventos posibles para lograr los
objetivos (por ejemplo, el flujo puede ser diferente de acuerdo a entradas
especficas del Actor) y hay situaciones en las cuales las metas no puedan
sean alcanzadas (por ejemplo, una conexin de red puede no estar
disponible), cada flujo de eventos debe contener muchos flujos,
incluyendo un Flujo Bsico y muchos Flujos Alternativos.

El Flujo Bsico especifica la interaccin entre los actores y el sistema para
un caso de uso ideal, cuando todo va segn lo planeado y las metas son
alcanzadas por el Actor. El flujo bsico representa la funcionalidad
principal proveda por este caso de uso.

Como el nombre lo dice, los Flujos Alternativos especifican interacciones
alternativas asociadas con la misma meta.

Relacionado con los casos de uso est el concepto de Escenario. Un
escenario es un flujo de eventos especfico para un conjunto especfico de
entradas y estados del sistema y del contexto del sistema. Los escenarios
estn ntimamente relacionados con los casos de prueba.
Propiedades de los Casos de Uso
a. Nombre
Cada caso de uso debe tener un nombre que describa claramente el
objetivo principal del caso de uso. El nombre debe tener el nmero de
palabras adecuado para ser claro y no tan extenso. Usualmente el
nombre identifica una accin por ejemplo: Retirar Dinero.

Nota: Dos casos de uso no pueden tener el mismo nombre.

b. Descripcin breve
Refleja de forma clara y concisa el propsito de los casos de uso.

c. Flujo de Eventos Contenido
El flujo de eventos deber describir claramente la interaccin entre el
actor, o actores, y el sistema. El flujo de eventos deber representar lo que
hace el sistema y no como el sistema est diseado para realizar la labor
requerida.

Se deben seguir las siguientes guas para crear el contenido del flujo de
eventos:
Describir como empieza y termina el caso de uso.
Describir que datos son intercambiados entre el actor y el caso de
uso.
No describir detalles de la interfaz de usuario a menos que sea
necesario para entender el comportamiento del sistema. Especificar
los detalles de la interfaz de forma temprano podra limitar las
opciones de diseo.
Describir el flujo de eventos, no solo la funcionalidad. Para forzar esto
empezar cada accin como "Cuando el actor...".
Evitar trminos vagos o ambiguos.
Detallar el flujo de eventos. Especificar que sucede cuando..., en
cada accin. Recuerde que este texto podr ser utilizado para
identificar casos de prueba.

Si se han utilizado ciertos trminos en otros casos de uso debe garantizarse
que tambin son utilizados de la misma forma (semntica y sintctica) en
el caso de uso actual. Para administrar los trminos se deben colocar en el
Glosario.

d. Flujo de Eventos Estructura
Las dos partes principales del flujo de eventos son el flujo bsico y los flujos
alternativos, El flujo bsico de eventos debe cubrir los que normalmente
pasa cuando se desarrolla el caso de uso. Los flujos alternativos de eventos
cubren comportamiento de carcter excepcional u opcional en relacin
con el comportamiento normal; tambin pueden hacer referencia a
variaciones del comportamiento normal. Se puede pensar en los flujos
alternativos como desviaciones en la ruta del flujo bsico de eventos
algunos de los cuales retornaran al flujo bsico mientras que otros se
llevaran hasta finalizar el caso de uso.

La flecha recta de la figura No 2 representa el flujo bsico de eventos y las
lneas curvas representan rutas alternativas en relacin a la normal.
Algunas rutas alternativas retornarn al flujo bsico de eventos mientras
que otras terminarn el caso de uso.


Para aclarar el sitio donde un flujo alternativo encaja en la estructura del
caso de uso es necesario describir los siguientes aspectos para cada uno
de los desvos del flujo bsico de eventos:

Dnde puede ser insertado el flujo alternativo de eventos
Cul es la condicin que debe cumplirse para que el comportamiento
alternativo comience.
Cmo y dnde se regresa al flujo bsico de eventos o como termina el
caso de uso.

Si un flujo de eventos es muy simple se tiende a insertarlo directamente
dentro del flujo bsico por medio de sentencias del tipo si entonces.

Lo anterior en todo caso debe evitarse ya que degenera en casos de uso
complejos de comprender. En todo caso se debe emplear lenguaje
natural y no emplear construcciones que parezcan pseudo cdigo.
Recordar que los casos de uso deben ser validados por los interesados.

Tanto los flujos bsicos como los alternativos pueden ser estructurados en
sub-flujos.

Al hacer esto se debe perseguir que el texto sea ms comprensible y fcil
de leer. Una gua es que el sub-flujo debe contener un segmento de
comportamiento con un objetivo claro dentro del caso de uso y que
puede ser atmico en el sentido de que las acciones que contiene deben
ser ejecutadas completamente.

e. Requerimientos Especiales
En la seccin de requerimientos especiales del caso de uso se describen
todos los requerimientos que no fueron cubiertos por los flujos de eventos.
Usualmente se trata de requerimientos no funcionales que pueden influir en
el modelo de diseo.

f. Precondiciones y poscondiciones
Una precondicin es el estado en que el sistema, y su contexto, debe estar
para que el caso de uso pueda iniciarse. Las postcondiciones son estados
en los cuales el sistema puede estar despus de que el caso de uso ha
terminado. Es de gran ayuda utilizar tanto las precondiciones como las
postcondiciones para aclarar como los casos de uso empiezan y terminan.
Sin embargo, se deben utilizar solo si los interesados y el grupo de desarrollo
necesitan realmente esta informacin. La figura No 3 muestra un ejemplo.

Ilustracin de precondiciones y postcondiciones








g. Nivel de detalle en los casos de uso
Usualmente el modelo contiene casos de uso que son tan simples que no
requieren una descripcin detallada y estructurada. En estos casos una
descripcin en formato paso a paso sera suficiente para describirlos, sin
embargo este enfoque solo debe tomarse si tanto los interesados como el
grupo de desarrollo acuerdan que no se necesita mayor refinamiento para
lograr entender el objetivo del caso de uso. Ejemplos clsicos incluyen a los
casos de uso que describen la entrada de datos al sistema o la bsqueda
de informacin dentro del mismo.
Lista de verificacin
Esta lista de verificacin provee una serie de preguntas que sirven
para determinar si los casos de uso han sido descritos de una manera
consistente o con un grado ptimo de exactitud

El nombre del caso de uso es nico, claro, descriptivo y no ambiguo?
El caso de uso tiene un nombre nico?
El nombre tiene la estructura verbo + sujeto (por ejemplo: Registrar
Espacio Acadmico)?
El nombre resume el propsito principal del caso de uso?
El nombre es independiente del Actor?

La descripcin efectivamente presenta el objetivo principal del caso de
uso?
Queda claro, despus de leer la descripcin, cual es propsito
principal del caso de uso?
Los resultados de valor que arroja el caso de uso son obvios?

Los actores e informacin intercambiada estn claramente definidos?
El caso de uso est asociado a uno o ms actores?
El actor principal o actor inicial est definido?
Es claro quien realiza las acciones en el caso de uso?
La informacin intercambiada ente el sistema y los actores est
claramente definida?
Si un actor "tiempo" es utilizado, Est seguro que no se est
desconociendo la importancia de un actor o de otros casos de uso
asociados? (quizs personal administrativo o de mantenimiento que
se encargan quienes definen los cronogramas)

Las precondiciones estn definidas?
Cada pre-condicin representa un estado concreto del sistema?

El flujo principal y los flujos alternativos son completos, correctos y
consistentes?
Est definido donde comienza el caso de uso?
El evento que desencadena el caso de uso est claramente
descrito?
El flujo tiene un final definitivo?
Cada paso del escenario tiene el mismo nivel de abstraccin o de
especificidad?
Cada paso del escenario describe algo que puede suceder
actualmente y que el sistema puede detectar razonablemente?
Cada paso representa un progreso para alcanzar la meta?
Faltan pasos? Est claro cmo se va desde un paso a otro? La
secuencia de comunicacin entre actores y el caso de uso est
conforme a las expectativas del usuario?
Cada paso describe como ste ayuda al actor a alcanzar sus
metas?
Cada paso es independiente de la tecnologa? Cada paso est
libre de detalles tcnicos o de restricciones de diseo?
Los pasos estn numerados de forma correcta?
Para cada flujo alternativo, las condiciones de inicio estn
claramente definidas?
Para cada flujo alternativo, Esta claro cmo termina el caso de uso
o en qu punto el flujo bsico continuo?

Las postcondiciones estn especificadas?
Si las Garantas Mnimas estn presentes, Estas siempre pasan
cuando se completa el caso de uso independientemente de su
xito? (Una Garanta Mnima representa una condicin que debe ser
verdadera cuando el caso de uso termina sin importar la forma en
que este termine.)
Si las Garantas de xito estn presentes. Estas siempre pasan
cuando el caso de uso termina de forma exitosa? (Una Garanta de
xito representa una condicin que ser verdadera cuando el caso
de uso termina de forma exitosa.)
Los requisitos no funcionales han sido capturados?
Los requisitos no funcionales que aplican al caso de uso han sido
capturados?
Dichos requisitos son aplicables a muchos casos de uso? Si esto es
cierto, considere capturarlos en el documento de Especificacin de
Requisitos.
Construccin de los Modelos de Casos de Uso
Esta gua describe como desarrollar y evolucionar el modelo de caso de
uso para poder capturar los requerimientos funcionales para el sistema en
desarrollo.

La clave de xito en un desarrollo iterativo es asegurar que el equipo de
desarrollo maximiza el valor entregado a los interesados y minimiza el riesgo
en las etapas tempranas del proyecto. Esto impone algunas restricciones
en la forma en que se desarrolla el modelo de casos de uso.

En un extremo est el enfoque clsico en cascada, el cual propone
detallar todos los requerimientos antes del diseo y la implementacin. Esto
demora innecesariamente las entregas que se puedan hacer a los
interesados y no se tiene un control sobre el riesgo.

En el otro extremo est comenzar el diseo y desarrollo antes de conocer
lo que el sistema debe de hacer lo que genera costosas reelaboraciones
en etapas tardas del ciclo de vida.

Un enfoque que ha demostrado ser adecuado propone detallar los
requerimientos que sern desarrollados en la siguiente (o mximo dos
siguientes) iteraciones. La seleccin de los requerimientos a desarrollar est
fundamentado en el valor que entrega a los interesados y en la reduccin
de los riesgos. Aunque no se espera un conocimiento completo del
dominio se es necesario tener una vista general del mismo.

Las siguientes discusiones bosquejaran el enfoque usado para llevar el
modelo de casos de uso a un sistema que alcance las metas propuestas.
El enfoque recomendado es ancho antes que profundo. Se deben
identificar los actores y los casos de uso para realizar bosquejos de ellos
rpidamente. Basado en este conocimiento se puede realizar una
valoracin inicial del riesgo y as concentrar el esfuerzo en detallar los casos
de uso de las reas correctas.

Este artefacto captura un modelo de las funciones esperadas del sistema
as como el mbito del mismo. Sirve de contrato entre la institucin y los
desarrolladores.

Este artefacto presenta una visin del comportamiento esperado del
sistema. Es la base para los acuerdos de desarrollo entre los interesados y el
grupo de proyecto. Tambin ayuda a guiar las diferentes tareas dentro del
ciclo de vida del desarrollo de software.
Diagramas de casos de uso
El caso de uso es un poderos concepto que ayuda a un analista a
comprender la forma en que un sistema deber comportarse. Le ayuda a
obtener los requerimientos desde el punto de vista del usuario. Es
necesario aprender a visualizar los conceptos del caso de uso.
El caso de uso es muy poderoso, pero lo es an ms cuando se
visualiza por medio del UML. Esta visualizacin le permitir mostrar los casos
de uso a los usuarios para que ellos le puedan dar mayor informacin. Es
un hecho que los usuarios con frecuencia saben ms de lo que dicen: el
caso de uso ayuda a romper el hielo. A su vez una representacin visual le
ayuda combinar los diagramas de casos de uso con otro tipo de
diagramas.
Una de las finalidades del proceso de anlisis de un sistema es
generar una coleccin de casos de uso. La idea es tener la posibilidad de
catalogar y referencia a esta coleccin, que sirve como el punto de vista
de los usuarios del sistema. Cuando llegue el momento de actualizar el
sistema, el catlogo de casos de uso funcionar como un fundamento
para obtener los requerimientos de la actualizacin.
Representacin de un modelo de caso de uso
Hay un actor que inicia un caso de uso y otro (posiblemente el que
inici, pero no necesariamente) que recibir algo de valor de l. La
representacin grfica es directa. Una elipse representa a un caso de uso,
una figura agregada representa a un actor. El actor que inicia se
encuentra a la izquierda del caso de uso, y el que recibe a la derecha. El
nombre del actor aparece justo debajo de l, y el nombre del caso de uso
aparece ya sea dentro de la elipse o junto debajo de ella. Una lnea
asociativa conecta a un actor con el caso de uso, y representa la
comunicacin entre el actor y el caso de uso. La lnea asociativa es slida,
como la que conecta a las clases asociadas.
Uno de los beneficios del anlisis del caso de uso es que la muestra
los confines entre el sistema y el mundo exterior. Generalmente, los actores
estn fuera del sistema, mientras que los casos de uso estn dentro de l.
Utilizar un rectngulo (con el nombre del sistema en algn lugar dentro de
l) para representar el confn del sistema. El rectngulo envuelve a los
casos de uso del sistema.
Los actores, casos de uso y lneas de interconexin componen un modelo
de caso de uso.

Ejemplo Mquina de Gaseosas:

Figura 2
Un modelo de caso de uso de una
mquina de gaseosas.





Secuencia de pasos en los escenarios
Cada caso de uso es una coleccin de escenarios y cada escenario
es una secuencia de pasos. Como puede ver, tales pasos no aparecen en
el diagrama. No se encuentran en notas adjuntas a los casos de uso. La
claridad es clave en la generacin de cualquier diagrama y el adjuntar
notas a cada caso de uso podra volverlo confuso Cmo y dnde hara
la secuencia de pasos?
El uso de los diagramas de casos de uso ser, por lo general, parte
de un documento de diseo que el cliente y el equipo de diseo tomarn
como referencia. Cada diagrama tendr su propia pgina, de igual
manera, cada escenario de caso de uso tendr su propia pgina, donde
se listarn en modo de texto:
El actor que inicia al caso de uso
Condiciones previas para el cas de uso
Pasos en el escenario
Condiciones posteriores cuando se finaliza el escenario
El actor que se beneficia del caso de uso
Tambin puede enumerar las conjeturas del escenario y una breve
descripcin de una sola frase del escenario.
Concepcin de las relaciones entre casos de uso
Anteriormente se describi que existen dos formas en que los casos
de uso se pueden relacionar entre s. Una de ellas, la inclusin, le permite
volver a utilizar los pasos de un caso de uso dentro de otro. La otra,
extensin, le permite crear un caso de uso mediante la adicin de pasos a
uno existente.
Existente otros dos tipos de relaciones que son generalizacin y
agrupamiento. Como en las clases, la generalizacin cuenta con un caso
de uso que se hereda de otro. El agrupamiento es una manera sencilla de
organizar los casos de uso.
Inclusin
Para representar a la inclusin utilizar una lnea discontinua con una
punta de flecha. Justo sobre la lnea, agregara un estereotipo: la palabra
incluir bordeada por dos pares de parntesis angulares. La figura 3 le
muestra la relacin de inclusin en el modelo de caso de uso de una
mquina de gaseosas.
Tenga en cuenta que un caso de uso incluido nunca aparecer solo.
Simplemente funciona como parte de un caso de uso lo incluya.
En la notacin de texto que sigue los pasos en la secuencia, indicar los
casos de uso incluidos. El primer paso en el caso de uso Reabastecer
podra ser incluir (Exhibir el interior).

Extensin
En un caso de uso, cuando uno nuevo agrega otros paso a la
secuencia del caso de uso original, que se le conoce como el caso de uso
base. Este nuevo caso de uso extiende al original.
La extensin slo se puede realizar en puntos indicados de manera
especfica dentro de la secuencia del caso de uso base. A estos puntos se
les conoce como puntos de extensin. En el ejemplo que hemos hablado
de una mquina de gaseosas, en el caso de uso Reabastecer, los nuevos
pasos (anotar las ventas y abastecer de manera acorde) se daran luego
que el representante haya abierto la mquina y est listo para llenar los
comportamientos de las marcas de gaseosas. Ac, el punto de extensin
es Llenar los compartimientos.
Como la inclusin, podr concebir la extensin con una lnea de
dependencia (lnea discontinua con punta una punta de flecha), junto
con un estereotipo que muestra extender entre parntesis angulares.
Dentro del caso de uso bsico, el punto de extensin aparecer debajo
del nombre del caso de uso. La figura 4 le muestra la relacin de extensin
para Reabastecer y Reabastecer de acuerdo a las ventas, junto con la
inclusin de relaciones para Reabastecer y Recolectar dinero.

Generalizacin
Las clases pueden heredarse entre s y esto tambin se aplica a los casos
de uso. En la herencia de los casos de uso, el caso de uso secundario
hereda las acciones y significado del primario, y adems agrega sus
propias acciones. Puede aplicar el caso de uso secundario en cualquier
lugar donde aplique el primario.
En el ejemplo, deber imaginar un caso de uso Comprar un vaso de
gaseosa que se hereda de Comprar gaseosa. El caso de uso
secundario tiene acciones como agregar hielo y mezclar marcas de
gaseosas. Modelar la generalizacin de casos de uso de la misma forma
que lo hace con la cas clases: con lneas continuas y una punta de flecha
en forma de tringulo sin rellenar que apunta hacia el caso de uso
primario, como se muestra en la figura 5.

La relacin de generalizacin puede establecerse entre actores, as
como entre casos de uso. Quiz tenga personificados el representante del
proveedor, al recolector y al agente del proveedor. Si cambia el nombre
del presentante como Reabastecedor, tanto ste como el Recolector
sern secundarios del Agente Proveedor, como muestra la figura 6.


Agrupamiento
En ciertos diagramas de casos de uso, podra tener varios casos de
uso que querr organizar. Eso puede ocurrir cuando un sistema consta de
varios subsistemas. Otra posibilidad sera cuando entrevista a los usuarios
para obtener los requerimientos de un sistema. Cada requerimiento podra
ser representado como un caso de uso por separado. Necesitar alguna
forma de ordenar los requerimientos por categoras.
La forma ms directa de organizar sera agrupar en un paquete los
casos de uso que se relacionen. Recuerde que un paquete aparece
como una carpeta tabular. Los casos de uso agrupados aparecern
dentro de la carpeta.









Enterprise Arquitect
El Modelo de Caso de Uso
El modelo de casos de uso describe la funcionalidad propuesta del nuevo
sistema. Un caso de uso representa una unidad discreta de interaccin
entre un usuario (humano o mquina) y el sistema. Un Caso de Uso es una
unidad simple de trabajo significativo; por ejemplo, "Validarse en el
sistema", "Registrarse en el sistema" y "Crear un pedido" son todos casos de
uso.
Cada caso de uso tiene una descripcin que describe la funcionalidad
que se construir en el sistema propuesto. Un caso de uso puede "incluir" la
funcionalidad de otro caso de uso o "extender" a otro caso de uso con su
propio comportamiento.
Una descripcin de caso de uso generalmente incluir:
Comentarios generales y notas describiendo el caso de uso
Requisitos -cosas que el caso de uso debe permitir hacer al usuario, tales
como <capacidad para actualizar pedido>, <capacidad para modificar
pedido>, etc.
Restricciones -reglas acerca de qu se puede y qu no se puede hacer-.
Incluye:
Pre-condiciones que deben ser verdaderas antes de que el caso de uso se
ejecute, por ejemplo <crear pedido> debe preceder a <modificar pedido>
Post-condiciones que deben ser verdaderas una vez que el caso de uso se
ejecut, por ejemplo <el pedido est modificado y es consistente>
Invariantes: stas son siempre verdaderas -por ejemplo, un pedido debe
tener siempre un nmero de cliente.
Escenarios -descripciones secuenciales de los pasos que se toman para
llevar a cabo el caso de uso. Pueden incluir escenarios mltiples, para
satisfacer circunstancias excepcionales y caminos de proceso alternativos
Diagramas de escenarios -diagramas de secuencia para describir el flujo
de trabajo- similar al punto 4 pero descrito grficamente.
Atributos adicionales como fase de implementacin, nmero de versin,
rango de complejidad, estereotipo y estado

Actores
Un actor es un usuario del sistema. Incluye usuarios humanos y otros
sistemas computarizados. Un actor usa un caso de uso para desempear
alguna porcin de trabajo que es de valor para el negocio. El conjunto de
casos de uso al que un actor tiene acceso define su rol global en el sistema
y el alcance de su accin.


Relaciones de Inclusin y Extensin entre Casos de Uso
Un Caso de Uso puede incluir la funcionalidad de otro como parte de su
procesamiento normal. Generalmente se asume que los casos de uso
incluidos se llamarn cada vez que se ejecute el camino base. Un ejemplo
puede ser listar un conjunto de rdenes de clientes de las cules poder
elegir antes de modificar una orden seleccionada; en este caso, el Caso
de Uso <listar rdenes> se puede incluir en el Caso de Uso <modificar
orden> cada vez que ste se ejecute.
Un Caso de Uso puede ser incluido por uno o ms casos de uso, ayudando
as a reducir la duplicacin de funcionalidad al factorizar el
comportamiento comn en los casos de uso que se reutilizan muchas
veces.
Un Caso de Uso puede extender el comportamiento de otro Caso de Uso;
tpicamente cuando ocurren situaciones excepcionales. Por ejemplo, si
antes de modificar un tipo particular de orden de cliente, un usuario debe
obtener la aprobacin de alguna autoridad superior, entonces el Caso de
Uso <obtener aprobacin> puede extender opcionalmente el Caso de Uso
normal <modificar orden>.

Los casos de uso modelan el sistema desde el punto de vista del usuario.
Describe cmo el usuario va a utilizar el sistema, los requisitos funcionales, la
forma en la que las cosas externas (los actores), interactan con el sistema
y las respuestas de ste.
Cuando describimos los casos de uso, no nos preocupamos en la manera
de implementarlo. Si pensamos en la descripcin de los casos de uso que
describen el uso de un automvil, tendremos en actor Conductor. El
escenario inicial se encuentra cuando va a acceder al automvil abriendo
la puerta con la llave. Se describir en detalle cada una de las
interacciones del usuario, como el ajuste del asiento y el volante, el uso del
cinturn de seguridad, el manejo de los mandos, etc. Hay que identificar
todas las situaciones que se puedan llegar a producir, como que ocurre si
no hay gasolina, o se salta el indicador del nivel del aceite. Todas estas
acciones describirn varios casos de uso. Del mismo modo, se identificarn
otros actores, como el actor Copiloto, que no conducir pero podr
realizar otras acciones, como subir y bajar la ventanilla, poner el aire
acondicionado, manipular la radio O el actor Mecnico que realizar
la revisin del coche, acceder al motor abriendo el cap, etc.
Elementos del diagrama de casos de uso
Vamos a ver un ejemplo bsico.

Caso de uso
Los actores se representan con un monigote, y cada uno de los casos de
uso, se representan con una elipse. El rectngulo que se muestra el
diagrama es la frontera del sistema. Todo lo que queda dentro del
rectngulo forma parte del sistema. Una lnea slida conecta el actor con
el caso de uso. El actor no necesariamente tiene que ser una persona,
puede ser cualquier entidad que interacta con el sistema.
Cada escenario de caso de uso, tendr su propia pgina, en la que se
describir en modo texto:
o Actor que inicia el caso de uso
o Condiciones previas
o Pasos en el escenario
o Condiciones posteriores, cuando se finaliza el escenario
o Actor que se beneficia del caso de uso
Inclusin
Si existen acciones que se repiten en varios casos de uso, se pueden
agrupar la secuencia de pasos en comn, y agruparlos en un nuevo caso
de uso que ser aprovechado en otros casos de uso. Por ejemplo, tanto el
Conductor, como el Copiloto abren la puerta del coche, se ajustan el
colocan el cinturn de seguridad, etc. Se pueden agrupar esas acciones
en un nuevo caso de uso Acceder al automvil.

Inclusin
Nota: Una manera de seleccionar el tipo de asociacin que nos interesa en
un diagrama de casos de uso en EA, consiste en hacer un clic sobre el
elemento de origen, hasta que se muestre una pequea flecha.
Seguidamente arrastraremos la flecha hasta el elemento de destino y
cuando la soltemos, se nos mostrar un cuadro de dilogo, donde
indicaremos el tipo de asociacin.

Detalle de la relacin
Extensin
Cuando creamos un caso de uso a partir de un caso existente, aadiendo
nuevas acciones, estamos hablando de extender el caso de uso. Por
ejemplo, si tuvisemos el caso de uso Revisar niveles, en los que un actor
revise los niveles de aceite, lquido de frenos, etc. se podra extender este
caso de uso para realizar una Revisin total, en el que adems de revisar
los niveles, comprobemos los faros, las ruedas, etc.

Extensin
Cuando se extiende un caso de uso, se puede utilizar un punto de
extensin, que indica en que escenario se produce el comportamiento
alternativo. En el ejemplo anterior, se podra haber incluido un texto todos
los niveles son correctos, para indicar nicamente se realiza la revisin
total, cuando todos los niveles estn a punto.
Nota: Para aadir puntos de extensin en EA, hay que hacer clic derecho
sobre el caso de uso y seleccionar Advanced >> Edit Extensin Points.
En el cuadro de dilogo que se abre, se pueden aadir todos los puntos de
extensin que se necesiten.

Aadir punto de extensin
Los puntos de extensin se muestran como un texto bajo una lnea
horizontal en el caso de uso.
Generalizacin
Es similar al caso anterior. Al igual que en la programacin orientada a
objetos podemos extender una clase para aadir nuevas propiedades, se
puede extender un caso de uso, para aadir nuevos comportamientos. Se
pueden generalizar tanto los casos de uso como los actores.




Conclusiones

El caso de uso es una poderosa herramienta para obtener los
requerimientos funcionales. Los diagramas de casos de uso agregan
mayor poder: debido a que conciben los casos de uso, facilitan la
comunicacin entre los analistas y los usuarios, y entre los analistas y los
clientes. En un diagrama, el smbolo del caso de uso es una elipse. El
smbolo de un actor es una figura adjunta. Una lnea asociativa conecta a
un actor con el caso de uso. Los casos de uso estn, por lo general, dentro
de un rectngulo que representa el confn del sistema.
La inclusin se representa por una lnea de dependencia con un
estereotipo incluir. La extensin se representa por una lnea de
dependencia con un estereotipo extender. Las otras dos relaciones
entre casos de uso son generalizacin, en la que un caso de uso hereda el
sentido y acciones de otro, y el agrupamiento, mismo que organiza un
conjunto de casos de uso. La generalizacin se representa por la misma
lnea que muestra la herencia entre clases. El agrupamiento se representa
por el icono del paquete.
Los diagramas de casos d uso figuran con fuerza en el proceso de anlisis.
Se empieza con entrevistas con los clientes para obtener diagramas de
clases. stos proporcionan una base para entrevistar a los usuarios. Tales
entrevistas dan por resultado un diagrama de casos de uso de alto nivel
que muestra los requerimientos funcionales del sistema. Para crear los
modelos de caso de uso, profundice en cada caso de uso de alto nivel.
Los diagramas resultantes de caso de uso darn los fundamentos para el
diseo y desarrollo.







BIBLIOGRAFIA

Schmuller, Joseph. Aprendiendo UML en 24 horas. Editorial Princtice Hall
EGRAFIA

http://www.sparxsystems.com.ar/resources/tutorial/use_case_model.html
http://www.udistrital.edu.co:8080/documents/276352/356568/Cap6Gestion
RequerimientosRequisitos.pdf