Ingeniería de Software. Casos de Uso (parte 2) Página 8-0
Ingeniería de Software.
Disciplina de Análisis.
Casos de Uso.
(Segunda Parte, Formas de Casos de Uso, Refinación del Diagrama de Casos de Uso y
Diagrama de Actividades)
Ingeniería de Software. Casos de Uso (parte 2) Página 8-1
Mapa del Proceso.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-2
Formas de Casos de Uso.
Las formas de casos de uso son una herramienta para registrar el
análisis detallado de cada caso de uso y sus escenarios.
Elemento Descripción
ID y nombre del caso de uso Identificación y nombre del caso (del SRS).
Descripción Una o dos líneas que describen el propósito del
caso de uso.
Actores Lista de todos los actores que pueden hacer
este caso de uso.
Prioridad La prioridad del caso de uso (del SRS).
Riesgo La calificación (alto, mediano, bajo) del riesgo
de este caso de uso.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-3
Formas de Casos de Uso (2).
Elemento Descripción
Pre-condiciones y
suposiciones
Acciones anteriores al caso de uso.
Disparador Actividades que hacen que inicie el caso de
uso.
Flujo de eventos El flujo normal del escenario principal del caso
de uso.
Flujos alternos Flujo de escenarios secundarios.
Post-condiciones Acciones que ocurren como consecuencia de
este caso de uso.
Requerimientos no-
funcionales
Lista de los NFRs relacionados a este caso de
uso. (Se pueden sumarizar o poner sus claves)
Ingeniería de Software. Casos de Uso (parte 2) Página 8-4
Creación de la Forma de Casos de Uso.
1. Llene los valores de los casos de uso que aparecen en el SRS.
2. Determine las pre-condiciones a partir de los escenarios.
3. Determine los disparadores a partir de los escenarios.
4. Determine el flujo de eventos a partir del escenario primario.
5. Determine los flujos alternos a partir de los escenarios secundarios.
6. Determine las post-condiciones a partir de los escenarios.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-5
Ejemplo, paso 1.
Llene los valores de los elementos que aparecen en el SRS.
Elemento Descripción
ID y nombre del caso de uso E1: Manejar Reservación.
Descripción Crear, consultar, actualizar o borrar
reservaciones
Actores Primario: agente de reservaciones
Secundario: recepcionista, gerente, propietario
Prioridad Esencial
Riesgo E1-102 (rendimiento)
E1-105 (escalabilidad)
E1-108 (confiabilidad)
Ingeniería de Software. Casos de Uso (parte 2) Página 8-6
Ejemplo, paso 2.
Determine las pre-condiciones a partir de los escenarios. El primer
párrafo de un buen escenario debe describir el estado del sistema
antes de que el caso de uso empiece. Estas son las pre-condiciones.
Elemento Descripción
Pre-condiciones y
suposiciones
El agente de reservaciones espera llamadas de
los clientes.
La pantalla principal de HotelApp está
desplegada.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-7
Ejemplo, paso 3.
Determine los disparadores a partir de los escenarios. El párrafo de
inicio del escenario debe establecer cómo sabe el actor cuando se
inicia el caso de uso.
Elemento Descripción
Triggers Se recibe una llamada de un cliente que solicita
hacer una reservación.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-8
Ejemplo, paso 4.
Determine el flujo de eventos a partir del escenario primario.
Elemento Descripción
Flujo de Eventos ---
3. el agente busca el tipo de cuarto
4. el sistema despliega los cuartos disponibles
del tipo buscado en el rango de fechas
deseado por el cliente.
5. el agente selecciona un cuarto.
---
Ingeniería de Software. Casos de Uso (parte 2) Página 8-9
Ejemplo, paso 5.
Determine los flujos alternos a partir de los escenarios secundarios.
Elemento Descripción
Flujos Alternos En el paso 4, si no hay cuarto disponible del
tipo deseado por el cliente, el agente le
pregunta si quiere alguno de los disponibles o
diferente rango de fechas y regresa al paso 3.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-10
Ejemplo, paso 6.
Determine las post-condiciones a partir de los escenarios. Un buen
escenario de un caso de uso debe describir el estado del sistema al
finalizar el caso de uso. Estas son las post-condiciones.
Elemento Descripción
Post-condiciones La reservación se guarda en la base de datos.
Se cierra la forma de reservación.
Se despliega la pantalla principal de HotelApp.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-11
Expansión de Casos de Uso Generales.
• Algunos casos de uso capturados durante la obtención derequerimientos pueden ser demasiado generales. En estassituaciones es útil introducir nuevos casos de uso más específicos.
• Por ejemplo:
Ingeniería de Software. Casos de Uso (parte 2) Página 8-12
Expansión de Casos de Uso Generales (2).
• "Manejar" o “administrar” una entidad implica Crear (Create),
Consultar (Retrieve), Actualizar (Update) y Borrar (Delete), lo
que se conoce en inglés como operaciones CRUD.
• Las operaciones CRUD generalmente se convierten en casos
de uso derivados del de “Manejar” o “Administrar”.
• Puede haber otros casos de uso generales que se pueden
identificar analizando los escenarios, si hay flujos
significativamente diferentes, hay que considerar hacer otros
casos de uso.
• Si varios escenarios tienen diferentes puntos de partida,
representan diferentes casos de uso.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-13
Expansión de Casos de Uso Generales (3).
Ejemplo:
Note que la expansión crea más asociaciones.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-14
Análisis de Patrones de Herencia.
• En los diagramas de Casos de Uso, puede haber herencia
tanto para actores como para casos de uso.
• Un actor puede heredar todas las asociaciones del actor
padre.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-15
Herencia de Actores.
Un actor puede heredar todas las asociaciones del actor padre.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-16
Especialización de Casos de Uso.
• Un caso de uso puede ser extendido (en el sentido de
subclase) en varios casos de uso especializados.
• Las especializaciones de casos de uso normalmente se
identifican por variaciones en los escenarios.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-17
Análisis de Dependencias de Casos de Uso.
Un Casos de Uso puede depende de otros casos de uso
en dos formas.
• Un caso de uso a puede incluir otro caso de uso b. Esto
significa que el caso a requiere la funcionalidad del caso b y
siempre realiza el caso incluido b.
• Un caso de uso a puede extender otro caso de uso b. Esto
significa que el caso a puede (opcionalmente) usar la
funcionalidad del caso b, de manera que es extendido.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-18
La Dependencia «include».
• La dependencia include permite identificar conductas del sistema que son comunes a varios casos de uso.
• Por ejemplo:
Ingeniería de Software. Casos de Uso (parte 2) Página 8-19
La Dependencia «include» (2).
• Cómo identificar y registrar conductas comunes:
– Revisar los escenarios buscando funciones similares.
– Nombrar estas funciones y colocarlas en el Diagrama de Casos
de Uso con la dependencia «include».
• Por ejemplo:
Ingeniería de Software. Casos de Uso (parte 2) Página 8-20
La Dependencia «include» (3).
• Cómo identificar y registrar conducta asociada con un sistema externo:
• Revisar los escenarios buscando secuencias de funcionalidad que involucre algo externo:
– Nombrar estas funciones y colocarlas en el Diagrama de Casos de Uso con la dependencia «include».
• Por ejemplo:
Ingeniería de Software. Casos de Uso (parte 2) Página 8-21
La Dependencia «extend».
• Esta dependencia permite identificar conductas del
sistema que no son parte del flujo principal, pero existen
en escenarios alternos.
• Por ejemplo:
Ingeniería de Software. Casos de Uso (parte 2) Página 8-22
La Dependencia «extend» (2).
• Cómo identificar y registrar conductas asociadas con un caso
de uso alterno:
– Revisar los diferentes escenarios buscando secuencias
cohesivas y significativas.
– Nombrar estas funciones y colocarlas en el Diagrama de Casos
de Uso con la dependencia «extend».
• Por ejemplo:
Ingeniería de Software. Casos de Uso (parte 2) Página 8-23
Ejemplo Completo.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-24
Validación de Casos de Uso con Diagramas de
Actividades.
• Los diagramas de actividades representan el flujo de eventos
de un caso de uso.
• Se puede validar el caso de uso revisando el diagrama de
Actividades con los involucrados del cliente.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-25
Elementos del Diagrama de Actividades.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-26
Elementos del Diagrama de Actividades (2).
Ingeniería de Software. Casos de Uso (parte 2) Página 8-27
Actividades.
• Una actividad es cualquier proceso o acción que realiza el
sistema o un actor.
• Las actividades se pueden escribir:
– en lenguaje natural.
• por ejemplo: leer el cliente
– en pseudocódigo.
• por ejemplo cust = retrieve customer
– en un lenguaje de programación específico.
• por ejemplo: cust = customerSvc.getCustomer(custID);
Ingeniería de Software. Casos de Uso (parte 2) Página 8-28
Flujo de Control.
• Un diagrama de actividades debe empezar con un nodo de
Inicio y terminar con un nodo de Fin.
• El flujo en sí se indica mediante flechas que unen las
actividades.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-29
Bifurcaciones.
Los nodos de bifurcación (branch) y unión (merge) representan
flujos condicionales de la actividad
• Un nodo de bifurcación tiene dos salidas, con predicados
booleanos para indicar la selección de la condición.
• El nodo de unión colapsa las ramas condicionales.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-30
Iteraciones.
Las iteraciones se indican mediante nodos de bifurcación.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-31
Flujo de Control Concurrente.
Las barras de separación (fork) y unión (join) indican el flujo de
control concurrente.
• Las barras pueden representar actividades realmente paralelas
(realizadas en multi-threading) o actividades que el usuario
realiza en paralelo.
• El indicador de multiplicidad especificar cuantas veces se pueden
realizar las actividades paralelas.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-32
Creación del Diagrama de Actividades.
Analizar el flujo de eventos en la forma de Casos de Uso para:
• Identificar actividades.
• Identificar bifurcaciones e iteraciones.
• Identificar actividades concurrentes.
Ingeniería de Software. Casos de Uso (parte 2) Página 8-33
Actividades del Caso de Uso.
Cada elemento del Flujo de Eventos de la
Forma de Casos de Uso se convierte en una
actividad.
1. Customer calls BookingAgent
2. BookingAgent selects“Make Reservation” icon.
3. BookingAgent enters search criteria
3.1 BookingAgent enters arrival and departure dates
3.2 BookingAgent enters type of room
4. BookingAgent presses the “Search” button
---
Ingeniería de Software. Casos de Uso (parte 2) Página 8-34
Bifurcaciones.
11. BookingAgent enters customer name
12. BookingAgent presses the “Search” button
13. If a customer match is not found
13.1 BookingAgent enters address info
13.2 BookingAgent enters phone info
13.3 BookingAgent presses “Add New Customer”
14. Else
14.1 The system display match list
14.2 BookingAgent selects the correct customer
14.3 The System populates the GUI with customer info
---
Ingeniería de Software. Casos de Uso (parte 2) Página 8-35
Flujo Concurrente.
1. Customer calls BookingAgent
2. BookingAgent selects“Make Reservation” icon.
3. BookingAgent enters search criteria
3.1 BookingAgent enters arrival and departure dates
3.2 BookingAgent enters type of room
4. BookingAgent presses the “Search” button
---
Ingeniería de Software. Casos de Uso (parte 2) Página 8-36
Ejercicios.
1. Dibujar el diagrama de Casos de Uso refinado para el
Sistema RentLimo.
2. Escribir la Forma del Caso de Uso E1: Manejo de
Reservaciones de RentLimo.
3. Dibujar el Diagrama de Actividades para el Caso de Uso
E1: Manejo de Reservaciones del RentLimo.
Top Related