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 anterior | Volver al principio del trabajo | Página siguiente  |