Curso de Metodología de Análisis y Diseño - Cap 4

1. Análisis y UML “ Fundamento de los Casos de Uso” Metodologías de Análisis y Diseño Unidad IV Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática

2. UML: Fundamentos de los modelos de Caso de Uso Fueron presentados por primera vez por Jacobson a principios de los 90. Los casos de uso documentan el comportamiento del sistema (acción y reacción) desde el punto de vista del usuario. Como <<usuario>> se entiende cualquier cosa que ajena al sistema se desarrolla y que interactúa con el mismo (persona, sistema de información, dispositivos de hardware, etc.). El modelado de caso de uso ayuda con tres de los aspectos más difíciles del desarrollo: La captura de requisitos, La planificación de las iteraciones del desarrollo, La validación de los sistemas.

3. UML: Fundamentos de los modelos de Caso de Uso Definición: Un caso de uso especifica un comportamiento deseado del sistema. Representan los requisitos funcionales del sistema. “ Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor” . Describe que hace el sistema, no como lo hace.

4. UML: Fundamentos de los modelos de Caso de Uso Un diagrama de caso de uso es relativamente fácil de comprender de forma intuitiva, incluso sin conocer la notación. Esto es una ventaja importante. Figura que representa al caso de uso. Un caso de uso individual representa un tipo de tarea que tiene que soportar el sistema Los casos de uso también se describen en detalle, normalmente en texto. (Descripción de alto nivel, Formato expandido)

5. UML: Fundamentos de los modelos de Caso de Uso Otro componente de los caso de uso es el Actor , normalmente aparece con el símbolo de un muñeco, representa un tipo de usuario del sistema. Notación UML Un actor es una entidad externa del sistema que de alguna manera estimula el sistema con eventos de entrada o espera una respuesta del sistema.

7. UML: Fundamentos de los modelos de Caso de Uso Ejemplo: Hay una línea que conecta un actor con un caso de uso si el actor interactúa con el sistema para realizar parte de la tarea. (Comunicación sencilla).

8. UML: Actores en Detalle Beneficiarios : Cada caso de uso tiene que representar una tarea, que se le requiere al sistema que soporte. Normalmente esto significa que el caso de uso tiene valor para al menos uno de los actores. Al actor para el que un caso de uso tiene valor se le llama beneficiario del caso de uso . Por esta razón los desarrolladores tienen que conocer quién necesita un caso de uso (Actor Primario) y quien esta implicado en él sin obtener ningún beneficio (Actor Secundario). Identificar los actores: los usuarios humanos potenciales de un sistema, tienden a ser relativamente fáciles de identificar. Para desarrollar un modelo de caso de uso se necesita identificar los roles que estos humanos pueden desempeñar.

11. UML: Escenarios y Casos de Uso Un caso de uso describe un conjunto de secuencias de interacciones o escenarios: flujo principal y flujo alternativos o excepcionales . Un escenario es una instancia de un caso de uso.

12. UML: Ejemplo Sist. Punto de Venta Comprar producto Log In Pagar producto Inicializar Terminar Agregar usuarios Cajero Cliente Sist. Adm. Gerente Agregar nuevos usuarios Sistema administrador Iniciar Terminar Gerente Comprar productos Paga productos Cliente Log in Dar vuelto Cajero Caso de uso Actor

15. UML: Formato para Casos de Uso Descripción del formato de alto nivel Ejemplo: Primario Tipo: Un cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y recibe el pago, el cual debe ser autorizado. Al terminar la operación, el Cliente se marcha con los artículos comprados. Descripción: Cliente, Cajero Actores: Comprar productos Caso de uso:

19. UML: Formato para Casos de Uso Descripción formato Expandido Segunda Sección: Formato Dos columnas Descripción numerada de las respuestas del sistema Acciones numeradas de los actores Responsabilidad del Sistema (Respuesta del Sistema) Acción del Actor

21. UML: Formato para Casos de Uso Descripción formato expandido Ejemplo: Funciones: R1.1, R1.2, R1.3, R1.7, R2.1 Referencias Cruzadas: Primario y esencial Tipo: Un cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y recibe el pago, el cual debe ser autorizado. Al terminar la operación, el Cliente se marcha con los artículos comprados. Resumen: Capturar una venta y su pago en efectivo. Propósito: Cliente (iniciador), Cajero Actores: Comprar productos Caso de uso:

22. UML: Formato para Casos de Uso Descripción formato expandido Ejemplo: Segunda Sección 12.- El cliente se marcha con los artículos comprados 11.- Registra venta concluida 10.- El cajero deposita el efectivo recibido y extrae el cambio 9.- Muestra al cliente la diferencia, emite recibo 8.- El cajero registra la cantidad de efectivo recibido 7.- El cliente efectúa el pago en efectivo (el efectivo ofrecido probablemente es mayor que la venta) 6.- El cajero indica el total al cliente 5.- Calcula y presenta el total de la venta 4.- Al terminar de introducir el producto. El cajero indica que se concluya la captura de productos 3.- Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presenta la descripción y el precio actual del producto. 2.- El cajero registra la identificación de cada producto. Si hay varios productos de una categoría, se puede introducir la cantidad 1.- Comienza cuando el cliente llega a una caja con productos que desea comprar. Respuesta del sistema Acción de los actores

