Casos de Uso

DIAGRAMAS DE CASOS DE USO
 Diagramas de Casos de Uso.

 Especificación de un Caso de Uso.

Casos de Uso
¿Qué es el Comportamiento del Sistema?
Es como el sistema actúa y
reacciona .
 Están basado en el
lenguaje natural, es decir,
es accesible por los
usuarios
El Comportamiento del
Sistema se captura mediante
los CASOS DE USO.
 Describe el sistema, su
entorno y la relación del
sistema y su entorno.
Casos de Uso
 Es una técnica para capturar

información de cómo un
sistema o negocio trabaja, o de
cómo se desea que trabaje
 Representan la funcionalidad
externa del sistema tal como es
vista por los usuarios.
 No pertenece estrictamente al
enfoque orientado a objeto, es
una técnica para captura de
requisitos.
Casos de Uso
 Un caso de uso representa un

requisito funcional del sistema
a construir.
 Los efectos de un caso de uso
deben ser tangibles.
 Debe producir algo de valor
para algún actor, tal como el
cálculo de un resultado, la
generación de nuevos objetos,
o el cambio de estado de los
objetos.
 Están basado en el lenguaje
natural, es decir, es accesible
por los usuarios.
Casos de Uso
Un buen ejemplo de los casos de uso puede ser el cómo una

familia utilizará una casa.
Las casas se utilizan para:
– comer
– dormir
– criar a los niños
– guardar cosas, etc.
El propósito principal del diagrama de casos de uso es


comunicar la funcionalidad del sistema y su
comportamiento al usuario final o cliente
Sistema
Caso de uso X
Actor A
Actor B
Caso de uso Y
Elementos de un Diagrama de Casos de Uso
Actores
 Un actor es cualquier objeto que interactúa con
el sistema.
• Principales: personas que usan el sistema.
• Secundarios: personas que mantienen o
administran el sistema
• Material externo: dispositivos materiales
imprescindibles que forman parte del ámbito
de la aplicación y deben ser utilizados
• Otros sistemas: sistemas con los que el
sistema interactúa Actor
 La misma persona física puede interpretar
varios papeles como actores distintos
 El nombre del actor describe el papel
desempeñado
Actores
Para identificarlos debemos
preguntarnos:
 ¿Quién usa el sistema?

 ¿Quién instala el sistema?
 ¿Quién ingresa información al
sistema?
 ¿Quién obtiene información del
sistema? Actor
 ¿Quién da mantenimiento el
sistema?
 ¿Qué otros sistemas van a usar a
este sistema
Actores
Documentación de los Actores
Una breve descripción de cada actor debe ser añadida al modelo.
La descripción debería identificar al rol que el actor juega en su
interacción con el sistema.
Por ejemplo, si se identificó un actor que se llama Cliente. Una

descripción del tal actor sería:
Un cliente es aquella persona que adquiere

un producto en la compañía
Actores
Instancias de Actores
Insert card
1 2 3
Juan actúa 4 5 6
como un 7 8 9
actor * 0 # Pedro actúa
Use-Case Mode l como un
actor
Caso de Uso
Actor
Actores
Un Usuario Puede Actuar como Muchos Actores
Insert card
Juan como operador
1 2 3
4 5 6
7 8 9
* 0 #
Juan Operador
Juan como
cliente
Cliente
Actores
Actores y los Límites del Sistema
Administrador
ATM
¿Límites del
Sistema?
Sistema
ATM
Sistema del
Cajero
Banco
Caso de Uso
 Describe lo que los actores quieren que haga el sistema.

 Se utilizan para indicar qué es lo que debe hacer el
sistema sin importar cómo se haga.
 Especifican el comportamiento del sistema, indicando
los pasos que el sistema realiza para llegar a un
resultado observable por un actor.
Caso de Uso
Para identificarlos debemos
preguntarnos:
Definir crédito
 ¿Qué funcionalidad requieren Supervisor
