Introduccin a los

Casos de Uso
Yadran Eterovic (yadran@ing.puc.cl)
MTIG 2010
Departamento de Ciencia de la
Computacin
Escuela de Ingeniera
Pontificia Universidad Catlica de Chile

1. El problema de los
requisitos

Los requisitos son capacidades y

condiciones que el sistema debe
cumplir
El sistema debe mostrar la lista completa
de alumnos oficialmente inscritos en el
curso ordenada alfabticamente.
El sistema debe permitir especificar la
ciudad o el aeropuerto de origen y la
ciudad o el aeropuerto de destino.
El sistema debe asegurar que un mismo
asiento de un vuelo en una fecha
determinada sea asignado a lo ms a un
pasajero.
3

Los requisitos afectan fuertemente

al desarrollo de un proyecto de
software
El mal manejo de requisitos es una de
las causas ms comunes de fracaso de
los proyectos.
Un pequeo error de requisitos llega a
ser un defecto maysculo durante la
instalacin del producto:
corregir estos defectos es muy caro se

ha gastado mucho esfuerzo yendo en una

direccin equivocada.
4

Costo relativo de corregir defectos en

las diferentes etapas del ciclo de vida
0.1 0.2

durante los requisitos

0.5

durante el
diseo

durante la
implementacin

durante las
pruebas unitarias

durante las
pruebas de aceptacin

20

durante el
mantenimiento

Es difcil manejar los requisitos

Los requisitos son abstractos y muy

diferentes de los programas
computacionales:
es difcil para gente hbil en los aspectos

concretos de la programacin identificar

bien los requisitos;
los requisitos no se ven reflejados

claramente en un mdulo del programa.

6

Tenemos que hacer gestin de

requisitos

Un enfoque sistemtico para encontrar,

documentar, organizar y seguir la pista a
los requisitos, siempre cambiantes, de un
sistema.

La gestin eficaz de requisitos

presenta varios desafos
1. Encontrar lo que el cliente y los
usuarios realmente necesitan.
2. Comunicar y recordar (es decir,
escribir) esas necesidades:
escribirlas de manera clara, tanto para el

cliente y los usuarios como para el equipo

de desarrollo;
evitar incluir decisiones de diseo o sobre

la interfaz de usuario.
8

3. Reducir el nmero y complejidad de

los requisitos:
resolver requisitos en conflicto;
eliminar requisitos redundantes;
separar los requisitos funcionales de los

no funcionales.

4. Asegurarse de que se le pueda seguir

la pista a los requisitos.

 adems, se da en un contexto de
necesidades cambiantes y poco
Un proyecto de software tpico
claras
experimenta entre un 25% y un 50% de
cambios en los requisitos:

C. Jones, Applied Software Measurement,

McGraw-Hill 1997.

En promedio, un 45% de las propiedades

de una aplicacin, basadas en requisitos
congelados al inicio del proyecto, nunca
son usadas:
C. Larman, Agile and Iterative Development:

A managers Guide, Addison-Wesley 2003.

10

Hay mltiples tipos de requisitos

Funcionales:
caractersticas,

capacidades, seguridad.

de Usabilidad:
factores humanos,

ayuda, documentacin.

de Confiabilidad:
frecuencia de fallas,

recuperabilidad,
predictibilidad.

de Desempeo:
tiempos de

respuesta, tasa de
salida, exactitud,
disponibili-dad, uso
de recursos.

de Soporte:
adaptabilidad,

mantenibilidad,
internacionalizacin,
configurabilidad.
11

2. Definiciones

Los casos de uso son relatos

para describir requisitos
funcionales

Sirven para descubrir y describir

requisitos, principalmente funcionales:
influencian varios aspectos de un proyecto,

p.ej., anlisis, diseo, testing.

Son relatos de cmo un actor usa un

sistema para lograr ciertos objetivos:
son principalmente texto y no diagramas;
la idea es simple, pero es difcil descubrir lo

