Máquinas Virtuales

ESTILOS DE ARQUITECTURAS DE SOFTWARE

1. Filtros y Tuberías

El estilo de arquitectura llamado Filtros y tuberías (Pipelines), se describe como un conjunto de filtros que se encargan en transformar los flujos de datos funcionales [1], cada filtro se encuentra compuesto por 3 elementos principales:

• Puerto de Entrada: recibe los datos a transformar o filtrar

• Componente de filtrado: es el componente que filtra la información.

• Puerto de salida: en el cual se envían los datos filtrados, estos puertos a su vez pueden servir como puertos de entrada para otros filtros.

Este conjunto de filtros y tuberías hace un proceso de forma incremental y local independiente de los filtros que se encuentran situados antes o después. Obteniendo un sistema en el que no se generan ciclos a través de su comportamiento.

Figura 1. Sistema de Filtros y Tuberías

Si el flujo degenera en una única línea de transformación, se denomina secuencia batch. En esta secuencia los componentes son independientes y se ejecutan hasta completarse antes que se inicie el siguiente componente. [2]

Figura 2. Secuencia Batch para filtros y tuberías.

Este estilo de arquitectura plantea características [3], [4]:

• Es simple de entender e implementar.

• Determinar realizar un procesamiento secuencial

• Los filtros se pueden agrupar para realizar el procesamiento de flujo de datos de manera paralela o distribuida.

• Falta de implementación de ciclos, condicionales u otras herramientas lógicas de control de flujo.

• Los filtros al ser independientes pueden generar la duplicación de funcionalidades.

Esta arquitectura presenta las siguientes ventajas:

• Permite entender el sistema global en términos de la combinación de componentes.

• Soporta de buena manera la reutilización. Los filtros son independientes de sus vecinos.

• Facilidad de mantenimiento y mejora.

• Facilidad de diagnóstico (rendimiento, interbloqueos)

• Soportan la ejecución concurrente.

2. N Capas (N-Layer)

Se basa en una distribución jerárquica de los roles y las responsabilidades para proporcionar una división efectiva de los problemas a resolver. Los roles indican el tipo y la forma de la interacción con otras capas y las responsabilidades la funcionalidad que implementan.

Figura 3. Estilo N-Layer

Normalmente esta arquitectura se implementa presentando una capa de presentación, una capa de lógica de negocio y una capa de acceso a datos. Adicionalmente, algunas literaturas agregan capas como: una capa de entidades de negocios y capa de datos.

Figura 4. Estilo clásico N-Layer

Algunas características de esta arquitectura son [5]:

• Descomposición de los servicios de forma que la mayoría de interacciones ocurre solo entre capas vecinas.

• Las capas de una aplicación pueden residir en la misma máquina o pueden estar distribuidos entre varios equipos; en el caso de estar distribuida entre varios equipos la arquitectura pasa a llamar N-Tiers.

• Los componentes de cada capa se comunican con los componentes de otras capas a través de interfaces bien conocidos.

• Cada nivel agrega las responsabilidades y abstracciones del nivel inferior.

• Muestra una vista completa del modelo y a la vez proporciona suficientes detalles para entender las relaciones entre capas.

• No realiza ninguna suposición sobre los tipos de datos, métodos, propiedades y sus implementaciones.

• Separa de forma clara la funcionalidad de cada capa.

3. Representational State Transfer - REST

Este estilo fue definido por Roy Fielding [6]. Es un estilo de arquitectura diseñado para sistemas distribuidos multimedia. REST se caracteriza por:

• Ser una arquitectura sencilla de implementar.

• Tener alta escalabilidad.

• Alto rendimiento debido a que se puede visualizar como un sistema en capas.

• Capacidad de evolucionar.

• Alto nivel de visibilidad al usar los identificadores uniformes de recurso (URI).

• Tiene bajo acoplamiento debido al ser desarrollada de forma cliente / servidor

Una aproximación al estilo arquitectural REST se muestra en la siguiente gráfica:

Figura 5. Transacciones REST

Inicialmente se diseñó como un modelo arquitectónico que explicaba cómo debería funcionar INTERNET, a partir de:

