Casos de Uso: Teoría y
Práctica
Introducción
Un caso de uso indica una historia para
alcanzar un objetivo o un conjunto de
historias de éxitos y fallos:
UC4: Colocar una orden
“1. El Cajero identifica al cliente, cada elemento y la
cantidad.
2. El Sistema acepta y coloca la orden en la cola.”
Extensiones:
“1a. Bajo crédito: El Cajero toma un prepago”
“2a. Bajo Inventario: El Cliente acepta reducir la cantidad
Los casos de uso están dirigidos a “cómo hacer
legibles y revisables los requerimientos
funcionales”
Los casos de uso mantienen los requerimientos funcionales en un formato de texto fácil de leer y seguir.
Un caso de uso recolecta cómo un objetivo se logra/falla; un escenario muestra una condición específica; los escenarios y los casos de uso se anidan.
Los casos de uso sólo muestran los requerimientos funcionales.
Forman el marco de trabajo para los requerimientos no funcionales y los detalles del proyecto.
La industria de TI ama los casos de uso, pero...
¿Cómo escribir grandes volúmnes de casos de
uso?
Común acuerdo: los casos de uso son útiles
Adoptados por la todas los métodos OO.
Recomendación repetida de desarrolladores,
usuarios, etc.
¿Qué son realmente los casos de uso?
¿Cómo estructurar 180 casos de uso?
¿Cuál es su formato? ¿Su nivel de detalle?
Jacobson inventó los “usos” y las relaciones
“extendes”:
Existen muchos significados de “casos de uso”
Este modelo tiene teoría y práctica
Un taller de 14 consultores líderes en OO
produjo 14 definiciones de “caso de uso”.
Valor: historia del usuario / requerimientos Estructura: Ninguna / Semiformal / formal
Contenido: Contradictorio / consistente / formal Escenario =? Caso de uso: lo mismo /
diferentes
El modelo: Una interacción es una secuencia o
conjunto de posibles secuencias de
interacciones.
Actor 1 Actor 2
Objetivo Conjunto Interacción Responsabilidad
de secuencias
Secuencia de Interacciones
Mensaje simple
La acción de un actor dispara una interacción,
llamando las responsabilidades de otros actores
Actor Comportamiento Interaction Interno Externo Sistema en diseño Subsistema Persona Grupo Objecto Sistema Responsabilidad Objetivo
Acción dispara llama Conjunto de secuencias Secuencia de Interacciones Mensaje simple
El modelo básico de los casos de uso es que los
actores interactúan para lograr sus objetivos
Actor Principal
persona o sistema con objetivos para el s.b.d
Sistema bajo diseño
Podría ser cualquier sistema
Actore Secundario
Otro sistema con el
Que el s.b.d. tiene un objetivo
Responsabilidad
- Objetivo 1 - Objetivo 2 ... acción 1
. :
- objetivo de respaldo para
el objetivo 2
Responsabilidad
- Objetivo 1
...acción 1 Responsabilidad (Interaccción 1)
Un actor tiene objetivos; los objetivos nombran
los casos de uso; un caso de uso tiene
escenarios nombrando sub-casos de uso
Actor
Objetivos
Caso de uso
Escenario
condición
éxito / fracaso
tiene
nombra
Examinar los objetivos que el sistema apoya
produce buenos requerimientos funcionales
“Colocar una orden”
“Obtener dinero de una cuenta bancaria”
“Obtener una cita”
“Encontrar la alternativa más atractiva”
“Rentar videos”
Los objetivos resumen la función del
Los usuarios, ejecutivos y desarrolladores
aprecian ver los requerimientos en forma de
objetivos
Usuarios:
“Podemos entender lo que significa”
“Quiere decir que nosotros vamos a ...”
Ejecutivos:
“Haz dejado fuera algo aquí sobre...”
Desarrolladores:
La narrativa estructurada mantiene visible el
contexto, aclarando el valor para el usuario
Compare los párrafos:
“el sistema de registro de órdenes tiene una interfaz a un sistema EBMS y a una terminal.
Calcula y muestra la suma del costo de los elementos de la orden.
...”
Con narrativa estructurada: “el sistema de registro de órdenes (EBMS o una
persona) identifica el nombre del cliente y los elementos de la orden.
El sistema muestra el costo total de la orden.
El caso de uso saca el objetivo y escenarios en
conjunto, cada escenario dice cómo se
desarrolla 1 condición
El nombre del caso de uso es el enunciado
del objetivo:
“Ordenar un producto del catálogo”
Escenario 1: Todo trascurre bien...
Escenario 2: Crédito insuficiente...
Escenario 3: Producto agotado...
El caso de uso es el enunciado del objetivo
más los escenarios.
Los escenarios recolectados son como las
piernas en los pantalones, una para éxito y otra
para el fracaso
Objetivo: “Colocar una orden”
esc1 esc2 esc6 esc7
...
E
esc3
(Escenarios de éxito) (Esc. de falla)
E
E
F
E
F
E
E
F
F
F
F
Establecer ... crédito ... Inventario¿Cómo lograrlo?:
(1) Identificar los actores y sus objetivos
¿Qué computadoras, subsistemas y personas
conducirán el sistema?
Un Actor es algo o alguien con comportamiento
¿Qué es lo que necesita hacer nuestro
sistema para cada Actor?
Cada necesidad se muestra como un disparador
para nuestro sistema
Resultado: Una lista de casos de uso, un
boceto del sistema.
¿Cómo lograrlo?:
(2) Escriba el caso simple: el objetivo se
logra
El escenario principal de éxito, el caso del día
feliz
El más fácil de leer y entender
Algo adicional sería una complicación.
Captura la intención y responsabilidad de
cada actor, desde el disparador hasta el logro
del objetivo.
Dice qué información pasa entre estos extremos Numérese cada línea
¿Cómo lograrlo?:
(3) Escriba las condiciones de fracaso
como extensiones
Generalmente, cada paso puede
fracasar.
Anote la condición de fracaso separada,
después del escenario principal de
éxito.
¿Cómo lograrlo?:
(4) Seguir la falla hasta su final o se
reunión con el flujo básico
Las extensiones recuperables se unen al curso principal.
Las extensiones no recuperables fracasan directamente.
Cada escenario va desde el disparador hasta su cumplimiento.
Las “extensiones” son meramente una forma de abreviar la
escritura.
Puede contener enunciados “if”
Puede escribirse cada escenario desde su principio hasta su
final.
¿Cómo lograrlo?:
(5) Anote las variaciones de datos
Algunas extensiones son de muy bajo nivel
para ser cubiertas en este momento
“Reembolsar al Cliente”
Reembolsar en efectivo, cheque, vale, TDC?
Posponga los casos de variaciones que deben
ser manejados eventualmente, por casos de
uso de nivel inferior.
Es útil para el seguimiento de requerimientos a
nivel superior.
Un Actor tiene objetivos; los objetivos nombran
los casos de uso; un caso de uso tiene
escenarios que llaman subcasos de uso
Actor
Objetivo
Caso de uso
Escenario
Producto
condiciones
tiene
nombra
contiene
Revisión: Hacer que los escenarios corran desde
el evento disparador hasta el logro o abandono
del objetivo
UC 4: “Colocar una orden”
Disparador: la petición (llamada telefónica, EDI, ...).
Fin: orden iniciada o cancelada.
(Caso de uso en formato de “tabla de decisión”)
Escenario todo bien: Escenario
Insuficiente $ Escenario No hay el producto Iniciar orden Rechazar orden y
El valor de los escenarios de fracaso es detectar
situaciones inusuales, minuciosamente
“¿Qué hacer si no tiene crédito?”
“¿Qué hacer si tiene crédito sobregirado?”
“¿Qué hacer si no podemos entregar la
cantidad pedida?”
Las fallas recuperables y no recuperables
son parte de los requerimientos.
Situación ideal (s1):
Buen crédito, elementos en stock -> aceptar
orden
Situación recuperables (s2, s3):
Bajo crédito -> Cliente frecuente? -> Aceptar Bajo stock -> Reducir pedido? -> Aceptar
Situaciones no recuperables (s4, s5):
Escriba los escenarios recuperables y de fracaso
como “extensiones” al escenario ideal
UC4: “Colocar una orden”
“1. El Cajero identifica al cliente, cada artículo y la
cantidad.
2. El Sistema acepta y pone en cola de atención
la orden.”
Extensiones:
“1a. Crédito reducido: Cliente ‘frecuente’...”
“1b. Crédito reducido y no es Cliente ‘frecuente’:
...”
Un escenario se refiere a objetivos de bajo
nivel: Subordina casos de uso o funciones
comunes
UC 4: “Colocar una orden”
1. Identificar Cliente (UC 41)
2. ...
UC 41: “Identificar Cliente”
1. Operador proporciona el nombre. 2. El Sistema encuentra posibles
coincidencias cercanas. Extensiones:
2a. No se encontraron
El caso de uso externo sólo se asegura que el
caso de uso interno tenga éxito, evitando
proliferación
UC 4: “Colocar una orden”
1.
Identificar Cliente
<- (supone éxito)
2. ...
Extensiones:
Cada paso del escenario es un subobjetivo,
ocultando un caso de uso anidado
Objetivo: “Colocar una orden”
s1 s2
s6 s7 ...
E
s3
(Escenarios de éxito) (Esc. De fracaso)
E
E
F
E
F
..?E
E
F
F
F
F
Establece ... crédito ... inventarios4
s5
Cada oración en cada nivel es un objetivo.
Los casos de uso tiene un estilo repetido de una oración
Objetivo: “El Cliente coloca una orden.”
cómo
por qué
Paso: “El Cliente prepaga la orden.”
cómo
por qué
Los casos de uso estratégicos, las tareas y las
subfunciones se conectan como un grafo
Imagen de velero: Los objetivos del usuario están al nivel del mar.
anunciar ordenar facturar
Definir promoción Referir promoción monitorear promoción Colocar orden crear factura Enviar factura identificar promoción identificar cliente Registrar
usuario identificar producto Objetivo del proyecto
El nivel de objetivo del caso de uso está más
alto que el nivel de los pasos: va de blanco a
azul, índigo, negro
Objetivo del caso de uso
Objetio de pasos
(azul=objetivo del usuario)
(blanco)
(índigo)
(negro)
Objetivo del caso de uso
Casos de uso anidados por (nivel, alcance, detalle)
Cuál deberá escribirse?
Nivel: Por qué queremos esté objetivo?
Proporcionar monto, a Obtener$, para comprar almuerzo. (“Subfunción” vs “tarea” vs “objetivo estratégico”)
Alcance: A cuál de los límites del sistema nos referimos?
El Panel es parte del ATM, que es parte del Banco. (“Interno” vs “Sistema” vs “organización/corporativo”)
Detalle: Describimos intención o detalle de acción?
