Está en la página 1de 4

Especificación de un caso de uso

El comportamiento de un caso de uso se especifica describiendo la secuencia de


acciones que el sistema debe llevar a cabo para proporcionar un servicio. Esta secuencia
de acciones, habitualmente denominada flujo de eventos, debe escribirse de forma que
sea lo suficientemente clara como para que alguien ajeno al sistema pueda entenderlo
fácilmente.

El estándar UML no se compromete con La especificación de un caso de uso. Los


autores de UML solamente dan unas cuantas recomendaciones sobre el contenido de la
especificación y la forma en qué debe escribirse. Para los autores de UML, la
especificación de un caso de uso debería incluir al menos la siguiente información:

• Cómo y cuándo empieza y acaba el caso de uso.


• Cuándo el sistema interactúa con los actores y qué objetos intercambian.
• Flujo de eventos básico y flujos alternativos de comportamiento.

Siguiendo estas recomendaciones proponemos la siguiente plantilla para escribir la


especificación de un caso de uso. Esta plantilla además de las recomendaciones de UML
incluye otras características recomendadas por A. Cockburn[], que consideramos muy
útiles para la planificación y gestión del riesgo del proyecto.

Nombre o título.

Descripción: breve descripción textual del caso de uso. En esta descripción


debería describirse cómo empieza el caso de uso y qué evento lo dispara.

Actores: enumeración de los actores que participan en el caso de uso.

Precondiciones: condiciones que debe tener el sistema antes de ejecutar el caso


de uso.
Poscondiciones: condiciones que debe tener el sistema después de ejecutar el
caso de uso. Es recomendable incluir las condiciones en caso de éxito y en caso
de fallo del caso de uso.

Flujo de Eventos Principal: descripción de la interacción entre los actores y el


sistema en condiciones normales, sin considerar ninguna excepción ni anomalía
en la ejecución del caso de uso.

Flujos de Eventos Alternativos: descripción de la interacción entre los actores


y el sistema en condiciones excepcionales.

Casos de Uso Relacionados.

Requisitos No Funcionales Relacionados.

Prioridad.

Frecuencia.

Riesgo asociado al caso de uso.

El siguiente ejemplo muestra la especificación del caso de uso Extraer Dinero.

Nombre o título: Extraer Dinero.

Descripción: El cliente solicita al cajero la cantidad que quiere retirar. El cajero


comprueba si el cliente dispone de esa cantidad en su cuenta y si es así se la
entrega. Antes de realizar la operación el cliente debe ser validado. Para ello, el
cliente introduce en el cajero su tarjeta y su número de PIN. El cliente tiene tres
intentos para introducir el PIN correcto.

Actores: Cliente.

Precondiciones: Ninguna
Postcondiciones:

En caso de éxito: el cliente obtiene la cantidad de dinero que ha


solicitado, la operación queda registrada y su saldo actualizado.

En caso de fallo:

Si el cliente introduce un número de PIN erróneo tres veces, su tarjeta


queda invalidada.

Si el cliente cancela la operación no hay ninguna postcondición.

Flujo de Eventos Principal:

1. El cliente introduce la tarjeta en el cajero.


2. El cajero solicita el número de PIN.
3. El cliente introduce el número de PIN.
4. El cajero comprueba el número de PIN
5. Si el PIN es correcto, el cajero solicita la cantidad a retirar.
6. El cliente introduce la cantidad a retirar.
7. El cajero comprueba si el cliente dispone de esa cantidad en su cuenta
y si hay suficiente dinero en el cajero.
8. Si el cliente dispone de esa cantidad y el cajero tiene suficiente
dinero, el cajero actualiza la cuenta del cliente, registra la operación,
le entrega la tarjeta y el dinero al cliente y acaba el caso de uso.

Flujos de Eventos Alternativos:

3.a. El cliente puede cancelar la operación. El cajero le


devuelve la tarjeta y el caso de uso acaba
5.a. Si el PIN introducido no es correcto y el cliente aún no ha
consumido los tres intentos se vuelve al paso 2.
5.b. Si el PIN introducido no es correcto y el cliente ya ha consumido
los tres intentos, el cajero invalida la tarjeta y el caso de uso acaba.
6.a. El cliente puede cancelar la operación. El cajero le
devuelve la tarjeta y el caso de uso acaba.
8.a Si el cliente no tiene esa cantidad disponible en su cuenta o
el cajero no tiene suficiente dinero, se informa al cliente y se
vuelve al paso 5.

Casos de Uso Relacionados.

Requisitos No Funcionales Relacionados.

Prioridad: Alta.

Frecuencia: Alta.

Riesgo asociado al caso de uso: Medio.

Se suele representar con una tabla:

Caso de Uso: Recibiendo Mensaje

Curso Normal Alternativas


1. El Sistema recibe el mensaje … 1.1 No hay Mensajes o ya fueron …
. Ir a 3.
2. El Sistema le recuerda al Usuario …
3. Fin del Caso de Uso.

También podría gustarte