Casos de Uso

Sistemas de Información I
Unidad II
Modelado de Sistemas
Competencia General
Al completar la asignatura el alumno será capaz

de analizar los requisitos mediante su
refinamiento con el fin de comprenderlos,
estructurarlos y plasmarlos en artefactos de
análisis de software orientado a objetos.
Competencias Concretas
• Reconoce los problemas existentes al
desarrollar sistemas de información, ventajas y
desventajas en el uso de modelos de
proceso, así como conceptos básicos en la
gestión de proyectos de software.
• Conoce e implementa el lenguaje unificado

de modelado, así como la programación en
JAVA de las relaciones entre clases.
Resultados de la Unidad
Conoce e implementa el lenguaje unificado de

modelado, así como la programación en JAVA
de las relaciones entre clases.
¿Qué han investigado
acerca de los temas a
estudiar hoy día?
Unidad II
Semana 10
Casos de Uso
Introducción
Contenidos
Modelar Casos de Uso
Tipos de relaciones
Propiedades
Tipología
Plantilla
Analista de negocios
no-IT: es alguien que
trabaja dentro del
contexto del negocio
(está implicada en la mejora de
Introducción
procesos, recorte de costes,

etc.)
Analista de negocios IT :
trabaja dentro del
contexto de proyectos
IT (proyectos para comprar,
adquirir o modificar algún
software).
Caso de uso de negocio y sistema
• La distinción no forma parte de UML, pero es
un extensión válida y aceptada.
Introducción
• Las extensiones se realizan a través de la

invención de nuevos estereotipos para los
elementos de UML .
• Un estereotipo amplía el significado de un

elemento de modelado. Por ejemplo, en el
modelado de negocio, un “actor de
negocio” es un estereotipo del actor de UML.
Un caso de uso (sin calificativos) se refiere a
la interacción con cualquier tipo de
sistema.
Introducción
Un caso de uso de negocio es una

interacción con un sistema de negocio.
Por ejemplo, “Procesar Reclamo” es un

caso de uso de negocio que describe
una interacción con una empresa
proveedora de Internet.
• Un caso de uso especifica un comportamiento
deseado del sistema.
• Representan los requisitos funcionales del

sistema.
“Un caso de uso especifica un conjunto de
secuencias de acciones, incluyendo variantes,
que el sistema puede ejecutar y que produce
un resultado observable de valor para un
particular actor.”
(Definición en UML)
• Describen qué hace el sistema, no cómo lo

hace.
Partes de un caso de uso (cdu)
• Conjunto de secuencias de acciones; cada
secuencia representa un posible comportamiento

del sistema
• Actores, roles que pueden jugar los usuarios
• Variantes: versiones especializadas, un cdu que

extiende a otro o un cdu que incluye a otro
• Un caso de uso realiza un trabajo tangible.

Emisor Centralita Receptor
listo( )
tono
marcar_numero
tono_sonando
timbre_sonando
telefono_cogido
Escenario para_tono
para_timbre
Los Casos de Uso son ideados por Jacobson a

principios de los noventa y están inspirados en los
Escenarios utilizados para describir procesos.
En sus primeras
reuniones con el
cliente, querrá
identificar todos los

proceso de negocio
a los que el
proyecto afectará.
Estos procesos son

los casos de uso de
negocio (representa
un flujo de trabajo
específico)
Diagramas - Casos de Uso de
Negocio
Un diagrama de caso de uso de

negocio (CUN) es un diagrama de
caso de uso en el que el sistema que
modela es el área de negocio del
mundo real. Ofrece una visión general
de los procesos y servicios (CUN) y las
entidades que utilizan esos servicios o
participan en su implementación.
Símbolos
Actor de
negocio
Caso de Uso
de negocio
Trabajador
Modelo de Casos de Uso del Negocio
Vendedor
Ejemplo de Caso de Uso
actor caso de uso
Gestionar Préstamos
Responsable
Prestamos
asociación
Casos de uso y Colaboraciones
• Con un caso de uso se describe un
comportamiento esperado del sistema, pero no

se especifica cómo se implementa.
• Una caso de uso se implementa a través de

una colaboración:
“Sociedad de clases y otros elementos que
colaborarán para realizar el comportamiento
expresado en un caso de uso”
• Una colaboración tiene una parte estática

