Introducción a la Arquitectura de Software:

Arquitecturas de Software Genéricas

2012Lic. David Espinoza Robles

FuenteProf. Sergio Ochoa

sochoa@dcc.uchile.cl

DCC, Univ. de Chile

Desmitificando del Tema…

Arquitectura = Diseño

….. pero diseño que funciona!!!

Arquitectura

Arquitectura = Diseño

Estructuración del Sistema

Proceso de Diseño Arquitectónico

• Que se entiende por Diseño Arquitectónico– Comprender el establecimiento de un marco de

trabajo estructural básico para el sistema– Alude a la estructura general de Software.– Esta compuesta par la estructura jerárquica de los

componentes (módulos), la manera en que los módulos interactúan, y la estructura de datos que utilizan los componentes.

• Propiedades de un Diseño Arquitectural:– Propiedades estructurales: define los

componentes de un sistema y la manera en que dichos componentes se agrupan en paquetes e interactúan.

– Propiedades extra funcionales: debe indicar como el diseño arquitectónico alcanza los requisitos no funcionales.

– Familias de Sistemas Relacionados: debe permitir reconocer su estructura en los patrones repetitivos que se encuentran de manera habitual en el diseño de sistema similares. Debe ser capar de reutilizar bloques de construcción arquitectural

• Un Diseño Arquitectural debe describirse Utilizando diferentes tipos de modelos:– Modelos estructurales: representa a la

arquitectura como una colección organizada de componentes.

– Modelo Frameworks: identifica patrones de diseño arquitectónico repetibles que se encuentran en aplicaciones similares.

– Modelos dinámicos: muestra el comportamiento dinámico de la arquitectura, indicando sus cambien en función de eventos externos.

– Modelo de Procesos: se enfoca en el diseño de los procesos de negocio que el sistema debe soportar.

– Modelo Funcional: presenta la jerarquía funcional de un sistema

• Porque es Importante su definición:– Facilita la comunicación de los participantes de un

proyecto de desarrollo.– Resalta las decisiones de diseño que pueden tener

gran impacto en el proceso de desarrollo posterior.– Aporta una visión de cómo estructurar un sistema y

como sus componentes trabajan.

Estructuración del Sistema (1)• … una vez que los requisitos (incluyendo los de

calidad) están claramente especificados, comenzamos a hacer arquitectura del sistema….

• Usualmente se parte por la estructuración de la solución (sistema).

• Se refiere a la descomposición del sistema a través de un conjunto subsistemas relacionados.

• El diseño de la arquitectura es normalmente expresado como un diagrama de bloques, el cual, presenta una vista de la estructura del sistema.

• Muchos modelos específicos muestran cómo los subsistemas comparten los datos, cómo son distribuidos y cómo las interfaces con otros subsistemas pueden ser desarrolladas.

Estructuración del Sistema (2)• Hay varias recomendaciones generales

(soluciones recurrentes) para estructurar un sistema, algunas de ellas son:– Modelo de depósito (o de repositorio)– Modelo Cliente/Servidor– Modelo de máquina abstracta– Mezclas de estos

• Cada uno es más apropiado para apoyar un cierto escenario o conjunto de escenarios.

• Cada uno apunta a potenciar uno (o más) requisitos de calidad.

• Estilos Arquitectónicos:– Modelo de descomposición de sistemas• Modelo de almacén central• Cliente servidor• Modelo de maquina abstracta.

– Modelo e control• Centralizado • Modelo de eventos

– Modelo de descomposición Modular• Modelo de flujo de datos.• Modelo orientado a objetos.

– Modelo de Dominio especifico

• Estilos Arquitectónicos:– Arquitectura Centrada en datos (Repositorio)– Arquitectura centrada en flujo de datos.– Arquitectura llamada y respuesta– Arquitectura de Sistemas Distribuidos• Multi procesador• Cliente Servidor• Objetos distribuidos• Peer to peer

