Casos De Uso Del Sistema

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

3. Diagrama de Casos de Uso • 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á.

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).

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.

6. Límites del Sistema • Constituido principalmente por los actores del sistema y sus casos de uso.

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.

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?

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?.

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.

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.

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.

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.

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

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)

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 interfase y • Requerimientos físicos.

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.

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.

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.

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.

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.

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.

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.

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.

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). ....

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.

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?.

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).

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.

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.

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.

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.

33. Plantilla

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.

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.

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.

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.

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.

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

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

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

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.

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.

44. Business Systems

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.

46. Trabajadores • Empleado de stock • Empleado de recepción • Empleador de despacho

47. Diagrama De CUN

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

49. Especificación CUN • Flujos Excepcionales (alternativos) • No se localiza stock. • Demora en la actualización de stock • Demora en el empaque y despacho.