Temas Introducción Conceptos en modelado de casos de uso Niveles de casos de uso

1. Temas • Introducción • Conceptos en modelado de casos de uso • Niveles de casos de uso OOA- Introducción a Casos de Uso

2. Bibliografía • Larman, Craig. Applying UML and Patterns: an introduction to Object Oriented Analysis and Design and Iterative Development. 3rd Edition. Prentice Hall. 2005.

3. Fin de la presentaciónContinúe en la siguiente actividad OOA- Introducción a Casos de Uso

4. Objetivos • Definir Casos de uso y actores • Usar diagramas de casos de uso para mostrar actores, casos de uso y sus interacciones (diagrama de contexto) • Identificar diferentes niveles de casos de uso

5. Casos de uso • El comportamiento del sistema es cómo reacciona y actúa un sistema • La parte externa, visible y que puede probarse • Se captura por medio de casos de uso • Describen al sistema, su ambiente y las relaciones entre el sistema y su ambiente • QUÉ no CÓMO

6. Casos de uso • Un caso de uso cuenta la historia de los actores al usar el sistema • “Renta Videos” • Un caso de uso es una secuencia de acciones que un sistema ejecuta y que llevan a un resultado observable de valor para un actor en particular. • Un artefacto que expresa (especialmente) requerimientos funcionales.

7. Conceptos en modelado de casos de uso • Un actor representa cualquier cosa que interactúa con el sistema • Los casos de uso en UML se representan como elipses

8. Modelo de casos de uso • Es un modelo de las funciones que se espera tenga el sistema (casos de uso) y su entorno (actores) • El mismo caso de uso se emplea en las fases de requerimientos, análisis, diseño y pruebas El principal objetivo del caso de uso es comunicar la funcionalidad del sistema y su comportamiento hacia el cliente o usuario final

9. Beneficios del modelo de casos de uso • Es usado para comunicarse con el usuario y los expertos funcionales • Ayuda a “vender” el sistema en etapas tempranas • Asegura el entendimiento mutuo de requerimientos • Es usado para identificar • Quién interactuará con el sistema y qué deberá hacer éste • Qué interfaces tendrá el sistema • Es usado para verificar • Que se hayan capturado todos los requerimientos • Que los desarrolladores hayan entendido los requerimientos

10. Actores • No son parte del sistema, representan roles que los usuarios pueden jugar • Un actor puede intercambiar activamente información con el sistema • Puede ser un receptor pasivo de información • Puede representar a una persona, máquina o a otro sistema

11. Tipos de actores • Actores primarios • Son usuarios del sistema cuyos objetivos son satisfechos por medio de servicios que ofrece el sistema • Por ejemplo un cliente en un cajero automático • Actor de soporte • Provee un servicio, por ejemplo información al sistema. Puede ser un sistema externo, una organización o persona. Por ejemplo un sistema de autorización de tarjetas de crédito es un actor de soporte.

12. Actores • En una tienda de videos, ¿quién es el actor primario el cliente o el cajero? Eso depende de los límites del sistema y para quién estemos diseñando el sistema.

13. Encontrar actores: preguntas útiles • Quién está interesado en cierto requerimiento • En qué parte de la organización se usa el sistema • Quién proveerá con información al sistema, la usará y la borrará • Quién usará X función en cuestión • Quién le dará mantenimiento y soporte al sistema • ¿El sistema usa un recurso externo? • Qué actores necesita el caso de uso • Un actor juega diferentes roles, diferentes actores juegan el mismo rol

14. Un usuario puede ser varios actores Enriquees operador Enrique es estudiante

15. Casos de uso • Un caso de uso modela un diálogo entre actores y el sistema • Es iniciado por un actor e invoca cierta funcionalidad en el sistema • Es un flujo de eventos completo y con sentido • En conjunto, todos los casos de uso constituyen todos los caminos para usar el sistema

