Cundo utilizar los Casos de Uso?

Los casos de uso son un tipo de requerimientos utilizados para especificar funcionalidad,
especialmente en sistemas con un alto grado de interaccin hombre/mquina (y pueden ser
utilizados hasta en sistemas de batch). En esencia los casos de uso describen los intercambios
entre el sistema que se est describiendo y las personas o sistemas externos que interactan con
el primero, por lo tanto son muy tiles para describir funcionalidades a varios tipos de usuarios y
con muchas interfaces.
Para qu sirven los Casos de Uso?
Los casos de uso son tiles para capturar requerimientos, ayudar a definir la arquitectura,
establecer las pautas para el diseo y las pruebas funcionales. Los CU son una gua de los
elementos que sern incluidos en los documentos de usuarios para las aplicaciones, as como la
forma en como stos deben ser empleados. Los CU tambin establecen las bases para los
protocolos de comunicacin entre aplicaciones y el diseo de las interfaces grficas, entre otros.
La validez de los casos de uso viene dada cuando los usuarios e involucrados del sistema aceptan
el funcionamiento propuesto en los CU, siempre que la redaccin de los mismo sea buena, no
dejando cabida a ambigedades.
Entonces los casos de uso deben ser tiles y ofrecer valor tanto al equipo de usuarios e
involucrados como a los desarrolladores del proyecto.
Qu es un Modelo de CU y que son los CU?
Los casos de uso describen secuencias de acciones que realiza un sistema y que lleva a un
resultado de valor a un actor especfico.
Un modelo de CU est compuesto por dos partes, un diagrama (grfico) y una parte textual. El
diagrama muestra las relaciones entre actores y casos de uso, as como las relaciones entre los
CU y entre actores en caso que existan . La parte textual muestra la descripcin escrita en
lenguaje natural que narra los pasos y dems caractersticas del caso de uso.