que se necesita y escribirlo bien.

13

Ejemplo: Caso de uso Consultar

Vuelo (formato de un prrafo)
El usuario indica que quiere hacer consultas
acerca de vuelos. El sistema ofrece opciones
para especificar las ciudades de origen y
destino y las fechas de ida y regreso. El
usuario especifica las ciudades de origen y
destino y las fechas de ida y regreso. El
sistema muestra una lista de vuelos de ida y
una lista de vuelos de regreso, con sus horas
de salida y llegada y sus tarifas en cabina
econmica. El usuario selecciona los vuelos
que desea. El sistema muestra el itinerario,
las restricciones de equipaje y la tarifa total,
incluyendo impuestos.

14

Ejemplo: Caso de uso Poner Notas

(formato de un prrafo)
El profesor indica que quiere conectarse a mi Portal
UC; el sistema le pide informacin de identificacin;
el profesor se identifica; y el sistema auten-tifica al
profesor. El profesor indica que quiere acceder a su
informacin acadmica; el sistema presenta la lista
de cursos que est dictando durante el presente
semestre; el profesor indica que quiere poner las
notas de un curso particular; y el sistema presenta
la lista de alumnos del curso. El profesor recorre la
lista de alumnos calificando a cada uno; al terminar,
el profesor indica que quiere grabar las
calificaciones; el sistema le pide su firma digital; el
profesor ingresa su firma; el sistema autentifica la
firma y graba las calificaciones.
15

Un actor es algo con comportamiento

P.ej.,
una persona (identificada por su rol con

respecto al sistema): usuario, profesor, etc.;

un sistema computacional, p.ej., una base de

datos;
una organizacin.

Hay tres tipos de actores:

actores principales;
actores secundarios;
actores fuera de escena.

16

Un flujo es un relato particular

de cmo usar un sistema
Flujo (tambin, escenario de caso de uso):
Una secuencia especfica de acciones e

interacciones entre actores y el sistema.

Un relato particular de cmo usar un

sistema, o una ruta a travs del caso de uso.

P.ej.,
el flujo de consultar por un cierto vuelo;
el flujo de calificar a los alumnos de un

curso.
17

Los casos de uso involucran a

actores y varios flujos
Un caso de uso es una especificacin de
secuencias de acciones, incluyendo
variantes y secuencias de error, que un
sistema, subsistema o clase puede realizar
interactuando con actores externos.
Un caso de uso es un conjunto de flujos
exitosos y fallidos relacionados; cada flujo
es una secuencia de acciones que describe
a un actor usando el sistema para lograr un
objetivo o resultado observable valioso.
18

Ejemplo: Caso de uso Comprar

Pasaje(formato con alternativas,
incompleto)
Flujo exitoso principal o bsico:
El pasajero indica que quiere comprar

pasajes para un vuelo;

Flujos alternativos:
Al especificar la forma de pago, el usuario

olvida especificar la marca de la tarjeta de

crdito,
Al pagar con tarjeta de crdito, el usuario

ingresa una fecha de expiracin errnea,

19

Ejemplo: Caso de uso Poner Notas

(formato con alternativas,
incompleto)
Flujo exitoso principal:
El profesor indica que quiere conectarse al

sistema mi Portal UC; el sistema le pide que

se identifique; el profesor se identifica; y el
sistema autentifica al profesor.

Flujos alternativos:
El sistema no puede autentificar al profesor,
El profesor ingresa una nota invlida,
El profesor ha dejado a un alumno sin nota,
El sistema no puede autentificar la firma

digital,

20

Actores principales:
Usan los servicios del sistema
Tienen objetivos que se logran usando
servicios del sistema inician la ejecucin
de los casos de uso:
el pasajero, que quiere consultar por vuelos

de Santiago a Punta Arenas;

el pasajero, que quiere comprar los pasajes

para un vuelo de Santago a Punta Arenas;

