bueno caso uso

1. Unidad de Aprendizaje: Programación
Avanzada
Elaborado por: M. En T. I. Rafael Valentín Mendoza
Méndez
UNIVERSIDAD AUTÓNOMA DEL ESTADO DE
MÉXICO
CENTRO UNIVERSITARIO UAEM
TEMASCALTEPEC
MAESTRÍA EN CIENCIAS DE LA COMPUTACIÓN

2. Objetivo
 Al término del curso el alumno aplicará la
programación Orientada al Objeto, a través del uso
del Lenguaje Unificado de Modelado (UML) y el
Lenguaje de programación Java, con la finalidad de
resolver problema de Sistemas reales. Considerando
los paradigmas de Programación: lógica funcional,
paralela, distribuida y orientada a agentes.

3. Contenido Básico III.
Modelación UML
Tema: CASOS DE USO

4. Casos de Uso:
Introducción
 Es una colección de diagramas y texto que juntos
documentan como los usuarios esperan interactuar
con el sistema.
 Los casos de uso se centran en los factores críticos
de éxito, en términos de la funcionalidad que los
usuarios necesitan para interactuar.

5. Casos de Uso: Objetivo
 La diferencia entre los Casos de Uso y el diseño
funcional es el foco. El diseño funcional documenta
un proceso, los casos de uso la meta del proceso.
 Centrarse en procesos, a menudo reproduce sistemas
existentes, ya que nos centramos en el “como” y no
en el “porque” y en el “que”.

6. Recursos del modelo de Casos de
Uso
Nombre
Suposiciones
Pre-condiciones
Diálogo
Post-condiciones
Excepciones
Mejoras futuras
Diagrama de Casos de Uso
Narrativa de los
Casos de Uso
Escenario de los
Casos de Uso

7. Diagrama de Casos de
Uso
 La meta del diagrama es proporcionar una
explicación de la relación del sistema y el mundo
exterior.
 Por ejemplo en el caso de un cajero el diagrama
del Caso de Uso puede corresponder a la
pantalla principal y el menú disponible: retiro,
consulta de saldo, etc. Cada una de estas
opciones puede representarse como un Caso de
Uso separado. El cliente (fuera del sistema) está
asociado con cada uno de los Casos de Uso
(dentro del sistema) que planea usar.

8. Elementos del Diagrama
Sistema
Dependencia
Generalización
Asociación
Actor
Caso de Uso

9. Elementos del Diagrama
 Sistema: Establece el límite del sistema en relación con los
actores que lo van a usar.
 Actor: Es un rol que puede jugar una persona, otro sistema,
ó un dispositivo.
 Caso de Uso: Identifica una característica clave del sistema,
expresa una meta que el sistema debe lograr.
 Asociación: identifica la asociación entre actores y Casos de
Uso. Cada asociación es un diálogo que debe explicarse
con la narrativa del Caso de Uso.
 Dependencia: Identifica una comunicación entre dos Casos
de Uso.
 Generalización: Define una relación entre dos actores ó
entre dos Casos de Uso, cuando uno de los casos hereda
las propiedades del otro.

10. Sistema en el Caso de
Uso
 Que tanto incluiremos en el sistema?
 Como se relaciona este sistema con otros?
 Quien va a usar este sistema?
 Un sistema es como un objeto con un propósito y con
interfases, la implementación interna puede cambiarse
sin afectar otras entidades, mientras el propósito y las
interfases no cambien.
 El propósito es la meta de la justificación del proyecto.
 Las interfases son los canales de comunicación entre
los actores fuera del sistema y las características del
sistema en sí: los Casos de Uso.

11. Actores en el Caso de Uso
 Usuarios: personas, sistemas o dispositivos
 Actor: rol que juega una entidad externa en
relación al sistema.
 Los actores normalmente son los sujetos en las
oraciones que describen como la gente usa los
sistemas.
 Es mejor utilizar roles
ya que permite centrarse
en como el sistema será
usado y no en puestos de
trabajo.
SISTEMA RH

12. Casos de Uso
 Definen las características requeridas por el sistema.
 Son nombrados usando una frase (verbo), expresando
la meta que debe cumplir el sistema.
 A pesar de que cada Casos de Uso soporta un proceso,
éstos se centran en la meta, no en el proceso
Retiro de
Efectivo
Actualización
de Cuenta

13. Continuación Casos de
Uso
 Definiendo los Casos de Uso de esta forma, el sistema se
especifica como un juego de requerimientos más que una
solución. No se dice como trabaja el sistema, sino lo que
debe ser capaz de hacer.
 Los Casos de Uso describen solo aquellas características