los actores del sistema?
 ¿Qué actores crean, leen,
actualizan o eliminan la
Hacer un pedido
información que el sistema
registra? Cliente
Vendedor
 ¿Debe el sistema avisar a un Consultar estado

Consultar
actor acerca de cambios de de pedido
embarques
estado de los objetos? pendientes
 ¿Existe algún evento externo

que el sistema deba conocer?
¿Cuál actor informa al sistema Anular pedido
acerca de este evento?
Despachador
Ejemplos : diagrama de casos de uso
Verificar Situación
Vendedor
Cliente
Establecer Crédito
Supervisor
Venta Normal
Preparar Catálogo
Secretaria
Tipos de Venta Venta en Rebajas

Cliente Vendedor
Venta en Oferta
En el paquete tipos de venta:

Relaciones en los Diagramas de Caso de Uso
Dentro de los diagramas Casos de Uso se
tienen las siguientes relaciones
 Comunicación o asociación (communicates)

 Inclusión o uso <<include>>
 Extensión <<extends>>
 Herencia
Ejemplos
Cliente remoto Giro por Internet
<<extend>>
<<include>>
Identificaciòn Giro Cliente Local
Credito Efectivo
Relaciones de Comunicación (communicate)
Participan un actor y un use case.
Esta es la única relación entre ambos.
Notación:
Caso de Uso
Actor
Hacer un pedido
Cliente
Participa en Use Case

Actor
Relaciones de Inclusión o Uso (Include o Uso)
Casos de uso con
<<Include>>
<<include>>
 Se da entre Casos
de Uso. Origen Destino
 Indica que un Caso
<<include>> reemplazó al denominado <<uses>>
de Uso, puede incluir
la funcionalidad de
otro Caso de Uso Anular pedido
<<include>>
Buscar pedido
dentro de su flujo de
eventos.
Use case utilizador
Incluye el comportamiento Use Case usado

especificado en
En la Figura se muestra cómo el caso de uso Realizar

Reintegro puede incluir el comportamiento del caso de
uso Identificación.
Use Case: Anular Pedido
Ejemplo - Escenario Primario:

1. El cliente solicita anular un pedido
2. El cliente ingresa su código o el número de
pedido
Consultar estado
de pedido 3. Si el cliente ingresó el número de pedido:
a) El sistema presenta el pedido deseado
4. Si el cliente ingresó su código:
Cliente a) El sistema presenta la lista de pedidos
Anular pedido b) El cliente selecciona un pedido de la lista
c) El sistema presenta el pedido seleccionado
5. Si el pedido aun no ha sido despachado:
a) El sistema marca el pedido como anulado
6. Si el pedido ya fue despachado:
a) El sistema presenta las políticas de
devolución de pedidos
Ejemplo Consultar estado

de pedido <<includes>>
Buscar pedido
Cliente
Anular pedido <<includes>>
Use Case: Anular Pedido

- Escenario Primario:
1. El cliente solicita anular un pedido
2. Usar Caso de Uso “Buscar Pedido”
3. Si el pedido aun no ha sido despachado:
a) El sistema marca el pedido como
anulado
4. Si el pedido ya fue despachado:
a) El sistema presenta las políticas de
devolución de pedidos
Relaciones de Extensión (Extend)
Casos de uso
con <<Extend>>
 Se da entre Casos de
Uso.
 Extiende la funcionalidad Origen <<extend>> Destino
de un Caso de Uso: el
Caso de Uso extendido
<<extends>>
puede contener el Hacer un pedido
Descuentos
especiales
comportamiento
especificado en el Caso
de Uso extensor.
Use case extendido
Puede contener el
comportamiento Use Case extensor
especificado en
Notación especial: Puntos de Extensión
Hacer un pedido <<extends>> (Ingreso de item)
Descuentos
Puntos de Extensión:
especiales
Ingreso de ítem
Use Case: Hacer un Pedido