(diagramas de clases) y una parte dinámica
(diagramas de secuencia).
Casos de uso y Colaboraciones
caso de uso
colaboración
Hacer Pedido
Gestión Pedidos
realización
Ejemplo diagrama de casos de uso
Reservar Libro Prestamo Revista
Profesor
Prestamo Libro Devolver Revista
Socio
Devolver Libro Actualizar Catalogo

Bibliotecario
Extender Prestamo
Consultar
Socio
Diagramas – Realización CUN
Cotizar productos
Realización del Caso de Uso del Negocio
Diagrama de Diagrama de
Actividades del Clases del
Negocio Negocio
Particiones o
Actividad de
Swimlanes
negocio
Decisión
Condición de
guardia
Objetos de
información
Modelar Casos de Uso de Sistema
Un caso de uso
especifica el
comportamiento de un
sistema o de una parte
del mismo, y es la
descripción de un
conjunto de secuencias
de acciones, incluyendo
variantes, que ejecuta
un sistema para producir
un resultado observable
de valor para un actor.
• Es una técnica para capturar información
de cómo un sistema o negocio trabaja

actualmente, o de cómo se desea que
trabaje.
• Describe qué hace un sistema, pero no

especifica cómo lo hace.
• Proporcionan un medio para que los

desarrolladores, los clientes, usuarios finales,
lleguen a una comprensión común del
sistema
Un caso de uso es el primer peldaño en la
conversión de las necesidades de los usuarios

a un sistema automatizado.
Por ejemplo, se puede

especificar cómo debería
comportarse un cajero
automático enunciando
mediante casos de uso
cómo interactúan los
usuarios con el sistema;
pero no se necesita saber
nada del interior del
cajero.
Un caso de uso describe un conjunto de
secuencias, donde cada secuencia

representa la interacción de los elementos
externos al sistema (sus actores) con el propio
sistema.
Se utiliza durante la
captura de requisitos y
el análisis para
visualizar, especificar,
construir y documentar
el comportamiento
esperado del sistema.
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

automáticamente por el sistema”).
• No forman parte del sistema.
29
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.
• Un actor necesita el caso de uso y/o participa

en él.
Actores
Tipos de actores:
– Principal:
Requiere al sistema el cumplimiento de
un objetivo.
– Secundarios:
El sistema necesita de ellos para
satisfacer un objetivo.
Actores
En resumen: Es un usuario del sistema, que
necesita o usa alguno de los casos de uso.

Un usuario puede jugar más de un rol. Un solo
actor puede actuar en muchos casos de
uso; recíprocamente, un caso de uso puede
tener varios actores.
Los actores no necesitan ser humanos

pueden ser sistemas externos que necesitan
alguna información del sistema actual.
Identificación de casos de uso
Requiere una lluvia de ideas y revisar
documentos sobre requerimientos.

Un método se basa en los actores:
• Se identifican los actores relacionados con un
sistema o empresa.
• En cada actor, se identifican los procesos que
inician o en que participan.
Otro método se basa en eventos:
• Se identifican eventos externos a los que un
sistema ha de responder.
• Se relacionan los eventos con los actores y con los
casos de uso.
Diagramas de Casos de Uso
Explica gráficamente un conjunto de casos
de uso de un sistema, los actores y la

relación entre éstos y los casos de uso. Estos
últimos se muestran en elipses y los actores
son figuras estilizadas.
Existen líneas de comunicaciones entre los

casos de uso y los actores; las flechas
indican el flujo de información o el
estímulo.
Diagramas de Casos de Uso
Ofrece una clase de diagrama contextual, que
permite conocer rápidamente los actores externos

de un sistema y las formas básica que la utilizan.
Caja
Compra producto
Cajero Cliente
Registra compra
Entrega cambio
Descripción de un caso de uso
• Son documentos de texto, no son diagramas.
El modelado de casos de uso consiste en escribir texto,

no en dibujar diagramas.
• 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 indicar: actores, flujos principal y

