7.- Flujo de Análisis7.- Flujo de AnálisisJusto N. Hidalgo SanzJusto N. Hidalgo Sanz

DEPARTAMENTO DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICAINFORMÁTICA

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

Contenidos

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

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Boundary Class Control Class Entity Class

Clase de Análisis

•Tipos de clases:•Boundary•Control•Entity

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

Actividades de Análisis

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

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

Ejemplo

Aplicación de realización de tests. Aunque en realidad este caso no requeriría de

análisis, se realiza uno someramente.

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

Patrones de análisis

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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.