You are on page 1of 38

Casos de Uso

 Se utilizan para especificar el comportamiento deseado de un

sistema o subsistema
 Describe el conjunto de secuencias de acciones que lleva a cabo el sistema

para producir un resultado para un actor.  Capturan el comportamiento deseado del sistema, sin especificar como se lleva a cabo dicho comportamiento
 Principalmente son un medio de comunicación para que los

desarrolladores y los usuarios lleguen a un consenso en la especificación  Ayudan a validar el sistema durante el desarrollo

1

Casos de Uso
 Los casos de uso son principalmente descripciones textuales  La notación gráfica de UML (diagrama de casos de uso) solo

muestra los nombres y sus relaciones  Al ser textuales, son informales y no son buenas para razonar acerca del sistema
 Es mejor utilizar los diagramas de interacción resultantes de su

formalización

2

Casos de Uso
 Formas: Narrativa, Escenario, Conversación.

 Alternativas: diagramas de interacción, diagramas de actividades.
 Fases: 1.El actor envía al sistema una petición y los datos

necesarios para llevarla a cabo 2.El sistema valida la petición y los datos 3.El sistema altera su estado interno 4.El sistema devuelve el resultado al actor

3

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

detallados  Se pueden considerar como una tabla de contenidos de casos de uso de niveles más  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  Pueden ser considerados prácticamente como manuales de operación  5 .Casossede Uso a muy distintos niveles de granularidad  Los casos de uso pueden detallar  Se suelen distinguir los siguientes niveles:  Nivel de resumen: muestran ciclo de vida de la secuencia de objetivos directamente relacionadas.

 Se suelen distinguir los siguientes ámbitos:  Organización (caja negra)  Organización (caja blanca)  Sistema (caja negra)  Sistema (caja blanca)  componente 6 . Este es su ámbito. Los casos de uso afectan a diferentes porciones del sistema Casos de Uso en cuestión.

