Universidad Arturo Prat

Departamento de Ingeniería

UML

Casos de Uso

Departamento de Ingeniería

Modelado de Casos de Uso

• Un caso de uso especifica un comportamiento deseado

del sistema.
• Representan los requisitos funcionales del sistema.

“Un caso de uso especifica una secuencia de

acciones, incluyendo variantes, que el sistema puede
ejecutar y que produce un resultado observable de
valor para un particular actor”

• Describen qué hace el sistema, no cómo lo hace.

Sistema de información II - 2007 Departamento de Ingeniería

1
 Casos de uso

– Un caso de uso es un documento narrativo que

describe la secuencia de eventos de un actor
(agente externo) que utiliza un sistema para
completar un proceso.
– Objetivo: el comportamiento deseado del sistema en
desarrollo, sin tener que especificar cómo se
implementa ese comportamiento.
– Elementos básicos son los actores y escenarios
– Casos de uso de alto nivel y expandidos.

Sistema de información II - 2007 Departamento de Ingeniería

Otras definiciones de caso de uso

• “Describe un conjunto de interacciones entre actores

externos y el sistema en consideración orientadas a
satisfacer un objetivo de un actor”. [D. Bredemeyer]

• “Es una colección de posibles secuencias de

interacciones entre el sistema en discusión y sus
actores externos, relacionado con un objetivo
particular”. [A. Cockburn]

• “Es una colección de escenarios de éxito y fracaso

relacionados que describe a los actores que usan un
sistema para conseguir un objetivo” [C. Larman]
Sistema de información II - 2007 Departamento de Ingeniería

2
 Casos de Uso

• Un escenario es un relato particular de cómo usar un

sistema
– Una secuencia específica de acciones e interacciones entre
actores y el sistema —también, una instancia de un caso de uso
– Un relato particular de cómo usar un sistema, o una ruta a través
del caso de uso
• P.ej.,
– el escenario de comprar exitosamente artículos con efectivo
– el escenario de no poder comprar artículos debido a una
denegación del pago con tarjeta de crédito

Sistema de información II - 2007 Departamento de Ingeniería

Emisor Centralita Receptor

listo( )

tono

marcar_numero

ESCENARIO tono_sonando
timbre_sonando

telefono_cogido
para_tono

para_timbre

• Casos de uso son ideados por Jacobson a principios de los noventa

• Se inspira en los escenarios utilizados para describir procesos
Sistema de información II - 2007 Departamento de Ingeniería

3
 Actores

Un actor representa un conjunto coherente de

roles que juegan los usuarios de los casos de
uso al interaccionar con el sistema.

• Roles jugados por personas, dispositivos, u

otros sistemas.
• El tiempo puede ser un actor (“procesos
iniciados por el sistema”)
• No forman parte del sistema

Sistema de información II - 2007 Departamento de Ingeniería

Actores

• Un usuario puede jugar diferentes roles.

• En la realización de un caso de uso pueden
intervenir diferentes actores.
• Un actor puede intervenir en varios casos de
uso.
• Es posible Identificar casos de uso mediante
actores y eventos externos.
• Un actor necesita el caso de uso y/o participa
en él.

Sistema de información II - 2007 Departamento de Ingeniería

4
 Actores

A. Cockburn distingue dos tipos de actores:

– Primarios:
Requieren al sistema el cumplimiento de un
objetivo

– Secundarios:
El sistema necesita de ellos para satisfacer un
objetivo

Sistema de información II - 2007 Departamento de Ingeniería

Casos de uso

• Un actor es algo con comportamiento, P.ej.,

– una persona (identificada por su rol con respecto al sistema):
cajero, cliente, SII, etc.
– un sistema computacional
– una organización
• El propio sistema en estudio es un actor si llama a los
servicios de otros sistemas
• Hay 3 tipos de actores
– Actores principales
– Actores secundarios
– Actores fuera de escena

Sistema de información II - 2007 Departamento de Ingeniería

5
 Casos de Uso

