Diagrama de Casos de Uso

Definicin y Usos
Un diagrama Uso-Caso describe lo que hace un sistema desde el punto de vista de un
observador externo, debido a esto, un diagrama de este tipo generalmente es de los ms
sencillos de interpretar en UML, ya que su razn de ser se concentra en un Que hace el
sistema, a diferencia de otros diagramas UML que intentan dar respuesta a
un Como logra su comportamiento el sistema.
Un Uso-Caso est muy relacionado con lo que pudiera ser considerado un escenario en
el sistema, esto es, lo que ocurre cuando alguien interacta con el sistema:
"Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y
posteriormente se abona a la cuenta del cliente el cargo".
Un Uso-Caso es empleado con ms frecuencia en alguna de las siguientes etapas:

Determinacin de Requerimientos: Por lo general nuevos requerimientos de

sistema generan nuevos usos-casos, conforme es analizado y diseado el sistema.

Comunicacin con el Cliente: Debido a la sencillez de este tipo de diagramas, son

fciles de emplear para comunicarse con el cliente final del proyecto.

Generacin de pruebas de Sistemas: A travs de los diagramas uso-caso se pueden

generar una serie de pruebas de sistema.

La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta interaccin es

esencial para una descripcin coherente del comportamiento deseado, quizs los lmites del
sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interaccin
entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los
actores son una especie de rol, un usuario humano u otra entidad externa pueden jugar
varios papeles o roles. As el Chef y el Cajero podran ser realmente la misma persona.

Se muestra como ilustracin los casos de uso de la mquina de caf.

Sistema
El rectngulo representa los lmites del sistema que contiene
los casos de uso. Los actores se ubican fuera de los lmites
del sistema.

Casos de Uso
Se representan con valos. La etiqueta en el valo indica la
funcin del sistema.

Actores
Los actores son los usuarios de un sistema.

Relaciones
Las relaciones entre un actor y un caso de uso, se dibujan
con una lnea simple. Para relaciones entre casos de uso, se
utilizan flechas etiquetadas "incluir" o "extender." Una
relacin "incluir" indica que un caso de uso es necesitado
por otro para poder cumplir una tarea. Una relacin
"extender" indica opciones

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML,
el cual describe notacin grfica para esas relaciones. Veamos una revisin de ellas a
continuacin:

Inclusin (include)
Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro caso de
uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto
es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso
a una descripcin individual (si el actor realiza el caso de uso base tendr que realizar
tambin el caso de uso incluido), desde el caso de uso. El estndar de Lenguaje de
Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos
de uso, pero no el formato para describir casos de uso.
Extensin (extend)
Es otra forma de interaccin, un caso de uso dado (la extensin) puede extender a otro. El
caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas
condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el
caso de uso extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser
til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el
mantenimiento del sistema y su extensin.
En otras palabras ser utilizado cuando un caso de uso sea similar a otro pero con ciertas
variaciones, un ejemplo claro es que se necesite comprar azcar y podemos seleccionar de
entre azcar rubia, blanca o su unidad de medida bolsa, kilo, etc.
Generalizacin
"Entonces la Generalizacin es la actividad de identificar elementos en comn entre
conceptos y definir las relaciones de una superclase (concepto general) y subclase
(concepto especializado). Es una manera de construir clasificaciones taxonmicas entre
conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales
son conformes con las superclases conceptuales en cuanto a la intencin y extensin."
En la tercera forma de relaciones entre casos de uso, existe una relacin
generalizacin/especializacin. Un caso de uso dado puede estar en una forma
especializada de un caso de uso existente. La notacin es una lnea slida terminada en un
tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se

asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til

factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una
vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

Ventajas
La tcnica de caso de uso tiene xito en sistemas interactivos, ya que expresa la intencin
que tiene el actor (su usuario) al hacer uso del sistema.
Como tcnica de extraccin de requerimiento permite que el analista se centre en las
necesidades del usuario, qu espera ste lograr al utilizar el sistema, evitando que la gente
especializada en informtica dirija la funcionalidad del nuevo sistema basndose solamente
en criterios tecnolgicos.
A su vez, durante la extraccin (elicitation en ingls), el analista se concentra en las tareas
centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al
negocio. Esto facilita luego la priorizacin del requerimiento.
Aunque comnmente se asocian a la fase de Test de una aplicacin, esta idea es errnea, y
su uso se extiende mayormente a las primeras fases de un desarrollo.
Limitaciones
Los casos de uso pueden ser tiles para establecer requisitos de comportamiento, pero no
establecen completamente los requisitos funcionales ni permiten determinar los requisitos

no funcionales. Los casos de uso deben complementarse con informacin adicional como
reglas de negocio, requisitos no funcionales, diccionario de datos que complementen los
requerimientos del sistema. Sin embargo la ingeniera del funcionamiento especifica que
cada caso crtico del uso debe tener un requisito no funcional centrado en el funcionamiento
asociado