excepcionales.
Organización de Casos de uso
Tres tipos de relaciones:
Tipos de relaciones
– Generalización
Un cdu hereda el comportamiento y
significado de otro.
– Inclusión
Un cdu base incorpora explícitamente el
comportamiento de otro en algún lugar de su
secuencia.
– Extensión
Un cdu base incorpora implícitamente el
comportamiento de otro cdu en el lugar
especificado indirectamente por este otro cdu.
Ejemplo
Extensión
Tipos de relaciones
«extend» Hacer Pedido

Hacer Pedido Urgente
(establecer
prioridad)
«include»
Comprobar clave
Inclusión
Validar Usuario
Generalización
«include»
Seguir Pedido
Examinar retina
Comunica (comunicates). Entre un actor y
un caso de uso, denota la participación del
actor en el caso de uso determinado.
Tipos de relaciones
Caso de Uso
Actor
Incluye (include): Relación entre dos casos
de uso, denota la inclusión del
comportamiento de un escenario en otro. Se
Tipos de relaciones
utiliza cuando se repite un caso de uso en

dos o más casos de uso separados.
Frecuentemente no hay actor asociado con

el caso de uso común.
<<include>>
Caso de Uso Origen Caso de Uso Destino

• Un caso de uso incluido no contiene una
funcionalidad significante para la
arquitectura del sistema;
Tipos de relaciones
• El diseñador se puede concentrar en el caso

de uso base y omitir los detalles particulares
del caso de uso incluido;
• Un caso de uso incluido está incompleto por

naturaleza;
• Un caso de uso incluido no es ejecutado por

un actor distinto al actor del caso de uso
base
La inclusión permite factorizar un
comportamiento en un caso de uso aparte y
evitar repetir un mismo flujo en diferentes casos
Tipos de relaciones
de uso.
• Ejemplo:
Hacer Pedido:
Obtener y verificar el número de pedido;
Incluir “Validar usuario”;
Recoger los ítem del pedido del usuario;
…
Extiende (extends): Relación entre dos casos,
denota cuando un caso de uso es una
especialización de otro. Se usa cuando se
Tipos de relaciones
describe una variación sobre el normal

comportamiento.
<<extend>>
Caso de Uso Origen Caso de Uso Destino

• Un caso de uso extendido y sus casos de uso
de extensión sí entregan un resultado de
valor observable;
Tipos de relaciones
• Un caso de uso de extensión no es una

especialización del caso de uso extendido;
Permite que el
analista de
requisitos se
concentre con los
usuarios en las
nuevas
características del
caso de uso
extendido.
La extensión sirve para modelar:
– la parte opcional del sistema, o
– un subflujo que sólo se ejecuta bajo
Tipos de relaciones
ciertas condiciones.
Ejemplo:
Hacer Pedido:
Incluir “Validar usuario”;
Recoger los ítem del pedido del usuario;
Establecer prioridad: punto de extensión

Enviar pedido para ser procesado según la
prioridad.
Tipos de relaciones
identificación
<<include>>
transferencia
Cliente
<<extend>>
Transferencia
en Internet
• Los casos de uso se pueden aplicar al
sistema completo.
• También se puede aplicar a partes del

Tipos de relaciones
sistema, incluyendo subsistemas e incluso

clases e interfaces individuales.
• Pueden utilizarse también como la base

para establecer casos de prueba.
• Aplicados a los subsistemas, son una fuente

de pruebas de regresión; aplicados al
sistema son fuente de pruebas del sistema y
de integración.
Un caso de uso es, en esencia, una
interacción típica entre un usuario y un
sistema de cómputo.
Propiedades
Entre sus propiedades:
• El caso de uso capta alguna función visible

para el usuario;
• El caso de uso puede ser pequeño o grande;
• El caso de uso logra un objetivo discreto para

el usuario.
• En su forma más simple, el caso de uso se
obtiene conversando con los usuarios habituales
y analizando con ellos las distintas cosas que
deseen hacer con el sistema.
Propiedades
• Se debe abordar cada cosa discreta que

quieran, darle un nombre y escribir un texto
descriptivo breve.
• ¡No trate de obtener todos los detalles justo

desde el principio; los obtendrá cuando los
necesite!
• ¡Centrarse primero en los objetivos del usuario y

después encontrar casos de uso que los
cumplan!
En resumen:
• Son iniciados por un actor con un objetivo en