• Actores principales
– usan los servicios del sistema
– Tienen objetivos de usuario que se logran usando servicios del sistema:
• P.ej., el cajero del sistema de un puesto de venta. (supermacado)
– Los identificamos para encontrar los objetivos de usuario, que son los que
motivan los casos de uso
• Actores secundarios
– proporcionan servicios al sistema
• P.ej., el servicio automatizado de autorización de pagos
– A menudo son sistemas computacionales, pero podrían ser organizaciones o
personas
– Los identificamos para clarificar interfaces y protocolos externos
• Actores fuera de escena
– Tienen interés en el comportamiento del caso de uso, pero no son principales ni
secundarios:
• P.ej., el servicio de impuestos internos
– Los identificamos para asegurarnos que todos los intereses necesarios están
considerados
– Estos intreses son fáciles de pasar por alto, si no los nombramos explícitamente

Sistema de información II - 2007 Departamento de Ingeniería

Propiedades de los casos de uso

• Son iniciados por un actor con un objetivo en mente y

es completado con éxito cuando el sistema lo satisface.
• Puede incluir secuencias alternativas que llevan al éxito
y fracaso en la consecución del objetivo.
• El sistema es considerado como una “caja negra” y las
interacciones se perciben desde fuera.
• El conjunto completo de casos de uso especifica todas
las posibles formas de usar el sistema, esto es el
comportamiento requerido.

Sistema de información II - 2007 Departamento de Ingeniería

6
 Descripción de un caso de uso

• Describir el flujo de eventos

– Texto estructurado informal
– Texto estructurado formal (plantillas)
– Pseudocódigo
– Notaciones gráficas: diagramas de secuencia

• Debe ser legible y comprensible para un usuario

no experto.
• Debe indicarse: inicio y final, actores, objetos que
fluyen, flujo principal y flujos excepcionales.

Sistema de información II - 2007 Departamento de Ingeniería

Casos de Uso

• Como escribir un caso de Uso

– Breve:Resumen de un párrafo del escenario exitoso
principal;
– Casual: Formato de párrafo informal; múltiples
párrafos que cubren varios escenarios;
– Completamente detallado: Todos los pasos y
variaciones están escritos en detalle, y hay secciones
de apoyo, p.ej., pre y poscondiciones

Sistema de información II - 2007 Departamento de Ingeniería

7
 Obtención de casos de uso

1) Identificar los usuarios del sistema.

2) Encontrar todos los roles que juegan los
usuarios y que son relevantes al sistema.
3) Para cada rol identificar todas las formas
(objetivos) de interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso.
(¡Cuidado!)
6) Revisar y validar con el usuario.
Sistema de información II - 2007 Departamento de Ingeniería

Plantilla para casos de uso (D. Coleman)

Caso de Uso identificador / historia

Descripción objetivo a conseguir
Actores lista de actores
Asunciones condiciones que deben cumplirse
Pasos interacciones entre los actores y el
sistema necesarias para obtener el
objetivo
Variaciones (opcional) cualquier variación en los
pasos
No-funcional (opcional) lista requisitos no
funcionales
Cuestiones lista de cuestiones que permanecen
por resolver
Sistema de información II - 2007 Departamento de Ingeniería

8
 Plantilla para casos de uso (D. Coleman)

Ejemplo campo “pasos”:

1. Operador es notificado de problema en la red
2. Operador inicia una sesión de reparación
3. REPETIR
3.1. Operador ejecuta aplicación diagnósticos en la red.
3.2. Operador identifica elementos que deben cambiarse y sus
nuevos valores para los parámetros.
3.3. EN PARALELO
3.3.1. Ingeniero mantenimiento comprueba elementos
en la red ||
3.3.2. Ingeniero mantenimiento envía informe fallo
4. Operador cierra sesión

Sistema de información II - 2007 Departamento de Ingeniería

Plantilla usecases.org (Larman)

• Actor Principal
• Personas involucradas e Intereses
• Precondiciones
• Postcondiciones
• Escenario Principal (Flujo Básico)
• Extensiones (Flujos Alternativos)
• Requisitos especiales
• Tecnología y Lista Variaciones de datos
• Frecuencia
• Cuestiones abiertas

Sistema de información II - 2007 Departamento de Ingeniería

9
 ¿Por qué casos de uso?