– Arquitectura en capas– Arquitectura orientada a objetos.

Depósito o Repositorio

El Modelo de Depósito o de Repositorio(1)

• Muchos subsistemas intercambian datos. Esto puede darse de dos maneras:

– Los datos compartidos se colocan en una base de datos central o repositorio (alternativa centralizada) y pueden ser accedidos por todos los subsistemas.

– Cada subsistema mantiene su propia base de datos y pasa datos explícitos a otros subsistemas (alternativa distribuida).

• Cuando grandes cantidades de datos son compartidos, el modelo de repositorio es el más comunmente utilizado.

Repositorio: Modelo Estructural

Editor deDiseños

Generador deCódigo

Empaquetador Repositorio de ProyectosEditor deProgramas

Analizadorde Diseños

Generador de Reportes

Ejemplo: Arquitectura de una herramienta CASE tradicional

Características del Modelo de Repositorio (1)

Como todos los modelos, éste tiene ventajas y desventajas.

• Ventajas– Es una forma eficiente de compartir grandes volúmenes

de datos. – Los sub-sistemas que producen datos no necesitan saber

cómo estos datos serán utilizados.– Proporciona un manejo centralizado de los datos

producidos, lo cual facilita su administración (respaldo, seguridad, etc).

– El modelo permite compartir facilmente los datos del repositorio, con todos los subsistemas (existentes o futuros).

– El sistema se vuelve más fácil de mantener, extender y escalar.

Características del Modelo de Repositorio (2)

• Desventajas– Los sub-sistemas deben hacer coincidir sus modelos de

datos, con el del repositorio, lo cual es inevitablemente un compromiso.

– Los cambios en el modelo de datos son caros y difíciles de implementar.

– El modelo de repositorio fuerza a que todos los subsistemas unifiquen la política de administración de sus datos.

– El repositorio se vuelve un punto vulnerable. Por otra parte, es dificil distribuir el repositorio en diferentes máquinas, ya que esto tiene una complejidad y un costo similar a las B.D. distribuidas.

– El conocimiento del negocio está distribuido (y a veces replicado) en diferentes subsistemas.

Repositorio: Modelo Estructural

Características del Modelo de Repositorio (3)

• El modelo de repositorio es pasivo, el control corre por cuenta de los sistemas involucrados.

• Existe una variante a este modelo, la cual es conocida como el modelo de pizarrón.

• Este modelo mantiene una arquitectura general, similar a la de repositorio, pero es proactivo….

• Cada vez que llegan datos al repositorio, éste hace una notificación inteligente a todos los subsistemas involucrados.

Variante del Modelo de Repositorio: Pizarrón

Arquitectura Centrada en Flujo de Datos

• Se basa en el patrón pipe and filter (tubería y filtro). Que consta de un conjunto de componentes denominado filtros, conectados entre si por tuberías, que transmiten datos desde un componente al siguiente.

• Cada filtro trabaja de manera independiente de los componentes que se encuentran situados antes o después de ella. Se diseñan de modo que esperan un conjunto de datos en un determinado formato y obtiene como resultado otros datos de salida en un formato especifico.

• Si el flujo degenera en una única línea de transformación, se denomina secuencial batch

Arquitectura Centrada en flujo de Datos

Arquitectura Llamada respuesta (Call and return)

• Permite a los diseñadores de software conseguir estructuras de programa relativamente fáciles de modificar y escalar.

• Podemos encontrar diferentes estilos dentro de este tipo:– Programa Principal / Sub programa.- descompone las

funciones de una jerarquía de control donde el programa invoca a los otros programas subordinados, los cuales pueden a su vez invocar otros.

– Llamada de procedimiento remoto.- Los componentes de la arquitectura son distribuidos entre diferentes ordenadores de la red.

Arquitectura Llamada y Respuesta (Call and return)

Arquitectura de Sistemas Distribuidos

• Praticamente todos los grandes sistemas basados en computadores son ahora distribuídos.

