DIAGRAMAS DE CASO DE USO

Resumido por: Leyda Caballero

Todo sistema interesante, interacciona con actores humanos o automatizados que utilizan el sistema con algún propósito, y esos actores esperan que el sistema se comporte previsiblemente.  Un caso de uso especifica el comportamiento de un sistema o una parte de él y es la descripción de un conjunto de secuencias de acciones, incluyendo variaciones, que un sistema realiza para producir un resultado de valor observable por un actor

Los casos de uso capturan el comportamiento del sistema que se está desarrollando, sin tener que especificar cómo se implementa ese comportamiento. Los casos de uso proporcionan a los desarrolladores una ruta para lograr un entendimiento común con los usuarios finales del sistema y expertos del dominio. Además, los casos de uso sirven para validar la arquitectura y para verificar que el sistema evolucione durante el desarrollo de manera congruente

El diagrama de Caso de uso es un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor.

Características:

• §  Describir una tarea del negocio que sirva a una meta de negocio.
• §  Tener un nivel apropiado del detalle.
• §  Ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento

Para que sirven los casos de uso:

§    Para capturar el comportamiento deseado del sistema sin tener que especificar como se implementa ese comportamiento.

§     Como medio de comprensión del sistema para desarrolladores, usuarios finales y expertos del dominio.

Ayudan a validar la arquitectura y a verificar el sistema en el transcurso del desarrollo de este

Los elementos básicos del diagrama de Caso de Uso son:

A.    Actores

B.    Casos de uso

C.   Relaciones

A. Los Actores

§  Representa un conjunto de roles que los usuarios de los casos de uso juegan al interactuar con éstos.

§  Representa un rol que es jugado por una persona, un dispositivo hardware u otro sistema que interactúe con nuestro sistema.

§  Un actor y un caso de uso se pueden comunicar a través de una asociación en donde cada uno de ellos puede enviar y recibir mensaje.

Existen dos tipos de actores:

Principal: Requiere al sistema el cumplimiento de un objetivo.

Secundarios: sistema necesita de ellos para satisfacer un objetivo.

B. Casos de uso

§  Representan todo lo que el usuario puede realizar con el sistema.

C. Relaciones

§  Permiten asociar los elementos anteriores, existen tres tipos de relaciones:

C1. Generalización

§  El caso hijo hereda el comportamiento y significado de caso de uso padre

§  El hijo puede añadir o redefinir el comportamiento del padre

§  El Caso de Uso fuente hereda la especificación del Caso de Uso destino. Ejemplo:. 

C2. Extensión

§  Significa que un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por el caso de uso que extiende al base.

§  Se usa esta relación cuando se tiene un caso de uso que es similar a otro, pero que hace un poco más.

Ejemplo:

C3. Inclusión       

§  Permite factorizar un comportamiento en un caso de uso aparte y evitar repetir un mismo flujo en diferentes casos de uso.

Ventajas de los Diagramas de Caso de Uso

§  La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso del sistema.

§  Como técnica de extracción 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 informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.

§  A su vez, durante la extracción (elicitation en inglés), 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 priorización del requerimiento.

§  Aunque comúnmente se asocian a la fase de Test de una aplicación, esta idea es errónea, y su uso se extiende mayormente a las primeras fases de un desarrollo.

Desventajas:

§  No establecen completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales.

§  Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos que complementen los requerimientos del sistema. Sin embargo la ingeniería del funcionamiento especifica que cada caso crítico del uso debe tener un requisito no funcional centrado en el funcionamiento asociado.

Ejemplo.

El dueño de un hotel le pide a usted desarrollar un programa para consultar sobre las piezas disponibles y reservar piezas de su hotel. El hotel posee tres tipos de piezas: simple, doble y matrimonial, y dos tipos de clientes: habituales y esporádicos. Una reservación almacena datos del cliente, de la pieza reservada, la fecha de comienzo y el número de días que será ocupada la pieza.

El recepcionista del hotel debe poder hacer las siguientes operaciones:

•Obtener un listado de las piezas disponible de acuerdo a su tipo

•Preguntar por el precio de una pieza de acuerdo a su tipo

•Preguntar por el descuento ofrecido a los clientes habituales

•Preguntar por el precio total para un cliente dado, especificando su número de RUT, tipo de pieza y número de noches.

•Dibujar en pantalla la foto de un pieza de acuerdo a su tipo

•Reservar una pieza especificando el número de la pieza, rut y nombre del cliente.

•Eliminar una reserva especificando el número de la pieza

El administrador puede usar el programa para:

•Cambiar el precio de una pieza de acuerdo a su tipo

•Cambiar el valor del descuento ofrecido a los clientes habituales

•Calcular las ganancias que tendrán en un mes especificado (considere que todos los meses tienen treinta días).

El hotel posee información sobre cuales clientes son habituales. Esta estructura puede manejarla con un diccionario, cuya clave sea el número de RUC y como significado tenga los datos personales del cliente. El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de pieza o clientes y a su vez permitir agregar nuevas consultas.