Use Case: Descuentos especiales
Escenario Primario:
Si el ítem ingresado está en la lista de
1. El cliente solicita hacer un pedido
artículos con descuento:
2. El cliente ingresa su código
1. El sistema calcula el descuento del
3. El sistema muestra los datos del
ítem
cliente
2. El sistema calcula el monto total de
4. El cliente ingresa el ítem deseado
descuento
5. El sistema presenta los datos del ítem
3. El sistema muestra el descuento
6. El cliente ingresa la cantidad deseada
7. El cliente acepta el pedido
8. El sistema registra el pedido
En la Figura se muestra como el caso de uso Comprar

Producto permite explícitamente extensiones en el siguiente
punto de extensión: info regalo. La interacción correspondiente
a establecer los detalles sobre un producto que se envía como
regalo están descritos en el caso de uso Detalles Regalo.
Relaciones de Herencia (Generalización –
Especialización )
 En los diagramas use case, también se presenta la herencia:

un Caso de Uso puede heredar el comportamiento de un
Caso de Uso mas general y especializar sus características.
 El Caso de Uso origen hereda la especificación del Caso de

Uso destino y posiblemente la modifica y/o amplía.
Especialización )
Caso de Uso Hijo Caso de Uso Padre
 Ejemplo:
Validar Cliente
Validar huella Validación de

digital de cliente retina de cliente
Especialización )
Los actores también pueden representarse en un esquema de
generalización - especialización.
Cliente
Empresa Persona
Natural
Aplicaciones Prácticas de los Casos de Uso
La Máquina de Café
Control de una máquina de entrega de café automática
 La máquina debe permitir a una persona entregar una cantidad de
dinero en monedas de S/. 0.10, 0.20 o 0.50, 1, escoger uno de los
productos de acuerdo a su precio (café negro, café claro, caldo),
escoger (si es pertinente) un nivel de azucar y entregar el producto y
dar el vuelto
 El dinero que los usuarios introducen se guarda en un recipiente aparte

al disponible para vueltos, el cual se encuentra ordenado por
denominación.
 Existen estados de error de la máquina, cuando detecta un mal

funcionamiento, no existencia de vuelto o no existencia de ingredientes.
 El usuario puede en cualquier momento antes de escoger el azúcar

cancelar la operación, mediante un botón existente para este objetivo.
Aplicaciones Prácticas de los Casos de Uso
Reservas Aéreas
Identifique los actores y dibuje el Diagrama de Casos de Uso que
represente un software que permita realizar la reserva de boletos
de avión en una agencia turística, considerando los siguientes
procesos del negocio:
 Todo cliente debe registrarse en el software antes de reservar (usuario).
 El cliente puede hacer una reserva con un día y hora, para que el sistema
se comunique con el software de la aerolínea deseada a verificar el
estado del vuelo. Si no hay disponibilidad, el cliente puede seleccionar
otro vuelo.
 - El cliente puede cancelar una reserva con 48 horas de anticipación
mínimo al Sistema. Si es así, la reserva se cancela en la aerolínea que se
hizo dejando disponibilidad para otro cliente.
 Un agente de viajes puede realizar la función del cliente en caso de que
sea desde una oficina física, registra al mismo cliente y le entrega una
clave para que se comunique él con el sistema.
Modelar el Contexto del Sistema
Implica definir el ambiente donde
se ejecuta el sistema,
identificando aquello que se Compras Telefónicas
encuentra “dentro” y “fuera” del

mismo. Definir crédito
Supervisor
Pasos: Hacer un pedido

1. Dibujar un cuadrado alrededor
de los use case que forman
parte del sistema Consultar estado
de pedido Vendedor
2. Identificar los actores que
interactúan con él
Anular pedido
3. Organizar estos actores en
estructuras de generalización
Consultar
especialización embarques
pendientes
4. Dibujar las relaciones entre Despachador
los actores y los use case del
sistema.
LENGUAJE DE MODELAMIENTO UNIFICADO
EL SISTEMA DE PUNTO DE VENTA DE SANTA ISABEL
 El caso de estudio es el Sistema de Punto de venta de Santa Isabel. En este
