Casos de Uso

Metodologías de Desarrollo de Software

Profesora: María Carolina Chamorro

 Casos de uso
• Los requisitos funcionales especifican qué debería hacer
un sistema
• Un caso de uso describe cómo el sistema y el usuario final
harían algo en forma conjunta
• El usuario final es un ser humano o cualquier otra entidad
externa.
• Un caso de uso describe un flujo de eventos entre el
usuario y el sistema

2
 Casos de uso y actores
• El modelo de casos de uso usa actores para
representar roles que los usuarios pueden jugar y
usa casos para representar cómo los actores
cooperan con el sistema.
• Un actor es típicamente un usuario en un rol
específico.

Los casos de uso no describen cómo el

sistema implementa lo que hace.
3
 Casos de uso
• Los casos de uso explican las acciones de los actores y las
respuestas del sistema.
• Los casos de uso ilustran escenarios de uso típico del
sistema (secuencia normal, feliz).
• Guían el diseño y la implementación final del sistema.
• El sistema debería ser probado contra los casos de uso
para verificar la equivalencia entre los casos de uso y el
sistema final.

4
 Casos de uso
• Los casos de uso son ejemplos concretos de cómo
un actor usa el sistema para obtener beneficios
concretos.

• La técnica de los casos de uso es una herramienta

para colectar y analizar diferentes formas de usar
el sistema, y entrega un medio de comunicación
en la fase de captura y análisis de los requisitos.

5
 Discusión de los casos de uso
• Hable con los potenciales usuarios para saber cómo
ellos podrían usar el software.
• Escriba las primeras versiones de los casos de uso
basado en las discusiones con los potenciales usuarios.
• Escriba los casos de uso de manera que los clientes los
puedan entender y hacer comentarios.
• Luego seleccione clientes claves para refinar los casos
de uso.

6
 Casos de uso
10 mandamientos para obtener buenos
casos de uso
(Según los autores de OMT++)

Referencia: A. Jaaksi 'Our Cases with Use Cases',

in Journal of Object-Oriented Programming, Vol 10,
No 9, February 1998, pp 58 -65.
 10 mandamientos
para obtener buenos casos de uso
1. Los casos de uso especifican los requisitos funcionales más
importantes

Por ejemplo, si es importante para el cliente que el sistema

imprima informes, entonces esa tarea debiera estar incluida en uno
o más casos de uso.

8
 10 mandamientos
para obtener buenos casos de uso
2. Un caso de uso describe algo que el diseñador estaría orgulloso
de hacer y que el cliente estaría dispuesto a pagar con gusto

Cada caso de uso debiera describir algo que es beneficioso para el

usuario. Por ejemplo, “producir un informe de venta” suena como
un buen caso de uso, mientras “seleccionar una impresora” es un
caso de uso demasiado pequeño y no sólo es beneficioso para el
usuario final.

9
 10 mandamientos
para obtener buenos casos de uso
3. Un caso de uso describe una manera típica de usar el sistema,
pero no más.

Un caso de uso es como el manuscrito de un obra de teatro que

describe lo que debe hacer un actor en un escenario dado. El que
tome el lugar de un actor debe ser capaz de jugar su rol. El sistema
juega el rol de otro actor. El caso de uso no debe dar demasiada
libertad a los actores como para que el acto termine en un caos.

10
 10 mandamientos
para obtener buenos casos de uso
4. Un caso de uso es una actuación

El caso de uso debiera describir la manera recomendada para

ejecutar una tarea. No debería cubrir temas que quedan fuera de su
incumbencia ni tratar de definir todas las posible formas de ejecutar
la tarea. Otras maneras de usar el sistema se describe en otro
caso de uso o en la sección de “Excepción” del caso de uso.

11
 10 mandamientos
para obtener buenos casos de uso
5. Un caso de uso tiene un comienzo, un cuerpo principal, y un
final.

Cada c.u. debiera ser una historia completa. El comienzo define las
condiciones iniciales y los primeros pasos del caso de uso. El
cuerpo principal describe funcionalidad que el cliente pagaría con
agrado. La parte final describe los pasos para terminar el caso de
uso. Un caso de uso sin estas características es probablemente
demasiado débil.

12
 10 mandamientos
para obtener buenos casos de uso
6. Un caso de uso es como un ensayo escrito por un estudiante de
escuela básica.

A cierta edad los niños tienden a escribir historias que describen el

flujo explícito de las acciones, una después de la otra, eso es
exactamente lo que un caso de uso debería hacer.

13
 10 mandamientos
para obtener buenos casos de uso
7. Un caso de uso cabe en una página

Los casos de uso grandes son difíciles de comprender ya que, o

son demasiado detallados, o intentan cubrir demasiada
funcionalidad. En el último caso el problema se puede resolver
quebrando el caso de uso en dos o más casos de uso.

14
 10 mandamientos
para obtener buenos casos de uso
8. Un caso de uso es fuerte y claro

Cada C.U. debe hacer afirmaciones claras y explícitas para que

cuando la gente lo lea, se pueda formar opiniones fuertes. Un C.U
debe motivar a los clientes a mejorar el sistema argumentando,
discutiendo, hasta lograr un acuerdo con el C.U. Si nadie está en
desacuerdo con la primera versión de un C.U. probablemente es
demasiado vago.

15
 10 mandamientos