• Un sistema distribuído es aquel que implica numerosas computradoras, en contraste con los sistemas centralizados en que todos los componentes de un sistema se ejecutan en una sola computadora.

• Compartir Recursos.- Un sistema distribuído permite compartir recursos, hardware y software

•

Arquitectura de Sistemas Distribuidos: Ventajas

• Apertura: Son Sistemas abiertos desarrollados sobre protocolos estándares, que permiten cambiar equipamiento y software de diferentes vendedores.

• Concurrencia: varios procesos pueden operara al mismo tiempo sobre diferentes computadoras de la red.

• Escalabilidad: son escalables mientras la capacidad del sistema pueda incrementarse, añadir nuevos recursos para cubrir demandas.

Ventajas

• Tolerancia a Defectos: pues cuentan con varias computadoras que pueden reproducir hardware o software que se encuentre defectuoso.

• Una completa perdida de servicio solo ocurre cuando existe una falla en la red.

Arquitectura Distribuida: Desventajas

• Complejidad: son mas complejas que los sistemas centralizados.

• Por ejemplo el rendimiento del sistema depende del ancho de banda y la velocidad de los procesadores de la red.

• Mover los recursos de una parte del sistema a otra puede afectar de manera radical el rendimiento del sistema.

• Seguridad: existe varios punto de acceso al sistema y el trafico en la red puede estar sujeto a escuchas.

Desventajas• Es mas difícil mantener la integridad de los

datos en el sistema, y que los servicios no se degraden por ataques.

• Manejabilidad: las computadoras pueden ejecutar diversas versiones de SO. Los defectos de una maquina pueden propagarse a otras.

• Se requiere mayor esfuerzo para mantener y gestionar el sistema.

• Impredecibilidad: tienen una respuesta impredecible, que depende de la cargo total del sistema, su organización y la red.

Arquitecturas Multiprocesador

• El modelo mas simple de un sistema Distribuido es un sistema Multiprocesador, donde el software esta formado por varios procesos que pueden correr en varios procesadores.

• Este modelo es común en sistemas grandes en tiempo real

• Recogen información, toman decisiones usando esta información y envían señales que modifican el entorno del sistema.

Arquitectura Multiprocesador

• Lógicamente la recopilación de información, toma de decisiones y control de actuadores podrían ejecutarse sobre un único procesador, bajo control de un planificador (scheduler)

• La distribución de procesos entre los procesadores puede ser predeterminada o estar bajo el control de un despachador (dispatcher) que decide que procesos se asigna a cada procesador.

• Ejemplo: Un conjunto de sensores distribuidos recogen información sobre el flujo de trafico y lo procesan localmente antes de enviarlo a una sala de control

• Los operadores toman decisiones usando esta información, y dan instrucciones a un proceso de control de semáforos.

• Hay varios procesos lógicos (pueden ser individuales o grupales) para gestionar los sensores, la sala de control y los semáforos.

Sistema Multiprocesador de control de transito

Arquitectura entre Pares Peer to Peer

• El modelo arquitectónico cliente servidor conduce a una distribución irregular de la carga de trabajo.

• Lo que conduce a Servidores recargados y Clientes de gran capacidad de procesamiento poco usada.

• El sistema entre pares p2p son sistemas descentralizados en que los cálculos pueden realizarse en cualquier nodo de la red, sin hacer distinción entre servidor y cliente.

• En p2p el sistema se diseña para sacar ventaja del poder computacional y de almacenamiento.

• Los estándares y protocolos que permiten la comunicación entre nodos se embeben en la aplicación y en cada nodo se ejecuta una copia de la aplicación.

• P2p se ha usado principalmente en sistemas personales mas que en empresariales (sistema de intercambio de archivos, sistemas de mensajería)

• P2p se usa en dos circunstancias:– Donde el sistema es de computo intensivo y se

puede separar estos en cálculos independientes.– En sistemas de intercambio de información entre

computadoras de una red.