mente y es completado con éxito cuando el
sistema lo satisface.
Propiedades
• 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.
Casos de Uso: Tipo texto
Es un documento narrativo
que describe la secuencia de
eventos de un actor que utiliza
un sistema para completar un
Tipología
proceso.
Son historias o casos de

utilización de un sistema; no
son exactamente los
requerimientos ni las
especificaciones funcionales,
sino que ejemplifican e
incluyen los requerimientos.
Descripción de un caso de uso:
textual
Realizar Venta (en un Terminal de Punto de Venta o
TPV)
Tipología
Actor Principal: Cajero

Flujo Principal: Un cliente llega al TPV con un conjunto de
artículos. El Cajero registra los artículos y se genera un ticket.
El cliente paga en efectivo y recoge los artículos.
1. El cliente llega al TPV con los artículos.

2. El cajero registra el identificador de cada artículo.
3. El sistema obtiene el precio de cada artículo y añade la
información a la transacción de venta.
4. Al acabar el cajero indica la finalización de la introducción
de artículos.
textual
Realizar Venta (en un Terminal de Punto de Venta o

TPV)
Tipología
5. El sistema calcula el total de la compra y lo muestra.

6. El cajero le dice al cliente el total.
7. El cliente realiza el pago.
8. El cajero registra la cantidad de dinero recibida.
9. El sistema muestra la cantidad a retornar al cliente y genera
un recibo.
10. El cajero deposita el dinero recibido y saca la cantidad a
devolver que entrega al cliente junto al ticket de compra.
11. El sistema almacena la compra completada.
12. El cliente recoge los artículos comprados.
gráfica
Realizar Venta
Diagrama de secuencia
Tipología
:Sistema
: Cajero
crearNuevaVenta()
* introducirItem(cod,cantidad)
finalizarVenta()
hacerPago(cantidad)
Formatos de Casos Típicos
Según grado de detalle
• Alto nivel
• Expandido
Tipología
Según prioridad para el desarrollo

• Primarios
• Secundarios
• Opcionales
Según grado de abstracción
• Esencial
• Real
Grado de detalle: alto nivel
Caso de uso: Comprar productos

Tipología
Actores: Cliente, Cajero.
Tipo: Primario.
Descripción: Un Cliente llega a la caja con los

artículos que comprará. El Cajero registrará los
artículos, cobra y devuelve el cambio. El Cliente
se va con los productos.
Grado de detalle: expandido
Muestra más detalles que uno de alto nivel;
suelen ser útiles para alcanzar un
conocimiento más profundo de los
Tipología
procesos y de los requerimientos.
La sección intermedia, secuencia de pasos

en los escenarios, es la parte medular del
formato expandido; describe los detalles
de la conversión interactiva entre los
actores y el sistema (historia de actividades y
terminación exitosa de un proceso).
Caso uso: Nombre del caso de uso
Actores: Lista de actores, indicando quién
inicia.
Propósito: Finalidad del caso típico.
Resumen: Repite el alto nivel o síntesis similar.
Tipología
Tipo: 1. Primario.
2. Esencial
Referencias
cruzadas: casos relacionados.
Secuencia de pasos en los escenarios
Acción del actor Respuestas del sistema

Cursos alternos
Ej. Comprar productos en Librería
Caso de uso: Comprar productos en efectivo
Actores: Cliente, Cajero.

Tipología
Propósito: Capturar una venta y su pago en

efectivo
Resumen: Un cliente llega a la caja 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 artículos
comprados.
Tipo: Primario y esencial
Referencias
cruzadas: funciones (casos relacionados).
Secuencia normal de eventos
Acción del actor Respuesta del sistema
1. Este caso de uso comienza

cuando un Cliente llega a
una caja con productos
Tipología
que desea comprar.
2. El cajero registra el 3. Determina el precio del

identificador de cada producto e incorpora a la
producto; Si hay varios transacción actual; Se
productos de una misma presentan la descripción y
categoría, el cajero el precio del producto
también puede introducir la actual.
cantidad.
4. Al terminar de introducir el 5. Calcula y presenta el total

producto, el Cajero oprime el de la venta.
botón que indica que se
Tipología
concluyó la captura del

producto.
6. El Cajero le indica el total al

Cliente.
7. El Cliente efectúa un pago en
efectivo (efectivo ofrecido)
posiblemente mayor que el
total de la venta.
8. El cajero registra la 9. Muestra al Cliente la