problema, veremos hay requisitos muy interesantes y problemas de diseño que
solucionar.
 Un sistema de Puntos de Venta es una aplicación utilizada para registra ventas y
realizar pagos. Incluye componentes hardware, como un ordenador y un lector de
código de barras, y software para ejecutar el sistema. Interactúa con varias
aplicaciones de servicios, como un servicio de cálculo de impuestos y un control
de inventarios, de terceras partes. Estos sistemas deben ser, relativamente,
tolerantes a fallos; es decir, incluso si los servicios remotos no están disponibles
temporalmente (como el sistema de inventarios), todavía deben ser capaces de
capturar las ventas y gestionar, al menos, los pagos en efectivo (de manera que
no se impida que el negocio funciones de manera adecuada)
 Un sistema de Punto de Venta, debe soportar múltiples y variados terminales e
interfaces del lado del cliente, como por ejemplo: terminal con navegador Web,
ordenador personal normal, entrada de datos mediante pantalla táctil, etc.
 Además, estamos creando un Sistema de Puntos de Venta comercial que se
venderá a diferentes clientes con necesidades dispares en términos de
procesamiento de reglas de negocio. Cada cliente deseará un conjunto exclusivo
de lógica a ejecutar en cientos puntos predecibles en escenarios de uso del
sistema, como cuando se inicia una venta o cuando se añade una nueva línea.
Por tanto, necesitaremos un mecanismo para proporcionar esta flexibilidad y
personalización.
Ejemplo Diagrama de
Contexto -
Sistema de Venta
Santa Isabel Procesar Venta
Servicio de
Autorizaciòn de Pagos
Gestionar Devoluciones
Cajero
Calculador de
Impuestos
Procesar Arquiler
Abrir Caja Sistema de

Contabilidad
GestionarUsurios
Administrador del
Sistema
Sistema de
Gestionar Seguridad RRHH
Casos Especiales
1. Manejo del Tiempo
En algunos sistemas se tienen
actividades que se ejecutan Calcular intereses
periódicamente, como por ejemplo, los

Tiempo
cálculos de intereses de los bancos se
realizan todas la noches. Para modelar
esto se puede realizar lo siguiente:
• Tratar al tiempo como un actor que
inicia el Caso de Uso. Calcular intereses
• Asumir que el tiempo es parte del Empleado

Bancario
sistema, de manera que el Caso de
Uso se ejecuta solo en algún
momento, y definir un actor que
reciba la salida del mismo.
Casos Especiales
2. Requerimientos manejados por Actores
Si algún requerimiento debe ser manejado por algún actor,
hay que revisar el alcance y determinar si el actor debe ser
parte del sistema:
a) Si el actor no es parte del sistema, entonces el requerimiento

tampoco lo es.
b) Si el actor es parte del sistema, hay que revisar el alcance del

sistema y contemplar todos los casos relacionados con este actor
que sean parte de este alcance.
Consejos para un buen Diagrama de Casos de Uso
 Asegurarse que cada caso de uso describe una parte

significativa del funcionamiento del sistema.
 Evitar un número excesivo de casos de uso.
 Un caso de uso no es un paso, operación o actividad
individual es un proceso.
 Un caso de uso describe un proceso completo que incluye
varios pasos.
 Los casos de uso tienen que ser entendibles tanto por
desarrolladores software como por expertos del dominio
 Es una descripción de alto nivel del sistema
 Evitar conceptos de diseño
 Cómo identificar casos de uso:
- A partir de los actores

• Identificar los actores relacionados con el sistema o la
organización
• Para cada actor, identificar los procesos que inician o
en los que participan
- A partir de los eventos