Qu son los actores y cmo identificarlos?
Actor es algo o alguien fuera del Sistema que interacta con el Sistema.
Un actor especifica un rol que alguna entidad externa adopta cuando interacta con el sistema
directamente. Puede representar un rol de usuario o un rol jugado por otro sistema o hardware que
toca la frontera del sistema. [NEUSTADT]
La siguiente es la lista de preguntas que permiten identificar a los actores que interactuarn con el
Sistema:
Quin o qu utiliza el Sistema?
Qu roles toman en la interaccin?
Quin toma informacin del Sistema?
Quin provee informacin al Sistema?
En qu parte de la compaa es utilizado el Sistema?
Quin instala, soporta y mantiene el Sistema?
Quin inicia y termina la ejecucin del sistema?
Qu otros sistemas utilizan el Sistema?
Ocurre algo en algn momento especfico?
La siguiente es la tabla que describe a los actores del sistema. El cdigo del actor reseado como
ACT.# se refiere al prefijo ACT. Seguido por el nmero de actor asignado. La descripcin se refiere
a una breve resea del rol del actor para el sistema y las fuentes son los involucrados del negocio
que ayudaron a definir y describir al actor.
Actor ACT.#Nombre del Actor
Descripcin <descripcin del actor>
Responabilidades <Responsabilidad 1>
<Responsabilidad 2>
Fuentes <Stakeholders que identificaron y contribuyeron a definir al actor>
Cmo se hace el Diagrama de CU?
El diagrama de CU ofrece la visin global que cuenta lo que hay afuera del sistema y lo que hay
adentro del sistema. Esto es, especifica las fronteras del sistema.
El aspecto de diagramas de casos de uso para sistemas batch vara con respecto a los empleados
para interfaces con usuarios.
El diagrama de CU no debe reflejar ni el flujo de control ni el flujo de datos, sino de asociaciones
que son canales de comunicacin.
Los casos de uso reflejan las relaciones entre los actores y los casos de uso.
Tampoco se trata de diseo.
Cuando la comunicacin es iniciada por el actor, la relacin de comunicacin contiene una flecha
hacia el lado del CU. Si no la contiene entonces el CU es quien solicita al actor de la interaccin.
Que un sistema invoque a un actor para alguna funcin solo ocurre con el caso de actores no
humanos (otros sistemas), y nunca ocurre que el CU por s solo invoca al actor, siempre tiene que
haber un actor que solicite su activacin, considere que si esto no ocurre, probablemente lo que
Ud. est tratando de modelar no sea un CU. Arlow y Neustadt sugieren la incorporacin de un
actor llamado tiempo para cuando un CU es disparado no por la interaccin directa de un actor
sino cada cierto perodo de tiempo, ejemplo, CU.1 Recolectar informacin de campo: Breve
descripcin Cada 5 minutos el sistema dispara automticamente este CU que se comunica con
los dispositivos de campo para solicitar informacin.
Qu son Casos de Uso y cmo identificarlos?
Los Casos de Uso representan lo que un actor desea que haga el Sistema. Los casos de uso
definen una secuencia de acciones ejecutadas por un sistema que producen un resultado
observable de valor para un actor.
En el libro The UML Reference Manual de RUMBAUGH se definen los casos de uso como: la
especificacin de secuencia de acciones, incluyendo variaciones a la secuencia y secuencia de los
errores, que un sistema, subsistema o clase realizan con la interaccin de actores externos.
Los casos de uso son siempre iniciados por un actor y son escritos desde el punto de vista del
actor.
La siguiente es la lista de preguntas que permiten identificar los casos de uso dentro de las
fronteras de un sistema:
Qu funciones del sistema son requeridas por un actor especfico?
El sistema guarda o recupera informacin? Si es as Qu actores disparan esta accin?
Qu ocurre cuando el sistema cambia de estado? Algn actor es notificado?
Algn evento externo afecta al sistema? Qu notifica el sistema respecto de estos
eventos?
El sistema interacta con algn sistema externo?
El sistema genera algn reporte?
Cmo especificar Casos de Uso?
La especificacin de los casos de uso se refiere a la descripcin de cada una de las partes
definidas para lograr su descripcin completa. En la organizacin, la especificacin de los Casos
de Uso se har bajo el formato presentado a continuacin. El siguiente cuadro muestra las partes y
las indicaciones bsicas para iniciar su redaccin. En las siguientes secciones del documento se
presentan las recomendaciones que hacen que la redaccin de CU sea ms fcil, sencilla de leer y
escribir.







Caso de Uso CU.1 XX
Fuentes <Stakeholders que proporcionaron informacin de esta funcionalidad>
Actor Act.# <nombre de los actores> [(<Pseudnimos>)] [ secundario]
Descripcin <Descripcin del caso de uso>
Flujo bsico 1. Titulo del paso
Descripcin del paso.
2. Titulo del paso
Descripcin del paso.
Flujos alternos 1. Titulo del FA
Descripcin del FA
2. Titulo del FA
Descripcin del FA.
Pre-condiciones 1. Titulo del Precondicin
Descripcin del PRC
Post-condiciones 1. Titulo del Poscondiciones
Descripcin de la PTC
Requerimientos
trazados
1. Titulo del requerimiento
Descripcin del requerimiento o porqu se enlaza a el desde este caso de uso
Puntos de
inclusin
1. Ttulo del punto de inclusin
Descripcin del punto de inclusin
Puntos de
extensin
1. Ttulo del punto de extensin
Descripcin del punto de extensin
Notas 1. Titulo de la Nota
Descripcin de la nota

Caso de Uso
El nombre del CU debe comenzar por un verbo y ser lo ms corto posible, pero que a su vez,
describa lo que el CU hace. El nombre del CU debe indicar el valor u objeto que genera para el
actor. El nombre del CU comienza por su identificacin CU.# donde # es el nmero asignado a
este CU.

