Introducción
Los diagramas de casos de uso de UML sirven para mostrar las funciones de un sistema de software desde el punto de vista de sus interacciones con el exterior y sin entrar en la implementación detallada de las funciones en cuestión. Estos diagramas se utilizan en la recogida de documentación y en la fase de análisis.
Actores
La finalidad de un software es proporcionar información a personas, máquinas o dispositivos externos en general. Un actor es un conjunto de papeles de una entidad exterior en relación con el sistema de software considerado. Para ser actor, una entidad exterior tiene que cumplir dos condiciones:
- Ser autónomo respecto al software (Por ejemplo: un motor eléctrico, pero no una CPU).
- Tener una relación directa con el software o con entidades exteriores que esten subordinadas a este software.
Un actor es un clasificador pero no es un estereotipo. Si un conjunto de entidades exteriores hacen el mismo papel las representaremos con un mismo actor. Los actores pueden tener relaciones de especialización o generalización mediante herencia (un actor A es una especialización de un actor B si hace al menos todos los papeles de B).
Un caso de uso representa una interacción entre el software y un actor o más. La interacción tiene que ser una función autónoma dentro del software. Los casos de uso son un caso particular de clasificadores, pueden tener atributos y operaciones. Entre casos de uso y actores hay asociaciones que representan el papel del actor en relación del caso de uso, pero no representan ningún flujo de datos. El actor principal es el que pide la función del software. Hay tres tipos de relaciones:
- Relación de extensión: Se dice que el caso de uso A extiende a B si dentro de B se ejecuta A, cuando se cumple una condición determinada.
- Relación de inclusión: Un caso de uso A esta dentro de los casos de uso de B, C..., si es una parte del proceso común a todos estos. El caso de uso no es autónomo, es decir, no tiene actor primario, por lo tanto, siempre se enciende desde otro caso de uso. Permite la reutilización.
- Relación de generalización y especialización: Un caso de uso A es una especialización de B si A hace todo lo que hace B más algún proceso especifico.
Representación básica:
Representación de una especialización/generalización:
Normalmente no se utilizan los símbolos de clasificadores. Los esteriotipos extend y include se utilizan para las relacoines de extensión y de inclusión, respectivamente:
Podemos crear las asociaciones convenientes entre actores y casos de uso.
Si nos conviene, y en el caso que representemos todos los casos de uso de un sistema, los podemos enmarcar o bien con un cuadrado y un título, o bien con un óvalo, para el sistema contenedor de los casos de uso, como se muestra a continuación:
Ejemplo de cajero automático:
- Este diagrama de casos de uso representa la funcionalidad de una aplicación de alquiler de películas de un cajero automático.
a) ¿Del diagrama se puede deducir que una persona sea responsable del cajero no puede alquilar películas?
No, puede actuar con el rol de cliente también.
b) ¿Si se cambia el sistema de tal manera que la forma de añadir los materiales es diferente, esto afectaria a las personas con rol de cliente?
No.
c) Mejora el diagrama teniendo en cuenta que los casos de uso de añadir DVD y añadir BR tienen partes en común. Explica tu decisión.
d) Supongamos que se mejora el sistema para que los clientes puedan recomendar los DVDs que más les gusta. Esta tarea se puede llevar de manera autónoma, pero también cuando alquilan DVDs. Representa en el diagrama estos requerimientos nuevos. e) Se podria considerar el cajero automático como un actor?
Sí, es un sistema externo de la aplicación.
- Teniendo en cuenta las respuestas a las siguientes preguntas del famoso juego del buscaminas, especifica el diagrama de casos de uso:
Recuerda que necesitaremos preguntarnos para realizar el diagrama...En este caso podemos suponer que estos són todos los casos de uso del juego.Preguntas habituales para especificar los casos de uso de un sistema serían:¿Qué casos de uso identificamos?
- Iniciar una nueva partida.
- Descubrir una casilla.
- Marcar la casilla.
¿Quién realiza estos casos de uso?
- El jugador.
- En la empresa donde trabajais han encargado un nuevo videojuego llamado Sokoban. Como analistas que sois, se pide que especifiqueis el diagrama de casos de uso del juego, teniendo en cuenta los siguientes requerimientos funcionales:
- Sokoban es un juego de varios niveles.
- Cada nivel esta compuesto por un jugador, cajeros, repisas i muros.
- El objetivo del juegador es empujar todas las cajas sobre las repisas.
- Cuando esto sucede el jugador pasa al siguiente nivel.
- Para mover una caja, el jugador tiene que situarse al lado y empujarla. Si la casilla hacia la que esta empujando esta libre, la caja se moverá.
- Si el jugador se queda bloqueado. Es decir, no puede acabar el nivel, puede reiniciar el nivel perdiendo una vida.
- Cuando el jugador pierde todas las vidas, la partida se acaba.
