tema 8: análisis y especificación de requisitos · análisis y especificación de requisitos...

Tema 8: Análisis y Especificación de Requisitos

Departamento de Lenguajes y Sistemas Informáticos II

www.kybele.urjc.es

Análisis y especificación de requisitos www.kybele.urjc.es

Requisitos

Análisis

Diseño

Implementación

Pruebas

Concepción Elaboración Construcción Transición

Iteración

preliminarItera.

#1

Itera.

#2

Itera.

#n

Itera.

#n+1

Itera.

#n+2

Itera.

#m

Itera.

#m+1

Flujos de Trabajo

Fases

Iteraciones

Introducción

3


Índice

Introducción

ArtefactosModelo de análisis

Clases de análisis

Realización en análisis de los casos de uso

Paquetes de análisis

ActividadesAnálisis de los casos de uso

Análisis de las clases

Análisis de los paquetes

4


Introducción

Durante la captura de requisitos:Lenguaje del cliente

Buscar acuerdo

Pueden quedar aspectos sin resolver Los CU deben mantenerse tan independientes unos de otros

como sea posible

Los CU deben describirse en el lenguaje del cliente

Cada CU debe formar una especificación de funcionalidad completa e intuitiva

Objetivo del análisis:Analizar los requisitos en profundidad

En el lenguaje de los desarrolladores

5


Introducción

En el análisis:Tratamos aspectos internos

Resolvemos problemas de interferencia, etc. de CU

Usamos un lenguaje más formal

Es decir, refinamos los requisitos, para facilitarComprensión

Preparación

Modificación

Mantenimiento…

Mediante: clases de análisis y paquetesTrazabilidad

6


Introducción

Utilizaremos diferentes diagramas para expresar el modelo de análisis

Modelo de casos de uso Modelo de análisis

Lenguaje del cliente Lenguaje del desarrollador

Vista externa del sistema Vista interna del sistema

Estructurado en casos de uso Estructurado en clases de análisis y paquetes

Como contrato Como precursor del diseño

Puede contener redundancias, inconsistencias (entre requisitos)

No debería contener redundancias inconsistencias (entre requisitos)

Captura la funcionalidad del sistema Da forma a la arquitectura para soportar tal funcionalidad

7


Introducción

En los requisitos

Pensamos en el sistema desde fuera

En el análisis

Pensamos en el sistema desde dentro

Primera aproximación al modelo de diseño e implementación

Pero no siempre se puede conservar, ya que los aspectos de la plataforma de implementación se abordan en el diseño

Es importante tener una comprensión completa y precisa de los requisitos antes del diseño

8


Introducción

Ejemplos de cuándo hacer análisis y cómo usarlo

Para poder planificar diseño e implementación de cada incremento analizado

Proporciona una visión general del sistema, incluso a posteriori

Para llevar a cabo diseños e implementaciones alternativas

Para hacer reingeniería con un sistema heredado

9


Introducción

Modelo de análisis

Modelo de diseño

Modelo de despliegue

Modelo de implementación

Modelo de pruebas

Modelo de casos de uso

Especificado por

Soportado por

Distribuido por

Implementado por

Verificado por

Modelo de análisis

Modelo de análisis

Modelo de diseño

Modelo de despliegueModelo de despliegue



Modelo de pruebas

Modelo de casos de usoModelo de

casos de uso

Especificado por

Soportado por

Distribuido por

Implementado por

Verificado por

10


Requisitos

Pruebas

Implementación

Diseño

Análisis

Modelo de

Despliegue

Modelo de

Análisis

Modelo de

Diseño

Modelo de

Implementación

Modelo de

Pruebas

Modelo de

Casos de Uso

dependencia de traza

Introducción

Relación externa al modelo,

entre dos elementos,

que representan el mismo

concepto con niveles de

significado diferentes y

con reglas específicas

para derivar uno de otro.El modelo

de análisis

se realiza

a partir de

los

casos

de uso

11


Modelo de

Caso de Uso

Modelo de

Análisis

Modelo de

Diseño

Modelo de

Pruebas

Modelo de

Despliegue

Modelo de

Implementación

Diagramas de

Casos de Uso

Diagramas de

Clases

Diagramas de

Componentes

Diagramas de

Despliegue