que son visibles y significativas para los actores que
usaran el sistema. Esto evita el hacer una descomposición
funcional.
 En conclusión: Modelar solo las características del sistema
que pueden ser vistas por un actor.
 Por ejemplo, si un sistema debe guardar datos en una
base de datos, solo se debe ilustrar el mensaje que indica
que los datos se guardaron, no como se guardan.

14. Asociaciones en los Casos de
Uso
 Se representan con una línea conectando un actor a
un Caso de Uso
 Pueden ser bidireccionales o unidireccionales.
Consulta de
saldo
Retiro de
efectivo
Asociación

15. Estereotipos
 Los estereotipos se usan en UML en los Casos de Uso,
clases y paquetes.
 Notación <<include>>: Cuando un Caso de Uso
necesita ayuda de otro Caso de Uso, la dependencia se
dibuja con una flecha punteada hacia el caso que será
“usado”. Es una subrutina o llamada a función.
 Notación <<extend>> indica que un Caso de Uso
puede necesitar ayuda de otro Caso de Uso, contrario
al include donde siempre la necesita.
Retiro
efectivo
Retiro
efectivo con
protección
Actualizar
cuenta
Protección por
falta fondos
<<include>>
<<extend>>

16. Generalización
 La herencia indica que un objeto tiene desde el
momento de su creación, acceso a todas las
propiedades de otra clase.
 Esto mismo se aplica a los actores y a los Casos de
Uso, se conoce como generalización y a veces se
especifica con una relación “es un”
Autorización
Cargo
Autorización
Cargo, con
Aviso al celular

17. Caso de Estudio: Construcción del
Diagrama de Caso de Uso
Fuente de información para poder construir el Caso de Uso:
Receiving, Stocking, Order fulfillment, Shipping.
Paso 1: Establecer el contexto del sistema meta. El contexto
define la ubicación del sistema dentro del negocio,
incluyendo procesos, planes y objetivos de negocio, otros
sistemas, gente y sus obligaciones en el trabajo,
restricciones impuestas por entidades externas.
De acuerdo con el problema, los participantes:
..informan al departamento de Cuentas
…notifican al departamento de Procesamiento de Ordenes
…contactan a los embarcadores
El contexto ubica al sistema dentro del las operaciones de la
bodega, trabaja con las órdenes, con cuentas por pagar y
con los que embarcan.

18. Paso 2: Identificar a los
actores
receptor almacenista inventarios surte
<<Actor>>
SistemaCuentas
Por Pagar
<<Actor>>
SistemaProcesa-
miento Ordenes

19. Paso 3: Identificar los casos de
Uso
Encontrar las características o la funcionalidad que
el sistema debe proporcionar con preguntas
como:
 ¿Qué produce el sistema para el actor? Ayuda a
identificar salidas críticas.
 ¿En que ayuda el actor al sistema) Facilita
conocer las entradas críticas.
 ¿En que ayuda el sistema al actor? Identifica las
reglas que deben aplicarse cuando el actor usa el
sistema.

20. Casos de uso
identificados
 RecibirProducto “…receive incoming
shipments….and updates inventory…”
 AlmacenarProducto “…looks up the correct
location …”
 LlenarOrden “..Other staff members fill orders …
update inventory …”
 LocalizarProducto “…locating the products
required …. “
 EmbarcarOrden “….order has shipped and
updates inventory…”

21. Paso 4: Definir las asociaciones
entre actores y Casos de Uso
LlenarOrden
EmbarcarOrden
RecibirProducto
AlmacenarProducto
Receptor
Encargado
de
Inventarios
Otros
Encargado
embarques
<<Actor>>
SistemaCuentas
Por Pagar
<<Actor>>
SistemaProcesa-
miento Ordenes
LocalizarProducto

22. Paso 5: Evaluar los actores y
Casos de Uso
 Renombrar, mezclar, dividir actores y Casos de Uso
cuando sea necesario.
 Preguntarse: ¿Por qué este actor es responsable de
estas tareas?
 ¿Por qué estas tareas se dan juntas, separadas ó en
este orden?
 En el ejemplo hay que verificar si el Receptor y el
Encargado de Inventarios son una misma persona

23. Evaluar los casos de Uso para
dependencias tipo <<include>
 Se aplica cuando un Caso de Uso siempre
llama a otro para que lo ayude con una tarea.
 En el ejemplo, “Actualizar inventarios” es un
requerimiento para AlmacenarProducto,
LlenarOrden y para EmabarcarOrden
EmbarcarOrden
LlenarOrden
AlmacenarProducto
ActualizarInventario
<<include>>
<<include>>
<<include>>

