c



c


¿Qué es un caso de uso?

- Es la descripción de una secuencia de interacciones entre el sistema y uno o

más actores en la que se considera al sistema como una caja negra y en la que
los actores obtienen resultados observables.

- Es una técnica para capturar información de cómo un sistema o negocio trabaja,

o de cómo se desea que trabaje. No pertenece estrictamente al enfoque
orientado a objeto, es una técnica para captura de requisitos del sistema.

Objetivo

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el

punto de vista del usuario. Por lo tanto, los casos de uso determinan los requisitos
funcionales del sistema, representan las funciones que un sistema puede ejecutar.

Los casos de uso tienen una representación gráfica en los denominados diagramas de
casos de uso. En estos diagramas, los actores se representan en forma de pequeños
monigotes y los casos de uso se representan por elipses contenidas dentro de un
rectángulo que representa al sistema. La participación de los actores en los casos de
uso se indica por una flecha entre el actor y el caso de uso que apunta en la dirección
en la que fluye la información. Cada caso de uso puede estar definido por: texto que lo
describe, secuencia de pasos ejecutados dentro del caso de uso, condiciones pre-post
para que el caso de uso comience o termine.
Los diagramas de casos de uso sirven para proporcionar una visión global del conjunto
de casos de uso de un sistema así como de los actores y los casos de uso en los que
éstos intervienen. Las interacciones concretas entre los actores y el sistema no se
muestran en este tipo de diagramas.

El diagrama de casos de uso representa la forma en cómo un Cliente (Actor) opera con
el sistema en desarrollo, además de la forma, tipo y orden en como los elementos
interactúan (operaciones o casos de uso). Un diagrama de casos de uso consta de los
siguientes elementos: Actores, casos de uso y relaciones de uso: herencia y
comunicación.




 

— 4 :

Una definición previa, es que un 4  es un rol que un usuario juega con

respecto al sistema. Es importante destacar el uso de la palabra rol, pues con
esto se especifica que un Actor no necesariamente representa a una persona en
particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas

en que el rol de Vendedor con respecto al sistema puede ser realizado por un
Vendedor o bien por el Jefe de Local.

— c

:

Es una operación/tarea específica que se realiza tras una orden de algún agente
externo, sea desde una petición de un actor o bien desde la invocación desde
otro caso de uso.

— º


:
Ê 4




Es el tipo de relación más básica que indica la invocación desde un actor

o caso de uso a otra operación (caso de uso). Dicha relación se denota
con una flecha simple.

Ê è





Es una forma muy particular de relación entre clases, en la cual una clase
depende de otra, es decir, se instancia (se crea). Dicha relación se denota
con una flecha punteada.

Ê 



 Este tipo de relación es uno de los más utilizados, cumple una doble
función dependiendo de su estereotipo, que puede ser
de 
 (<<uses>>) o de 
(<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y

no para actores).

 
: Se recomienda utilizar cuando un caso de uso es similar a otro

(características).



: Se recomienda utilizar cuando se tiene un conjunto de

características que son similares en más de un caso de uso y no se
desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y

modelamiento de clases, en donde esta la duda clásica
de 
 o  .




Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El

sistema debe controlar y/o aceptar:

— Registrar el número de ítemes ingresados.

— Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada item
c. Total
— El usuario/cliente presiona el botón de comienzo
— Existe un operador que desea saber lo siguiente:
a. Cuantos ítemes han sido retornados en el día.
b. Al final de cada día el operador solicita un resumen de todo lo depositado
en el día.
— El operador debe además poder cambiar:
a. Información asociada a ítemes.
b. Dar una alarma en el caso de que:
i. Item se atora.
ii. No hay más papel.

Como una primera aproximación identificamos a los actores que interactuan con el
sistema:
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar
la información de un Item o bien puede Imprimir un informe:

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de

depositar algún item por un cliente o bien puede ser realizada a petición de un
operador.
Entonces, el diseño completo del diagrama Use Case es:

¢
 



 
 
  
 

¢
   
 !"  #
# #
# #
 ¢ 

Herramienta: Enterprise Architect

¢
$$$
%&
 
  

%¢ 



 u
 





Un caso de uso del modelo describe la funcionalidad propuesta de un nuevo sistema. Un caso de uso
representa una unidad discreta de interacción entre un usuario (humano o máquina) y el sistema. Esta
interacción es una sola unidad de trabajo significativo, como en Crear cuenta o ver los detalles de la cuenta.
Cada caso de uso describe la funcionalidad que se construirá en el sistema propuesto, que puede incluir la
funcionalidad de otro caso de uso o ampliar otro caso de uso con su propio comportamiento.

Una descripción de casos de uso general se incluye:

— Comentarios generales y notas describiendo el caso de uso.

