Ingeniería de Software.

Diagramas de Casos de Uso.

(Segunda Parte, Refinación del Diagrama)

Ingeniería de Software. Casos de Uso (parte 2) Página 0

 Mapa del Proceso.

Ingeniería de Software. Casos de Uso (parte 2) Página 1

 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 2

 Formas de Casos de Uso (2).

Elemento Descripción

Pre-condiciones (y Acciones anteriores al caso de uso.

suposiciones)
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- Lista de los NFRs relacionados a este caso de
funcionales uso. (Se pueden sumarizar o poner sus claves)

Ingeniería de Software. Casos de Uso (parte 2) Página 3

 Creación de la Forma de Casos de Uso.

1. Llene los valores de los elementos 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 4

 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 5

 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 El agente de reservaciones espera llamadas de

suposiciones) los clientes.
La pantalla principal de HotelApp está
desplegada.

Ingeniería de Software. Casos de Uso (parte 2) Página 6

 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 7

 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

 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 9

 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 10

 Expansión de Casos de Uso Generales.

• Algunos casos de uso capturados durante la obtención de

requerimientos pueden ser demasiado generales. En estas
situaciones es útil introducir nuevos casos de uso más específicos.

• Por ejemplo:

Ingeniería de Software. Casos de Uso (parte 2) Página 11

 Expansión de Casos de Uso Generales (2).

• "Manejar" 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 12

 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 13

 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.

• Un caso de uso puede ser extendido (en el sentido de

subclase) en varios casos de uso especializados.

Ingeniería de Software. Casos de Uso (parte 2) Página 14

 Herencia de Actores.

Un actor puede heredar todas las asociaciones del actor padre.

Ingeniería de Software. Casos de Uso (parte 2) Página 15

 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 16

 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 17

 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 18

 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 19

 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 20

 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 21

 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 22

 Ejemplo Completo.

Ingeniería de Software. Casos de Uso (parte 2) Página 23

 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 24

 Elementos del Diagrama de Actividades.

Ingeniería de Software. Casos de Uso (parte 2) Página 25

 Elementos del Diagrama de Actividades (2).

Ingeniería de Software. Casos de Uso (parte 2) Página 26

 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 27

 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 28

 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 29
 Iteraciones.
Las iteraciones se indican mediante nodos de bifurcación.

Ingeniería de Software. Casos de Uso (parte 2) Página 30

 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 31
 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 32

 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 33

 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 34

 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 35

 Ejercicios.

1. Elaborar las formas de Caso de Uso para los casos de uso

Registrar Jugador y Crear Calendario del Sistema SATUF.

2. Completar el diagrama de Casos de Uso para el Sistema

SATUF.

3. Elaborar un diagrama de Actividades para el Caso de Uso

Registrar Jugador por un cliente en el Sistema SATUF.

Ingeniería de Software. Casos de Uso (parte 2) Página 36