Fuentes
Son las personas que conocen del negocio, y las que proporcionan informacin para la descripcin
de la funcionalidad.

Actores
Los actores que interactan directamente con el sistema, tanto los primarios quienes inician el CU,
como los secundarios que interactan con el sistema luego que este ha iniciado. Cuando se
nombran los actores en la seccin de actores del CU se coloca el cdigo asignado en la seccin de
actores ejemplo Act.1. En caso de haber actores segundarios, el CU debe indicar cuales son
secundarios, el resto se asumen primarios, de lo contrario se asume que todos son primarios. Los
actores secundarios se les coloca luego del pseudnimo un guin y la palabra secundario en
letra itlica.
El nombre del actor puede contener al lado una lista de pseudnimos, estos son utilizados en el
CU para describir su funcionamiento con el empleo del pseudnimo en vez del nombre del actor (o
rol) que puede ser muy largo. El pseudnimo tambin puede ser empleado en forma de lista de
actores, si un pseudnimo est indicado en varios actores, entonces la referencia al pseudnimo
en el detalle del CU har indistinta la sustitucin por cualquiera de los actores.

Descripcin
Es un prrafo que resume el objetivo del caso de uso. Sin dar detalles del cmo, la descripcin del
caso de uso resume todo lo que el caso de uso hace, que es el valor que da al actor (o actores)
primario, as como la necesidad de la existencia de actores secundarios, para los casos que
aplique.

