capitulo03p05
description
Transcript of capitulo03p05
![Page 1: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/1.jpg)
Fundamentos de Ingeniería del Software
Capítulo 3. Análisis de Requisitos
Introducción a los casos de uso
![Page 2: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/2.jpg)
Cap 3. Análisis de RequisitosEstructura
1. Actividades iniciales.
2. Técnicas de recogida de la información.
3. Requisitos y análisis de requisitos.
4. Actividades generales de análisis de requisitos.
5. Documentos de especificación de requisitos.
6. Análisis estructurado.
7. Introducción a los casos de uso.
8. Prototipado.
![Page 3: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/3.jpg)
7. Introducción a los casos de uso. Estructura
7.1. Introducción
7.2. Diagramas de casos de uso
7.3. Actores
7.4. Casos de uso7.4. 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
![Page 4: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/4.jpg)
Introducción a los 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)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.
![Page 5: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/5.jpg)
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.� 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.
![Page 6: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/6.jpg)
Realizar llamada telefónica
Diagrama de casos de uso. Ejemplo
Realizar llamada de conferencia
<<extend>>
Recibir llamada telefónica
Usar agenda
Red telefónica
Usuario
Realizar llamada de conferencia
Recibir llamada adicional
<<extend>>
Teléfono móvil
(Booch et al. 99)
![Page 7: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/7.jpg)
É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 de principales técnicas de especificación de requisitos.
�Presentes en casi cualquier nuevo método de desarrollo de software.
�Incluidos en UML y Métrica 3.
![Page 8: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/8.jpg)
7.2. Diagramas de casos de uso
Elementos:
�Actores: roles que juegan los usuarios con respecto al sistema.
Confirmar reserva
�Casos de uso: interacciones típicas entre usuarios y el sistema.
Dar OK vuelo
Comprobar tabla de vuelos
Sistema de vuelo Sistema de vuelo Sistema de vuelo Sistema de vuelo (Jacobson et al. 92)Piloto
Oficinista
![Page 9: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/9.jpg)
7.3. Actores
�Inician la ejecución de los casos de uso.
�No tienen que ser personas necesariamente.necesariamente.
�Un mismo rol puede ser jugado por más de un usuario.
�Un usuario puede jugar más de un rol.
![Page 10: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/10.jpg)
Actores (II)
�En UML, se pueden generalizar actores.
�p.ej.
Cliente
Cliente
individual
Cliente
corporativo
![Page 11: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/11.jpg)
Actores (III)
�Ayudan a capturar los casos de uso
...aunque algunos casos de uso no tienen actores (de inicio) asociados...
p.e. “enviar factura” (nadie la pide) 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”
![Page 12: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/12.jpg)
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.
![Page 13: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/13.jpg)
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 (actor primario del caso de uso),
� o pueden sólo “participar” en él (actores secundarios del caso de uso)
![Page 14: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/14.jpg)
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�Un camino básico
� Caminos alternativos (describir tantos como sea posible para aumentar la robustez del sistema)
� Caso de uso ↔� Descripciones breve, informal y completa (Larman 03)
� También con diagramas de actividad y de secuencia
Descripción en lenguaje natural
![Page 15: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/15.jpg)
Casos de uso Descripción textual
� Un escenario primario y varios secundarios. P.ej.:
Caso de uso Ordenar pedidoPrecondición: Un usuario válido ha entrado en el sistema
Flujo de eventos:
Camino básico1. El caso de uso comienza cuando el usuario selecciona Ordenar pedido.
(Schneider Winters 98)
1. El caso de uso comienza cuando el usuario selecciona Ordenar pedido.
2. El usuario introduce su nombre y dirección.
3. Si el usuario sólo introduce el código postal, el sistema mostrará la ciudad y provincia.
4. El usuario introduce los códigos de los productos deseados.
5. El sistema proporcionará la descripción y el precio de cada elemento.
6. El sistema mostrará el coste total de los elementos introducidos hasta el momento.
7. El usuario introduce información de pago mediante tarjeta de crédito.
8. El cliente seleccionará “Enviar”.
9. El sistema verificará la información, guardará el pedido como “pendiente” y enviará la información de pago al sistema de contabilidad.
10. Cuando el pago es confirmado, el pedido se marca “Confirmado”, un ID de pedido se manda al usuario y termina el caso de uso.
Caminos alternativosEn el paso 7, si cualquier información es incorrecta, el sistema pedirá al usuario corregir la información.
Post-condición: El pedido ha sido guardado en el sistema y marcado como “Confirmado”.
![Page 16: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/16.jpg)
Casos de uso Descripción textual (II)
Caso de Uso Ordenar Fabricación
� Disponibles muchas plantillas
P.ej., la plantilla de Coleman:
Caso de Uso Ordenar Fabricación
Descripción Se crearán órdenes de trabajo para cada producto solicitado en el pedido, y serán enviadas al jefe deproducción para su planificación.
Actores Jefe técnicoAsunciones - Es viable la fabricación de cada producto solicitado en el pedido.
- Existe una plantilla de fabricación para cada producto solicitado.Pasos 1. REPETIR
1.1 Obtener un producto del pedido.1.2 Buscar la plantilla de fabricación asociada al producto.1.3 Crear la orden de trabajo.1.4 Almacenar la orden de trabajo con el estado pendiente.
Variaciones -Req. No Funcionales -Cuestiones -
![Page 17: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/17.jpg)
Encontrar los casos de uso
� Es útil encontrar primero los actores
� Se puede diferenciar entre (Fowler 99):�Objetivos del usuario:
“formatear un documento” “formatear un documento”
� Interacciones del sistema:
“def. un estilo”, “mover un estilo a otro doc.”
� Guía útil: primero buscar los objetivos del usuario, y luego cubrir cada objetivo con interacciones del sistema.
![Page 18: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/18.jpg)
Relaciones entre casos de uso(en UML, Booch et al. 99)
�«extend»: el caso de uso que extiende realiza una acción en un punto del caso de uso extendido, si se cumple una condición.
Denota un “punto de extensión”.Denota un “punto de extensión”.
Sirve para representar las condiciones de error y poco usuales, que podrían oscurecer el caso de uso base.
�«include»: se factorizan acciones que se utilizan en más de un caso de uso (se incluye siempre).
![Page 19: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/19.jpg)
Relaciones entre casos de uso(en UML, Booch et al. 99) (II)
Imprimir
Ptos. de extensiónpapel atascado
<<include>> <<extend>>(papel atascado)
⇒ En UML también existe la generalización
DesatascarpapelValidar usuario
(papel atascado)
![Page 20: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/20.jpg)
include y extend. Ejemplo
Establecer límites
Analizar riesgo
Actualizar cuentas
Valoración
<<include>>
<<include>>Gerente de comercioSistema de
Contabilidad
(Fowler 99)
Negociar precio
Capturar negociación
Límite excedido
Valoración<<include>>
<<extend>>
Gerente de comercio
ComercianteAgente de Ventas
Contabilidad
![Page 21: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/21.jpg)
Casos de uso. Ejemplo
�Máquina de reciclado:
Botes
Recibo
Extraído de (Jacobson et al. 92) p.150
BotellasRecibo
Cajas de botellas
![Page 22: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/22.jpg)
Casos de uso. Ejemplo (II)
Máquina de reciclado de botes, botellas y envases de plástico
� Como cada ítem tiene precios y dimensiones distintas el sistema debe identificar el tipo de ítem que acaba de recibir
� El sistema registra el número de ítems recibidos y, si el cliente pide � El sistema registra el número de ítems recibidos y, si el cliente pide un recibo, imprime el número de ítems recibidos, su tipo, los precios parciales y el total que será devuelto al cliente en la caja, al presentar ese recibo impreso
� Un operador puede, al final del día, solicitar un listado de todos los ítems recuperados ese día
� El operador también puede cambiar la información del sistema (precios, tipos, etc.)
![Page 23: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/23.jpg)
Casos de uso. Ejemplo (III)
Primero determinar los actores: Usuario y Operador
Después determinar los objetivos de los actores:
Usuario: puede devolver ítems (el CdU incluye desde la devolución de ítems a la impresión del recibo)
Operador: puede pedir listado diario o bien modificar información de ítems
Modif.
Usuario
Devolver ítems
Listar diario
Actor Asociación
Operador
Modif. ítems
![Page 24: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/24.jpg)
Granularidad de los casos de uso
�Pueden ser grandes o pequeños:
�p.ej. en un procesador de textos...− “poner texto en negrita” •
••
− “crear tabla de contenidos”− ”formatear el documento”
�¿Qué criterio adoptar?�Proyecto 10 personas/año ⇒ Valores esperados :
−Según I. Jacobson: 20 casos de uso.−Según M. Fowler: 100 casos de uso.
••
![Page 25: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/25.jpg)
7.5. Escenarios y Casos de Uso
�“Interacción típica entre el usuario y el sistema”
�Distintas acepciones:�Distintas acepciones:
�(a veces) Escenario = Caso de uso
�En UML, escenario = “camino dentro de un caso de uso“(una combinación especial de condiciones dentro de un caso de uso)
![Page 26: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/26.jpg)
Escenarios y Casos de Uso (II)€
Insertar tarjeta
Pedir clave
Introducir clave
Verificar cuenta Verificar cuenta con banco
BANCO CONSORCIO
CAJERO AUTOMÁTICO USUARIO
Interactuar con cajero automático
CASO DE USO ESCENARIO
con banco
Cuenta errónea
Cuenta errónea Mensaje de
cuenta errónea
Imprimir recibo
Expulsar tarjeta
Pedir recoger tarjeta
Recoger tarjeta
Mostrar pantalla principal
![Page 27: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/27.jpg)
7.6. Especificación de requisitos con casos de uso
� El SRS (Software Requirements Specification) puede estar formado por:�Diagrama de casos de uso
�Modelo del dominio�Modelo del dominio
� (Para cada caso de uso)
Descripción textual (usando una plantilla)
Descripciones de las interfaces de usuario
� Especificación suplementaria− Requisitos no funcionales− Reglas de negocio− Otros requisitos funcionales (no incluidos en los casos de uso)
![Page 28: capitulo03p05](https://reader031.fdocuments.es/reader031/viewer/2022020518/577c80951a28abe054a94fa3/html5/thumbnails/28.jpg)
7.7. Desarrollo dirigido por los casos de uso (Jacobson et al. 92)
Diagrama de casos de usoDiagrama de casos de usoDiagrama de casos de usoDiagrama de casos de uso
puede ser
class... OK
OK
FAIL
expresado en términos de estructurado
porrealizado
por implementado por
probado en
Modelo de objetos del dominio
Modelo de análisis
Modelo de diseño
(colaboraciones)Modelo de
implementaciónModelo de pruebas