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. 5.a. El cliente puede cancelar la operación. El cajero le devuelve la tarjeta y el caso de uso acaba 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. 6.a. 8.a

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. El cliente puede cancelar la operación. El cajero le devuelve la tarjeta y el caso de uso acaba. 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 1. El Sistema recibe el mensaje … 2. El Sistema le recuerda al Usuario … 3. Fin del Caso de Uso. Alternativas 1.1 No hay Mensajes o ya fueron … . Ir a 3.

Sign up to vote on this title
UsefulNot useful