Ejemplo. El caso de uso permite al Administrador crear, modificar y borrar usuarios en el sistema
El caso de uso permite al Cliente obtener la informacin sobre su estado de cuenta del Sistema
de Manejo de Clientes.
Flujo bsico
El flujo bsico (FB) describe los pasos que se sucederan en el escenario del mundo perfecto o
del da feliz. El flujo bsico es un camino simple, sin ramificaciones y en l suelen hacerse una
serie de asunciones, las alternativas a estos presuntos son los flujos alternos.
Cada paso del flujo bsico contiene 1) un nmero de paso o flujo, 2) titulo del paso, y 3) la
descripcin del paso. La numeracin del paso es un consecutivo que inicia con el nmero 1 en el
primer paso. El ttulo del paso representa un resumen de lo que el paso realiza, suele ser una
oracin que inicia con un verbo en estado activo Ej. crear usuario, buscar datos de clientes
mayores. La descripcin del paso contiene el detalle de lo que se espera que ocurra en el paso.
Dependiendo de la complejidad del sistema o los datos manejados, los pasos pueden tener varios
intercambios, ejemplo:
Flujos alternos
Los flujos alternos (FA) se definen como flujos independientes, no como subflujos, permitiendo
hacer que un flujo alterno aplique de manera global a todo el CU, o a varios flujos bsicos u
alternativos. Mantener los FA de forma plana facilita su lectura, su escritura y su comprensin. El
formato utilizado emplea una seccin separada para los flujos alternos. Los flujos alternos pueden
hacer referencia a flujos bsicos u otros flujos alternos. Todos los FA deben indicar (en este orden):
Dnde comienzan? Desde donde parte este FA, puede ser un FB o un FA.
Qu los dispara? Que hace que este FA inicie
Qu sucede? Lo que pasa cuando el FA es invocado, anlogo al FB.
A dnde regresa? Una vez que termina de ejecutarse el flujo alterno, A dnde
regresa la ejecucin del caso de uso?
Pre-condiciones
Las precondiciones son elementos opcionales de los CU. Cada precondicin listada tiene: 1)
nmero, 2) ttulo 3) descripcin (opcional). El nmero es un consecutivo. El titulo debe resumir muy
brevemente la condicin. La descripcin puede dar detalles de cmo la condicin es evaluada, o el
rango de valores que pueden ser aceptados para la condicin.
Bittner y Spence hacen nfasis en que las precondiciones no son eventos que disparan o activan el
CU en el sistema. Sin embargo son declaraciones en las cuales el caso de uso puede comenzar.
Las precondiciones son necesariamente ciertas para que el CU pueda comenzar, pero no
suficientes. El CU slo puede ser comenzado por el actor cuando las precondiciones son ciertas.
Las precondiciones no son evaluadas en los FB ni los FA pues se asumen como ciertas. Si las
precondiciones aplican para todos los CU del sistema entonces es un requerimiento y no debe
indicarse.
Para hallar precondiciones formlese las siguientes preguntas:
En qu estado debe encontrarse el sistema para que el CU se pueda disparar?
Qu elementos deben estar presentes para que el CU pueda iniciar?
Cules son los supuestos asumidos?
Qu restricciones aplican al empleo del CU por los actores?
Note que las precondiciones son opcionales de no existir no agregue precondiciones que no
aporten a la explicacin del CU. Evite precondiciones como El usuario debe estar vivo o La
maquina debe estar encendida y el sistema debe estar activado y funcionando, pues no agregan
valor al diseo y son obvias.
Post-condiciones
Las postcondiciones son elementos opcionales de los CU. Los elementos y patrones para describir
postcondiciones son iguales a los de las precondiciones.
Bittner y Spence explican que las postcondiciones deben ser ciertas cuando el CU termina, sin
importar el curso de eventos que se sucedieron. Si algo puede fallar Ud. debe cubrirlo en las
postcondiciones para describir el estado en el que el sistema se encontrar cuando el CU se
completa.
Las postcondiciones son importantes puesto que dan las luces sobre las condiciones que
garantizan que siempre que termine el CU el sistema queda en un estado vlido y los datos
inherentes (en caso de existir) se encuentran consistentes. Las postcondiciones son igualmente
tiles para verificar que las pruebas que se realicen sobre este CU aseguren que estas condiciones
se darn al salir, sea cual fuere el curso de acciones tomadas.
Para hallar postcondiciones formlese las siguientes preguntas:
En qu estado debe quedar el sistema luego que termina el CU?
Qu debe garantizarse cuando termine para que el sistema no quede
inconsistente o no utilizable?
Cules son las nicas condiciones vlidas en las que puede acabar una
ejecucin del CU?
Armour y Miller aclaran que tanto las precondiciones como postcondiciones se refieren a estados
del sistema, no del ambiente fuera del mismo, ello debido a que las condiciones del ambiente no se
modelan dentro del sistema.
Requerimientos trazados
Los requerimientos son formas de enlazar los CU o especificaciones funcionales con el resto de las
especificaciones no funcionales. Estas especificaciones o requerimientos deben encontrarse en el
repositorio de requerimientos con la informacin completa de los atributos definidos. Aunque la
trazabilidad con los requerimientos especiales se da por demostrada en el mapa de trazabilidad de
los requerimientos, el tenerlos presentes en el CU hace ms fcil su lectura para el diseador e
constructor.
Para los requerimientos se debe especificar el nmero, el ttulo y la descripcin del requerimiento
(opcional). El ttulo puede contener el cdigo del requerimiento y el ttulo del mismo segn la
definicin que se establezca para las especificaciones no funcionales del sistema. La descripcin
puede omitirse puesto que se asume que la misma se encuentra en el repositorio de
requerimientos, sin embargo se pueden dar indicaciones adicionales de cmo el CU debe cumplir
con este requerimiento.
Puntos de inclusin y extensin
Los puntos de inclusin son los enlaces para incluir un funcionamiento especfico del CU que es
empleado por ms de un CU.
Los puntos de extensin son los enlaces que permiten extender la funcionalidad de un CU en un
punto especfico de flujo bsico.
Para determinar cuando colocar y qu colocar en un punto de inclusin o un punto de extensin
ver la seccin de Cmo estructurar Casos de Uso?.
Notas
Las notas son elementos opcionales muy importantes de los CU pues reflejan el anlisis y la
comprensin del funcionamiento del sistema, ms all de la descripcin de las interacciones entre
los usuarios. Las notas en los CU se utilizan para plasmar explicaciones, detalles sobre la
informacin, formatos de archivos que ya se encontraban establecidos y otros acuerdos con los
que la aplicacin debe cumplir. Es importante que todas las notas se encuentren referenciadas con
algn elemento del Caso de Uso, ejemplo la descripcin, el FB, el FA, las referencias justifican la
existencia de la nota.
Las notas son caractersticas muy importantes de los CU puesto que permiten capturar
conocimientos propios del sistema que no se est describiendo, que son tiles a la hora de hacer
el diseo y la implementacin, sin embargo, no representan una funcionalidad propia del CU que
se est especificando.
Recuerde que en su rol de analista de requerimientos, su misin es plasmar la mayor cantidad
posible de detalle posible, ello debido a que es Ud. quin se encuentra ms cercano a los
funcionales que puedan estar revelando la informacin.
Consideraciones a la hora de escribir un Caso de Uso
La siguiente es una serie de consideraciones que deben ser tomadas a la hora de escribir o
especificar casos de uso.
Empleo del SI Condicional
Referido en ingls como using if-statement. Ni los flujos bsicos ni los alternos deben contener SI
condicionales, en esencia, los casos de uso no son algoritmos, sino que describen la interaccin
entre los actores y el sistema. Para hacerlos no ambiguos, los casos de uso asumen un camino
ideal y el resto son caminos alternativos.
Opciones de los actores
Referido en ingls como actor choices o avoid CRUD use cases. Tanto en flujos bsicos,
principalmente, como en flujos alternos, un paso puede contener varias alternativas. El paso debe
presentar al lector todas las alternativas posibles para el actor y tomar una de ellas, la que
corresponde al da feliz. El resto de las opciones correspondern a flujos alternos del caso de uso.
El listado de las opciones debe ser completo, no debe utilizarse el etc. pues es un indicio de
elementos que no han sido especificados y dejarn al diseador la opcin para que los sustituya
por cualquier cosa. El siguiente ejemplo muestra el uso de opciones de los actores.
Mostrando iteraciones
Las iteraciones son descritas en el caso de uso de manera plana, no se debe escribir en forma de
algoritmo con pasos, sino de forma descriptiva. El siguiente es un ejemplo del uso de iteraciones.
Secuencias de eventos y eventos opcionales
A la hora de especificar secuencias de eventos, debe considerarse que no se indiquen secuencias
que no son requeridas. Cada paso en el flujo bsico indica un orden, en el cual los eventos deben
ocurrir, sin la posibilidad (explicita) de hacerse en otro orden. En el caso en que esto ocurre, se
deben especificar los eventos como parte de un mismo flujo o, de forma explcita, de que forma los
eventos pueden ser ejecutados en otro orden. El siguiente ejemplo muestra los pasos en un flujo
bsico que indican secuencias que no son requeridas y dos alternativas para resolverlas.