• Un framework guía para el desarrollo de protocolos estándar.

• Identificar problemas existentes, comparar soluciones alternativas, asegurar que las extensiones de los protocolos no violan las restricciones de INTERNET.

• Captura todos los aspectos que cubren los requisitos de comportamiento y rendimiento en INTERNET.

REST se rige a través de los siguientes principios básicos:

• Un recurso es cualquier cosa que tenga identidad y debe estar identificado mediante algún mecanismo. El identificador de un recurso no expone detalles acerca de su implementación.

• Todos los recursos deben compartir la misma interfaz uniforme. Los métodos definidos en esta interfaz deben ser utilizados acorde a la semántica que se les impuso al crearlos.

• El formato de las representaciones debe estar documentado y ser estándar. Las representaciones deben incluir enlaces a otros recursos relacionados.

• La comunicación debe ser auto contenida (stateless)

4. Máquinas Virtuales

La arquitectura de máquinas virtuales se ha llamado también intérpretes basados en tablas [2] [7]. El estilo comprende básicamente dos formas o sub-estilos, que se han llamado intérpretes y sistemas basados en reglas.

Cada intérprete posee por lo general cuatro componentes:

• Una máquina de interpretación, que lleva a cabo la tarea.

• Una memoria que contiene el pseudo-código a interpretar.

• Una representación del estado de control de la máquina de interpretación

• Una representación del estado actual del programa que se simula.

Figura 6. Componentes Máquina Virtual

La arquitectura basada en máquinas virtuales presenta ventajas como:

• Solución software a problemas hardware

• Configuración rápida

• Intercambiable

• Gran uso en redes compartidas

Y también presenta desventajas como:

• Sobre carga de hardware y software

• Insuficiente suporte a software

5. 4 + 1

La arquitectura del software se trata de abstracciones, de descomposición y composición, de estilos y estética. También tiene relación con el diseño y la implementación de la estructura de alto nivel del software. Los diseñadores construyen la arquitectura usando varios elementos arquitectónicos elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y desempeño del sistema, así como también otros requisitos no funcionales tales como confiabilidad, escalabilidad, portabilidad y disponibilidad del sistema [8].

Figura 7. Componentes 4 +1

5.1. Vista Lógica

La vista lógica apoya principalmente los requisitos funcionales, lo que el sistema debe brindar en términos de servicios a sus usuarios. El sistema se descompone en una serie de abstracciones clave, tomadas principalmente del dominio del problema en la forma de objetos. Aquí se aplican los principios de abstracción, encapsulamiento y herencia. Esta descomposición no sólo se hace para potenciar el análisis funcional, sino también sirve para identificar mecanismos y elementos de diseño comunes a diversas partes del sistema.

5.2. Vista de Procesos

La vista de procesos toma en cuenta algunos requisitos no funcionales tales como la performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribución, integridad del sistema, de tolerancia a fallas. La vista de procesos también especifica en cual hilo de control se ejecuta efectivamente una operación de una clase identificada en la vista lógica. Se describe en varios niveles de abstracción, donde cada nivel se refiere a distintos intereses. El nivel más alto la vista de procesos puede verse como un conjunto de redes lógicas de programas comunicantes (llamados “procesos”) ejecutándose en forma independiente, y distribuidos a lo largo de un conjunto de recursos de hardware conectados mediante un bus, una LAN o WAN.

5.3. Vista de Desarrollo

La vista de desarrollo se centra en la organización real de los módulos de software en el ambiente de desarrollo del software. El software se empaqueta en partes pequeñas, bibliotecas de programas o subsistemas, que pueden ser desarrollados por uno o un grupo pequeño de desarrolladores. Los subsistemas se organizan en una jerarquía de capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las capas superiores. Tiene en cuenta los requisitos internos relativos a la facilidad de desarrollo, administración del software, reutilización y elementos comunes, y restricciones impuestas por las herramientas o el lenguaje de programación que se use. Apoya la asignación de requisitos y trabajo al equipo de desarrollo, y apoya la evaluación de costos, la planificación, el monitoreo del progreso

...