. formatos..)  Constituyen un elemento de enlace con otros requisitos  Sirven para la prueba del sistema 7 . .El papel de los casos de uso en la ingeniería de requisitos  Los casos de uso:  Ayudan a razonar y a comprender el sistema  Proporcionan un lenguaje común  Facilitan la “traducción” de niveles  Constituyen un contrato  Representan requisitos  No representan todos los requisitos  (interfaces.

8 . un dispositivo hardware u otro sistema al interactuar con el nuestro  Se pueden definir categorías generales de actores y especializarlos a través de la relaciones de generalización  Los actores se conectan a los casos de uso mediante asociaciones.Elementos básicos en los Casos de Uso  Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con ellos  Normalmente representan a una persona.

Elementos básicos en los Casos de Uso 9 .

Diagramas de Casos de Uso  Se pueden organizar en paquetes  Se pueden especificar relaciones entre ellos:  generalización  extensión  inclusión  Estas relaciones se usan para:  Factorizar el comportamiento común  extrayendo un comportamiento de los casos en que se incluye  Factorizar variantes  poniendo ese comportamiento en otros casos de uso que lo extienden 10 .

Diagramas de Casos de Uso  Generalización  El caso de uso hijo hereda el comportamiento y el significado del caso de uso padre  El hijo puede añadir o redefinir el comportamiento del padre  El hijo se puede colocar en cualquier lugar en que aparezca el padre  Inclusión  El caso de uso base incorpora explícitamente el comportamiento del caso de uso incluido  El caso de uso incluido forma parte de otro más complejo  Se utiliza para evitar describir flujos repetidos 11 .

Diagramas de Casos de Uso logout <<include>> <<include>> acciones instructor sesion instructor <<include>> cambiar estado modificar parámetros login Instructor controlCI control backtrack sesión alumno 12 .

Diagramas de Casos de Uso  Extensión  Se utilizan para modelar la parte de un caso de uso que puede ser vista como un comportamiento opcional  También se pueden utilizar para modelar un subflujo separado que solo se ejecuta bajo ciertas condiciones  Un ejemplo es el modelado de varios flujos que se puedan dar en un punto dado por la interacción explicita con un actor 13 .

Diagramas de Casos de Uso identificación <<include>> Alumno sesion alumno <<include>> <<extend>> Acción errónea Acciones de Alumno Petición de valores Activar vble dinámica Todos los valores Valores cambiados Selección 14 .

Diagramas de Casos de Uso Nacional <<includes>> Marcar Número Llamante Realizar Llamada <<extends>> Internacional <<extends>> <<extends>> Numero no existe <<extends>> Numero Incorrecto Comunicando Llamado Recibir Llamada <<extends>> No hay linea 15 Llamada no atendida .

Diagramas de Casos de Uso Identificar Cliente Identificar Cliente y Cuenta en Cajero Automático <<includes>> <<includes>> <<includes>> Ingresar Dinero <<includes>> Transferir Dinero Obtener un Balance <<includes>> Sacar Dinero <<includes>> <<includes>> Correo Ciclo de Vida Cuenta 16 Cajero Cliente Cajero Automático .

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

..Cuestionario de Casos de Uso  Se utilizan para dar un formato uniforme a la explicación textual de los casos de usocaso de uso Caso de uso: Nombre del Este es el objetivo del caso de uso descrito con una frase corta Ámbito: La “caja negra” considerada Nivel: Uno de los tres niveles anteriores Contexto de uso: Una frase más larga con la descripción del objetivo y las condiciones normales de desarrollo Actor Principal: Un nombre de rol del actor principal o su descripción Escenario de Éxito Principal: . 18 ... Extensiones: .

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

La notación utilizada es: Sustitución: 2 || Alternativa: 2a Una alternativa puede corresponder a un comportamiento regular.Cuestionario 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. excepcional recuperable o erróneo no recuperable 20 .

Ejemplo Caso de uso: Ciclo de Vida de Cuenta Ámbito: El sistema completo 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 21 .

El sistema solicita al cajero la siguiente información: Nombre Dirección DNI Tipo de Cuenta 4.Ejemplo Escenario de Éxito Principal: 1. El sistema valida la información y crea la cuenta del cliente 22 . 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.

23 El cliente ingresa dinero – sub-caso de uso El cliente obtienen 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. en representación del cliente. 10. 6. 8.Ejemplo Principal: Escenario de Éxito Los pasos del 5 al 8 son opcionales. 7. 11. inicia el cierre de la cuenta El sistema elimina la cuenta El sistema envia un balance con los últimos movimientos . individualmente repetibles y pueden ocurrir en cualquier orden 5. 12. 9.

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

Actores 4. Ininteligibles 10. Especificaciones laaargas 7. Demasiados CU 5. Inacabados 25 . Telas de araña 6. Descripción funcional errónea 9. Especificaciones confusas 8. Punto de vista 3.Fallos Comunes 1. Límites 2.

Extensiones: Variantes del EPE. Escenario principal de éxito: El caso en que todo sale bien. Caso de uso: Contrato acerca del comportamiento del sistema. Glosario  Actor principal: Parte que inicia una interacción con el sistema para lograr       un objetivo.  Parte: Algo o alguien con un interés en el comportamiento del sistema. 26 . Referencias: Para referenciar un caso de uso en otro se subraya. Precondiciones y garantías: Lo que debe ser cierto antes y después de la ejecución del caso de uso. Actor: Algo o alguien con un “comportamiento”. Ámbito: Identifica el sistema que se trata.

4.Los cuatro pasos en la especificación de un caso de uso 1. después manejar. 3. Trabajo sucio y sorpresas. Manejo de fallos: respuestas. Primero identificar. “Brainstorm”. Actores y objetivos: listar. priorizar y asignar. Condiciones de fallo: completar EPE. 2. Conviene “calentar” con una descripción narrativa 27 . MSS/EPE: esquematizar y revisar. revisar.

Actores y partes  Los casos de uso constituyen un contrato de funcionalidad  SUD (system under discussion) /SEC (sistema en cuestión)  Los actores tienen objetivos  Las partes tienen intereses  Cada línea o frase de un caso de uso describe una acción relevante para los intereses de una parte  Una línea describe:  Una interacción entre actores  Lo que el sistema debe hacer para proteger los intereses de las partes 28 .

 Niveles: Las pulgas de las pulgas  Fallo: Los objetivos pueden no cumplirse  Escenario: Una interacción compuesta (unas circunstancias     Actores y partes determinadas y un resultado) Un caso de uso agrupa todos los escenarios (éxito y fallo) La metáfora de los pantalones Un escenario puede contener subcasos de uso (pasos). 29 . Un paso de un escenario no depende de qué evolución del subcaso de uso se dio sino de su resultado.

alias. perfil)  Actores de Soporte  SEC  Actores Internos y Cajas Blancas 30 .Actores y partes  El actor principal y los representantes  Importancia del actor principal  Actores  Objetivos  Actores y Roles  Tabla actores/roles  Introducción  Generalización (UML)  Descripción de actores (nombre.

Localizar todos los CU de A para S 5. Comenzar con un objetivo de usuario 2. Encontrar el ámbito S más externo al cual no pertenece A (compañía. Escribir este CU  31 . ciclos de vida. tablas de contenido  Los casos del nivel más externo 1.Niveles en los objetivos del usuario Usuario  Niveles en los CU de usuario  Resumen  Contexto. Averiguar a qué actor A sirve este objetivo 3. Crear el CU de resumen (de A para S) 6. sistema informático en desarrollo) 4. sistema informático en conjunto.

Niveles en los objetivos del usuario  Subfunción  Sólo deben incluirse por legibilidad  Por muy bajo que sea su nivel el actor principal debe seguir siendo externo  Puntos importantes  Dedicar el mayor esfuerzo a los CU de usuario  Crear algunos CU de resumen para poner en contexto los de usuario  No enfadarse porque un requisito no “llegue” a CU 32 .

Usar el nivel adecuado  Iterar:  ¿Qué desea realmente el actor principal?  ¿Por qué hace esto?  Usar de 3 a 8(10) pasos (si tiene más es seguro que mejorará con la reducción)  Eliminar detalles del IU  Subir el nivel  Unir pasos  Eliminar errores (continuará)  Subir el nivel: ¿Por qué?  Bajar el nivel: ¿Cómo? 33 .

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  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?) 34 .

