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

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

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  

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

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

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

Formato de Casos de Uso Extensiones: Condición especial ":"

  Siempre

Descripción de acción | sub-caso de uso

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

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

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

Ejemplo Escenario de Éxito Principal: Los pasos del 5 al 8 son opcionales, individualmente repetibles y pueden ocurrir en cualquier orden 5.  6.  7.  8.  9.  10.  11.  12.  13. 

El cliente ingresa dinero – sub-caso de uso El cliente obtiene un balance – sub-caso de uso El cliente saca dinero – sub-caso de uso El cliente transfiere dinero – sub-caso de uso Este paso se repite indefinidamente una vez al mes desde la fecha de apertura hasta fecha de cierre El Sistema envía por correo ordinario la información de su cuenta al cliente El cajero, representando al cliente, inicia el cierre de la cuenta El sistema elimina la cuenta El sistema envía un balance con los últimos movimientos

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

Pasos para la especificación de un CU 1) 

2)  3) 

4) 

Actores y objetivos: listar, revisar, priorizar y asignar. MSS/EPE: esquematizar y revisar. Condiciones de fallo: completar EPE, “Brainstorm”. Primero identificar, después manejar. Manejo de fallos: respuestas. Trabajo sucio y sorpresas.

Conviene “calentar” con una descripción narrativa

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

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

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

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)

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

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.

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

  Modelar

los requisitos del mismo

  Especificar

externo

las fronteras e identificar los actores que debe hacer el sistema desde el punto de vista

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

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

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

Requerimientos: ¿Para qué sirven? Requerimientos

Requerimientos: Tipos

Los Requerimientos: Categorías FURPS+

Requerimientos o Atributos de Calidad

Los Requerimientos: Categorías FURPS+

Requerimientos: Artefactos Los Requerimientos Funcionales

Tarea En grupos de 3 o 4 personas.   Elaborar el diagrama de Casos de Uso para el sistema de Quiniela Mundial 2010.   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. 