Diagramas de

Secuencias

Diagramas de

Colaboraciones

Diagramas de

Estados

Diagramas de

Actividad

Diagramas de

Objetos

Incluidos paquetes

Diagramas de

Interacción

Introducción

12


Gestionar asignaturas Realización en análisis

UI asignaturas Gestor de asignaturas Asignatura

participante

Introducción

Modelo de análisis:

Especificación detallada (precisa) de requisitos.

Refina los casos de uso como colaboraciones entre clasificadores:

Clasificadores: clases de análisis, paquetes

Colaboraciones: realizaciones de los casos de uso.

13


Índice

Introducción


Clases de análisis






14


Artefactos. Modelo de análisis

Representa la estructura global del sistema (subsistemas y/o capas en el modelo de diseño).

*

Clase de análisis

Paquete de análisis

Realización

en análisis

Modelo de análisis

*

**

* *

Diagramas de clases

Diagramas de interacción

Descripción textual

Interfaz Control Entidad

Responsabilidades

Atributos

Relaciones

Descripción

arquitectónica

15


Índice

Introducción


Clases de análisis






16


Clase de análisis

Interfaz Control Entidad

Resposabilidades

Atributos

Relaciones

Artefactos. Clases de análisis

Representa una abstracción de lo que serán una o varias clases en diseño.

Se centra en los requisitos funcionales.

17


Utilizamos el ejemplo….

Un sistema de enseñanza virtual

Actor: Estudiante

Caso de Uso: Matricularse

…

Estudiante

Matricularse

Sist. de enseñanza virtual

Matricularse

18



Clases límite o interfaz

Modelan la interacción entre el sistema y los actores u otros sistemas

IU Matriculación

IU Matriculación

<<boundary>>

IU Matriculación

19



Clases límite o interfaz

Representan la interfaz del sistema (ventanas, formularios, ...), pero con poco detalle.

Describen la información presentada al actor y las peticiones que hace el actor al sistema

Estudiante UI Matriculacion

20



Clases Entidad

Representan la información significativa para el sistema.

Modelan la información de larga vida (persistencia).

Pueden provenir de las entidades del dominio o de las del negocio, pero no tienen por qué corresponderse completamente

Alumno

AlumnoAlumno

<<entity>>

21



Clases Entidad

Pueden ser pasivas o activas (comportamiento complejo).

Encapsulan información y operaciones asociadas.

Por ejemplo: repositorios de información.

Estudiante UI Matriculacion AlumnoGestorMatricula

22



Clases Control

Se usan para representar el control de un caso de uso concreto

Representan la coordinación entre objetos

GestorMatriculaGestorMatricula

<<control>>

GestorMatricula

23



Clases Control

Lógica del negocio, cálculos que no se puede asignar a una información concreta .

No representan ni interacciones con el usuario ni problemas de almacenamiento de información.

Estudiante UI Matriculacion GestorMatricula

24


Índice

Introducción


Clases de análisis






25


Artefactos. Realización en análisis de los casos de uso

Es una colaboración que describe cómo se realiza en análisis un caso de uso en términos de clases de análisis y sus interacciones.

Modelo de casos

de uso

Modelo de análisis

Use case Realización en análisis

<<trace>>

26



La realización en análisis de un caso de uso incluye:

Diagramas de clases: clases participantes

Diagramas de interacción: escenarios del CU

Descripción textual del flujo de eventos

Requisitos no funcionales si aparecen (si no se deja para el diseño)

27


Artefactos. Realización en análisis de los casos de uso. Diagramas de clases

Una clase de análisis puede participar en varias realizaciones

Algunas responsabilidades, atributos y asociaciones suelen ser relevantes para una única realización de un caso de uso.

Diagrama de clases para la realización del caso de uso “Matricularse”

Estudiante UI Matriculación Gestor

Matricula

Alumno

28






Descripción textual del flujo de eventos

Requisitos no funcionales si aparecen (si no se deja para el diseño)

30


Artefactos. Realización en análisis de los casos de uso. Diagramas de interacción

La secuencia de acciones en un caso de uso comienza cuando un actor envía un mensaje a un objeto límite.

Se utilizan diagramas de colaboración

: Profesor : UI Profesor : GPub : Asignatura