16. Encontrar casos de uso: preguntas prácticas • Cuáles son las tareas de este actor • Qué caso de uso creará, almacenará, cambiará, eliminará o leerá información del sistema • El actor necesitará ser informado por el sistema respecto a cambios externos repentinos • Necesita ser informado sobre sucesos en el sistema • Qué casos de uso mantendrán y darán soporte al sistema • ¿Todos los requerimientos funcionales están incluidos en los casos de uso ?

17. Fuentes de información para casos de uso • Especificaciones del sistema/enunciado del problema • Literatura relevante del tema • Entrevistas con expertos • Conocimiento personal del tema • Sistemas legados

18. El diagrama de casos de uso • Los casos de uso y los actores interactúan enviando estímulos de uno a otro

19. Casos de Uso • Los casos de uso no son parte de la metodología orientada a objetos. De hecho pueden utilizarse bajo cualquier metodología • Pero son útiles en el análisis y diseño orientado a objetos • Se necesita algún tipo de entrada en cuanto a requerimientos para la fase de diseño • Son ampliamente usados • En cuanto a UML los casos de uso cuentan con diagramas de casos de uso

20. Un reto muy importante es identificar casos de uso a un nivel útil. Por ejemplo, ¿cómo sabemos cuáles de los siguientes están a un nivel útil ? Negociar un contrato con un proveedor Rentar Videos Conectarse al sistema Iniciar el sistema Niveles de casos de uso

21. Una respuesta cierta es que todos son casos de uso. Pero no es de ayuda… Podemos terminar con demasiados casos de uso muy específicos o inútiles Niveles de casos de uso

22. EBP (Elementary Business Process o Procesos de Negocio Elementales) es un término definido como: “Una tarea realizada por una persona en un lugar a un tiempo, en respuesta a un evento del negocio, que agrega valor al negocio, medible, y deja los datos en un estado consistente” Debemos enfocarnos en casos de uso a nivel EBP. Lineamientos: Para los niveles de casos de uso elegir EBPs

23. Para medir el valor que agrega al negocio podemos aplicar la “prueba del jefe” al caso EBP Jefe: “¿Qué hizo todo el día?” Yo: ”Estuve haciendo el inicio de sesión!” ¿Estará feliz el jefe? Lineamientos: Para los niveles de casos de uso elegir EBP

24. Un caso de uso a nivel EBP normalmente está compuesto de varios pasos, no sólo uno o dos. Aplicando los lineamientos de EBP y tamaño el caso de uso a modelar es: Negociar un contrato con un proveedor Rentar Videos Conectarse al sistema Iniciar el sistema Los otros podrían modelarse también como casos de uso Pero, es preferible enfocarse en los de nivel EBP. Lineamientos: Tamaño de los casos de uso

25. Diagramas de casos de uso • UML cuenta con diagramas de casos de uso • Los casos de uso son texto no diagramas. El análisis de casos de uso en un esfuerzo de escritura no de dibujo. • Pero un tiempo reducido creando un diagrama de casos de uso provee el contexto para: • Identificar los casos de uso por nombre • Crear el “diagrama de contexto”

26. Diagramas de casos de uso Cuidado: No invierta mucho tiempo diagramando. El trabajo en casos de uso significa escribir texto, no dibujar diagramas.

27. Lineamientos: Diagramas de casos de uso

28. Lineamientos: Modelado de casos de uso • Es común agrupar las operaciones CRUD (create, retrieve, update, delete) en un solo caso de uso. • Administrar usuarios • Los nombres empiezan con un verbo. • Administrar usuarios • Todos los sistemas tienen un caso de uso para el Inicializar (Start up) y otro para Apagarlo (Shut Down) (tal vez triviales y a bajo nivel ) • Pero a veces importantes (p.ej. el sistema de un avión)

29. Solicitar lista de cursos Sistema de Cobro Registro para cursos Professor Seleccionar cursos a enseñar Estudiante Mantener info del curso Mantener información profesor Generar catálogo Mantener info estudiante Oficina Registros Ejemplo: Modelo de casos de uso (Diagrama de Contexto) sistema inscripciones