• En teoría, en los sistemas p2p, cada nodo podría conocer cualquier otro nodo, conectarse con el, e intercambiar datos.

• En la practica esto no es posible, ya que los nodos se encuentran dentro de Localidades con algunos nodos que actúan como puentes a otras localidades de nodos.

• En una arquitectura descentralizada, los nodos en la red no son solo elementos funcionales, sino que son también interruptores de comunicaciones que pueden encaminar los datos y señales de control de un nodo a otro.

• En la figura siguiente, si n1 debe buscar un archivo que esta en n10, la búsqueda se encamina a través de los nodos n3, n6, n9 hasta n10

Arquitectura p2p desentralizada

Ventajas

• Esta arquitectura desentralizada tiene ventajas: es altamente redundante, y tolerante a defectos y a nodos desconectados de la red.

• Sin embargo existe sobrecarga en el sistema ya que la misma búsqueda puede ser procesada por varios nodos diferentes lo que sobrecarga las comunicaciones.

• Un modelo p2p alternativo es una Arquitectura Semicentralizada en la que, dentro de la red, uno o mas nodos actúan como servidores

Arquitectura p2p SemiCentralizada

• En una Arquitectura Semicentralizada, el papel del servidor es ayudar a establecer contacto entre iguales en la red o para coordinar los resultados de un calculo.

• Ejemplo: la figura anterior representa un sistema de mensajería instantánea, los nodos de la red se comunican con el servidor (indicados por líneas punteadas), para encontrar que otros nodos están disponibles.

• Una ves que estos son encontrados, se puede establecer comunicaciones directas y la conexión con el servidor es innecesaria.

• Por lo tanto los nodos n2,n3,n5,n6 están en comunicación directa

• Todavía hay problemas en el uso de las arquitecturas p2p, ya que cuestiones tales como protección y la autenticidad no están del todo resuelto.

• Esto significa que los sistemas p2p se usan mas en sistemas de información no criticas.

Cliente-Servidor

Modelo Cliente-Servidor (1)• Este modelo brinda otra alternativa para

estructurar los sistemas.• Es un modelo de Sistemas Distribuido

(parcialmente distribuido), el cual muestra cómo los datos y el procesamiento se distribuye entre un rango de computadores.

• Típicamente, está compuesto por tres componentes:– Conjunto de servidores “stand-alone”, los cuales

proporcionan servicios específicos como impresión, manejo de datos, etc.

– Conjunto de clientes que llaman a estos servicios. – Redes que permiten que los clientes accedan a los

servidores.• Este modelo cuenta con la arquitectura básica

más utilizada en la actualidad.

Ejemplo: Arq. de un Sistema Bibliotecario de Películas e Imágenes

Cliente 1 Cliente 2 Cliente 3 Cliente 4

Ancho de Banda de la red

Servidor deCatálogo

Catálogo

Servidor deVídeo

Archivos clip de Película

Servidor deFotografía

FotografíaDigitalizada

Servidor deHipertexto

Hipertexto WEB

Modelo Cliente-Servidor (2)

Características del Modelo Cliente-Servidor

• Ventajas– La distribución de datos es directa.– Permite el uso efectivo de sistemas de red. Generalmente

requiere hardware barato. – Es fácil añadir nuevos servidores (escalabilidad) o actualizar

los existentes.

• Desventajas– El modelo no comparte datos con los diferentes subsistemas

(duplicidad de datos). El intercambio de datos puede ser ineficiente.

– Si se intercambian grandes volúmenes de datos, quien más sufrirá será la performance.

– Hay administración redundante en cada servidor (trabajo solapado).

– No existen registros centrales de nombres y servicios, esto hace difícil encontrar los servidores y servicios disponibles.

– Es más dificil realizar datamining, o procesos de inteligencia de negocio.

Evolución del Modelo C/S

Máquina Abstracta

Modelo de Máquina Abstracta (1)

• Este modelo también es conocido como el modelo de capas, o estratificado.