• Identificar los eventos externos a los que puede
responder el sistema
• Relacionar los eventos con actores y casos de uso
 Un caso de uso debe ser simple, inteligible, claro y conciso

 Generalmente hay pocos actores asociados a cada Caso de
Uso
 Preguntas clave:
• ¿cuáles son las tareas del actor?
• ¿qué información crea, guarda, modifica, destruye o lee el
actor?
• ¿debe el actor notificar al sistema los cambios externos?
• ¿debe el sistema informar al actor de los cambios
internos?
Caso Práctico Propuesto
Cajero Automático Portátil
El Banco Sudamericano necesita ayuda para modelar el sistema que
hará funcionar sus nuevos cajeros automáticos portátiles. Éstos, del
porte de un teléfono público, le permitirán al usuario realizar sólo las
operaciones más simples : retirar y consultar saldo (no soportarán
movimientos entre cuentas de otros bancos o compras de tarjetas de
prepago telefónico). Para ello se debe tener en cuenta que:
 Se pide ingresar la clave del usuario posteriormente al paso de la
tarjeta por la ranura.
 No se puede retirar más fondos de los que realmente hay,
notificando de esta situación al usuario.
 Al tercer ingreso de clave no válida se queda decomisada la tarjeta
en la ranura.
 Si al hacer el retiro el saldo no alcanza, se notifica a la central y se
cancela la operación
Realizar el Diagrama de Casos de Uso.

CASOS DE USO

ESPECIFICACION DE UN CASO DE USO
Documentación de los Casos de Uso
 Los casos de uso están

documentados en:
 Una breve descripción : El
propósito del caso de uso en unas
pocas líneas.
 Flujo de eventos detallados :
Descripción del flujo de eventos
primario y alternativo que ocurren
cuando el caso de uso es
iniciado.
 La documentación debe leerse
como un diálogo entre actor y el
caso de uso.
 Deberá estar escrito en términos
que el cliente entenderá.
Documentación de los Casos de Uso
¿Quiénes leen la Documentación de los
Casos de Uso?
 Clientes : aprueban lo que debe hacer el sistema
 Usuarios : obtienen comprensión del sistema
 Desarrolladores del Sistema : Documentan el
comportamiento del sistema.
 Analistas de Sistema (Diseñadores) : proveen la base para
un análisis y diseño.
 “Probador” del Sistema : usado como base para casos de
prueba.
 Líder del proyecto : Provee entradas para el planeamiento
del proyectos.
 Escritor Técnico : base para escribir la guía del usuario.
Plantilla de Casos de Uso
Diagrama <Nombre del Diagrama>
Caso de Uso <Nombre del Caso de Uso>
Objetivo Explica claramente el objetivo del caso de uso. Esta explicación debe comenzar con
un verbo. Por ejemplo: Controlar todos los rechazos…, Reiniciar el tramite….,Informar
la cantidad de mora….
Precondiciones Se debe indicar las condiciones que debe cumplir el servicio para que inicie.
Post Condiciones Establecen qué deben cumplirse cuando el caso de uso se completa con éxito.
Actor Principal y Actor principal: El actor principal que recurre al sistema para cumplir un objetivo.
Actores Esta lista es más importante de lo que podría parecer a primera vista. Sugiere y
Secundarios delimita que es lo que debe hacer el sistema.
Descripción Pasos Acción
1. Describe el camino de éxito típico que satisface los intereses del
personal involucrado.
2.
Extensiones Pasos Indican todos los otros escenarios y bifurcaciones, tanto de éxito
como de fracaso.
1.
Frecuencia Cada cuanto tiempo ocurre el servicio

Requisitos Esto incluye cualidades tales como rendimiento, fiabilidad y facilidad de uso, y
especiales restricciones de diseño (a menudo, en dispositivos de entrada/salida) que son
obligatorios o se consideran probables.
Caso de Uso Primario: Lista de casos de uso que son llamados por el servicio.
Primario y Secundario: Lista de casos de uso que llaman el servicio.
Secundario
Descripción o Extensiones
 Indican los pasos que se siguen dentro de un caso de uso.
 Estos pasos pueden ir por distintos caminos dependiendo de ciertas
