OOA- Introducción a Casos de Uso

Presentación del tema: "OOA- Introducción a Casos de Uso"— Transcripción de la presentación:

1 OOA- Introducción a Casos de Uso
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

3 Fin de la presentación Continú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
Enrique es 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 Niveles de casos de uso 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

21 Niveles de casos de uso 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

22 Lineamientos: Para los niveles de casos de uso elegir EBPs
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.

23 Lineamientos: Para los niveles de casos de uso elegir EBP
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?

24 Lineamientos: Tamaño de los casos de uso
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.

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