Disciplina de Análisis. Casos de Uso.

Transcripción

1 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-0

2 Mapa del Proceso. Ingeniería de Software. Casos de Uso (parte 2) Página 8-1

3 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 Descripción Actores Prioridad Riesgo Identificación y nombre del caso (del SRS). Una o dos líneas que describen el propósito del caso de uso. Lista de todos los actores que pueden hacer este caso de uso. La prioridad del caso de uso (del SRS). 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-2

4 Formas de Casos de Uso (2). Elemento Descripción Pre-condiciones y suposiciones Disparador Flujo de eventos Flujos alternos Post-condiciones Requerimientos nofuncionales Acciones anteriores al caso de uso. Actividades que hacen que inicie el caso de uso. El flujo normal del escenario principal del caso de uso. Flujo de escenarios secundarios. Acciones que ocurren como consecuencia de este caso de uso. 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-3

5 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-4

6 Ejemplo, paso 1. Llene los valores de los elementos que aparecen en el SRS. Elemento ID y nombre del caso de uso Descripción Actores Prioridad Riesgo Descripción E1: Manejar Reservación. Crear, consultar, actualizar o borrar reservaciones Primario: agente de reservaciones Secundario: recepcionista, gerente, propietario Esencial E1-102 (rendimiento) E1-105 (escalabilidad) E1-108 (confiabilidad) Ingeniería de Software. Casos de Uso (parte 2) Página 8-5

7 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-6

8 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-7

9 Ejemplo, paso 4. Determine el flujo de eventos a partir del escenario primario. Elemento Descripción Flujo de Eventos 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-8

10 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-9

11 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-10

12 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 8-11

13 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-12

14 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-13

15 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-14

16 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-15

17 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-16

18 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-17

19 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-18

20 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-19

21 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-20

22 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-21

23 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-22

24 Ejemplo Completo. Ingeniería de Software. Casos de Uso (parte 2) Página 8-23

25 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-24

26 Elementos del Diagrama de Actividades. Ingeniería de Software. Casos de Uso (parte 2) Página 8-25

27 Elementos del Diagrama de Actividades (2). Ingeniería de Software. Casos de Uso (parte 2) Página 8-26

28 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-27

29 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-28

30 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-29

31 Iteraciones. Las iteraciones se indican mediante nodos de bifurcación. Ingeniería de Software. Casos de Uso (parte 2) Página 8-30

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

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

34 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-33

35 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-34

36 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-35

37 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. Ingeniería de Software. Casos de Uso (parte 2) Página 8-36