• “Ofrecen un medio sistemático e intuitivo para

capturar los requisitos funcionales, centrándose
en el valor añadido para el usuario”
• Dirigen todo el proceso de desarrollo puesto
que la mayoría de actividades (planificación,
análisis, diseño, validación, test,..) se realizan a
partir de los casos de uso.
• Mecanismo importante para soportar
“trazabilidad” entre modelos.
Sistema de información II - 2007 Departamento de Ingeniería

Críticas a los casos de uso (B.Meyer)

• Los casos de uso no son adecuados en el

modelado orientado a objetos porque:
i) Favorecen un enfoque funcional, basado en procesos
ii) Se centran en secuencias de acciones
iii) Se basan en los escenarios actuales del sistema

“Solo deben ser usados por equipos expertos

en desarrollo OO”
• Útiles para validación

Sistema de información II - 2007 Departamento de Ingeniería

10
 Utilidad de los casos de uso

• Hay consenso en considerar casos de uso

como esenciales para capturar requisitos y
guiar el modelado.
• Pero existe (¿ha existido?) mucha confusión
sobre cómo usarlos.
• Diferentes opiniones sobre el número de
casos de uso conveniente:
– 20 para un proyecto 10 personas/año (Jacobson)
– depende de la granularidad

Sistema de información II - 2007 Departamento de Ingeniería

Granularidad

• Diferente granularidad
• Un caso de uso puede describir:
– Un objetivo o propósito del usuario
– Una interacción con el sistema
• Un objetivo implica una o más interacciones.
• Construir un caso de uso por cada objetivo
del usuario.

Sistema de información II - 2007 Departamento de Ingeniería

11
 Tipos de casos de uso

• Según el nivel de detalle

– Breve : Descripción en unas pocas líneas
– Informal : Varios párrafos que cubren varios
escenarios
– Expandido : Descripción detallada con una plantilla
• Según la importancia
– Primario, secundario u opcional
• Según el nivel de abstracción
– Esencial : ¿Qué hace el sistema?
– Concreto : Se contemplan detalles de implementación
(GUI y tecnología)

Sistema de información II - 2007 Departamento de Ingeniería

Casos de Uso

• Nombre
• Alcance • Escenario exitoso
• Nivel: objetivo de usuario principal
o subfunción • Escenarios alternativos
• Actor principal • Requisitos no funciona-
• Interesados e intereses les relacionados
• Precondiciones • Variaciones tecnológi-cas
y de datos
• Poscondiciones
• Frecuencia de ocurrencia
• Otros

Sistema de información II - 2007 Departamento de Ingeniería

12
 Casos de Uso

• Formato de un caso de uso

Caso de uso: Nombre del caso de uso

Actores: Elementos que participan. Pueden ser personas u otros sistemas.

Propósito: Objetivo del caso de uso.

Resumen: Descripción breve de los hechos.

Tipo: Importancia del caso de uso. Orden de prioridad. : por ejemplo, primario, escencial, etc.

Referencias Cruzadas Corresponde a referencias a otros documentos o casos de usos.

Acción del actor Respuesta del sistema

Descripción de hechos del sistema.
NO DEBEN EXISTIR LA FORMA EN QUE SE IMPLEMENTARÁ,
Descripcion de hechos del actor
POR EJEMPLO NO NOMBRAR BASES DE DATOS, PAGINAS
WEB, MODULOS, ETC.

Cursos alternos

Corresponde a acciones alternativas a la ideal que está descrito arriba (en las acciones del actor y las acciones del sistema)

Sistema de información II - 2007 Departamento de Ingeniería

Casos de Uso

• Caso de uso de alto nivel

Caso de uso: Comprar productos en efectivo

Actores: Cliente (iniciador), Cajero.

Propósito: Capturar una venta y su pago en efectivo.

Resumen: Un Cliente llega a la caja registradora con artículos que desea comprar. El Cajero
registra los productos y recibe un pago en efectivo. Al terminar la operación, el
Cliente se marcha con los productos comprados.

Tipo: Primario y esencial.

Referencias Funciones: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1.

cruzadas:

Sistema de información II - 2007 Departamento de Ingeniería

