2. Arquitectura Cambiar la Arquitectura de un producto ya construido en general exige mucho esfuerzo => Evaluación de Arquitecturas
2. Arquitectura Cambiar la Arquitectura de un producto ya construido en general exige mucho esfuerzo => Evaluación de Arquitecturas
2. Arquitectura Cambiar la Arquitectura de un producto ya construido en general exige mucho esfuerzo => Evaluación de Arquitecturas
2. Arquitectura Definición, estilos y evaluación:
Un estilo arquitectónico
expresa un esquema de organización estructural para sistemas de software. Provee un conjunto de tipos de elementos predefinidos, especifica sus responsabilidades e incluye reglas y guías para organizar las relaciones entre ellos
2. Arquitectura Estilos
2. Arquitectura Estilos Sommerville
2. Arquitectura Estilos Pressman
2. Arquitectura Definición, estilos y evaluación:
Distintos “estilos” definen familias de sistemas en términos de patrones de organización estructural.
Un estilo de arquitectura implica sus componentes, conectores y exigencias al combinarlos.
Identificarlos y caracterizarlos para facilitar la comunicación entre diseñadores
Arquitectura Influencia y características:
Sus características condicionan las características del producto final:
escalabilidad, capacidad, desempeño, consistencia, mantenibilidad, compatibilidad, etc.
Arquitectura Influencia y características:
Estilo y estructura particular elegidos pueden depender de Requerimientos No Funcionales:
1 – Desempeño: localizar operaciones críticas en un número reducido de subsistemas con poca comunicación. Componentes de grano grueso.
2 – Seguridad: estructurar en capas los recursos más críticos, protegidos por las capas más internas con alto nivel de validación.
3 – Mantenibilidad: componentes autocontenidos que puedan ser intercambiados con facilidad, evitando estructuras de datos compartidas. Componentes de grano fino.
CONFLICTO DE INTERESES: entre los requerimientos 1 y 3, si se tienen ambos se deberá buscar una solución intermedia.
Arquitectura Elementos para la documentación:
SAD (Software Architecture Description) salida del proceso de diseño de arquitectura, donde se incluyen modelos gráficos que muestran perspectivas distintas del sistema y descripciones textuales.
Documentarla para que pueda ser utilizada y mantenida por otros, con suficiente detalle, sin ambiguedades ni repeticiones, registrando decisiones tomadas.
Arquitectura Elementos para la documentación:
Notaciones: UML general, accesible. ADL’s formales, para expertos.
Complejidad se maneja documentando diferentes vistas de la arquitectura, proyección en una dimensión mostrada desde una perspectiva, sin tener en cuenta entidades no relevantes a esa perspectiva.
The “4+1” View Model of Software Architecture – Kruchten’95 Vistas definidas: lógica, procesos, implementación, física y CU. Todas son guiadas por los CU (o escenarios) significativos a la arquitectura
Beneficios esperados:
Mejorar la comunicación entre los distintos interesados: Cliente – diseñadores Diseñadores – desarrolladores
Clarificar intenciones de diseño la arquitectura concebida a menudo se pierde, comunicación en general informal (difícil) Arquitectura
Beneficios esperados:
Proporcionar bases para análisis del diseño predecir desempeño y otras características y ajustar el diseño como tarea rutinaria
Mejorar el mantenimiento gran parte del esfuerzo de mantenimiento se dedica a entender
Identificar cuestiones interesantes incluso careciendo de métodos formales Arquitectura
Métodos para evaluación de arquitecturas:
Analizar la arquitectura para ver si cumple requisitos de calidad establecidos (ej. confiabilidad, interoperabilidad) Preferible realizar evaluaciones tempranas que permitan introducir cambios con menor impacto y mejorar los aspectos de riesgo identificados Evaluaciones a posteriori resultan útiles como forma de aprendizaje y estudio de posibilidades de mejora, por ej. para una nueva versión del producto Software Engineering Institute (SEI) propone: Architecture Tradeoff Analysis Method (ATAM) Software Architecture Analysis Method (SAAM) Arquitectura
Diseño: Arquitectura vs. Programas (Gp:) Implementaciones de partes (Gp:) Interacciones entre partes (Gp:) Muestra (Gp:) Copia de código o llamado a bibliotecas (Gp:) Composición de subsistemas (Gp:) Reutilización (Gp:) Dentro de los límites de módulo (Gp:) Fuera de los límites de módulo (Gp:) Visión (Gp:) Desempeño de algoritmos (Gp:) Desempeño a nivel del Sistema (Gp:) Evaluación (Gp:) En general dinámico (Gp:) En general estático (Gp:) Análisis (Gp:) Propiedades computacionales (Gp:) Propiedades estructurales (Gp:) Considera (Gp:) Programas (Gp:) Arquitectura
Arquitectura–Estilos Flujo de Datos: Secuencial por lotes / Tubos y Filtros/ Circuitos de Control
Llamada y Retorno: Programa Principal y subrutinas / Orientada a Objetos
Componentes Independientes: Procesos que se comunican / Invocación implícita (Eventos)
Centrado en los Datos (repositorios): Bases de Datos / Pizarrones (Blackboards)
Máquinas Virtuales: Intérpretes / Capas Jerárquicas
Específicas del Dominio de Aplicación: Modelos genéricos / Modelos de referencia
Distribuidas: Cliente-Servidor/ Objetos Dists. / Dist. Procesos, datos / SOAs
Heterogéneas y Otras Clasificación Shaw-Garlan, 1996 (1 al 5, 8). Sommerville, 2000 (6 y7 ).
a) Flujo de Datos Características: La disponibilidad de los datos controla la ejecución La estructura del diseño está dominada por el movimiento ordenado de los datos de un componente a otro El patrón del flujo de datos es explícito En un sistema puro no hay otra interacción entre procesos
Ejemplos: Secuencial por lotes (dominada por actualización de BD) Tubos y Filtros – Filtros conectados en un grafo de flujo de datos Circuitos de Control de Procesos
a) Flujo de Datos: Tubos y Filtros Características: Por los tubos fluyen datos, transmisión de salidas de un filtro a la entrada de otro Cada filtro admite una o varias entradas (tubos) y una o varias salidas (tubos) Cada filtro es independiente del resto y no conocen la identidad de los filtros antes y después de él La transformación del filtro puede comenzar antes de terminar de leer la entrada (distinto al proceso por lotes) Respetando el grafo, no importa la secuencia (paralelismo)
a) Flujo de Datos: Tubos y Filtros Bondades: Fácil comprender el comportamiento total de entrada/salida del sistema a partir de los efectos de cada filtro (entrada->transformación->salida) Permite reutilización (simplicidad de interfaces, filtros reutilizables) Fácil evolución y mantenimiento (agregar, sustituir, eliminar filtros) Permite evaluar desempeño (independencia de filtros) Permite ejecución en paralelo
Limitaciones: Orientado a procesamiento por lotes (no interactivo) Necesidad de consistencia entre flujos de datos La independencia entre filtros puede acarrear la repetición de procesos de preparación (ineficiencias) (ej. validaciones)
a) Flujo de Datos: Circuitos de Control (de Procesos) Propósito: Proveer control dinámico de un entorno físico. Ej. sistema acondicionamiento ambiental Mantener propiedades específicas de las salidas del proceso dentro o cerca de valores de referencia indicados (puntos fijos o referencias)
Elementos a considerar: Variables a monitorear, sensores a utilizar, su calibración, temporización tanto del sensado como del control.
a) Flujo de Datos: Circuitos de Control (de Procesos) Clasificación:
Bucle con retroalimentación (feedback loop) Mide la variable controlada y ajusta el proceso para mantener el valor cerca o dentro de la referencia. (Gp:) Proceso (Gp:) Controlador (Gp:) Punto de fijación (Gp:) Variable Controlada (Gp:) Cambios en las variables manipuladas
a) Flujo de Datos: Circuitos de Control (de Procesos) Clasificación: Bucle con prealimentación o anticipador (feedforward loop) Mide otras variables del proceso que actúan como indicadores e intenta anticipar los futuros efectos sobre la variable controlada. (Gp:) Punto de fijación (Gp:) variables de Entrada (Gp:) Controlador (Gp:) Cambios en las variables manipuladas (Gp:) Variable Controlada (Gp:) Proceso
Flujo de Control vs. Flujo de Datos Flujo de Control: La cuestión dominante es cómo se mueve el control a través del programa los datos pueden acompañar el control pero no son dominantes el razonamiento se refiere al orden de ejecución
Flujo de Datos: La cuestión dominante es cómo los datos se mueven a través de un conjunto de procesos atómicos a medida que se mueven los datos se activa el control el razonamiento se refiere a la disponibilidad de los datos, su transformación, las demoras
b) Llamada y retorno Programa Principal y Subrutinas: Descomposición Funcional tradicional
Orientada a Objetos (tipos abstractos de datos): Ocultamiento de Información, especialmente de representaciones
Otros Capas Jerárquicas Sistemas Cliente/Servidor Remote Procedure Call
b) Llamada y retorno: Programa Principal y Subrutinas Características:
Descomposición jerárquica: basada en la relación “usa” Único Hilo de Control (Thread of Control): soportado directamente por los lenguajes de programación Estructura de subsistemas implícita: subrutinas agregadas en un módulo Razonamiento jerárquico: que una subrutina sea correcta depende de que sean correctas las subrutinas llamadas
b) Llamada y retorno: Programa Principal y Subrutinas Bondades: Permite analizar los flujos de control y saber como responderá el sistema a cierto tipo de entradas
Limitaciones: Manejo de excepciones
| Página siguiente |