Beneficios esperados de prestarle atención:
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 gral. informal (difícil) 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 2. Arquitectura (4)
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) 2. Arquitectura (5)
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 (Garlan&Shaw, Sommerville,otros) 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
1 – Flujo de Datos Caracterizadas por: 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
Tubos y Filtros (1) 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)
Ejemplo: pipelines (Unix)
Filtro Tubo
Tubos y Filtros (2) 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)
Circuitos de Control (de Procesos) (1) Propósito: Proveer control dinámico de un entorno físico. Ej. sist. acond. 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. 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. 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.
Circuitos de Control (de Procesos) (2) Proceso Controlador variables de Entrada Punto de fijación Variable Controlada Cambios en las variables manipuladas Bucle con retroalimentación (feedback loop): Bucle anticipador (feedforward loop): variables de Entrada Punto de fijación Controlador Cambios en las variables manipuladas Variable Controlada 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
2 – 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
Programa Principal y Subrutinas (1) 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 Bondades: Permite analizar los flujos de control y saber como responderá el sistema a cierto tipo de entradas Limitaciones: Manejo de excepciones
Programa Principal y Subrutinas (2) Principal Subr. A Subr.B Subr.C Subsistema Llamado/Retorno
Orientada a Objetos (1) Caracterizada por: La solución está compuesta por un conjunto de agentes que interactúan Representación de datos y operaciones asociadas se encapsulan en un objeto o TAD. Herencia, Polimorfismo, Sobrecarga de operadores, enlace dinámico Bondades: Facilita el Mantenimiento (localización de impacto) Promueve la reutilización de componentes Permite cambiar la implementación de un objeto sin afectar al resto Limitaciones: Un objeto debe conocer las interfaces de aquellos que utiliza Si se cambia una interfaz, se afectan todos los que la utilizan
Orientada a Objetos (2) Llamado Objeto
3 – Componentes Independientes Procesos que se comunican Pasan mensajes a los participantes conocidos Sistemas guiados por eventos Invocación implícita de participantes desconocidos Otros Envíos de mensajes múltiples con enlace dinámico
Procesos guiados por interrupciones Controlador de interrupciones pasa el control a algún componente para su procesamiento
Procesos que se comunican (1) Características: Muestra al sistema como un conjunto de unidades ejecutando concurrentemente y sus interacciones. Componentes: procesos independientes típicamente implementados como tareas independientes Conectados por: mensajes punto a punto asincrónicos y sincrónicos RPC y otros protocolos se pueden construir encima Ejemplos: procesos que monitorean ejecución de otros procesos.
Procesos que se comunican (2) Mensaje Proceso
Invocación Implícita (guiada por eventos) Caracterizada por: Se registran procedimientos para los eventos Un componente comunica un evento Cuando se anuncia un evento los procedimientos asociados son invocados implícitamente El orden de invocación es no determinista Bondades: Facilita la reutilización de componentes Fácil cambiar los componentes que atienden un evento Limitaciones: No hay garantías respecto a qué va a pasar frente a un evento (quién responderá ni en que orden se dará la ejecución) Limitaciones en la verificación (comprobar correctitud debido a dependencia del contexto y secuencia de eventos) Ejemplos: Depurador de programas que invoca uno u otro editor
4 – Centrados en los datos (repositorios) Caracterizada por: Hay un almacenamiento central de datos y un conjunto de componentes que operan sobre éste.
Bases de Datos transaccionales gran almacén de datos central orden de operación determinado por la entrada de datos Pizarrón (blackboard) representación central compartida adecuada a una aplicación orden de operación determinado por estado actual de la estructura central Otros Herramientas CASE Sistemas integrados de diseño
Pizarrón (Blackboard) (1) Fuentes de Conocimiento Procesos independientes que corresponden a particiones del conocimiento del mundo y del dominio dependientes de la aplicación Responden a cambios en el pizarrón Estructura de datos del Pizarrón Estado completo de la solución del problema Jerarquía de datos de estado para resolver el problema único medio por el cual las Fuentes de conocimiento interactúan para llegar a la solución Control Guíado enteramente por el estado del pizarrón Las Fuentes de conocimiento responden oportunamente cuando los cambios en el pizarrón aplican Puede implementarse en las FC, en el pizarrón, en un componente separado o cualquier combinación de éstos.
Pizarrón (2) Pizarrón FC 1 FC 7 FC 6 FC 2 FC 3 FC 4 FC 5 Cálculos Memoria (Compartida)
5 – Máquinas Virtuales Intérpretes: crean una máquina virtual cuando no se dispone de la que se desea Capas Jerárquicas: cada capa constituye una máquina virtual que provee servicios a las otras capas Otros: Sistemas basados en Reglas tipo especial de intérpretes procesadores de lenguaje de comandos shells
Intérpretes (1) Características: procesador emulado por software datos representación del programa que se interpreta estado del programa que se interpreta estado interno del intérprete El control reside en el ciclo de ejecución del intérprete
(Gp:) Datos (estado del programa) (Gp:) Programa siendo interpretado (Gp:) Estado interno del interprete (Gp:) Motor de interpretación simulada (Gp:) Memoria (Gp:) entradas (Gp:) salidas (Gp:) Máquina de estado de la ejecución (Gp:) Instrucción seleccionada (Gp:) Datos seleccionados (Gp:) Acceso a datos Recuperar/Almacenar
Intérpretes (2)
Capas Jerárquicas (1) Caracterizada por: Hay diversas capas, cada una provee un conjunto de servicios a las capas superiores y requiere servicios de las inferiores. Modelo estricto: el acceso a servicios de otras capas está limitado, una capa sólo utiliza servicios de la inmediata inferior, y ofrece servicios a la inmediata superior. Sino Modelo relajado. Definición de protocolos mediante los que interactúan las capas Bondades: Facilita la comprensión (basado en niveles de abstracción) Facilita mantenimiento (posible modificar una capa sin afectar al resto) Facilita reutilización Facilita portabilidad Limitaciones: No siempre es fácil estructurar en capas ni identificar los niveles de abstracción a partir de los Requerimientos Puede afectar el desempeño la coordinación entre los niveles
Capas Jerárquicas (2) (Gp:) Usuarios (Gp:) Criptografía (Gp:) Interfaces de Archivos (Gp:) Gestión de Claves (Gp:) Autenticación
Ejemplo: Capas de Sistema de Seguridad
6 – Específicas del dominio de aplicación Modelos específicos para un dominio de aplicación particular Modelos genéricos: Abstracciones de sistemas existentes que encapsulan las características principales de los mismos. A menudo representan la arq. común de una familia de aplicaciones (línea de productos). Ejs. Módulos que se deben incluir en un compilador Modelos de referencia: Modelos abstractos idealizados derivados de un estudio del dominio de aplicación. Proveen información sobre la estructura general del sistema y actúan como estándar contra el cual evaluar sistemas. Ejs. Modelo de capas OSI para sists. de comunicación
7 – Distribuidas Cliente-Servidor: servicios provistos por los servidores y requeridos por los clientes Objetos Distribuidos: objetos brindan y requieren servicios de otros objetos Service Oriented Architecture (SOA): composición de servicios (ej. web-services) Distribución de: Datos (centralizados, distribuidos, replicados) Procesos (fija, variable) Comunicación: Remote Procedure Call Pasaje de mensajes
7 – Distribuidas Características: El procesamiento de la info es distribuído sobre varias computadoras (procesadores) conectados por una red se requiere cierto software de “middleware” para administrar las partes y asegurar comunicación e intercambio de datos el “middleware” es un software de propósito gral. que por lo regular se vende comercialmente, y actúa como mediador entre las partes categorías de “middleware”: monitor transaccional (TPM), remote procedure call (RPC), message oriented mid.(MOM), distributed object mid., database access mid. Bondades: Compartición de recursos, apertura, concurrencia, escalabilidad, tolerancia a fallas, transparencia. Limitaciones: complejidad, seguridad, difíciles de gestionar, poco predecibles
| Página siguiente |