13
 Caso de uso: Comprar productos en efectivo

Actores: Cliente (iniciador), Cajero.

Propósito: Capturar una venta y su pago en efectivo.

Resumen: Un Cliente llega a la caja registradora con artículos que desea comprar. El Cajero registra los productos y recibe un pago en
efectivo. Al terminar la operación, el Cliente se marcha con los productos comprados.

Tipo: Primario y esencial.

Referencias Cruzadas Funciones: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1.

Acción del actor Respuesta del sistema
1. Este caso de uso comienza cuando un cliente llega a una caja del
terminal de punto de venta (TPV) con productos para comprar.
2. El Cajero registra el identificador de cada producto. Si hay varios
3. Determina el precio del producto e incorpora a la transacción actual la
productos de una misma categoría, el Cajero también puede introducir la
información correspondiente.
cantidad.
4. Al terminar de introducir los productos, el Cajero indica al TPV que se
5. Calcula y presenta el total de la venta.
concluyo la captura de los mismos.

6. El Cajero le indica el total al cliente.

7. El Cliente efectúa un pago en efectivo, posiblemente mayor que el total
de la venta.
8. El Cajero registra la cantidad de efectivo recibida. 9. Muestra al Cajero y al Cliente la diferencia. Genera la boleta.

10. El cajero deposita el efectivo recibido en la caja, y extrae el cambio. 11. Registra la venta concluida.

12. El cliente se marcha con los artículos comprados.

Cursos alternos
Item 2: Introducción de identificador inválido. Indicar error.
- Item 7: El cliente no tiene suficiente dinero. Cancelar transacción de venta o restar productos.

Casos de Uso

• ¿por que usar casos de uso?

– Nosotros tenemos objetivos y queremos que los computadores nos
ayuden a lograrlos:
• Registrar ventas, jugar juegos, estimar el flujo de petróleo de futuros pozos

– Las mejores formas para capturar objetivos son aquéllas que son
simples y familiares:
• Facilitan —especialmente a los clientes— contribuir a su definición y
revisión, reduciendo el riesgo de equivocarse
• La falta de involucramiento de usuarios está al comienzo de la lista de
razones por las que los proyectos de software fracasan

– Éste es un énfasis más centrado en el usua-rio comparado con

simplemente preguntar por una lista de características del sistema
• ¿Quién está usando el sistema?
• ¿Cuáles son sus escenarios de uso típicos?
• ¿Cuáles son sus objetivos?

Sistema de información II - 2007 Departamento de Ingeniería

14
 Casos de Uso

• ¿por que usar casos de uso?

– Los casos de uso son principalmente
requisitos funcionales
• Pueden ser usados para otros tipos de requisitos,
especialmente cuando éstos se relacionan
estrechamente con un caso de uso
• Un caso de uso define un contrato de cómo se
comportará un sistema

Sistema de información II - 2007 Departamento de Ingeniería

Para escribir casos de uso, sigamos los

siguientes pasos

1. Elijamos la frontera del sistema:

– ¿Es sólo una aplicación, la aplicación más el
hardware como una unidad, ésta más la persona
que la usa, o toda una organización?
2. Identifiquemos los actores principales:
– Aquéllos que tienen objetivos que se logran usando
los servicios del sistema
3. Identifiquemos los objetivos de cada actor
4. Definamos casos de uso que satisfagan objetivos de
usuario:
– Normalmente, un caso de uso para cada objetivo

Sistema de información II - 2007 Departamento de Ingeniería

15
 Casos de uso

• Ejercicios
– Solicitar préstamo de libros en biblioteca.
– Ver cuenta corriente banco.
– Obtener crédito fiscal.
– comprar un pasaje aéreo en www.lan.com
– Imagine que Ud. posee un notebook, un celular y una
tarjeta de crédito para redbanc. Describa los casos
de uso para poder pagar el servicio de electricidad de
su casa. (considere que recibe una boleta o
comprobante por este pago)

Sistema de información II - 2007 Departamento de Ingeniería

Caso de uso: Solicitar préstamo de libros en biblioteca

Actores: Alumno, bibliotecario.