condiciones.
 Generalmente se tiene un camino principal y varios caminos
alternos.
 El camino principal se conoce como el escenario primario
(Descripción).
 Este escenario ocurre si todo va bien.
 En caso contrario tenemos los caminos alternativos o escenarios
secundarios (Extensiones).
 Un escenario secundario puede ser visto por un usuario como una
situación anormal, pero desde el punto de vista del sistema, debe
preverse todos los posibles caminos.
 Los escenarios pueden ser presentados como un secuencia de
actividades (texto libre), una secuencia enumerada de actividades, o
como diagramas de actividades.
Ejemplo : Flujo de Eventos Principal
(Descripción)
 El caso de uso comienza cuando el sistema pide al Usuario
un PIN.
 El Usuario puede introducir el PIN por medio del teclado.
 El Usuario acepta la entrada pulsando ENTER. El sistema
comprueba entonces este PIN para ver si es válido. Si el PIN
es válido, el sistema acepta la entrada, y así acaba el caso de
uso.
Ejemplo : Flujo de Eventos Excepcional
(Extensiones)
 El Usuario puede cancelar una transacción en cualquier
momento pulsando el botón cancelar, reiniciando de esa
forma el caso de uso
Ejemplo : Caso de Uso : Validar Cliente
 Descripción: Mediante este caso de uso se autentica a un
cliente.
 Descripción:
1. El sistema solicita la clave del cliente
2. El cliente ingresa la clave y presiona OK
3. El sistema valida la clave
4. Si es correcta reconoce al cliente y termina
 Extensiones:
a) El cliente cancela la transacción presionando el botón de cancelar,
el caso de uso termina.
b) El cliente presiona el botón CLEAR, borra la clave y vuelve a
ingresar otra.
c) El cliente ingresa una clave errónea, el sistema la valida y el caso
de uso se reinicia.
Si esto sucede tres veces seguidas, el cajero cancela la
transacción y deja de funcionar por un minuto.
Pre – Postconditions
 Indican las condiciones del sistema antes de iniciar

un caso de uso (preconditions), así como el estado
en el cual el sistema debe quedar al finalizar el
mismo (postconditions).
 La condición posterior debe ser cierta sin importar

cual camino alternativo se siga en el caso de uso.
Pre – Postconditions
Consideraciones Pre-Postconditions
 Son estados que el usuario puede observar.
 Una precondición es una restricción y no un evento que lo
inicializa.
 Una precondición no es solo para un escenario del caso de
uso.
 Una postcondición para un caso debería ser verdadero sin
importar que flujo se ejecute.
 El caso de uso extendido no introduce un subflujo que viola la
postcondición.
 Postcondiciones pueden ser una herramienta útil para describir
casos de uso.
LENGUAJE DE MODELAMIENTO UNIFICADO
Ejercicio – Revisar el caso de Uso “Procesar
Venta”. El caso de estudio es el Sistema de Punto de venta de Santa
Isabel. En este problema, veremos hay requisitos muy interesantes y problemas
de diseño que solucionar.
 Un sistema de Puntos de Venta es una aplicación utilizada para registra ventas y
realizar pagos. Incluye componentes hardware, como un ordenador y un lector de
código de barras, y software para ejecutar el sistema. Interactúa con varias
aplicaciones de servicios, como un servicio de cálculo de impuestos y un control
de inventarios, de terceras partes. Estos sistemas deben ser, relativamente,
tolerantes a fallos; es decir, incluso si los servicios remotos no están disponibles
temporalmente (como el sistema de inventarios), todavía deben ser capaces de
capturar las ventas y gestionar, al menos, los pagos en efectivo (de manera que
no se impida que el negocio funciones de manera adecuada)
 Un sistema de Punto de Venta, debe soportar múltiples y variados terminales e