cantidad de efectivo diferencia. Genera
recibida. factura.
Tipología
10. El cajero deposita el 11. Registra la venta

efectivo recibido y extrae concluida
el cambio del pago.
12. El Cliente se marcha con los

productos comprados.
Cursos alternos:
Línea 2: introducción de identificador inválido. Indica error

Línea 7: el Cliente no tenia suficiente dinero. Cancelar la transacción.
Según prioridad para desarrollo
• Casos primarios de uso: representan los

procesos comunes más importantes.
Tipología
• Casos secundarios de uso: representan

procesos menores o raros;
• Casos opcionales de uso: representan

procesos que pueden no abordarse.
Grado de abstracción: esenciales
Los casos esenciales de uso son casos

expandidos que se expresan en una forma
teórica que contiene poca tecnología y
Tipología
pocos detalles de implementación;
Las decisiones de diseño se posponen y se

abstraen de la realidad especialmente las
concernientes a la interfaz para el usuario.
Grado de abstracción: esenciales
1. El cajero registra el 2. Determina el precio del

identificador en cada producto y agrega la
producto; información sobre él a la
Tipología
actual transacción de
Si hay más de un venta.
producto igual, el cajero Aparecen la descripción
puede introducir de igual y el precio del producto
manera la cantidad. actual.
3. Y así sucesivamente….. 4. Y así sucesivamente…..
65
Grado de abstracción: real
A diferencia de una versión esencial del caso de
uso, una versión real se compromete con el diseño

Tipología
1. En cada producto, el 2. Muestra el precio del

Cajero teclea código producto y agrega la
del producto en el información sobre él a la
campo de entrada de actual transacción de
la Ventana1. Después venta. La descripción y el
oprime el botón precio del producto actual
“introducir producto” se muestran en el cuadro
con el ratón u de Texto2 de la Ventana1.
oprimiendo la tecla
<enter>
3. Y así sucesivamente….. 4. Y así sucesivamente…..

Granularidad
Diferente granularidad
– Casos de uso del negocio

Tipología
Procesos de Negocio: Objetivo estratégico de la empresa

Ej. Vender productos
– Casos de uso del sistema

Objetivo de un usuario
Ej. Realizar una compra
– Casos de uso de inclusión

Forman parte de otro, son como subfunciones
Ej. Buscar, Validar, Login
Obtención de casos de uso
En resumen se debe:
1. Identificar los usuarios del sistema.

Tipología
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.
6. Revisar y validar con el usuario.
Plantilla usecases.org (Larman)
• Resumen
• Actores Principales y Secundarios
• Personas involucradas e Intereses
Plantilla
• Precondiciones
• Pos condiciones
• Escenario Principal (Flujo Básico-
Secuencia normal)
• Extensiones (Flujos Alternativos)
• Requisitos de Interfaz de Usuario
• Requisitos No-Funcionales
• Cuestiones Pendientes
Caso de uso “Realizar Venta”
• Resumen: Un cliente llega al TPV con un conjunto de
artículos. El cajero registra los artículos y se genera
un ticket. El cliente paga en efectivo y recoge los
artículos.
Plantilla
• Actores: Cajero (principal), Sistema (secundario)
• Personal Involucrado e Intereses:

– Cajero: quiere entradas precisas, rápidas y sin errores de pago.
– Compañía: quiere registrar transacciones y satisfacer clientes.
– ...
• Precondición: El cajero se identifica y autentifica.
• Pos condiciones: Se registra la venta. Se calcula el

impuesto. Se actualiza la contabilidad y el
inventario.
• Escenario Principal (Flujo Básico):
1. El cliente llega al TPV con los artículos.
2. El cajero inicia una nueva venta.
3. El cajero introduce el identificador de cada artículo.
Plantilla
4. El sistema registra la línea de venta y presenta descripción

del artículo, precio y suma parcial.
5. El cajero repite los pasos 3 y 4 hasta que se indique.
6. El sistema presenta el total.
7. El cajero le dice al cliente el total a pagar .
8. El cliente paga y el sistema gestiona el pago.
9. El sistema registra la venta completa y actualiza el
inventario.
10. El sistema presenta recibo.
71
• Extensiones (Flujos Alternativos):
A1: Identificador no válido
La secuencia A1 comienza en el punto 3.
1. El sistema señala el error y rechaza la entrada.
El escenario vuelve al punto 3.
Plantilla
A2: El cliente pide eliminar un artículo de la compra.