• Es utilizado para modelar las interfaces entre los subsistemas.

• El modelo organiza el sistema en base a un conjunto de capas (o máquinas abstractas), cada una de las cuales proporciona un conjunto de servicios.

• Soporta el desarrollo incremental de subsistemas en las diferentes capas. Cuando la interfaz de una capa cambia, solamente la capa adyacente se ve afectada.

• Sin embargo, es difícil estructurar los sistemas de esta manera.

Modelo de Máquina Abstracta (2)

Ejemplo: La arquitectura de un sistema de administración de versiones, puede ser abordado utilizando el modelo de máquina abstracta.1. Suministra los recursos de administración de releases

del sistema.2. Comprende la administración de versiones de

componentes.3. Para ello utiliza un sistema de administración de

componentes, que provee servicios de administración y almacenamiento de clases.

4. Utiliza un SABD para proveer almacenamiento básico de datos y servicios (adm. de transac., confirmación y recuperación, control de acceso, etc.).

Modelo de Máquina Abstracta (3)

Administrador de Releases del Sistema

Ejemplo: Sistema Administrador de Versiones

Sistema de Base de Datos

Administrador de Clases

Administrador de Versiones de Componentes

Administrador de Releases del Sistema

Sistema de Base de Datos

Administrador de Clases

Administrador de Versiones de Componentes

Características del Modelo de Máquina Abstracta

• Ventajas:– Permite el desarrollo incremental.– Es más mantenible.– Flexible y fácil de evolucionar.

• Desventajas:– Estructurar un sistema en capas en general es

difícil.– Puede haber problemas de performance

debido a los distintos niveles de interpretación de órdenes.– Puede suceder que una capa dependa de

otra, que no es su predecesor inmediato.

Arquitecturas de 2/3 Capas… para Web

3-Tiers Architecture

2-Tiers Architecture

Arquitecturas de 2/3 Capas… para Web

Arquitectura de 5 Capas… para Web

Recomendaciones Generales• Desempeño (performance).

– Si el desempeño es un requisito crítico, la arquitectura debe estar diseñada para albergar las operaciones críticas, dentro de un número reducido de subsistemas y evitar (o reducir el número de) cambios de estado.

– Esto significa utilizar componentes de grano grueso (componentes que realizan multiples tareas), de esa manera habrá menos componentes en el sistema.

– Ojalá con poca comunicación entre estos subsistemas.– Poco uso de la red.

• Seguridad. – Si la seguridad es un requisito crítico, se debería utilizar una

arquitectura estratificada (por capas).– Los recursos más críticos deben alojarse en las capas más

internas.– Cada capa debe proveer un mecanismo de validación, de

acuerdo a la información que ésta maneja.

Recomendaciones Generales

• Protección (de transacciones). – Si la protección de transacciones es un requisito

crítico, la arquitectura debe estar diseñada de tal forma que las operaciones encargadas de la protección se localicen en único subsistema o en un conjunto muy reducido de estos.

– Esto reduce riesgos, y falicita la administración de dichas transacciones (inclusive en casos de roll-back).

• Disponibilidad. – Si la disponibilidad es un requisito crítico, como parte

de la arquitectura se deben incluir componentes redundantes, y/o la posibilidad de mover código en tiempo real (migrar servicios de una máquina a otra).

– Estos podrán reemplazar a los componentes con problemas, en caso de fallas.

Recomendaciones Generales• Mantenibilidad. – Si la mantenibilidad es un requisito crítico, la

arquitectura debe estar diseñada utilizando componentes autocontenidos de grano fino.

– Estos componentes pueden ser módulos o componentes de software bien definidos.

– Estos podrán cambiarse o reemplazarse con facilidad, y con un mínimo efecto sobre el resto del sistema.

– Los productores de datos deben estar separados de los consumidores.

– Las estructuras de datos compartidas deben evitarse.

– La circulación de órdenes de control entre módulos o subsistemas, también debe evitarse.