Cmo identificar las Clases y Objetos.
En el mundo real es sencillo identificar los objetos, sus atributos y sus funciones, pero a la hora de
hacer un programa informtico esta identificacin no resulta tan evidente. Los objetos desde la
realidad se manifiestan como:

Entidades Externas. Pueden ser cosas o personas externos al sistema pero que producen o
consumen informacin del sistema.

Cosas. Objetos fsicos del sistema, informes, facturas, maquinas, etc.

Ocurrencias o sucesos. Cuando se produce un cambio en el tiempo, sacar dinero de una cuenta,
una mquina llega al final de carrera, etc.

Papeles o roles. Los desempeados por personas que interactan en el sistema

Unidades organizacionales. Si son relevantes en un sistema, divisin, equipo, etc.

Lugares. Establecidos en el contexto del sistema. Planta, N de aparcamiento, Plaza, Almacn,
etc.

Estructuras. Una clase de objetos, maquinas, sensores, etc.

As por ejemplo para un programa que juegue al ajedrez podemos identificar:

Clase/ Objeto Potencial
Jugador -> entidad externa o rol
Pieza ->cosa
Tablero -> cosa
Posicin -> atributo de la pieza
Captura -> ocurrencia
Movimiento -> ocurrencia
Color -> atributo de la pieza

