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

1. 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: • Analysis Patterns. Martin Fowler. Addison-Wesley Pub Co; ISBN: 0201895420 • Enlaces: • www.martinfowler.com: autor del libro "Analysis patterns". • http://www.industriallogic.com/patterns/ili_nyc_ap.html: the analysis patterns group. • http://hillside.net/patterns/books/: libros sobre patrones.