DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

Presentación del tema: "DEPARTAMENTO DE INGENIERÍA INFORMÁTICA"— Transcripción de la presentación:

1 DEPARTAMENTO DE INGENIERÍA INFORMÁTICA
7.- Flujo de Análisis Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

2 Contenidos Introducción Utilidad del análisis
Secuencia básica de tareas Artefactos Actividades de análisis Patrones de análisis

3 Introducción El análisis estructura los requerimientos y los expresa en el lenguaje de los desarrolladores. Adopta un punto de visto interno frente al externo que es adoptado en la recolección de requerimientos y tiene como objetivo identificar la estructura básica de componentes del sistema.

4 Utilidad del Análisis El análisis es útil fundamentalmente para:
Tener una visión general del sistema antes del diseño. Pueden diseñarse en cada iteración pequeñas porciones del sistema, pero el modelo de análisis proporciona la visión general precisa para planificar y realizar estas iteraciones. Proporcionar una visión general fácilmente entendible por nuevas incorporaciones al proyecto sin necesidad de introducirse en las complejidades del diseño. Diseños/implementaciones alternativas: el análisis provee una visión conceptual.

5 Secuencia básica de tareas
Arquitecto: análisis inicial de la arquitectura, identificando los paquetes de análisis fundamentales, las clases de entidad más evidentes y requerimientos comunes. Ingenieros de casos de uso: realización de cada caso de uso en términos de las clases de análisis, estableciendo el comportamiento de estas clases. Ingenieros de componentes : para cada clase de análisis un conjunto de atributos, relaciones y responsabilidades que permita plasmar todas las responsabilidades de la clase en todos los casos de uso. Arquitecto+Ingenieros de casos de uso: nuevos paquetes de análisis, clases, etc. que se van también definiendo y refinando por parte de los ingenieros de componentes.

6 Realidad del análisis El análisis no siempre se sigue actualizando a lo largo de todo el ciclo de creación del software. En la práctica, para la mayoría de proyectos, estas labores puede hacerlas todas una única persona.

7 Artefactos (I) Clase de análisis Manejo de requisitos funcionales
Mayor granularidad que las clases de diseño. Definición de responsabilidades poco formal -descripción textual-. Definición de atributos de muy alto nivel. Relaciones entre clases sin mucho detalle. Tipos de clases: Boundary Control Entity

8 Artefactos (II): Clases Boundary
Modela la interacción entre el sistema y sus actores -usuarios y sistemas externos-. Modela las partes del sistema que dependen directamente de los actores. SUELEN ser abstracciones de ventanas, formularios, interfaces de comunicación, terminales, APIs, … Ejemplo: interfaz de usuario para TPV

9 Artefactos (III): Clases Entity
Modela información de larga duración y generalmente persistente Bases de Datos, repositorios de información, … Aunque normalmente tiene un comportamiento pasivo, no tiene que ser así. Ejemplo: Stock de la tienda

10 Artefactos (y IV): Clases Control
Representan la lógica de negocio de la aplicación, el control, coordinación, secuencia de objetos. Ejemplo: Lógica de acceso al stock del TPV.

11 Actividades de Análisis
Análisis de Arquitectura Análisis de Casos de Uso Analizar una clase Analizar un paquete

12 Actividad: Análisis de Arquitectura (I)
Actividad desarrollada por el arquitecto. Básicamente: identificación de los paquetes y clases más evidentes y requisitos especiales comunes. Entradas: Modelo de casos de uso. Descripción de requerimientos adicionales. Descripción de la arquitectura -casos de uso relevantes para la arquitctura-.. Modelo de negocio -si existe-. Salidas: Paquetes de análisis Clases de análisis Descripción de arquitectura con la parte de análisis relevante para la arquitectura.

13 Actividad: Análisis de Arquitectura (y II)
Pasos: Identificar paquetes de análisis Concepto de paquete. Para: Casos de uso de un determinado actor o grupo de actores. Casos de uso necesarios para un caso concreto de negocio. Casos de uso relacionados a través de generalizaciones y extensiones. Identificar clases entity En este momento pueden identificarse algunas entity clases obvias, aunque será durante el análisis de los casos de uso cuando surgan casi todas. Identificar requerimientos especiales comunes Requerimientos no funcionales, restricciones en cuanto a seguridad, eficiencia, tolerancia a fallos, etc.

14 Actividad: Análisis de Casos de Uso
Para cada caso de uso: Identificación de las clases que participan. Requerimientos especiales en la realización del caso de uso. Para la identificación de clases: Obtener primero las clases entity. Identificar una clase interfaz para cada actor humano. Identificar una clase interfaz para cada clase entity. Identificar una clase interfaz para cada actor externo Identificar una clase de control -al menos- para el manejo de la coordinación del caso de uso: Más si es necesario. Ninguna si las clases interfaz se ocupan de ello… generalmente no.

15 Actividad: Análisis de una clase
Identificación y mantenimiento de las responsabilidades de cada clase. Identificación y mantenimiento de atributos y relaciones. Identificación de generalizaciones. Capturar de requer¡mientos especiales en la realización de la clase.

16 Actividad: Análisis de un paquete
Agrupación de clases con comportamiento común en paquetes. Propósito: Asegurarse de que el paquete es tan independiente como sea posible. Asegurarse de que cumple su propósito de realizar un conjunto de casos de uso. Describir dependencias entre paquetes para poder estimar el impacto de cambios en el futuro.

17 Ejemplo Aplicación de realización de tests.
Aunque en realidad este caso no requeriría de análisis, se realiza uno someramente.

18 Patrones de análisis

19 Bibliografía Libros: Enlaces:
Analysis Patterns. Martin Fowler. Addison-Wesley Pub Co; ISBN: Enlaces: autor del libro "Analysis patterns". the analysis patterns group. libros sobre patrones.