Para definir las clases y los objetos conviene analizar sintcticamente el enunciado o
especificacin del software a desarrollar detectando los posibles objetos (nombres) y los posibles
mtodos (verbos). Se han definido seis caractersticas para considerar si se incluye un objeto en
un modelo de anlisis:
Servicios Necesarios. Debe ser capaz de cambiar el valor de sus atributos a travs de un conjunto
de operaciones identificables:

Informacin retenida. La informacin acerca del objeto debe ser recordada para que el sistema
funcione.

Atributos Mltiples. Un objeto debe tener atributos mltiples, si slo tiene uno se puede
considerar durante el anlisis pero seguramente se pueda incluir dicho atributo dentro de otro
objeto
Operaciones Comunes. Las operaciones tienen que ser aplicables a todas las ocurrencias del
objeto.

Atributos Comunes. Los atributos tienen que ser aplicables a todas las ocurrencias del objeto.

Requisitos esenciales. Las entidades externas que intervienen en el problema consumiendo o
produciendo informacin esencial para el sistema tambin deben ser incluidas como objetos.
Para incluir un objeto en nuestro modelo, debe satisfacer la mayora de los puntos mostrados
anteriormente. Una vez elegido el objeto, sus atributos se buscan con la premisa de que definan
completamente los objetos que los hacen nicos.
Si retomamos el ejemplo del ajedrez podemos ver si cumplen los requisitos.

Clase/ Objeto Potencial
Jugador -> entidad externa o rol Rechazado: no cumple muchas caractersticas.
Pieza ->cosa Aceptado: Cumple todas
Tablero -> cosa Rechazado: solo contiene la posicin que pasa a atributo
de . la pieza
Posicin -> atributo de la pieza Pasa a atributo de la pieza
Captura -> ocurrencia Pasa a mtodo de la pieza
Movimiento -> ocurrencia Pasa a mtodo de la pieza
Color -> atributo de la pieza Pasa a atributo de la pieza

Para encontrar las operaciones (mtodos) hay que prestar atencin a los verbos de la definicin
del sistema. As en la definicin del juego de ajedrez el verbo mover es importante y define un
mtodo. Tambin existe el verbo capturar, por lo que habr que tenerlo en cuenta a la hora de
disear la clase.
Finalmente tendremos slo una clase principal llamada Pieza que tendr como propiedades el
color de la pieza y su posicin sobre el tablero, tambin ser necesario aadir otra propiedad que
no viene en la lista que nos diga el tipo de pieza de que se trata.
Tendr un mtodo mover y otro capturar que puede fusionarse como caso especial del mtodo
mover. Tambin es conveniente heredar una clase para cada tipo de pieza. De este modo
tendremos la clase padre Pieza con las clases hijas Pen, Torre, Caballo, Alfil, Rey y Reina, todas
heredan todos los atributos como Color, Posicin, etc. y cada una de ellas implementa un mtodo
diferente llamado Mover que incluye el caso especial Capturar. Dicho caso especial obliga a
introducir otro atributo en la clase pieza que nos indique si la pieza est en juego o no.
Diseo de entrada: consiste en desarrollar los requerimientos y los pasos a seguir
y la realizacin de los procesos necesarios para colocar los datos de forma utilizable
para el procesamiento es asi como se logra instruir a la computadora.
Diseo de salida: es todo aquello producido por el sistema, si la salida no es de
calidad entonces el sistema es innecesario una de las salidas puede ser documentos o
formularios dependiendo del objetivo del sistema.