IR14 Creando Casos de Uso

8/20/2019 IR14 Creando Casos de Uso

1/56

Ingeniería de requerimientos

Ingeniería de Sistemas e Informática


2/56

Examen final

Día: domingo 21 de febrero de

2016.

Hora: 08:15 horas.

Aula: F503-A


3/56

Propósito de la sesión

• Explica cómo se obtuvieron las

características de los requerimientos

para el software Online Travel Agency.

• Elabora el documento de

especificación de caso de uso.

Contenido de la sesión

• Características de los requerimientos.

• Caso de uso y diagrama de casos deuso.

• Especificación de caso de uso.

Propósito y contenido de la sesión


4/56

Recapitulando …


5/56

Derivando las características de los

requerimientos del stakeholders

Características de los

requerimientos delstakeholders.

Atributos se utilizaron

en las características.


6/56

CREANDO CASOS DE USO

Ingeniería de requerimientos


7/56

Creando casos de uso

Los requerimientos funcionales son descritos usando casos deuso.

Estos se derivan de las características.

Un caso de uso es una descripción del sistema en términos de

una secuencia de acciones.

Se debería producir un resultado o valor observable para el actor(un actor es algo o alguien que interactúa con el sistema).


8/56


9/56


10/56

¿De dónde se obtiene los casos de uso? (2)

Los casos de uso derivan

de las características

que describe la

funcionalidad del

sistema.

Los escenarios derivan

de los casos de uso.


11/56


12/56

Candidatos a actor en la agencia de viajes en

línea (online Travel Agency)

Dueño de la agencia de viaje

Usuario 1 (de Estados Unidos)

Usuario 2 ( de Francia)

Desarrollador

Administrador de contenido

Representante de servicio al cliente

Administrador

Proveedor del hotel, agente de renta de carros, representante de la aerolínea


13/56


14/56

Identificando casos de uso (2)

•Guía para crear casos de uso:

•

Cada caso de uso debería interactuar por lo menos con un actor•Cada caso de uso debería ser iniciado por un actor

•Los nombres de los casos de uso deben ser significativos

•Buscar reservación y buscar viajero es mejor que búsqueda 1 ybúsqueda 2

•Dos casos de uso no deben tener el mismo nombre

• Los nombres deben ser entendidos no solo por losdesarrolladores, sino también por los clientes y usuarios.

•Un caso de uso describe la funcionalidad, no la implementación.

•Debe ser claro quien inicia el caso de uso.

•El caso de uso no debe ser pequeño, ni grande.

Los casos deuso pueden ser

identificados

durante el

taller derequerimientos


15/56

Casos de uso de la agencia de viajes en línea

• Usuario

– Registro

– Log in• Viajero

– Reservar vuelo

– Comprar pasaje

– Reservar cuarto de hotel – Buscar atracciones

– Reservar un carro

• Representante de servicio alcliente

• Log in

• Cambiar reservación

• Borrar reservación

• Buscar reservación

– Administrador• Registrar usuario

• Buscar por usuario

• Actualizar información de usuario

• Log in

• Correr reporte.


16/56


17/56

Casos de uso iniciados por el actor usuario y el

viajero


18/56

Casos de uso para el administrador y

representante de servicio al cliente


19/56


20/56

RELACIONES DE LOS CASOS DE USO

Casos de uso


21/56

Relación include


22/56

Relación extend


23/56

Generalización de casos de uso


24/56

Generalización de actores


25/56

Fragmento de un caso de uso

• Aquí tenemos un fragmento de un caso de uso:

– El usuario ingresa la información requerida del vuelo: aeropuerto y

fecha de partida, aeropuerto y fecha de arribo.

– El sistema muestra todos los vuelos salientes coincidentes con el

criterio de búsqueda.

– El usuario selecciona un vuelo saliente.

– El sistema muestra una lista de vuelos de retorno disponibles.


26/56


27/56

Propósito de un caso de uso…

• Adicionalmente, puede producir diagramas de secuencia,diagramas de colaboración y diagramas de clases de loscasos de uso.

• Puede derivar la documentación de usuario de los casosde uso.

• Los casos de uso pueden también ser útiles al planear elcontenido técnico de las iteraciones y dar a losdesarrolladores del sistema una mejor comprensión delpropósito del sistema.

• Puede usar como una entrada para los casos de prueba.


28/56


29/56

Documento de especificación de caso de uso (1)


30/56

Flujo básico: Caso de uso reservar vuelo


31/56

Flujos alternativos: Caso de uso reservar vuelo


32/56

Convención

Flujo básico: B

• Pasos el flujo básico: B1, B2, B3, …

Flujos alternativos: A1, A2, A3, …

• Pasos en el flujo alternativo 1: A1.1, A1.2, A1.3, …

• Pasos en el flujo alternativo 2: A2.1, A2.2, A2.3, …


33/56

Requerimientos especiales y otros

Requerimientos especiales

Pre condiciones

Post condición

Punto de extensión


34/56

Diagrama de contexto para el caso de uso

reservar vuelo


35/56

Diagrama de actividad para reservar vuelo (1)


36/56

Diagrama de actividad para

reservar vuelo (2)



37/56


reservar vuelo (3)


38/56

DIAGRAMA DE ESTADOS

Documento de especificación del caso de uso


39/56

Diagrama de máquina de estado

Es opcional

Se utiliza cuando es necesario describir

los estados de un objeto• Por ejemplo, el objeto vuelo podría estar

reservado o confirmado.


40/56

ESCENARIOS



41/56


42/56

Escenarios (2)


43/56


44/56

ESCENARIOS PARA EL CASO DE USO RESERVAR

VUELO



45/56


reservar vuelo (1)



46/56


reservar vuelo (2)


47/56

Flujos en el caso de uso reservar vuelo


48/56

Diagrama que muestra el flujo básico y los

alternativos


49/56

Escenariosdel caso de

uso reservar

vueloseleccionados

para la prueba


50/56

ESPECIFICACIÓN DE CASOS DE USO EN

REQUISITEPRO

Demostración


51/56

Especificación de casos de uso en RequisitePro

Creando especificación de casos de uso

Creando requerimiento tipo caso de uso

• Creando un requerimiento hijo tipo caso de uso

Creando requerimiento tipo escenario


52/56

Elaborando el documento de especificación de

casos de uso

Desarrolle la prácticade laboratorio 03:

Creando casos de

uso.


53/56

Preguntas


54/56

¿Qué hemos aprendido?


55/56

Reflexionemos


56/56

Documents

IR14 Creando Casos de Uso