el profesor, que quiere calificar a los alumnos.

Los identificamos para encontrar los

objetivos de usuario, que son los que
motivan los casos de uso.

21

Actores secundarios:
Proporcionan servicios al sistema
Interactan con el caso de uso despus de
que ste ha iniciado su ejecucin:
la base de datos de vuelos de la lnea area;
la base de datos de alumnos de la

universidad.

A menudo son sistemas computacionales,

pero podran ser organizaciones o
personas.
Los identificamos para clarificar interfaces
y protocolos externos.
22

Actores fuera de escena: Tienen

inters en la ejecucin del caso de
uso Tienen inters en el comportamiento del caso
de uso, pero no participan directamente:
la Gerencia Comercial de la lnea area quiere

saber cules son los destinos ms consultados;

la Direccin de Docencia de la Escuela de

Ingeniera quiere saber cuntos alumnos han

reprobado cursos.

Los identificamos para considerar todos los

intereses que afectan al caso de uso:
estos intereses que no son objetivos de usuario

son fciles de pasar por alto, si no los

explicitamos.

23

3. Los casos de uso como

requisitos en contexto

Diseemos software
centrado en el usuario

25

Empleemos tcnicas simples para

capturar los objetivos de los
Tenemos objetivos y queremos que los
usuarios
computadores nos ayuden a lograrlos:
consultar por vuelos, poner notas a los

alumnos.

Las mejores formas para capturar objetivos

son simples y familiares:
facilitan especialmente a los clientes

contribuir a su definicin y revisin,

reduciendo el riesgo de equivocarse;
la falta de involucramiento de usuarios es la

primera razn por la que los proyectos de

software fracasan.

26

Los casos de uso enfatizan

la perspectiva y objetivos del
usuario
Siempre son iniciados por un actor.
Siempre son escritos desde el punto de vista
de los actores.
Para escribirlos, hacemos las siguientes
preguntas:
Quin va a usar el sistema?
Cules son sus escenarios de uso tpicos?
Cules son sus objetivos?

No preguntamos por las caractersticas del

sistema.

27

Tomemos la perspectiva del actor