1: publicar notas

2: visualizar (“¿asignatura?")

3: seleccionar (asignatura, ficheroNotas)

4: publicar (asignatura, ficheroNotas)

5: Notas (ficheroNotas)

6: OK7: OK

8: visualizar (notas publicadas)

31


Artefactos. Realización en análisis de los casos de uso. Flujo de eventos y Requisitos no

funcionales




Descripción textual del flujo de eventos Para clarificar los diagramas de colaboración: descripción

textual

Si es muy complejo ¿no será mejor dividir el caso de uso?

Requisitos no funcionales si aparecen (si no se deja para el diseño) Asignados a casos de uso.

Se recogen si aparecen.

32


Índice

Introducción


Clases de análisis






33


Artefactos. Paquetes de análisis

Para organizar los artefactos de análisis: clases de análisis, realización de casos de uso y otros paquetes.

34

*

Clase de análisis

Paquete de análisis

Realización

en análisis

* *



Fuertemente cohesionados y débilmente acoplados.

La cohesión es la medida cualitativa de lo estrechamente relacionados que están los elementos internos de un módulo

El acoplamiento es un concepto abstracto que nos indica el grado de interdependencia entre módulos.

No existen en tiempo de ejecución.

35



Analizarse de forma separada por diferentes desarrolladores con diferente conocimiento del dominio.

Los paquetes de análisis se deben crear basándonos en requisitos funcionales y en el dominio del problema y deberían ser reconocibles por las personas con conocimiento del dominio. No deben basarse en requisitos no funcionales o en el dominio de la solución.

Los paquetes de análisis probablemente se convertirán en subsistemas en diseño

36


Índice

Introducción


Clases de análisis






37

Análisis y especificación de requisitos www.kybele.urjc.es 38

Actividades del análisis en el PU

La creación del modelo de análisis comienza identificando:los paquetes de análisis

las clases de entidad evidentes

los requisitos comunes.

Esta identificación se realiza de forma continua a medida que el modelo de análisis evoluciona.

Después se realiza cada caso de uso en términos de clases de análisis exponiendo los requisitos de comportamiento de cada clase (creando responsabilidades), atributos y relaciones.

Según se avanza se refinan y mantienen los paquetes de análisis


Actividades del análisis en el PU

Para ilustrar las actividades, utilizaremos el ejemplo del cajero automático.

39


Índice

Introducción


Clases de análisis






40


Actividades. Análisis casos de uso

Identificar las clases de análisis necesarias para la realización del caso de uso.

Distribuir el comportamiento del caso de uso entre las clases de análisis.

Capturar/asignar requisitos no funcionales a clases de análisis.

41


Actividades. Análisis casos de uso. Identificar las clases de análisis

Identificar las clases de análisis

Clases entidad se derivan de la descripción del caso de uso o de las clases del modelo del dominio.

Una clase interfaz por cada actor (protocolo de comunicación).

Una clase de control que gobierne en flujo del caso de uso

Representar las clases de análisis en un diagrama de clases

Considerar las clases ya existentes

42


Análisis del caso de uso: “Validar usuario”

43






44


Actividades. Análisis casos de uso. Distribuir el comportamiento entre las clases

Describir las interacciones entre objetos

Utilizar diagramas de colaboración

instancias y enlaces

1 diagrama de colaboración por cada camino del caso de uso (Escenarios)

Sobre los diagramas de colaboración:

inicia un actor

expresión de las interacciones: mensajes

45






Incorporar a la realización los requisitos especiales, para tratarlos en el diseño (persistencia, transacciones por hora…)

46


Análisis del caso de uso: “Validar usuario” Camino Básico

Caminos alternativos:

“Anular transacción”

“código incorrecto” *

si 3 veces error: cancelar y quedarse con la tarjeta

47


Caso de Uso: Validar Usuario

Camino alternativo: supera los 3 intentos de validación

49


Análisis del caso de uso: “Sacar dinero”

50


Análisis del caso de uso: “Sacar dinero”Camino básico

* MagicDraw: Opción: Show stereotypesText and Icon

51


Análisis del caso de uso: “Sacar dinero”Camino Alternativo: No hay saldo

Falta

en el cajero no hay dinero.

se ha superado el límite diario

* MagicDraw: Opción: Show stereotypesShape Image

52


Análisis del caso de uso: “Ingresar dinero”

55


Análisis del caso de uso: “Transferencia”

Suponemos que el usuario ya ha sido identificado.

La cuenta origen es la de la tarjeta y hay que teclear la de destino.

Comprobar primero si hay saldo y luego sacar

58


Diagrama de clases completo (ejemplo)

62


Índice

Introducción


Clases de análisis






63


Actividades. Análisis de las clases

Identificar las responsabilidades

Identificar atributos

Identificación de asociaciones y agregaciones

Identificación de generalizaciones

Capturar requisitos especiales

64



Identificar responsabilidades

En cada caso de uso, ver qué papel juega (diagramas de colaboración).

Combinar papeles y describirlos juntos.

65


Análisis de las clases. Identificar responsabilidades. “Validar usuario”. Secuencia correcta

66

IU Cajero

Usuario

Mostrar (Ingrese Clave)

Mostrar (Seleccione Opción)

Leer Tarjeta

Validar (DatosTarjeta, Clave)

Leer Clave

Gestor de Autenticación


Mostrar (Mensaje)


Análisis de las clases. Identificar responsabilidades“Validar usuario”. Código incorrecto

67

IU Cajero

Usuario

Leer Tarjeta


Leer Clave



Mostrar (Mensaje)

IU Cajero

Usuario

Leer Tarjeta


Leer Clave



Mostrar (Mensaje)


Análisis de las clases. Identificar responsabilidades“Sacar dinero”. Secuencia correcta

68

IU Cajero

UsuarioLeer Tarjeta


Leer Clave



Mostrar (Mensaje)

Entregar Dinero (Cantidad)

Leer importe

Usuario



Entregar Tarjeta

Cuenta

Egreso (Cantidad)

Sacar (Cantidad)

Gestor de Sacar Dinero








69




Suelen ser nombres.

Los tipos son conceptuales

Clases entidad: derivados del dominio.

Clases interfaz con actores humanos: campos de texto, etiquetas, etc

Clases interfaz con subsistemas externos: propiedades de la interfaz de comunicación.

Clases control: estado de la sesión actual.

70


Análisis de las clases. Identificar atributos“Validar usuario”. Secuencia correcta

71

IU Cajero


Usuario

DatosTarjeta

DatosTarjeta, Clave


Análisis de las clases. Identificar atributos“Transferencia”. Secuencia correcta

72

Interfaz de cajero Gestor de Autenticación

UsuariosDelBanco

DatosTarjeta

DatosTarjeta,Clave

Gestor de Transf.

Cantidad

Cuenta

Saldo



Clase Atributos Responsabilidades

IU Cajero “Definir IU” Mostrar (mensaje)

Leer (tarjeta); leer (clave)

Leer (cantidad)

Entregar Dinero (cantidad)

ContarBilletes

Validar (Cantidad)Leer (opciones)

Usuario DatosTarjeta, Clave Validar (DatosTarjeta, Clave)

Cuenta Saldo

Límite diario


Gestor de Autenticación Nro de Cuenta Validar (DatosTarjeta, Clave)

Gestor de Sacar Dinero Cantidad Sacar (Cantidad)

Gestor de Transferencia Cantidad transferencia (NroCuenta, Cantidad)

… … …

73






Definir multiplicidad y papeles

Agregación y composición

Identificar generalizaciones y/o especializaciones entre clases



74







Para extraer comportamiento compartido y común entre clases de análisis, a nivel alto


Requisitos no funcionales asociados a una clase de análisis que se tratarán en diseño e implementación

75


Índice

Introducción


Clases de análisis






76


Actividades. Análisis de los paquetes

Con el objetivo de refinarlos

Paquetes débilmente acoplados

Elementos cohesionados

Se identifican las clases que tienen la dependencia con clases de otros paquetes para:

estimar el efecto de cambios futuros

reubicar clases contenidas en paquetes que son demasiado dependientes de otros paquetes.

77


Bibliografía

El Proceso Unificado de Desarrollo de Software. I. Jacobson, G. Booch y J. Rumbaugh. PearsonPrentice-Hall 2007

78

tema 8: análisis y especificación de requisitos · análisis y especificación de requisitos...

Documents