para obtener buenos casos de uso
9. Los clientes y diseñadores de software pueden firmar el caso de
uso

Cada caso de uso debería ser concreto y claro para que los
clientes y los diseñadores lo puedan firmar. Los casos de uso
actúan como un contrato entre los clientes y los desarrolladores.
Nadie debería hacer alguna modificación a los casos de uso sin la
aprobación de todos.

16
 10 mandamientos
para obtener buenos casos de uso
10. Un caso de uso puede ser usado en el desarrollo y la prueba
del sistema

Los C.U. no se usan en forma aislada. Los C.U. deberían

especificarse para ser usados en las siguientes fases del proceso,
por ejemplo, en la fase de análisis de objetos y la fase de análisis
de comportamiento. Si los C.U. son suficientemente explícitos ellos
se pueden usar en la prueba del sistema.

17
 Pre y pos condiciones
• Proveen contexto a los casos de uso

• Permiten conectar un caso de uso con otros

casos de uso. Por ejemplo, una precondición
puede determinar que algún otro caso de uso
debe ser ejecutado antes del caso de uso en
cuestión.

18
 Ejemplo de colección de requisitos
Sistema de Mensajes Cortos (SMC)

• Se desea un sistema que permita al usuario de

un teléfono móvil enviar mensajes cortos a
otros usuarios de teléfonos móviles.
• ¿Cómo comunicar la idea?
Se puede crear una transparencia como la siguiente:

19
Ejemplo de colección de requisitos
Sistema de Mensajes Cortos
•Fácil edición de los mensajes
•Manejo de listas de correos
•Puede almacenar los mensajes en forma persistente
Pantalla PC
Hola,
Hola,
¿cómo estas?
¿cómo estas?

20
Ejemplo de colección de requisitos
Requisitos funcionales
1) El usuario puede enviar mensajes cortos desde un PC a través
de un teléfono móvil adherido al PC
2) El usuario puede almacenar y cargar números telefónicos
basado en nombres de receptores (destinatarios)
3) El usuario puede construir “listas de correo” de múltiples
destinatarios
4) El usuario puede almacenar y reutilizar dichos comunes como
frases
5) El usuario puede grabar los mensajes enviados y más tarde
puede mirarlos y reutilizarlos

21
Ejemplo de colección de requisitos
Requisitos no-funcionales
1) El sistema debe correr en plataformas
Windows y Macintosh
2) El sistema debe permitir múltiples accesos
simultáneos a los números de teléfono
almacenados así como a los grupos
3) El sistema debe almacenar los datos de las
tonadas en archivos tipos ASCII delgado.

22
 Ejemplo de colección de requisitos
Casos de uso importantes del SMC
• Caso de uso nº 1: Enviando un mensaje corto
• Actor: Un usuario corriente del teléfono móvil
• Requisito de usabilidad: El usuario puede detectar si
el mensaje ha sido enviado exitosamente.
• Precondiciones: El usuario ha sido aceptado por el
sistema. Hay nombres de destinatarios de mensajes,
de grupos y frases guardadas en el sistema.

23
 Ejemplo de colección de requisitos

Casos de uso importantes del SMC

Descripción: El usuario escribe un mensaje corto
(Excepción1: carga un mensaje) y le agrega su
firma al final del mensaje. El usuario selecciona
diferentes nombres de destinatarios y grupos
(Excepción2: no hay destinatarios ni grupos
disponibles). Después guarda el mensaje para sí
mismo. Luego él envía el mensaje corto a los
destinatarios y grupos seleccionados. Finalmente,
la aplicación anuncia que la red ha recibido el
mensaje corto.

24
 Ejemplo de colección de requisitos

Casos de uso importantes del SMC

Excepciones:
1. Carga un mensaje: el usuario carga un mensaje que
estaba guardado para trabajar con él
2. No hay destinatarios ni grupos disponibles: el usuario
primero entra al sistema de información de nombres
de destinatarios y lo usa.

Poscondiciones:
Mensaje corto del usuario enviado y hay una copia
almacenada.

25
 Ejemplo de colección de requisitos

Casos de uso importantes del SMC

Caso de uso Nº 2: Creando y manteniendo grupos

Actor: Un usuario corriente del teléfono móvil

Precondiciones: El usuario ha sido aceptado por el

sistema. Hay nombres de destinatarios y grupos
de destinatarios guardados en el sistema

26
 Ejemplo de colección de requisitos

Casos de uso importantes del SMC

Descripción: El usuario crea un nuevo grupo de
destinatarios de mensajes. El/ella agrega al grupo
varios nombres de destinatarios (Excepción: los
nombres necesarios no están en el sistema). Luego el
usuario elimina algún otro grupo. Después el usuario
selecciona otro grupo, elimina un nombre y le agrega
dos nuevos. Finalmente, el usuario comienza a
escribir un mensaje.

27
 Ejemplo de colección de requisitos
Casos de uso importantes del SMC
Excepciones:
• Los destinatarios necesarios no están en el
sistema: el usuario entra la información de los
destinatarios.
Poscondiciones:
Un grupo ha sido eliminado. Hay un nuevo
grupo con varios nombres. Información de un
grupo ha sido modificada y guardada.

28
 Casos de Uso

Metodologías de Desarrollo de Software

Profesora: María Carolina Chamorro

29