Estilos Arquitectónicos

Motivación

·        Incremento en el tamaño y complejidad del software

·        Necesidad de aprender de la experiencia (Reutilización de estructuras usadas en problemas similares)

·        Una adecuada estructura general es tan importante o más que las implementaciones concretas de las partes.

 

Descripción

Al generalizar los tipos en estilos podremos ver elementos comunes entre los primeros, que es una de las actividades a la que se aplica cualquier disciplina cuando quiere sacar conclusiones un poco más genéricas que las que podría deducir al analizar sólo casos particulares.

 

Definición

La arquitectura de software está compuesta por la estructura de los elementos de un programa o sistema, sus interrelaciones y los principios y reglas que gobiernan su diseño y evoluciona lo largo del tiempo.

·        La definición incluye:

o       la descripción de los componentes con los cuales se construyen los sistemas

o       las interacciones entre esos componentes

o       Los patrones para guiar la composición

o       restricciones sobre dichos patrones

 

·        Describe los elementos arquitectónicos básicos

o       Estructura, componente, Conexión, evolución

·        Componentes

o       Servidores, clientes, bases de datos, filtros, capas en un sistema jerárquico, etc.

 

 

Tipos de Estilos arquitectónicos:

 

1.      Sistemas de flujo de datos

Secuencial en lote

Tubos y filtros

2.      Máquinas virtuales

Intérpretes

Sistemas basados en reglas

3.      Sistemas de llamada y retorno

Programa principal y subrutina

Sistemas orientados al objeto

Capas jerárquicas

4.      Sistemas centrados en los datos

Bases de Datos

Sistemas de hipertexto

Pizarras

5.      Componentes independientes

Procesos comunicativos

Sistemas de eventos

 

De esta forma, es evidente que un estilo arquitectónico define una familia de sistemas en términos de un patrón de organización estructural. En particular, de acuerdo a los autores, un estilo arquitectónico define tanto un vocabulario de tipos de componentes y conectores como en el caso de filtros y tubos como un conjunto de restricciones sobre cómo combinar esos componentes y conectores. Algunos de estos estilos:

 

Figura 1 Estilo de tubos y filtros

 

Una de las metáforas utilizadas para el nombre filtro no es quizás muy adecuada, porque sugiere que los que ocurre dentro del proceso es retener algunos de los datos y dejar pasar a otros, cuando lo que pasa en realidad es una verdadera transformación de los datos de entrada. La descripción realizada para este tipo de estilo es que cada componente tiene un conjunto de entradas y un conjunto de salidas; cada componente lee corrientes de datos en sus entradas y produce corrientes de datos en las salidas.

 

Normalmente esto se produce aplicando una transformación local a las corrientes de entrada y realizando una computación incremental, de tal manera que la salida comienza antes de  haberse consumido toda la entrada.

 

Esto en cuanto a la organización, pero si consideramos las restricciones en particular las invariantes del estilo, es que los filtros deben ser entidades independientes, es decir ninguna depende del estado o condiciones de ninguna otra. Otra invariante importante es que los filtros no conocen la identidad de los otros, ya sea anterior o posterior en la cadena de  transformaciones. Las especificaciones se restringen a lo que aparece en las corrientes de entrada, o a garantizar lo que se producirá como corrientes de salida, pero nunca podrán identificar lo que hay al final de estos tubos de entrada y salida.

 

Otro estilo importante es el de abstracción de datos u orientación al objeto, dentro del grupo de los denominados de llamada y retorno. Los componentes de este estilo arquitectónico son los objetos también considerados originalmente como instancias de tipos abstractos de datos, aunque ahora diríamos clases. Los objetos son ejemplos de un tipo de componentes que algunos llaman gestor porque es responsable de preservar la integridad de un recurso, es decir la representación. Los objetos interactúan a través de invocaciones de funciones y procedimientos.

 

Figura 2 Tipos abstractos de datos y objetos

 

Hay dos aspectos importantes en relación con este estilo:

1.      un objeto es responsable de preservar la integridad de su representación (normalmente, manteniendo algún invariante de la misma)  

2.      La representación permanece oculta respecto de los demás objetos

 

Patrones arquitectónicos

Si tuviéramos que relacionar el estilo con algo, podríamos decir que está vinculado a la forma más general en que está organizado un sistema de software, independientemente de consideraciones más específicas (los tipos de objeto que estamos considerando, por ejemplo). En el ejemplo anterior, podemos describir el estilo mostrando entidades genéricas llamadas objetos, y no nos interesa saber a qué tipos de datos abstractos o clases pertenecen.

 

