1. Casos De Uso Del Sistema
Lic. César Alcántara Loayza

2. Diagramas de Casos de Uso
 Elementos:
 Sistema
 Actores
 Casos de uso
 Asociaciones
 Dependencias
CAL/Fundamentos

3. Diagrama de Casos de Uso
2
3
1
4
5
Actor_1
Case_2
 1. Actor – Persona, sistema o dispositivo que participa en la operación
exitosa del sistema.
 2. Sistema – Contexto del sistema con relación a los actores que usarán
las características que proveerá.
CAL/Fundamentos

4. Diagrama de Casos de Uso
 3. Caso de Uso – Identifica las
características clave del sistema. Sin estas
características el sistema no cumpliría con
los requerimientos del usuario/actor. Cada
caso de uso expresa una meta que el
sistema debe lograr.
 4. Asociaciones - Identifica interacción
entre casos de uso y actores.
 5. Dependencia – identifica interacción
entre casos de uso. (estereotipo).
CAL/Fundamentos

5. Diagramas de Casos de Uso
 En los diagramas de casos de uso
tanto a las personas, sistemas y
dispositivos se les refiere como actores.
Un actor es un rol que juega una
entidad externa con relación al sistema .
 Típicamente los actores son los sujetos
de la frase que describe como usará el
sistema.
CAL/Fundamentos

6. Límites del Sistema
 Constituido principalmente por los
actores del sistema y sus casos de uso.
CAL/Fundamentos

7. Identificando Actores
 Si modelamos desde el Negocio, los
actores del sistema, serán:
 Los trabajadores del negocio cuyas tareas
sean soportadas por el sistema.
 Los actores del negocio que tengan
soporte directo del sistema.
CAL/Fundamentos

8. Identificando Actores
 ¿quién usa el sistema?
 ¿quién instala el sistema?
 ¿quién arranca el sistema?
 ¿quién mantiene el sistema?
 ¿qué otros sistemas usan el sistema?
 ¿quién obtiene información del sistema?
 ¿quién provee información al sistema?
 ¿Ocurre algo automáticamente?
CAL/Fundamentos

9. Identificando Casos de Uso
 ¿qué funciones necesitará el actor del sistema?
 ¿El sistema almacemará información?, ¿qué
actores la crean, leen, actualizan o borran aquella
información?.
 El sistema necesita notificar a un actor acerca de
cambios en sus estados internos?.
 ¿Existe algún evento externo que el sistema
deba conocer?, ¿qué actor informa al sistema de
aquellos eventos?.
CAL/Fundamentos

10. Actores y Casos de Uso
 Descripción de los actores de Procesamiento de
Ordenes:
 Cliente: una persona que ordena los productos a
National Widgets.
 Representante de Cliente: Un empleado de National
Widgets quien procesa las solicitudes del cliente.
 Compañía de despacho: DHL, FedEx, otras
 Empleado: Un empleado de National Widgets quien
empaca, rotula y despacha ordenes.
 Sistema de Inventario: Software que ratrea el
inventario de la Empresa.
CAL/Fundamentos

11. Actores y Casos de Uso
 En el proceso de identificación y
definición de actores y casos de uso, se
puede determinar los límites del sistema
(fronteras) – lo que esta dentro del
sistema (casos de uso) y lo que está
fuera (actores). Se registra esta
información en un diagrama de casos de
uso.
 Se refina a lo largo del proceso.
CAL/Fundamentos

12. Actores – Rol - Tareas
 Es frecuente modelar los roles en
función a las descripciones de trabajo y
flujos de trabajo, pero las
organizaciones de personas y tareas es
lo que mas cambia. Las cosas que una
persona hace deberían estar separadas
de las asignaciones de trabajo.
CAL/Fundamentos

13. Alcance del proyecto
 Habiendo determinado los límites del
sistema, se puede establecer el
alcance del proyecto.
 Un proyecto tiene una fecha de inicio y un
final y dinero para gastos que cubran las
metas del proyecto.
 Se debería priorizar los requerimientos.
CAL/Fundamentos