— ºequisitos - Los requisitos de forma funcional de las cosas que un caso de uso debe proporcionar al
usuario final, tales como <capacidad para actualizar orden>. Estos corresponden a las
especificaciones funcionales que se encuentran en las metodologías estructuradas, y la forma de un
contrato que el caso de uso realiza alguna acción o preste algún valor para el sistema.
— ºestricciones - Las reglas formales y las limitaciones de un caso de uso opera bajo, la definición de
lo que puede y no se puede hacer. Estos incluyen:
Ê re-condiciones que debe haber ocurrido o estar en su lugar antes de que el caso de uso se
ejecuta, por ejemplo, <crear debe preceder <modificar orden>
Ê ost-condiciones que deben ser verdaderas una vez que el caso de uso es completo, por
ejemplo, <order se modifica y consistente>
Ê ÿnvariantes que siempre debe ser verdad todo el tiempo el caso de uso opera, por ejemplo,
un orden siempre debe tener un número de cliente.
— Escenarios - formal, las descripciones secuenciales de los pasos dados para llevar a cabo el caso de
uso, o el flujo de los acontecimientos que ocurren durante un ejemplo de casos de uso. Estos
pueden incluir escenarios múltiples, para hacer frente a circunstancias excepcionales y las rutas
alternativas de transformación. Estos se suelen crear en el texto y corresponden a una
representación textual del diagrama de secuencia.
— diagramas de Escenario - diagramas de secuencia para describir el flujo de trabajo, similar a los
escenarios, pero retrata gráficamente.
— atributos adicionales, como fase de ejecución, el número de versión, número de complejidad,
estereotipo y estado.

4



Los casos de uso están generalmente relacionadas con "actores", que son entidades humanas o de la
máquina que utilizan o interactuar con el sistema para realizar un trabajo significativo que ayude a alcanzar
una meta. El conjunto de casos de uso que un actor tiene acceso define su rol global en el sistema y el
alcance de su acción.
ÿ 

  


   







Un Caso de Uso puede incluir la funcionalidad de otro como parte de su proceso normal. En general, se
asume que el casos de uso incluidos se llama cada vez que la ruta de acceso de base se ejecuta. or
ejemplo, al enumerar una serie de pedidos de los clientes para elegir antes de modificar una orden
seleccionada, la <lista órdenes> de casos de uso se incluyen cada vez que el <modificar orden> de casos de
uso se ejecuta.
Un Caso de Uso puede ser incluido por uno o más casos de uso, por lo que ayuda a reducir la duplicación de
funcionalidad al factorizar el comportamiento común en los casos de uso que son muchas veces utilizados de
nuevo.
Un Caso de Uso puede extender el comportamiento de otro, por lo general cuando las circunstancias
excepcionales se encuentran.or ejemplo, si un usuario debe obtener la aprobación de alguna autoridad
superior antes de modificar un determinado tipo de pedido del cliente, entonces el <obtener aprobación>
caso de uso opcional, podría extender el normal <modificar orden> de casos de uso.




 

  

Los diagramas de secuencia proporcionan una representación gráfica de la interacción entre los objetos a
través del tiempo. Éstos muestran típicamente a un usuario oa un actor y los objetos y componentes que
interactúan en la ejecución de un caso de uso. Un diagrama de secuencia representa típicamente un único
escenario de Caso de Uso o flujo de los acontecimientos.
Los diagramas de secuencia son una excelente manera de documentar los escenarios de uso y la captura de
los dos objetos necesarios de manera temprana en el análisis y uso del objeto comprobar más adelante en
el diseño. Los diagramas muestran el flujo de mensajes desde un objeto a otro, y como tal corresponde a
los métodos y eventos con el apoyo de una clase / objeto.
El siguiente ejemplo de un diagrama de secuencia muestra al usuario o actor de la izquierda iniciando un
flujo de eventos y mensajes que corresponden a la situación de casos de uso. Los mensajes que pasan entre
objetos se convierten en operaciones de clase en el modelo final.


 

   

Un Caso de Uso es una descripción formal de la funcionalidad que el sistema tendrá cuando se construya. Un
diagrama de implementación se asocia típicamente con un caso de uso para documentar qué elementos de
diseño (por ejemplo, componentes y clases) implementará la funcionalidad de casos de uso en el nuevo
sistema. Esto proporciona un alto nivel de trazabilidad para el diseñador del sistema, el cliente y el equipo
que construirá el sistema. La lista de casos de uso que un componente o una clase está relacionada con los
documentos de la funcionalidad mínima que debe ser implementada por el componente.

El ejemplo anterior muestra que 'Entrar' el caso de uso implementa el requisito formal de «1 0.01 iniciar
sesión en el" sitio web.También muestra que el componente "lógica empresarial" y el componente "páginas
AS" aplicar algunas o todas las funcionalidades de la 'sesión'. Un refinamiento adicional es mostrar la
"sesión" de la pantalla (una página web) como la aplicación de la "sesión" de casos de uso. Estos vínculos de
ejecución o realización definen la trazabilidad desde los requisitos formales, a través de casos de uso de los
componentes y pantallas.

¢
$$$
%&
 
 
  

 
¢