y su objetivo
La frase un actor usando el sistema para
lograr un objetivo o resultado observable
valioso, (diap. # 18) destaca dos actitudes
al hacer anlisis de requisitos:
escribamos requisitos desde el punto de vista

de los actores de un sistema, preguntndonos

por sus objetivos y situaciones tpicas;
entendamos qu es para el actor un resultado

valioso.

La industria est llena de proyectos fallidos

que no entregaron lo que la gente quera
realmente.
28

Preguntemos por
el objetivo del objetivo
Un usuario dice que su objetivo es ver la
pantalla con los selectores de ciudades y
fechas:
el usuario est pensando en una GUI, cajas de

dilogo;
este es un mecanismo para lograr un objetivo; no es

el objetivo propiamente tal.

Al preguntar Cul es el objetivo del objetivo?

llegamos a objetivos independientes de un
mecanismo:
Consultar por vuelos entre dos ciudades.
Comprar pasajes para un vuelo de una ciudad a

otra.

29

Al escribir casos de uso,

sigamos las siguientes sugerencias

Dejemos fuera la GUI:

estilo esencial.

No describamos el funcionamiento interno

del sistema:
casos de uso de caja negra.

30

Dejemos fuera la GUI,

concentrmonos en la intencin del
usuario
Esta pauta ha ayudado a crear mejores
interfaces de usuario y a hacer ingeniera
de la usabilidad.
El estilo resultante se llama esencial:
la narracin es expresada al nivel de las

intenciones del usuario y de las

responsabilidades del sistema, y no de sus
acciones concretas;
los casos uso en las diaps. # 14, 15, 19 y

20 estn escritos siguiendo un estilo

esencial.

31

El estilo esencial deja abiertas las

opciones de diseo
P.ej., si el caso de uso Poner Notas
requiere identificacin y autentificacin
del profesor, escribimos,

El profesor se identifica.
El sistema autentifica la identidad.

El diseo de la solucin para este objetivo

y esta responsabilidad est abierto:
lectores biomtricos, cajas de dilogo para

contraseas, etc.

32

El estilo concreto incluye las

decisiones de UI en el caso de uso
P.ej., Comprar Pasajes lo escribimos asi:
El usuario ingresa su nmero de tarjeta de crdito,
fecha de expiracin y cdigo de verificacin en
los campos de texto y selectores (ver Fig.3).
El sistema verifica la validez de la tarjeta de
crdito.
El sistema muestra la pgina de Confirmacin
(ver Fig. 4).

Los casos de uso concretos pueden ser tiles

durante el diseo detallado de la GUI, pero no
son apropiados durante el anlisis de
requisitos.

33

Bajamos con cmo

y subimos con por qu
Meta: Colocar una orden de compra
Cmo?

Por qu?

Paso: Especificar el producto

Cmo?

Por qu?

Subpaso: Ingresar el cdigo

34

Escribamos casos de uso

de caja negra
Los casos de uso de caja negra no
describen el funcionamiento interno del
sistema, ni sus componentes, ni su
diseo.
El sistema es descrito simplemente como
teniendo responsabilidades:
tema metafrico unificador comn en OO;
los elementos de software objetos,

mdulos tienen responsabilidades y

colaboran con otros elementos que tambin
tienen responsabilidades.

35

Durante el anlisis de requisitos

evitemos tomar decisiones de
cmo
P.ej.,
Escribamos, El sistema registra la compra

de pasajes.
No escribamos, El sistema escribe la

compra de pasajes en una base de datos;

tampoco, El sistema genera una sentencia
SQL INSERT para la compra de los pasajes.

Especifiquemos lo que el sistema debe

hacer anlisis de requisitos funcionales,
sin decidir cmo lo har diseo de la
solucin.

36

Hay varios formatos

(y niveles de formalidad)
Un prrafo:
Resumen de un prrafo del flujo bsico; p.ej.,

diaps. # 14 y 15.

Con alternativas:
Formato de prrafo informal; mltiples prrafos

que cubren varios flujos; p.ej., diaps. # 19 y

20.

Detallado:
Todos los pasos y variaciones estn escritos en

detalle, y hay secciones de apoyo, p.ej., pre y

poscondiciones.
37

El formato para el curso

Nombre e identificador nico.
Proyecto y cdigo de proyecto.
Contexto.
Actor principal.
Actores secundarios (o asociados).
Otros intereses (lista de actores fuera de escena y sus
intereses).
Precondiciones.
Resultados esperados (o poscondiciones).
Flujo bsico (o principal): descripcin de alto nivel y
descripcin detallada.
Flujos alternativos.

38

Las pre y poscondiciones

restringen el estado del sistema
Precondiciones:
condiciones que el estado del sistema debe

cumplir lo que debe ser verdadero antes

de que el caso de uso pueda ser ejecutado;
son condiciones fuera del alcance del caso

de uso, pero dentro del sistema que se est

desarrollando.

Poscondiciones:
condiciones que el estado del sistema debe

cumplir lo que deber ser verdadero

despus de que el caso de uso haya sido
ejecutado.

39

Precondiciones: (parte del)

Contrato entre el caso de uso y el
mundo

No son validadas por el caso de uso

se las supone verdaderas:
tpicamente, un flujo de otro caso de uso

que se ha completado exitosamente.

P.ej., algo dentro del sistema que se

est construyendo, pero fuera de este
caso uso, que debe haberse establecido
o debe estar funcionando o listo para
funcionar antes de que este caso de uso
pueda ejecutarse.
40

Resultados esperados
(o poscondiciones)
Tambin son parte del contrato entre este
caso de uso y el mundo exterior.
Despus de que este caso de uso se ha
completado exitosamente, los resultados
esperados son verdaderos
y deben ser independientes de la ruta

alternativa tomada dentro del caso de uso.

No es necesario especificar qu pasa

cuando hay un error, p.ej., en el input de
un actor.

41

Flujo bsico:
Ruta feliz exitosa tpica sin
condiciones

1. El <actor>
2. El sistema
3. El <actor>

El <actor> repite los pasos 3-4 hasta que

indica que ha terminado.

7. El sistema

42

Flujos alternativos:
Otras rutas, exitosas o fallidas
Un flujo alternativo tiene dos partes: la
condicin que lo produce y el manejo de la
situacin.
Escribamos la condicin haciendo referencia
al nmero del paso en el flujo bsico y como
algo que puede ser detectado por el sistema o
un actor:
4a. El sistema detecta que no se puede

comunicar con el servicio de validacin de

cheques.

El manejo de la situacin puede resumirse en

un paso o incluir una secuencia.
43

4. Pasos para encontrar

casos de uso

Para escribir casos de uso,

sigamos (aprox.) los siguientes
pasos
1. Encontremos la frontera del sistema.
2. Encontremos los actores.
3. Identifiquemos los objetivos de cada
actor.
4. Definamos casos de uso que satisfagan
los objetivos de los actores.
Iteremos hasta que los casos de uso, los
actores y la frontera del sistema estn
estables.

45

Paso 1:
Encontremos la frontera del
sistema
En uno de nuestros ejemplos, el sistema de
consultas de vuelos es el sistema en
estudio:
todo lo que est fuera del sistema de consultas

de vuelos est fuera de la frontera del sistema,

incluyendo personal del Counter, Pasajero, etc.

La prxima diap. ilustra otras fronteras

posibles, ms all del sistema de consulta
de vuelos:
para la Lnea Area, el actor principal es el

Pasajero; el personal del Counter es parte del

sistema.

46

Actores y fronteras del Sistema

Lnea area
Pasajero

Sistema de Consulta de vuelos

Counter
Fronteras del
Sistema
47

Pasos 2 y 3: Encontremos los actores

principales y sus objetivos
Es artificial tratar de identificar a todos los
actores princi-pales estrictamente antes
que los objetivos de usuario:
a veces, objetivos revelan a actores, o vice

versa;
sugerencia: Preguntmonos acerca de los

actores principales primero.

Adems de actores y objetivos obvios, las

siguientes preguntas (prxima diap.)
ayudan a encontrar otros que se nos
pueden pasar.
48

Quin inicia y detiene el sistema?

Quin hace gestin de usuarios y seguridad?
Quin hace la administracin del sistema?
Es el tiempo un actor? (si el sistema responde a
eventos de tiempo).
Hay un proceso que reinicie el sistema si ste
falla?
Cmo se actualiza el software?
Quin evala el desempeo del sistema?
Quin evala los logs? Son recuperados
remotamente?
A quin se le notifica cuando hay errores o fallas?
Hay sistemas de software o robticos externos
que llamen a los servicios del sistema?

49

Preguntemos por los objetivos de

los actores, no por los casos de uso
En vez de preguntar, Qu haces t?:
las respuestas reflejarn soluciones y

procedimientos vigentes, y las complicaciones

asociadas.

preguntemos, Cules son tus objetivos

cuyos resultados tienen valor observable?:
las respuestas posibilitan soluciones nuevas,

mejores;
se concentran en agregar valor de negocio;
y van al corazn de lo que los interesados

quieren del sistema.

50

Paso 4: Definamos un caso de uso

para cada objetivo de usuario
Nombremos el caso de uso similarmente
al objetivo.
Empecemos el nombre con un verbo.
Los objetivos de crear, recuperar,
actualizar, y eliminar <X> pueden
mezclarse en un nico caso de uso
Manejar <X> :
p.ej., crear destino, eliminar destino,

etc., son todos incluidos en el caso de uso

Manejar Destinos.

51

5. Cmo validar casos de

uso?

Hay diferentes niveles de casos de

uso
Cul de estos es un caso de uso vlido?
definir una nueva ruta;
hacer checkin;
conectarse al sistema;
ingresar el cdigo de una reserva.

Todos podran ser casos de uso, pero a

diferentes niveles, dependiendo de la
frontera del sistema, actores y objetivos.
53

Validemos el nivel de los casos de

uso
En lugar de preguntar,
Cul es un caso de uso vlido?

una pregunta ms til es,

Cul es un nivel apropiado para expresar
casos de uso durante el anlisis de
requisitos?

Pruebas para validar posibles casos de uso:

La prueba del jefe.
La prueba EBP.
La prueba del tamao.

54

La prueba del jefe: Utilidad para el

negocio
Si el jefe pregunta, Qu has estado
haciendo todo el da?
y le contestamos, Conectndome al
sistema
va a estar contento el jefe?
Si el jefe no est contento, entonces el
caso de uso no pasa la prueba del jefe:
el caso de uso no est relacionado con el

logro de resultados de valor medible para el

negocio.
55

La prueba EBP:
Complejidad en tiempo y espacio
Proceso de negocio elemental (EBP):
Una tarea realizada por una persona en un

lugar y de una vez, en respuesta a un evento

del negocio, que agrega valor de negocio
medible y deja los datos en un estado
consistente.
P.ej., Consultar Vuelos, Comprar Pasajes,

Hacer Checkin.

Busquemos casos de uso que reflejen EBPs:

esta prueba es similar a la del jefe, en

trminos de la calificacin de valor de negocio

medible.

56

La prueba del tamao:

Extensin de la narracin
Rara vez un caso de uso es una accin o
un paso individual, tal como
ingresar el cdigo de una reserva;
borrar una lnea;
imprimir un documento.

Un caso de uso tpicamente contiene

varios pasos; en el formato totalmente
detallado, puede llegar a tener varias
pginas de texto.
57

Qu pasa si aplicamos las pruebas

a los casos de la diap. # 53?
Definir una nueva ruta:
ms amplio y demoroso que un EBP;

Hacer checkin:
OK con el jefe; parece un EBP; tamao

apropiado.

Conectarse al sistema:
el jefe no est contento si es lo nico que

hacemos.

Ingresar el cdigo de una reserva:

paso individual falla la prueba de tamao.58

Hay excepciones razonables

Autentificar Usuario falla la prueba del

jefe, pero es complejo y requiere un
anlisis cuidadoso.
Falla como EBP un caso de uso si
necesita dos personas, o si una persona
tiene que caminar de una oficina a otra?
Probablemente no.
59

Casos de uso como subfunciones

A veces es til escribir casos de uso como
subfunciones:
subtareas o pasos dentro de un caso de uso

al nivel EBP;
p.ej., si pagar con tarjeta de crdito

aparece en varios casos de uso, lo

separamos en su propio caso de uso y lo
conectamos a los otros, para evitar
duplicacin de texto.
60

6. Aplicando UML a los casos

de uso

El diagrama de casos de uso del

UML muestra quin hace qu
Ilustra los nombres de los casos de uso y de
los actores, y las relaciones entre ellos.
Es un diagrama de contexto visual sucinto:
muestra la frontera del sistema, los casos de uso

que estn dentro, y los actores que estn fuera.

Sugerencias:
mostrar los actores que son sistemas con una

notacin diferente de la de los actores humanos;

mostrar los actores principales a la izquierda y

los otros a la derecha.

62

Diagrama
de
Casos de
Uso
Pasajero

Consultar
Vuelos

actor
Sistema I

Reservar
Pasajes
Comprar
Pasajes
Hacer
Checkin
Canjear
Premio

actor
Sistema II

actor
Sistema
III

Anular
Compra
63