14. Requerimientos MoSCoW
 Algunos requerimientos se deben satisfacer,
los procesos básicos del sistema. Requeridos
ó Must Have.
 Otros son importantes pero no vitales –
Importantes o Should Have.
 Otros podrían ser bonitos tenerlos – Bonitos o
Could Have.
 El resto son sueños – Futuros ó Would Like to
Have.
 MoSCoW
CAL/Fundamentos

15. Requerimientos FURPS+
Existen muchas clases diferentes de requerimientos.
Una forma de categorizar es descrita por el modelo
FURPS+, Utilizando el acrónimo FURPS para
describir las categorías principales de requerimientos
con subcategorías como se muestra:
• Funcionality (funcionalidad)
• Usability (Facilidad de uso)
• Reliability (Confiabilidad)
• Performance, (Rendimiento) y
• Supportability (Soporte)
CAL/Fundamentos

16. Requerimientos FURP+
El "+" en FURPS+ le ayuda a recordar que también
incluye otros requerimientos como:
• Restricciones de diseño,
• Requerimientos de implementación,
• Requerimientos de interface y
• Requerimientos físicos.
CAL/Fundamentos

17. Dibujando Diagramas CUS
 Comenzar dibujando el sistema;
provienen del contexto definido del
proceso (casos de uso del negocio)
 Adicionar actores al diagrama para
representar los roles que los usuarios
humanos juegan en relación al sistema.
 Adicionar el rotulo del nombre del actor
 Adicionar otro actor, puede ser un
sistema.
CAL/Fundamentos

18. Dibujando Diagramas CUS
 Los casos de uso definen las características
requeridas por el sistema. Sin tales
características el sistema no podría tener
éxito.
 Denomine cada Caso de Uso con una frase
con Verbo que exprese el objetivo del sistema
que se debe cumplir, ejem. Depositar dinero,
prestar dinero, ajustar cuenta. Aunque cada
uno de ellos implica un proceso de soporte, el
enfoque está en el objetivo no en el proceso .
CAL/Fundamentos

19. Dibujando Diagramas CUS
 Al definir los CUS de esta forma, el
sistema es definido como un conjunto
de requerimientos en vez de una
solución. No se describe como hace el
sistema, se describe lo que el sistema
es capaz de hacer. Describe solo
aquellas características visibles y
significativas a los actores quienes
usarán el sistema.
CAL/Fundamentos

20. Dibujando Diagramas CUS
 Esto ayuda a evitar la descomposición
funcional, partir procedimientos y tareas
en procesos mas y mas pequeños
hasta tener descritos todo el
comportamiento interno del sistema.
CAL/Fundamentos

21. Asociaciones y Dependencias
 Una asociación se representa por una
línea que conecta a un actor con un
caso de uso. Con flecha o sin flecha.
 Lo importante es identificar que casos
de uso necesita acceder el actor.
CAL/Fundamentos

22. Asociaciones y Dependencias
 En ciertos casos un caso de uso necesita
de otro; para lo cual se usa una relación
de delegación a través de un estereotipo
<<include>>
 Un estereotipo funciona como un
calificador sobre un elemento del modelo,
dando mas información acerca del
elemento sin ver su implementación.
CAL/Fundamentos

23. Asociaciones y Dependencias
 <<include>> un caso de uso siempre buscará
la ayuda de otro caso de uso. Ejecución
incondicional.
 <<extends>> un caso de uso buscará ayuda
de otro caso de uso si se encuentra una
condición específica. Ejecución condicional.
CAL/Fundamentos

24. Descripción Narrativa de CUS
 Los diagramas son muy concisos para
describir lo que el usuario espera.
 La mayoría de descripciones narrativas
de Casos de Uso incluyen lo siguiente:
 Supuestos: condiciones que deben probar
ser ciertas para usar el caso de uso. Se
colocan normalmente en un documento de
overview en vez de incluirlos en cada CU.
CAL/Fundamentos

25. Descripción Narrativa de CUS
 Precondiciones: Condiciones que deben
