Sunteți pe pagina 1din 52

DIAGRAMAS DE CASOS DE USO

 Diagramas de Casos de Uso.


 Especificación de un Caso de Uso.
DIAGRAMAS DE CASOS DE USO

 Diagramas de Casos de Uso.


 Especificación de un Caso de Uso.
DIAGRAMAS DE CASOS 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.
DIAGRAMAS DE CASOS DE USO
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.
DIAGRAMAS DE CASOS DE USO
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.
DIAGRAMAS DE CASOS DE USO
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.
DIAGRAMAS DE CASOS DE USO

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
DIAGRAMAS DE CASOS DE USO
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
DIAGRAMAS DE CASOS DE USO
Elementos de un Diagrama de Casos de Uso
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
DIAGRAMAS DE CASOS DE USO
Elementos de un Diagrama de Casos de Uso
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
DIAGRAMAS DE CASOS DE USO
Elementos de un Diagrama de Casos de Uso
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
DIAGRAMAS DE CASOS DE USO
Elementos de un Diagrama de Casos de Uso
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
DIAGRAMAS DE CASOS DE USO
Elementos de un Diagrama de Casos de Uso
Actores
Actores y los Límites del Sistema

Administrador
ATM
¿Límites del
Sistema?
Sistema
ATM

Sistema del
Cajero
Banco
DIAGRAMAS DE CASOS DE USO
Elementos de un Diagrama de Casos de Uso
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.
DIAGRAMAS DE CASOS DE USO
Elementos de un Diagrama de Casos de Uso
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
DIAGRAMAS DE CASOS DE USO
Elementos de un Diagrama de Casos de Uso
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:


DIAGRAMAS DE CASOS DE USO
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
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
Ejemplos

Cliente remoto Giro por Internet

<<extend>>

<<include>>
Identificaciòn Giro Cliente Local

Credito Efectivo
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
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
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
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
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
Relaciones de Inclusión o Uso (Include o Uso)

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


Reintegro puede incluir el comportamiento del caso de
uso Identificación.
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
Relaciones de Inclusión o Uso (Include o Uso)
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
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
Relaciones de Inclusión o Uso (Include o Uso)

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
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
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
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
Relaciones de Extensión (Extend)
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
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
Relaciones de Extensión (Extend)

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.
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
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.
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
Relaciones de Herencia (Generalización –
Especialización )

Caso de Uso Hijo Caso de Uso Padre

 Ejemplo:
Validar Cliente

Validar huella Validación de


digital de cliente retina de cliente
DIAGRAMAS DE CASOS DE USO
Relaciones en los Diagramas de Caso de Uso
Relaciones de Herencia (Generalización –
Especialización )
Los actores también pueden representarse en un esquema de
generalización - especialización.

Cliente

Empresa Persona
Natural
DIAGRAMAS DE CASOS DE USO
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.
DIAGRAMAS DE CASOS DE USO
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.
DIAGRAMAS DE CASOS DE USO
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
Modelar el Contexto del Sistema
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.
DIAGRAMAS DE CASOS DE USO
Modelar el Contexto del Sistema
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
DIAGRAMAS DE CASOS DE USO
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.
DIAGRAMAS DE CASOS DE USO
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.
DIAGRAMAS DE CASOS DE USO
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
DIAGRAMAS DE CASOS DE USO
Consejos para un buen Diagrama de Casos de Uso

 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
DIAGRAMAS DE CASOS DE USO
Consejos para un buen Diagrama de 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?
DIAGRAMAS DE CASOS DE USO
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

 Diagramas de Casos de Uso.


 Especificación de un Caso 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á.
ESPECIFICACION DE UN CASO DE USO
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.
ESPECIFICACION DE UN CASO DE USO
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
ESPECIFICACION DE UN CASO DE USO
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.
ESPECIFICACION DE UN CASO DE USO
Descripción o Extensiones
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.
ESPECIFICACION DE UN CASO DE USO
Descripción o Extensiones
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
ESPECIFICACION DE UN CASO DE USO
Descripción o Extensiones
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.
ESPECIFICACION DE UN CASO DE USO
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.
ESPECIFICACION DE UN 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
Modelar el Contexto del Sistema
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.
ESPECIFICACION DE UN CASO DE USO
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.