Introduccion a casos de uso

Fundamentos de Ingeniería del Software

Capítulo 3. Análisis de Requisitos Introducción a los casos de uso

Cap 3. Análisis de Requisitos Estructura
1. 2. 3. 4. 5. 6. 7. 8. Actividades iniciales. Técnicas de recogida de la información. Requisitos y análisis de requisitos. Actividades generales de análisis de requisitos. Documentos de especificación de requisitos. Análisis estructurado.Introducción a los casos de uso. Prototipado.

7. Introducción a los casos de uso. Estructura
7.1. 7.2. 7.3. 7.4. Introducción Diagramas de casos de uso Actores Casos de uso
Descripción Relaciones entre casos de uso Granuralidad de los casos de uso

7.5. Escenarios y casos de uso 7.6. Especificación de requisitos con casos de uso 7.7. Desarrollo dirigido por los casos de uso

Introducción alos casos de uso. Bibliografía
“UML Gota a gota”. M. Fowler, K. Scott. Ed. Addison-Wesley Longman. 1999. (Cap. 3) “UML y Patrones” (2ª Edición). C. Larman. Ed. Prentice-Hall. 2003. (Cap. 6) “El lenguaje unificado de modelado”. G. Booch et al. Ed. Addison-Wesley. 1999. (Caps. 16 y 17) “Object-Oriented Software Engineering. A Use Case Driven Approach”. I. Jacobson et al. Ed. Addison-Wesley. 1992.“Applying Use Cases”. G. Schneider, J. P. Winters. Ed. Addison-Wesley. 1998.

7.1. Introducción
Técnica de recolección y especificación de requisitos. Fáciles de comprender/validar por los usuarios. Guían todo el proceso de desarrollo. Ayudan a la planificación/desarrollo incremental. Tradicionalmente ligados a la OO
pero no obligatorio

Ayudan a determinar la interfaz de usuario.

Diagramade casos de uso. Ejemplo

Realizar llamada telefónica

Red telefónica

Realizar llamada de conferencia Recibir llamada telefónica Recibir llamada adicional

Usar agenda

Teléfono móvil
Usuario

(Booch et al. 99)

Éxito de los casos de uso
Concebidos por I. Jacobson Objectory/OOSE (Jacobson et al. 92) Se han asentado como una de las principales técnicas de especificación derequisitos. Presentes en casi cualquier nuevo método de desarrollo de software. Incluidos en UML y Métrica 3.

7.2. Diagramas de casos de uso
Elementos:
Actores: roles que juegan los usuarios con respecto al sistema. Casos de uso: interacciones típicas entre usuarios y el sistema.
Dar OK vuelo Comprobar tabla de vuelos Piloto Confirmar reserva Oficinista

Sistema de vuelo (Jacobson et al. 92)7.3. Actores
Inician la ejecución de los casos de uso. No tienen que ser personas necesariamente. Un mismo rol puede ser jugado por más de un usuario. Un usuario puede jugar más de un rol.

Actores (II)
En UML, se pueden generalizar actores.
p.ej.
Cliente

Cliente individual

Cliente corporativo

Actores (III)
Ayudan a capturar los casos de uso

...aunque algunos casos de usono tienen actores (de inicio) asociados...
p.e. “enviar factura” (nadie la pide)
(Fowler 99)

Dos posibles soluciones:

(Schneider Winters 98)

que el sistema pueda iniciar el caso de uso (no permitido en UML, pero estos autores creen que sería útil) crear un actor como “Tiempo” (para un caso de uso que se debe iniciar automáticamente cada cierto intervalo de tiempo) o “Sistema”

Actores(IV)
Ayudan a configurar el sistema para cada usuario
crear profiles o perfiles de usuario

Ayudan a tomar soluciones de compromiso durante el desarrollo
se observa quién (qué actor) necesita cada caso de uso.

Encontrar los actores
¿Qué se considera un actor?
⇒ podemos preguntarnos

¿Por qué se construye el sistema?
Los actores “ganan valor” con la ejecución del caso de uso (actorprimario del caso de uso), o pueden sólo “participar” en él (actores secundarios del caso de uso)

7.4. Casos de uso
Capturan una función visible para el usuario. Consiguen un objetivo para el usuario del sistema. Por cada caso de uso:
Un camino básico Caminos alternativos (describir tantos como sea posible para
aumentar la robustez del sistema)

Caso de uso ↔ Descripción en lenguaje...