ser ciertas para usar el caso de uso. A
diferencia de los supuestos estos deben
ser probados por el caso de uso antes de
hacer algo. Si la condición no es cierta no
se permite que el actor u otro caso de uso
lo ejecute.
 Proceso: Descripción paso a paso del
dialogo entre el caso de uso (sistema) y el
usuario (actor u otro caso de uso). ....
CAL/Fundamentos

26. Descripción Narrativa de CUS
 ... Frecuentemente es útil modelar la
secuencia de eventos usando un diagrama
de actividad.
 Post-Condiciones: Condiciones que deben
ser ciertas cuando el caso de uso finaliza.
Debe garantizar que el sistema es estable
cuando el caso de uso finaliza.
CAL/Fundamentos

27. Descripción Narrativa de CUS
 Una buena pregunta que debemos
hacer es:
 ¿Cómo puedo usar el modelo de casos de
uso para determinar los requerimientos del
flujo de trabajo y las pantallas?.
CAL/Fundamentos

28. Ejemplo
 Nombre Retiro de Efectivo
 Número 11.0
 Autor Joe
 Ultima actualización 01/04/03
 Supuestos El usuario ha proporcionado
una tarjeta y password válidos.
 Precondiciones: El usuario proporciona una
cantidad válida de retiro (notar que esta es la
primera prueba ejecutada por el dialogo).
CAL/Fundamentos

29. Ejemplo
 Descripción del Caso de Uso:
 Inicialización: El caso de uso se inicia sobre
demanda.
 Dialogo del Caso de Uso:
 El sistema pregunta por la cantidad de retiro.
 El usuario proporciona el monto.
 La maquina ATM (cajero) verifica que la cantidad esté
dentro de los límites permitidos y si es divisible por la
denominación definida, ej. Multiplos de $20. Si la
cantidad no cumple estos requerimientos, el usuario
recibe un mensaje de error.
CAL/Fundamentos

30. Ejemplo

De otro modo el ATM intenta conectarse con el
banco.

Si la conección no tiene éxito el usuario recibe
un mensaje de error.
 Si se dispone de fondos, elt ATM le dá al
usaurio su dinero e imprime una boleta.
 Si no se dispone de fondos, el usuario recibe
un mensaje de error.
CAL/Fundamentos

31. Ejemplo
 Finalización del caso de uso:
 El caso de uso finaliza cuando:
 El sistema entrega el dinero e imprime la
boleta.
 El sistema muestra el mensaje de error
indicando que el monto es inválido.
 El sistema muestra el mensaje de error
indicando que no se puede conectar con el
banco.
 El usuario cancela la transacción.
CAL/Fundamentos

32. Ejemplo
 Post_Condiciones:
 Al termino éxitoso del retiro:
 El sistema imprime el saldo final sobre la
boleta:
 La cuenta bancaria es actualizada.
 La transacción es concluida
 Bajo una condición de error, el ATM regresa a
su estado inicial.
 Bajo una opción de cancelación, el ATM
regresa a su estado inicial.
CAL/Fundamentos

33. Plantilla
CAL/Fundamentos

34. Guías
 Resista la tentación de tener mucho detalle,
se añadirá detalle mas adelante en el
proceso, estamos colectando requerimientos
no haciendo el análisis y diseño detallado .
 El escenario necesita estar completo – se
debe ser claro en los puntos de inicio y
finalización - y estar seguro que la lista de
pasos cubre en general todo lo que necesita
para describir la funcionalidad del caso de
uso.
CAL/Fundamentos

35. Guías
 Tendremos un gran porcentaje de casos de
uso que comienzan y terminan con un actor.
 Pueden existir un número pequeño de casos
de uso que empiecen con el actor y terminen
internamente.
 Los escenarios son escritos desde el punto
de vista del actor. Por lo tanto todos los
pasos en sus escenarios deberian ser
visibles a /o por el actor.
CAL/Fundamentos

36. Guías
 Los escenarios son herramientas de
comunicación – Son efectivos solo cuando
pueden comunicar información acerca del
trabajo del sistema.
 Importante considerar quien leerá los