garantías y disparos  Disparo: Evento que inicia el CU  Ejercicio:  Escribir las precondiciones. –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: 35 •El cliente introduce su tarjeta .Precondiciones. Aut. garantías y disparos del CU de sacar dinero de un Caj.

Escenarios y pasos.ext. Extensiones  MSS / EPE  Condiciones de ejecución (precondiciones y disparo)  Objetivo  Conjunto de pasos o acciones  Condición de fin  Conjunto de alternativas (extensiones)  Cuerpo de un escenario  Cada paso describe:  Una interacción entre dos actores (int. ?)  Validación  Cambio de estado interno 36 . .

Extensiones      Extensiones: alternativas al EPE. Condición (detección) + Pasos Los requisitos más interesantes están en las extensiones Primero listar.Escenarios y pasos. después manejar Considerar:  Escenarios de éxito alternativos  El actor principal actúa de forma incorrecta  El actor principal no actúa  Cada paso que contenga “el sistema valida”  Respuesta incorrecta o nula de un actor de soporte  Fallos internos que deban detectarse y gestionarse  Fallos internos inesperados que deban tratarse  Fallos de eficiencia (velocidad) que deban detectarse 37 .

Los clientes reconocen que el conjunto de CU es el que querían . Tenemos todos los actores principales y todos los objetivos de nivel de ¿Cuándo acabamos?     38 usuario Tenemos todos los disparos (como disparos de CU o como extensiones) Hemos escrito todos los CU de usuario y los de resumen y subfunción que los soportan Cada CU está descrito de forma que:  Los clientes reconocen que pueden saber si se cumplen  Los usuarios reconocen que son los que querían (o con los que se conforman)  Los desarrolladores reconocen que pueden proporcionar esa funcionalidad.