La secuencia A2 puede ocurrir entre los puntos 3-6.
1. El cajero introduce identificador a eliminar.
2. El sistema actualiza la suma.
El escenario continúa en el punto 6.
A3: Pago en efectivo

La secuencia A3 ocurre en el punto 7.
1. El cajero introduce la cantidad entregada por el cliente.
2. El sistema muestra cantidad a devolver.
El escenario continúa en el punto 8.
• Requisitos de Interfaz de Usuario:
- Pantalla táctil en un monitor de pantalla plana.
- El texto debe ser visible a un metro de distancia.
• Requisitos No-Funcionales:
Plantilla
- El identificador del producto podría ser cualquier

esquema de código de barras UPC, EAN-8, EAN-13,
...
- El tiempo de respuesta para autorizar el pago con la
tarjeta de débito o de crédito es de 30 segundos.
• Cuestiones Pendientes:
- Explorar cuestiones de recuperación de accesos a
servicios remotos.
- ¿Qué adaptaciones son necesarias en un TPV para
diferentes negocios?
73
¿Cuáles son
los temas
estudiados
el día de
hoy?
¿Para que me
sirve y como lo
aplicaría en mi
vida profesional
y personal?
Unidad II
Semana 10
Casos de Uso

Casos de Uso

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Casos de Uso

Cargado por

Copyright:

Formatos disponibles

Sistemas de Información I

Al completar la asignatura el alumno será capaz

• Conoce e implementa el lenguaje unificado

Conoce e implementa el lenguaje unificado de

procesos, recorte de costes,

• Las extensiones se realizan a través de la

• Un estereotipo amplía el significado de un

Un caso de uso de negocio es una

Por ejemplo, “Procesar Reclamo” es un

• Representan los requisitos funcionales del

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

secuencia representa un posible comportamiento

• Actores, roles que pueden jugar los usuarios

• Variantes: versiones especializadas, un cdu que

• Un caso de uso realiza un trabajo tangible.

Los Casos de Uso son ideados por Jacobson a

identificar todos los

Estos procesos son

Un diagrama de caso de uso de

Modelo de Casos de Uso del Negocio

actor caso de uso

comportamiento esperado del sistema, pero no

• Una caso de uso se implementa a través de

• Una colaboración tiene una parte estática

Reservar Libro Prestamo Revista

Prestamo Libro Devolver Revista

Devolver Libro Actualizar Catalogo

de cómo un sistema o negocio trabaja

• Describe qué hace un sistema, pero no

• Proporcionan un medio para que los

conversión de las necesidades de los usuarios

Por ejemplo, se puede

secuencias, donde cada secuencia

Un actor representa un conjunto coherente de

• Roles jugados por personas, dispositivos, u otros

• El tiempo puede ser un actor (“procesos iniciados

• No forman parte del sistema.

• En la realización de un caso de uso pueden

• Un actor puede intervenir en varios casos de

• Un actor necesita el caso de uso y/o participa

necesita o usa alguno de los casos de uso.

Los actores no necesitan ser humanos

documentos sobre requerimientos.

de uso de un sistema, los actores y la

Existen líneas de comunicaciones entre los

permite conocer rápidamente los actores externos

El modelado de casos de uso consiste en escribir texto,

• Describir el flujo de eventos

• Debe ser legible y comprensible para un

• Debe indicar: actores, flujos principal y

«extend» Hacer Pedido

utiliza cuando se repite un caso de uso en

Frecuentemente no hay actor asociado con

Caso de Uso Origen Caso de Uso Destino

• El diseñador se puede concentrar en el caso

• Un caso de uso incluido está incompleto por

• Un caso de uso incluido no es ejecutado por

describe una variación sobre el normal

Caso de Uso Origen Caso de Uso Destino

• Un caso de uso de extensión no es una

Establecer prioridad: punto de extensión

• También se puede aplicar a partes del

sistema, incluyendo subsistemas e incluso

• Pueden utilizarse también como la base