escenarios – si no los entiende deberían
rehacerse.
 Verificar en cada escenario primario uno por
uno y preguntarse para cada paso ¿qué es lo
mas probable que ocurra aquí? – esto es que
debería escribir para este paso particular.
CAL/Fundamentos

37. Guías
 Incluir suficiente información en los
escenarios para ser capaz de determar
si un caso de uso particular maneja una
funcionalidad particular.
CAL/Fundamentos

38. Escenarios de Casos de Uso
 Los casos de uso identifican objetivos
primarios del sistema. Cuando un actor
intenta alcanzar un objetivo usando el
sistema, existen decisiones o reglas que
podrían variar el resultado
 Cada posible resultado de un intento de
alcanzar un objetivo es llamado escenario.
Un escenario es una única ruta lógica através
de un dialogo de un caso de uso.
CAL/Fundamentos

39. Escenarios de Casos de Uso
 Generalmente es preferible utilizar los
diagramas de actividad para definir los
escenarios. Es ejecutar el caso de uso.
 Un escenario es la ejecución particular
de un caso de uso, frecuentemente
usado como un caso de prueba
CAL/Fundamentos

40. Ejercicio
 Para el ejercicio Realizar Ordenes
 Hacer la Realización de CUN.
 Derivar CUS a partir del modelo CUN.
 preparar descripciones narrativas de cada
CUS, usando los cuatro elementos
básicos:
 Precondiciones
 Diálogo y
 Postcondiciones
CAL/Fundamentos

41. Ejercicio Realizar Ordenes
 Declaración del problema:
 Recepción

El empleado de recepción recibe los embarques
que ingresan emparejando las ordenes de
compra contra el stock del embarque. Ellos
informan al departamento de cuentas por pagar
cuando los artículos de la orden de compra se
han recibido.
 Almacenes
 El stock puede provenir de ordenes canceladas,
ordenes regresadas y embarques recibidos. El
CAL/Fundamentos

42. Ejercicio

..stock es colocado en el almacen en ubicaciones
predefinidas. El empleado de stock busca la ubicación
correcta para el nuevo stock, coloca el stock en la ubicación
y actualiza el inventario con la ubicación y cantidad.
 Ejecución de la orden

Otros empleados cubren ordenes localizando el stock
necesario para la orden. A medida que cubren la orden
actualizan el inventario para reflejar el hecho que ellos han
tomado stock. Ellos también notifican al departamento de
procesamiento de ordenes que la orden ha sido completada.
CAL/Fundamentos

43. Ejercicio
 Despacho

Cuando las ordenes se han completado son
empacadas y preparadas para el despacho.
Los empleados de despacho contactan a
despachadores para realizar las entregas y
actualizan el inventario para regostrar el hecho
de que los ya se han despachado los
productos. Ellos también notifican al
departamento de procesamiento de ordenes
que la orden fue despachada.
CAL/Fundamentos

44. Business Systems
CAL/Fundamentos

45. Actores
 Cliente : es el comprador
 Proveedor : quien suministra mercaderías
a la empresa através de embarques.
 Cuentas por Pagar: es a quien se notifica
cuando los artículos han llegado al
almacén.
 Despachador: en el caso de tratarse de
terceros subcontratados para hacer el
reparto de la mercadería.
CAL/Fundamentos

46. Trabajadores
 Empleado de stock
 Empleado de recepción
 Empleador de despacho
CAL/Fundamentos

47. Diagrama De CUN
CAL/Fundamentos

48. Especificación CUN
 Despacho de Ordenes
1. El Cun empieza cuando los empleados
atienden las ordenes del cliente
localizando el stock necesario.
2. El negocio actualiza el stock y notifica al
departamento de procesamiento de
ordenes que la orden está completa.
3. Se empaca y despacha la orden y se
notifica que la orden está despachada.
CAL/Fundamentos

49. Especificación CUN
 Flujos Excepcionales (alternativos)
1. No se localiza stock.
2. Demora en la actualización de stock
3. Demora en el empaque y despacho.
CAL/Fundamentos