De esta manera, el estilo está asociado a formas generales de organización sistemas orientados al objeto mientras que los patrones estarán asociados a formas más concretas, que tienen que ver con la especialización que adoptan los objetos y clases de acuerdo al tipo de aplicación o entorno tecnológico, a técnicas conocidas por su eficiencia para resolver ciertos problemas, etc.

 

Por ejemplo, pensando que el entorno de ejecución de una aplicación puede estar distribuido en distintos elementos nodos es aconsejable y beneficioso descomponer la aplicación en capas, correspondientes a los nodos donde podría tener que ejecutarse. Los beneficios de dicha descomposición son varios, entre los cuales se mencionan:

1.      Se puede comprender una capa como un todo coherente, sin necesidad de conocer las restantes;

2.      Se puede sustituir una capa con implementaciones alternativas de los mismos servicios básicos.

3.      Se minimizan las dependencias entre las capas

4.      Las capas son un buen sitio para la estandarización

5.      Una vez implementada una capa, se la puede utilizar para muchos servicios de alto nivel.

 

La descomposición más habitual  es decir el patrón usualmente empleado es dividir la aplicación en tres capas:

1.    Lógica de presentación, que se ocupa de toda la interacción entre el usuario y el software, pudiendo tratarse de un sistema de menús muy simple o una interfaz gráfica de usuario relativamente compleja

2.    La lógica del dominio, también conocida como la lógica de negocio, que es todo lo que necesita conocer la aplicación para poder trabajar con el dominio en cuestión. Implica realizar cálculos basados en datos de entrada o almacenados,  validación de cualquier dato proveniente de la capa de presentación y la ejecución de algoritmos específicos en función de los comandos de la presentación

3.    La lógica de fuente de datos, que se ocupa de comunicarse con otros sistemas que se encargan de tareas en representación de la aplicación. Estos pueden ser monitores de transacciones, otras aplicaciones, sistemas de mensajes, etc.

 

Otro ejemplo de patrón arquitectónico podría ser el de Módulo Tabla, uno de los múltiples patrones presentado por Martin Fowler en “Patterns of Enterprise Application Architecture” (2003). El enfoque tradicional de la orientación al objeto está basado en objetos que tienen una identidad. Es decir que si tenemos una clase Empleado, cualquier instancia de la misma corresponde a un empleado particular. Este esquema funciona bien porque una vez que tenemos una referencia a un empleado, podemos ejecutar operaciones, seguir relaciones y recoger información sobre el mismo.

Pero uno de los problemas con este modelo es la interfaz con las bases de datos relacionales. En muchos casos este enfoque se asemeja al del pariente loco, que vive encerrado en un ático y del cual nadie quiere hablar: con frecuencia este enfoque requiere un trabajo considerable de programación para llevar los datos y extraerlos de la base de datos y transformarlos a otro tipo diferente de representación.

La ventaja de este patrón es que organizamos la lógica del dominio con sólo una clase por tabla de la base de datos, ya que una única instancia de la clase contiene los diversos procedimientos que se aplicarán a los datos. La diferencia fundamental con un esquema clásico llamado también Modelo de Dominio es que, si tenemos varios pedidos, este último modelo empleará un objeto por cada pedido, mientras que el Módulo Tabla tendrá sólo un objeto para manejar todos los pedidos, con lo cual aumentamos la granularidad de los objetos de la aplicación.

 

Como hemos podido ver, la diferencia entre los estilos y patrones arquitectónicos está en el nivel de abstracción en el que nos movemos. Los estilos se aplican a un nivel muy alto de abstracción, en el cual no interesa saber cuál es la semántica de los elementos que estamos utilizando, sólo hablamos de filtros, tubos u objetos sin interesarnos por lo que están representando. En el caso de los patrones, tenemos en cuenta el significado de los filtros, tubos u objetos, tal como hemos visto en los patrones de descomposición en capas en el que se habla de presentación, dominio de aplicación y de datos o en el de Módulo Tabla, que diferencia entre un objeto que representa un elemento una línea de una tabla o registro u otro objeto que representa la totalidad de la tabla.

 

Otro aspecto importante que menciona Fowler pero que adjudica a Ralph Johnson es que la arquitectura es algo subjetivo, una comprensión compartida del diseño de un sistema por parte de los desarrolladores de un sistema. En general, esta comprensión compartida está expresada en términos de los principales componentes del sistema y de sus interacciones. Pero es también sobre las decisiones, en especial aquellas que deben tomar correctamente al principio del proyecto porque se las considera difíciles de cambiar. Este componente de subjetividad se debe al hecho de que si algo resulta más fácil de cambiar de lo que imaginábamos al comienzo, deja de ser una decisión arquitectónica o sobre la arquitectura.

 