24. Evaluar los casos de Uso para
dependencias tipo <<extend>
 Un Caso de Uso puede o no usar otro Caso de Uso
dependiendo de una cierta condición. Cuando la
condición se cumpla se llama al otro Caso de Uso, sino,
no se llama.
 Si en el ejemplo se quisiera aumentar un producto en el
inventario sin tenerlo que colocar en una de las
ubicaciones predefinidas, sin tener que pasar por el
Caso AlmacenarProducto. El Caso RecibirProducto
tendría que solicitar permiso para llamar
ActualizarInventario.
RecibirProducto ActualizarInventario
<<extend>>

25. Evaluando actores y los Casos de
Uso para Generalización
 El problema dice “The products may come
from cancelled orders, returned orders, or
vendor shipments.” Si las reglas de
almacenaje son distintas para los varios tipos
de entrada, se puede usar generalización en
el Caso de Uso AlmacenarProducto
AlmacenarProd
Regresado
AlmacenarProd
Nuevo
AlmacenarProd
Cancelado
AlmacenarProd

26. Asociaciones
 1) Entre el Receptor y RecibirProducto. “The receiving
clerks receive incoming shipments…” y entre
RecibirProducto y SistemasCuentas por Pagar

27. Narrativa del Caso de
Uso
 Es una descripción del Caso de Uso, que se
refiere a la comunicación entre el Caso de Uso y
el usuario, que puede ser un actor u otro Caso de
Uso. Una narrativa debe incluir:
 Suposiciones: Describen el estado del sistema que
debe ser verdadero antes de que se pueda usar el
Caso de Uso. Estas condiciones no se prueban para el
Caso de Uso. Por ejemplo, autenticación y
autorización en un sistema, un sistema típico soporta
estas funciones. Cada Caso de Uso subsecuente
supone que el usuario no puede acceder si no ha
pasado por el chequeo de seguridad, por lo que no
tendremos que incluir en cada Caso de Uso la
verificación de la seguridad.

28.  Precondiciones: A diferencia de las suposiciones, estas
condiciones si son probadas por el Caso de Uso, si no son
verdaderas, no se puede continuar. Estas reglas deben
conocerse, por ejemplo si se le pide a un cliente proporcionar
un password, debe decirle exactamente como debe estar
formado.
 Iniciación del Caso de Uso: Hay que definir que va a iniciar el
caso, sobre todo cuando éste se va a reutilizar y/o ser utilizado
por varios actores.
 Diálogo: Es una descripción paso a paso de la conversación
entre el Caso de Uso (el sistema) y el usuario (un actor ú otro
Caso de Uso). A menudo es útil modelar esta secuencia de
eventos con un diagrama de Actividades. Por ejemplo si
quieres sacar dinero de un cajero: Una vez que se pasó el
Caso de Uso de seguridad y se tiene el menú de opciones,
seleccionar “Retiro efectivo”. El sistema preguntará cuanto
quieres sacar. Hay que escribir la cantidad en pesos, si se
rebasa el permitido, el sistema dará un mensaje de error o bien
si se pide una cantidad que no sea múltiplo de los billetes que
maneja el cajero. Si se cumplen las restricciones del cajero, se
obtendrá el dinero.

29.  Terminación del Caso de uso: Puede haber varias
formas de terminar un caso de uso, por ejemplo si todo
va por buen camino el caso de uso llegará a su fin
normalmente, si no es así tendrá un fin diferente, un
mensaje de error, una cancelación, etc.
 Post-condiciones: Describen un estado del sistema que
debe ser verdadero cuando el Caso de Uso termina. A
veces se usa el término “garantizar”, por ejemplo al final
de una transacción, exitosa o fallida, debemos notificar al
usuario el estado de la transacción.

30. Narrativa para el caso en estudio
 Usaremos el caso LlenarOrden: básicamente este es
el punto principal del negocio: personal autorizado
toma un Producto del inventario de acuerdo a la
especificación de la Orden. Actualiza la orden y el
inventario. Si no hay alguno de los ítems, se crea una
backorder.

31.  Suposiciones: El personal debe estar autorizado,
por lo que supondremos que la seguridad está
soportada por otro Caso de Uso (ValidarAcceso) y
que se hace en forma confiable y correcta.
Suposición Usuario válido con permiso
 Precondiciones: El problema dice “Other staff
members fill orders by locating the products
required…”, si el número de orden ó el de los
productos no son válidos, no podrá continuar
Precondición Dar un número de orden válido