interfaces del lado del cliente, como por ejemplo: terminal con navegador Web,
ordenador personal normal, entrada de datos mediante pantalla táctil, etc.
 Además, estamos creando un Sistema de Puntos de Venta comercial que se
venderá a diferentes clientes con necesidades dispares en términos de
procesamiento de reglas de negocio. Cada cliente deseará un conjunto exclusivo
de lógica a ejecutar en cientos puntos predecibles en escenarios de uso del
sistema, como cuando se inicia una venta o cuando se añade una nueva línea.
Por tanto, necesitaremos un mecanismo para proporcionar esta flexibilidad y
personalización.
Caso Práctico
Ejercicio Propuesto
Realizar el diagrama de casos de uso y especificar en la plantilla
pre definida los dos casos de uso mas importantes :
Modela la operación de hacer un pedido a través de Internet de cierto

tipo de productos. Un usuario registrado en la tienda como cliente, una
vez autenticado puede realizar el pedido de uno o más productos. El
sistema muestra los productos disponibles en la tienda y el usuario
selecciona y añade un producto seleccionado a un carro de compras.
En cualquier momento el usuario puede indicar la realización del
pedido con los productos que haya en el carro de compras. En
cualquier momento puede eliminar productos del carro de compras.
Existen distintas formas de pago: tarjeta de crédito, contra reembolso o
mediante transferencia bancaria. Cuando el usuario realiza el pedido
debe indicar la dirección para el envío.

Casos de Uso

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Casos de Uso

Загружено:

Авторское право:

Доступные форматы

DIAGRAMAS DE CASOS DE USO

 Diagramas de Casos de Uso.

 Diagramas de Casos de Uso.

 Es una técnica para capturar

 Un caso de uso representa un

Un buen ejemplo de los casos de uso puede ser el cómo una

El propósito principal del diagrama de casos de uso es

 ¿Quién usa el sistema?

Por ejemplo, si se identificó un actor que se llama Cliente. Una

Un cliente es aquella persona que adquiere

 Describe lo que los actores quieren que haga el sistema.

 ¿Debe el sistema avisar a un Consultar estado

 ¿Existe algún evento externo

Tipos de Venta Venta en Rebajas

En el paquete tipos de venta:

 Comunicación o asociación (communicates)

Cliente remoto Giro por Internet

Participa en Use Case

Incluye el comportamiento Use Case usado

En la Figura se muestra cómo el caso de uso Realizar

Ejemplo - Escenario Primario:

Ejemplo Consultar estado

Use Case: Anular Pedido

Use Case: Hacer un Pedido

En la Figura se muestra como el caso de uso Comprar

 En los diagramas use case, también se presenta la herencia:

 El Caso de Uso origen hereda la especificación del Caso de

Caso de Uso Hijo Caso de Uso Padre

Validar huella Validación de

 El dinero que los usuarios introducen se guarda en un recipiente aparte

 Existen estados de error de la máquina, cuando detecta un mal

 El usuario puede en cualquier momento antes de escoger el azúcar

encuentra “dentro” y “fuera” del

Pasos: Hacer un pedido

Abrir Caja Sistema de

periódicamente, como por ejemplo, los

• Asumir que el tiempo es parte del Empleado

a) Si el actor no es parte del sistema, entonces el requerimiento

b) Si el actor es parte del sistema, hay que revisar el alcance del

 Asegurarse que cada caso de uso describe una parte

 Cómo identificar casos de uso:

- A partir de los actores

- A partir de los eventos

 Un caso de uso debe ser simple, inteligible, claro y conciso

Realizar el Diagrama de Casos de Uso.

 Diagramas de Casos de Uso.

 Los casos de uso están

Frecuencia Cada cuanto tiempo ocurre el servicio

 Indican las condiciones del sistema antes de iniciar

 La condición posterior debe ser cierta sin importar

Modela la operación de hacer un pedido a través de Internet de cierto

Вам также может понравиться