Arquitecturas orientadas a servicios

Hasta ahora nos hemos centrado en la aplicación, considerándola como una unidad de ejecución de un procesador o cuando la visión se amplía y la distribuimos entre nodos un grupo de procesadores. Por eso también tenemos que considerar patrones arquitectónicos para que esa descomposición sea adecuada y eficiente en función de los factores considerados.

 

Pero el concepto de aplicación sigue ampliándose, ya no se reduce a un grupo humano que interactúa con el software dentro de los límites de la empresa u organización. La Web nos ha conducido a generalizar lo que en un origen estaba en algún nodo corporativo y a pensar que algunos de los componentes de la aplicación pueden estar donde sea más rentable o adecuado que estén. Si necesitamos acceder a algún sitio de la Web para poder ejecutar nuestra aplicación, diremos que estamos utilizando un servicio de Web.

 

Algunas definiciones genéricas que encontramos en la Web nos plantean que un Servicio de Web puede ser incluso el FTP (File Transfer Protocol), que se podía acceder en los 1990 sólo desde un comando Unix, pero que desde 1995 podía accederse desde un navegador Web. Esto se denominaba una ‘evolución’ de los servicios Web y todavía no tenían nada que ver con el uso de XML.

 

Si nos obligaran a resumir este concepto, podríamos decir que un servicio Web es "una función de negocio autocontenida que opera en Internet". En algunos sitio de la Web (http://www.servicearchitecture.com) se considera que los Servicios son lo que conectamos utilizando los Servicios Web, Un servicio es el punto final de una conexión. Además, un servicio tiene algún tipo de sistema de computación subyacente que soporta la conexión ofrecida. La combinación de servicios internos y externos a la organización  configura una arquitectura orientada a servicios.

 

Al ser más compleja la coordinación de todos estos servicios para obtener como resultado una aplicación, también es necesario apelar a conceptos metáforas utilizados en actividades de coordinación de conjuntos: coreografía y orquestación. Y también es cierto que aparecieron es ese orden.

 

El W3C (WorldWide Web Consortium) creó un grupo de trabajo con la intención de desarrollar un estándar para describir los vínculos y patrones de uso entre los servicios de Web. El grupo considera a la coreografía un equivalente de los conceptos de orquestación, de colaboración, coordinación, etc.

 

Por otro lado, la orquestación es considerada como la coordinación de eventos de un proceso, también superponiéndose con el concepto de coreografía. La orquestación dirige y gestiona el ensamblado sobre demanda de múltiples servicios componentes para crear una aplicación o proceso de negocio compuesto.

La orquestación tiende a ser considerada como una única fuerza coordinadora, mientras que la coreografía también se aplica a una coordinación compartida a través de  múltiples sistemas autónomos.

 

La tendencia actual después de haberse evaluado varias especificaciones en competición está convergiendo en considerar la propuesta conjunta de IBM/Microsoft/Bea como especificación BPEL4WS (Business Process Execution Language for Web Services) como el estándar principal para la orquestación de los servicios Web.

Es decir que no sólo se trata de la organización en componentes y sus vinculaciones, de añadir incluso las decisiones más importantes, sino que a partir de ahora se trata de una coordinación compleja de eventos para lograr un resultado en el que se integran servicios que están distribuidos en diversos sitios de la Web (la propia instalación de la empresa, la de sus clientes, proveedores y partenaires) junto a las propias intervenciones de los usuarios en un todo proceso de negocio genérico que combina servicios de

Software y acciones humanas.

En el nuevo modelo de empresa ágil y eficiente, el software deberá implementarse como componentes para una fácil reutilización y adaptación a las arquitecturas orientadas a servicios. La orquestación es una lógica de negocio que secuencia, coordina y gestiona conversaciones entre servicios Web.

 

CONCLUCIONES

·        Los estilos arquitectónicos ayudan a determinarlas características a alcanzar.

·        Se recupera la perspectiva  arquitectónica la verdadera transición entre el análisis y diseño basada  en principios conocidos pero olvidados

·        Los estilos se ocupan de definir el diseño preliminar o de alto nivel.

·        No se ocupa del diseño detallado, diseño de algoritmos aunque es un algoritmo y diseño de estructura de datos.

·        La granularidad es importante 

·         

BIBLIOGRAFIA

http://kybele.escet.urjc.es/documentos/ISI/Arquitecturas%20de%20SW.pdf

 

http://es.wikipedia.org/wiki/Categor%C3%ADa:Estilos_arquitect%C3%B3nicos

 

 

 

About these ads

About omaracostacasas

ING SOFTWARE
This entry was posted in Ingenieria de Software. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s