32.  Iniciación Caso de Uso: Describir como se inicia el diálogo con el
caso.
Iniciación El Caso inicia por demanda
 Diálogo: Se requiere interacción entre el usuario y el sistema.
Diálogo
El sistema pide un número de orden
El usuario lo proporciona
El sistema busca la orden, sino encuentra se detiene, si lo encuentra
proporciona la orden al usuario.
El usuario selecciona un ítem y el sistema lo busca, si está disponible, el
usuario da la cantidad.
Si hay algún ítem que no se tuvo se hace una backorder, utilizando el Caso de
Uso CrearBackOrder

33.  Terminación Caso de Uso:
Terminación El usuario puede cancelar
El Caso de Uso puede exceder tiempo
El usuario puede dejar la orden a la mitad
El usuario puede terminar todos los ítems
 Poscondiciones:
Poscondiciones Fin normal: Los cambios en la orden
deben salvarse, si se creó una BackOrder
debe soportarse por el Caso de Uso
correspondiente.
Cancelación: La Orden debe salvarse sin
cambios. Si se creó una BackOrder debe
cancelarse.

34. Escenarios en los Casos de Uso
 Un Caso de Uso identifica una meta primaria de
un sistema. Cuando un actor trata de completar
la meta usando el sistema, usualmente habrá
decisiones y reglas que pueden influir la salida.
 Un escenario es un camino lógico de un Caso de
Uso.
 Se construyen a partir de la narrativa.
 Empiezan a revelar los trabajos internos del
sistema y las expectativas de los usuarios.

35. Como dibujarlo
 Iniciar con el camino que se considera correcto,
ya que es el más fácil de entender.
 Trazar los pasos hasta que se llega a una
decisión (diamante).
 Tomar una decisión y continuar con los pasos,
hasta el fin. Es escenario 1.
 Regresar hasta el punto de decisión y trazar la
segunda rama.
 Repetir el proceso hasta tener trazados cada
segmento del diagrama.

36. Escenarios para el Caso de Uso:
SurtirOrden (FillOrder)
Diálogo
El sistema pide un número de orden
El usuario lo proporciona
El sistema busca la orden, sino encuentra se detiene, si lo
encuentra proporciona la orden al usuario.
El usuario selecciona un ítem y el sistema lo busca, si
está disponible, el usuario da la cantidad.
Si hay algún ítem que no se tuvo se hace una backorder,
utilizando el Caso de Uso CrearBackOrder

37. Pedir
Num Orden
Dar
Num Orden
Se encontró la
Orden?
si
no
Se traza el escenario
hasta el primer
punto de decisión

38. Pedir
Num Orden
Se encontró
la
Orden?
no
Escenario 1
Dar
Num Orden
Dar la
Cantidad
Selecciona
Item
Buscar
Item
Desplegar
Orden
Se encontró
el Item?
si
no
si
Actualiza
Inventario
no
si
Quedan
Items en la Orden?
I
II I’
II’

39. Pedir
Num Orden
Se encontró
la
Orden?
no
Dar
Num Orden
Mensaje de
error
si
Escenario 2

40. Pedir
Num Orden
Se encontró
la
Orden?
no
Dar
Num Orden
Selecciona
Item
Buscar
Item
Desplegar
Orden
Mensaje de
error
Se encontró
el Item?
si
no
si
Crear
BackOrder
Escenario 3

41. Pedir
Num Orden
Se encontró
la
Orden?
Dar
Num Orden
Dar la
Cantidad
Selecciona
Item
Buscar
Item
Desplegar
Orden
si
Actualiza
Inventario
no
si
Quedan
Items en la Orden?
Escenario 4
Se encontró
el Item?

42. Resumiendo…
 Las narrativas explican en detalle como esperan los
usuarios interactuar con el sistema.
 Los escenarios proporcionan un análisis detallado de
cada posible salida del Caso de Uso.
 Los escenarios pueden usarse para desarrollar un
plan de pruebas.

43. Pedir
Num Orden
Se encontró
la
Orden?
no
Escenario 1
Dar
Num Orden
Dar la
Cantidad
Selecciona
Item
Buscar
Item
Desplegar
Orden
Mensaje de
error
Se encontró
el Item?
si
no
si
Actualiza
Inventario
no
si
Quedan
Items en la Orden?
Crear
BackOrder
Escen 2
Escenario 3
Escenario 4

44. Pedir
Num Orden
Dar
Num Orden
Se encontró la
Orden?
si
no
Se traza el escenario
hasta el primer
punto de decisión

45. Bibliografía