Los Casos de Uso no son parte del diseño (cómo), sino
parte del análisis (qué).
De forma que al ser parte del análisis nos ayudan a
describir qué es lo que es sistema debe hacer.
Los Casos de Uso son qué hace el sistema desde el
punto de vista del usuario.
Es decir, describen un uso del sistema y cómo este
interactúa con el usuario.
Los DCU representan cómo
interactúan los diferentes actores de un sistema con cada caso de uso. Se
emplean para visualizar el comportamiento del sistema, una parte de el o de una
sola clase. De forma que se pueda conocer como responde esa parte del sistema.
Es muy útil para definir como debería ser el comportamiento de una parte del
sistema, ya que solo especifica como deben comportarse y no como están
implementadas las partes que define.
En el diagrama nos encontramos con diferentes figuras que
pueden mantener diversas relaciones entre ellas:
Casos de uso: representado por una elipse, cada caso de
uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden
tener relaciones con otros caso de uso.
Sus relaciones son:
- Inclusión: Representado por una flecha con línea discontinua y la palabra <<include>>. A include B quiere decir que A incluye el caso de uso B. Un caso de uso base incorpora explícitamente el comportamiento de otro en algún lugar de su secuencia.
- Extensión: Representado por una flecha con línea discontinua y la palabra <<extends>>. A extends B indica que A se usa en B. La relación de extensión sirve para modelar: la parte opcional del sistema, un subflujo que sólo se ejecuta bajo ciertas condiciones o varios flujos que se pueden insertar en un punto determinado.
- Generalización: Representado por una flecha con línea continua. Es la típica relación de herencia A generaliza B quiere decir que B es un caso particular de A.
Actores: se representan por un muñeco.
Sus relaciones
son:
- Comunicación / Asaciación: Comunica un actor con un caso de uso, o con otro actor.
- Límite del sistema: Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.
Podemos emplear el diagrama de dos formas diferentes,
para modelar el contexto de un sistema, y para modelar los requisitos del
sistema.
Se debe modelar la relación del sistema con los elementos
externos, ya que son estos elementos los que forman el contexto del sistema.
Los pasos a seguir son:
- Identificar los actores que interactúan con el sistema.
- Organizar a los actores.
- Especificar sus vías de comunicación con el sistema.
Modelado de requisitos
Los requisitos establecen un contrato entre el sistema y su exterior, definen lo que se espera que realice el sistema, sin definir su funcionamiento interno. Es el paso siguiente al modelado del contexto, no indica relaciones entre autores, tan solo indica cuales deben ser las funcionalidades (requisitos) del sistema. Se incorporan los casos de uso necesarios que no son visibles desde los usuarios del sistema.
Para modelar los requisitos es recomendable:
- Establecer su contexto, para lo que también podemos usar un diagrama de casos de uso.
- Identificar las necesidades de los elementos del contexto (Actores).
- Nombrar esas necesidades, y darles forma de caso de uso.
- Identificar que casos de uso pueden ser especializaciones de otros, o buscar especializaciones comunes para los casos de uso ya encontrados.
Acompaña a este tipo de diagramas una lista de fichas, en donde se representa
cada caso de uso con los sig. datos:
Nombre del caso de uso
Autor
Fecha
Descripción
Actores
Precondiciones
Flujo Normal
Flujo Alternativo
Poscondiciones
Las precondiciones son los hechos que se han de
cumplir para que el flujo de evento se pueda llevar a cabo.
El flujo normal de eventos, que corresponde a la ejecución normal y exitosa del caso de uso (use case).
Los flujos alternativos son los que nos permiten indicar qué es lo que hace el sistema en los casos menos frecuentes e inesperados.
Por último, las poscondiciones son los hechos
que se ha de cumplir si el flujo de eventos normal se ha ejecutado
correctamente.
Mostramos a continuación el diagrama de casos de uso de
una máquina expendedora de café.
Los actores son los sujetos de las acciones
que representan los casos de uso. Existen dos actores:
Cliente. Es el que obtiene el café de la
máquina.
Realiza las acciones siguientes:
Realiza las acciones siguientes:
- Entrega el dinero.
- Escoge el producto.
- Escoge el azúcar.
Máquina. Es el actor que realiza las funciones que ponen a disposición del cliente el café.
La máquina realiza las siguientes acciones:
- Prepara el producto.
- Entrega el producto
- Devuelve el cambio
- Imprime el recibo.
Relaciones de inclusión:
El caso de uso "Entrega de producto" incluye la preparación del mismo ya que si no no se podría entregar. Asi "Entrega producto" incluye "Prepara producto".
El caso de uso "Prepara producto" incluye "escoge producto" y "Escoge azúcar" ya que no se podría realizar la primera sin estas.
Relaciones de extensión.
El caso de uso "Devuelve cambio" e "Imprime recibo" extienden "Entrega producto" ya que se realizan una vez hecho este.
Relaciones de comunicación.
Los casos de uso "Entrega dinero" "Escoge producto" y "Escoge azúcar" son realizados por cliente y por tanto se comunican con él.
De la misma forma "Prepara producto" y "Entrega producto" se comunican con la máquina.
Análisis / Casos Resueltos
Cajero automático
Se ha de realizar el diagrama de casos de uso de un
cajero automático en el que se pueden realizar las operaciones
siguientes:
- Retirar efectivo.
- Ingresar o depositar efectivo.
- Hacer transferencias.
- Obtener información de nuestra cuenta: movimientos, saldo, etc.
Para realizar cualquiera de las operaciones el cajero
automático ha de validar la tarjeta y la clave que introduce el usuario.
Se debe considerar la interacción que tiene con el cajero, a la hora de
realizar estas operaciones, el banco y el consorcio. Llamaremos consorcio
a la red de cajeros automáticos a las que se suscriben los bancos para que los
cajeros automáticos realicen las operaciones. Los consorcios
son: 4B, servired, red6000.
Tienda de alquiler de videos
Una tienda de alquiler de películas posee alrededor de 5000
películas de las que requiere llevar registro.
Cada una tiene un número de identificación que se adjudica
cuando se dá de alta al sistema.
Para cada película, se necesita conocer título, duración,
director y la categoría según la siguiente clasificación: drama, acción,
suspenso, comedia,guerra y ciencia-ficción.
Existen muchas copias de la mayoría de las películas. Se le
asigno a cada una un identificador específico.
La tienda de video tiene muchos clientes y solamente alquila
vídeos a personas que sean socias del vídeo club.
Para que una persona pueda pertenecer al video club debe
asociarse, para lo cual se le asigna un número que lo identifica y se deben
registrar sus nombres y apellidos, número telefónico, dirección de residencia.
Se necesita llevar el registro de que vídeo casete ha
alquilado cada socio en un momento determinado. Un cliente puede alquilar
varias películas simultáneamente.
Cada vez que un cliente alquila un video, se debe registrar
la fecha de alquiler, el día que devolverá el video. Todos los video casetes
deben ser devueltos a la tienda a más tardar tres días después de su alquiler,
y, en caso de no entregarse a tiempo, se cobrara una multa de 100$ por película
y día de retraso.
El histórico de alquiler de videos se requiere con el fin de
analizar el comportamiento del alquiler de videos. Con el histórico seremos
capaces de determinar cuantas cintas alquila cada cliente y cuantas veces un
cliente ha devuelto una cinta tarde. También necesitamos saber cuantas veces
una cinta ha sido usada, y saber cuando retirar dicha cinta.
También podremos analizar las preferencias de nuestros
clientes y conocer el valor en $ recibido por el concepto de alquiler de videos
y multas por retrasos.
