Professional Documents
Culture Documents
Despus de habernos detenido en nuestros dos artculos anteriores en los fundamentos del concepto de arquitectura de software (ver nmeros de agosto y septiembre) podemos ir viendo algunos tipos de arquitectura, tratando de agrupar esos tipos en conjuntos a los que podamos asignar cierto nivel de generalizacin como los que muestran Mary Shaw y David Garlan en su clsico libro Software Architecture (1996). 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 ms genricas que las que podra deducir al analizar slo casos particulares. Para comenzar, los autores aclaran que utilizan tres trminos como equivalentes: patrn de arquitectura, modismo arquitectnico (architectural idiom) y estilo arquitectnico, y presentan 5 de estos estilos: Sistemas de flujo de datos Secuencial en lote Tubos y filtros Sistemas de llamada y retorno Programa principal y subrutina Sistemas orientados al objeto Capas jerrquicas Componentes independientes Procesos comunicativos Sistemas de eventos De esta forma, es evidente que un estilo arquitectnico define una familia de sistemas en trminos de un patrn de organizacin estructural. En particular, de acuerdo a los autores, un estilo arquitectnico define tanto un vocabulario de tipos de componentes y conectores como en el caso de filtros y tubos- como un conjunto de restricciones sobre cmo combinar esos componentes y conectores. Veamos algunos de estos estilos: Mquinas virtuales Intrpretes Sistemas basados en reglas Sistemas centrados en los datos Bases de Datos Sistemas de hipertexto Pizarras
Figura 1 Estilo de tubos y filtros Una de las metforas utilizadas para el nombre filtro- no es quizs 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 transformacin de los datos de entrada. La descripcin 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 transformacin local a las corrientes de entrada y realizando una computacin incremental, de tal manera que la salida comienza antes de haberse consumido toda la entrada. Esto en cuanto a la organizacin, 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 anteriores o posteriores 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 podrn identificar lo que hay al final de estos tubos de entrada y salida. Otro estilo importante es el de abstraccin de datos u orientacin al objeto, dentro del grupo de los denominados de llamada y retorno. Los componentes de este estilo arquitectnico son los objetos tambin considerados originalmente como instancias de tipos abstractos de datos, aunque ahora diramos 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 representacin. Los objetos interactan a travs de invocaciones de funciones y procedimientos.
Figura 2 Tipos abstractos de datos y objetos Hay dos aspectos importantes en relacin con este estilo: 1) un objeto es responsable de preservar la integridad de su representacin (normalmente, manteniendo algn invariante de la misma) y 2) la representacin permanece oculta respecto de los dems objetos
Patrones arquitectnicos
Ya se habr percibido a lo largo de estos artculos la variedad de denominaciones y sobre todo- la dificultad para compartir las definiciones sobre arquitectura. En la seccin anterior vemos la propuesta de llamar a los estilos patrones, pero optaremos por reservar este trmino a algo que est en un nivel distinto de lo que llamamos estilos. Si tuviramos que relacionar el estilo con algo, podramos decir que est vinculado a la forma ms general en que est organizado un sistema de software, independientemente de consideraciones ms especficas (los tipos de objeto que estamos considerando, por ejemplo). En el ejemplos anterior, podemos describir el estilo mostrando entidades genricas 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 organizacin sistemas orientados al objeto- mientras que los patrones estarn asociados a formas ms concretas, que tienen que ver con la especializacin que adoptan los objetos y clases de acuerdo al tipo de aplicacin o entorno tecnolgico, a tcnicas conocidas por su eficiencia para resolver ciertos problemas, etc.
Por ejemplo, pensando que el entorno de ejecucin de una aplicacin puede estar distribuido en distintos elementos nodos- es aconsejable y beneficioso descomponer la aplicacin en capas, correspondientes a los nodos donde podra tener que ejecutarse. Los beneficios de dicha descomposicin 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 bsicos; 3) Se minimizan las dependencias entre las capas; 4) Las capas son un buen sitio para la estandarizacin y 5) Una vez implementada una capa, se la puede utilizar para muchos servicios de alto nivel. La descomposicin ms habitual es decir el patrn usualmente empleado- es dividir la aplicacin en tres capas: 1) Lgica de presentacin, que se ocupa de toda la interaccin entre el usuario y el software, pudiendo tratarse de un sistema de mens muy simple o una interfaz grfica de usuario relativamente compleja; 2) La lgica del dominio, tambin conocida como la lgica de negocio, que es todo lo que necesita conocer la aplicacin para poder trabajar con el dominio en cuestin. Implica realizar clculos basados en datos de entrada o almacenados, validacin de cualquier dato proveniente de la capa de presentacin y la ejecucin de algoritmos especficos en funcin de los comandos de la presentacin; y 3) la lgica de fuente de datos, que se ocupa de comunicarse con otros sistemas que se encargan de tareas en representacin de la aplicacin. Estos pueden ser monitores de transacciones, otras aplicaciones, sistemas de mensajes, etc. Otro ejemplo de patrn arquitectnico podra ser el de Mdulo Tabla, uno de los mltiples patrones presentado por Martin Fowler en Patterns of Enterprise Application Architecture (2003). El enfoque tradicional de la orientacin 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 informacin 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 programacin para llevar los datos y extraerlos de la base de datos y transformarlos a otro tipo diferente de representacin. La ventaja de este patrn es que organizamos la lgica del dominio con slo una clase por tabla de la base de datos, ya que una nica instancia de la clase contiene los diversos procedimientos que se aplicarn a los datos. La diferencia fundamental con un esquema clsico llamado tambin Modelo de Dominio- es que, si tenemos varios pedidos, este ltimo modelo emplear un objeto por cada pedido, mientras que el Mdulo Tabla tendr slo un objeto para manejar todos los pedidos, con lo cual aumentamos la granularidad de los objetos de la aplicacin. Como hemos podido ver, la diferencia entre los estilos y patrones arquitectnicos est en el nivel de abstraccin en el que nos movemos. Los estilos se aplican a un nivel muy alto de abstraccin, en el cual no interesa saber cul es la semntica de los elementos que estamos utilizando, slo hablamos de filtros, tubos u objetos sin interesarnos por lo que estn 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 descomposicin en capas en el que se habla de presentacin, dominio de aplicacin y de datos- o en el de Mdulo Tabla, que diferencia entre un objeto que representa un elemento -una lnea 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 comprensin compartida del diseo de un sistema por parte de los desarrolladores de un sistema. En general, esta comprensin compartida est expresada en trminos de los principales componentes del sistema y de sus interacciones. Pero es tambin sobre las decisiones, en especial aquellas que deben tomar correctamente al principio del proyecto porque se las considera difciles de cambiar. Este componentes de subjetividad se debe al hecho de que si algo resulta ms fcil de cambiar de lo que imaginbamos al comienzo, deja de ser una decisin arquitectnica o sobre la arquitectura.