24. UML: Formato para Casos de Uso Otros formatos Formato de una línea para eventos. Nota: No existe el formato ideal. Algunos prefieren un a columna otros dos. Quitan y agregan secciones. Sin embargo esto no es importante, la clave está en escribir el curso normal de eventos y los curso alternativos en alguna forma.

25. UML: Limite del Sistema Opcionalmente, puede haber una caja en un diagrama de casos de uso, alrededor de los casos de uso, etiquetado con el nombre del sistema. La caja representa el limite del sistema. Puede ser útil cuando se modelan sistemas complejos con muchos subsistemas.

28. UML: Utilización de los casos de uso Casos de uso a través del desarrollo Aspectos políticos: entregar primero los casos de uso más prioritarios, para mostrar que el sistema genera aportes. Aspectos Técnicos: entra en conflicto con los anteriores, hay que implementar primero los casos de uso más riesgosos, para abordar los riesgos cuando sea posible. Validación del sistema: Cada caso de uso describe un requisito del sistema por lo que un diseño correcto permite que se ejecuta cada caso de uso: es decir realizar cada caso de uso. Una técnica y obvia para validar el diseño de un sistema es tomar de uno en uno los casos de uso y comprobar que el sistema permite ejecutar dicho caso de uso.

29. UML: Ejercicios Realice los siguientes ejercicios para practicar los conceptos aprendidos. Ejercicios

30. UML: Relación entre casos de uso Casos de Uso para la reutilización El caso más vital es cuando se puede sacar factor común del comportamiento de dos o más casos de uso originales. También cuando se descubre que se puede implementar parte de uno de los casos de uso utilizando un componente. Ejemplo: Tomar prestada copia y ampliar préstamo. Actor Ampliar Préstamo Tomar Prestada Copia de libro Comprobar para Reserva <<include>> <<include>>

31. UML: Relación entre casos de uso Casos de Uso para la reutilización Destacar que la flecha va desde el caso de uso <<usuario>> hacia el caso de uso <<usado>>, y se etiqueta con <<include>>, para representar que el caso de uso origen incluye el caso de uso destino Actor Ampliar Préstamo Tomar Prestada Copia de libro Comprobar para Reserva <<include>> <<include>>

32. UML: Relación entre casos de uso Casos de Uso para la reutilización El caso de uso origen depende del caso de uso destino, pero el caso de uso destino no depende del caso de uso origen. Cuando una instancia del caso de uso <<llega al lugar>> donde el comportamiento de otro caso de uso debe ser incluido, ejecuta todo el comportamiento descrito por el caso de uso incluido y luego continua de acuerdo a su caso de uso original.

36. UML: Relación entre casos de uso Separación del comportamiento variable <<extend>> Si un caso de uso incorpora dos o más escenarios con diferencias significativas, esto es, se podría mostrar como un caso de uso principal y uno o más casos secundarios. Cuando se realiza esto es un problema de juicio, ya que siempre se pueden mostrar casos variables en un caso de uso. Ejemplo: Tomar prestada copia de libro. Actor Tomar Prestada Copia de libro Rechazar Préstamo <<extend>>

37. UML: Relación entre casos de uso Separación del comportamiento variable <<extend>> Se utiliza la flecha <<extends>> desde el caso de uso menos central al central. La flecha va desde el caso excepcional al caso normal. La precondición debe hacer referencia al caso de uso extendido Actor Tomar Prestada Copia de libro Rechazar Préstamo <<extends>>

38. UML: Relación entre casos de uso Generalización (herencia) Dos actores, o dos casos de uso, pueden estar relacionados por medio de la generalización. Ejemplo: generalización actores PrestatarioLibro PrestatarioRevistas

39. UML: Relación entre casos de uso Generalización (herencia) Cuando los casos de uso están relacionados a través de una generalización la idea es mostrar una tarea y una versión especializada de la misma. Pagar en Efectivo Pagar con Cheque Pagar

40. UML: Relación entre casos de uso Una regla básica es que si se quiere describir comportamiento extra posiblemente se requiera <<extends>>, mientras que si lo que se quiere es una etiqueta para una versión especializada de una tarea completa, probablemente se quiera generalización.

42. UML: ¿Por qué casos de Uso? “ Ofrecen un medio sistemático e intuitivo para capturar los requisitos funcionales, centrándose en el valor añadido para el usuario”. Dirigen todo el proceso de desarrollo puesto que la mayoría de las actividades (planificación, análisis, diseño, validación, test, ..) se realizan a partir de los casos de uso. Mecanismo importante para soportar “trazabilidad” entre modelos.

43. UML: Recomendaciones ERROR COMÚN: no identificar como casos de uso las tareas que lanza el propio sistema. “ Anular reservas pasadas quince días” No incluir casos de uso de las operaciones CRUD sobre un objeto de negocios (consultas, borrado, actualización, registros): excepto si se trata de operaciones relevantes para el sistema, como “registrar clientes” en un sistema de ventas por Internet. Cuidado con el empleo de la relación <<include>> NO HACER UNA DESCOMPOSICIÓN FUNCIONAL!!!

44. UML: Recomendaciones Escribir casos de uso independientes de la interfaz o de detalles de implementación, escribirlos a nivel esencial. Hay que comprobar que los casos de uso incluyen toda la funcionalidad del sistema. Los casos de uso sólo consideran los requisitos funcionales del proyecto, hay que añadir los no funcionales.