CLASE 4: CASOS DE USO REQUERIMIENTOS. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Martínez

Transcripción

1 CLASE 4: CASOS DE USO REQUERIMIENTOS Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Martínez

2 Casos de Uso Un caso de uso es una descripción de las posibles secuencias de interacción entre el sistema y actores externos en relación a el objetivo de un actor particular

3 Casos de Uso: Niveles Nivel de resumen: muestran ciclo de vida de la secuencia de objetivos directamente relacionadas. Se pueden considerar como una tabla de contenidos de casos de uso de niveles más detallados Nivel de usuario: describen el objetivo del actor cuando intenta llevar a cabo una acción sobre el sistema Nivel de subfunción: son casos de uso requeridos para llevar a cabo los de usuario, con un mayor nivel de detalle

4 Casos de Uso Niveles: Resumen Ciclo de vida Cuenta Usuario Ingresar Dinero Transferir Dinero Obtener un Balance Sacar Dinero Subfunción Identificar Cliente Identificar Cliente y Cuenta en Cajero Automático

5 Formatos de Casos de Uso Se utilizan para dar un formato uniforme a la explicación textual de los casos de uso Caso de uso: Nombre del caso de uso Este es el objetivo del caso de uso descrito con una frase corta Nivel: Uno de los tres niveles descritos Contexto de uso: Una frase más larga con la descripción del objetivo y las condiciones normales de desarrollo, precondiciones,... Actor Principal: Un nombre de rol del actor principal o su descripción Escenario de Éxito Principal:... Extensiones:...

6 Formatos de Casos de Uso Escenario de Éxito Principal: Número_de_Paso "." descripción_de_acción Se numeran todos los pasos del escenario desde el disparo al objetivo Se pueden anidar, utilizando numeración de Dewey (3.1.2) No se deben incluir sentencias condicionales; las condiciones y alternativas se muestran en la parte de extensión Extensiones:...

7 Formato de Casos de Uso Extensiones: Condición especial ":" Descripción de acción sub-caso de uso Siempre se refiere a un paso del escenario principal Una extensión o sustituye al paso principal o es una alternativa. La notación utilizada es: Sustitución: 2 Alternativa: 2a Una alternativa puede corresponder a un comportamiento regular, excepcional recuperable o erróneo no recuperable

8 Ejemplo Caso de uso: Ciclo de Vida de Cuenta Nivel: Resumen Contexto de uso: Para interactuar con el sistema el cliente es representado por un cajero o por cajero automático Actor Principal: Cliente

9 Ejemplo Escenario de Éxito Principal: 1. Un cliente informa al cajero de que quiere abrir una cuenta 2. En representación del cliente el cajero inicia la apertura de la cuenta en el sistema 3. El sistema solicita al cajero la siguiente información: Nombre Dirección DNI Tipo de Cuenta 4. El sistema valida la información y crea la cuenta del cliente

10 Ejemplo Escenario de Éxito Principal: Los pasos del 5 al 8 son opcionales, individualmente repetibles y pueden ocurrir en cualquier orden 5. El cliente ingresa dinero sub-caso de uso 6. El cliente obtiene un balance sub-caso de uso 7. El cliente saca dinero sub-caso de uso 8. El cliente transfiere dinero sub-caso de uso 9. Este paso se repite indefinidamente una vez al mes desde la fecha de apertura hasta fecha de cierre 10. El Sistema envía por correo ordinario la información de su cuenta al cliente 11. El cajero, representando al cliente, inicia el cierre de la cuenta 12. El sistema elimina la cuenta 13. El sistema envía un balance con los últimos movimientos

11 Ejemplo Extensiones: 4a. El sistema informa que el cliente ya tiene una cuenta de este tipo abierta 4a.1. El sistema solicita al cajero que confirme la creación de la cuenta 4a.1a. El cajero confirma la creación y el caso de uso continua por el paso 3 4a.1b. El cliente decide no crearla y el caso de uso finaliza sin ningún efecto sobre el estado...

12 Pasos para la especificación de un CU 1) Actores y objetivos: listar, revisar, priorizar y asignar. 2) MSS/EPE: esquematizar y revisar. 3) Condiciones de fallo: completar EPE, Brainstorm. Primero identificar, después manejar. 4) Manejo de fallos: respuestas. Trabajo sucio y sorpresas. Conviene calentar con una descripción narrativa

13 Precondiciones, garantías y disparos Precondición: lo que debe ser cierto antes de que un CU se ejecute Debe ser necesaria SIEMPRE Puede ser Otro CU Una condición que se consigue en un paso de otro CU Una condición externa

14 Precondiciones, garantías y disparos Garantía: lo que es cierto una vez ejecutado el caso de uso Mínimas: se producen en cualquier caso (comprobar con las partes) De éxito: se producen sólo para los escenarios de éxito ( Qué fastidiaría a tal parte que sucediese (o no) en un caso de éxito?)

15 Precondiciones, garantías y disparos Disparo: Evento que inicia el CU Precondiciones: El cliente tiene una cuenta y una tarjeta válidas Garantías: Mínimas: El cajero informa del saldo disponible El cajero produce un recibo (?) De éxito: El cajero entrega el dinero La cuenta se actualiza Disparo: El cliente introduce su tarjeta

16 Escenarios y pasos. Extensiones MSS / EPE Condiciones de ejecución (precondiciones y disparo) Objetivo Conjunto de pasos o acciones Condición de fin Conjunto de alternativas (extensiones)

17 Escenarios y pasos. Extensiones Cuerpo de un escenario: Cada paso describe: Una interacción entre un actor y el sistema Una validación Un cambio de estado interno

18 Escenarios y pasos. Extensiones Extensiones: alternativas al EPE. Condición (detección) + Pasos Los requisitos más interesantes suelen estar en las extensiones Primero enumerar, después manejar.

19 Casos de Uso. Resumen Los diagramas de casos de uso pueden ser vistos como un mapa general de las funcionalidades más importantes del sistema Deben ser lo suficientemente claros para que alguien externo al sistema los entienda Los casos de uso se deben utilizar para: Modelar el contexto del sistema Especificar las fronteras e identificar los actores Modelar los requisitos del mismo Especificar que debe hacer el sistema desde el punto de vista externo

20 Casos de Uso. Resumen Los casos de uso son la base para establecer las pruebas del sistema También pueden utilizarse en ingeniería inversa. En este caso los pasos a seguir son: Identificar cada actor que interactúa con el sistema Trazar el flujo de eventos del sistema ejecutable en relación con cada actor Agrupar flujos relacionados en casos de uso Organizarlos utilizando las relaciones vistas

21 Los Requerimientos Qué son? Para qué sirven? Cómo se clasifican? A través de qué artefactos pueden describirse?

22 Requerimientos: Qué son? Qué deberá hacer el sistema? En qué condiciones deberá hacerlo? Qué cualidades o atributos deberá poseer el sistema?

23 Requerimientos: Para qué sirven? Requerimientos

24 Requerimientos: Tipos

25 Los Requerimientos: Categorías FURPS+

26 Los Requerimientos: Categorías FURPS+ Requerimientos o Atributos de Calidad

27 Requerimientos: Artefactos Los Requerimientos Funcionales

28 Tarea En grupos de 3 o 4 personas. Elaborar el diagrama de Casos de Uso para el sistema de Quiniela Mundial Describir todos los casos de uso encontrados en formato resumen. Describir 3 o 4 (uno por miembro del equipo) casos de uso en formato extendido.