Propósito: Solicitud y entrega de un libro.

Resumen: Un alumno llega al mesón de biblioteca a solicitar un libro, el bibliotecario lo entrega si se encuentra disponible.

Tipo: Primario y esencial.

Referencias Cruzadas R1: reservar libro

Acción del actor Respuesta del sistema

1. Este caso de uso comienza cuando un alumno llega al mesón de la
biblioteca y solicita un libro.
2. El bibliotecario le solicita al alumno su carnet.
3. El bibliotecario consulta en el sistema si hay morosidad para el rut del
4. Indica que no existe morosidad para el alumno.
alumnos
6. Indica los libros disponibles y su ubicación, y las fechas de devolución de los
5. El bibliotecario solicita los datos del libro y los ingresa al sistema.
no disponibles.
7. El bibliotecario busca y encuentra el ejemplar.
9. Calcula la fecha de devolución y la informa. Registra que el libro ha sido
8. El bibliotecario registra el libro con el rut del alumno.
prestado al alumno.
10. Se repiten los pasos del 5 al 9 hasta 3 veces si el alumno desea mas
libros
11. El bibliotecario entrega al alumno el libro.

12. El alumno se retira de biblioteca con el libro.

Cursos alternos
4: el deudor tiene morosidad. El sistema indica que no se debe entregar el libro.
6: no existe el libro para los datos ingresados. Indica error
6: no existen libros disponibles, se podrá elegir un libro entre los no disponibles y se registrara como reservado.

16
 Caso de uso:

Actores:

Propósito:

Resumen:

Tipo:

Referencias Cruzadas

Acción del actor Respuesta del sistema

Cursos alternos

Recomendaciones

• Especificar casos de uso no es una actividad de

dibujar diagramas sino de escribir con el detalle
necesario el flujo principal y los flujos alternativos:
“centrado en la escritura en vez del dibujo”
• No hay que preocuparse demasiado por las
relaciones entre casos de uso ni entre actores.
• El objetivo inicial es identificar los actores y a partir
de sus objetivos encontrar los casos de uso, el
diagrama de casos de uso es una ayuda visual.
• Los actores deben interactuar con el sistema

Sistema de información II - 2007 Departamento de Ingeniería

17
 Recomendaciones

• ¿Qué granularidad es apropiada para un caso

de uso?
• En un sistema de venta por internet,
– “Añadir producto al carro de la compra”
– “Introducir datos facturación”
¿son casos de uso?
• Deben ser objetivos del usuario
• Error común: no identificar como casos de uso
las tareas que inicia el propio sistema
– “Anular reservas pasados quince días”
Sistema de información II - 2007 Departamento de Ingeniería

Recomendaciones

• No incluir como caso de uso las operaciones CRUD

sobre un objeto de negocio (alta, consulta, borrado,
actualización): función del sistema aparte, excepto si se trata
de operaciones relevantes para el sistema, como “registrar
cliente” en un sistema de venta por internet
• Cuidado con el empleo de la relación “include”
¡NO HACER UNA DESCOMPOSICION FUNCIONAL!
• Escribir casos de uso independientes de la interfaz o
de detalles de implementación, escribirlos a nivel
esencial.
• ¿A qué nivel de detalle se describe un caso de uso?
– Primero informal, luego expandido

Sistema de información II - 2007 Departamento de Ingeniería

18
 Recomendaciones

• Hay que comprobar que los casos de uso

incluyen toda la funcionalidad del sistema.
• Preocupación por mantener la validez y
consistencia del conjunto de casos de uso.
• Cada compañía debe tener un manual sobre
uso de los casos de uso.
• Los casos de uso sólo consideran los
requisitos funcionales del proyecto, hay que
añadir los no-funcionales.

Sistema de información II - 2007 Departamento de Ingeniería

Referencias

• http://alistair.cockburn.us/usecases/usecases.html
• “Writing effective uses case”, Alistair Cockburn, Addison-Wesley, 2000
• C. Larman, “UML y Patrones: Una introducción al análisis y diseño
orientado a objetos y al proceso unificado”, Prentice-Hall, 2003.

Sistema de información II - 2007 Departamento de Ingeniería

19