Arquitectura del
software
Nathalie Moreno Vergara
Antonio Vallecillo Moreno
José Raúl Romero Salguero
Francisco Javier Durán Muñoz
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de
Reconocimiento-Compartir igual (BY-SA) v.3.0 España de Creative Commons. Se puede modificar la obra, reproducirla, distribuirla o comunicarla públicamente siempre que se cite el autor y la fuente (FUOC. Fundació per a la Universitat Oberta de Catalunya), y siempre que la obra derivada quede sujeta a la misma licencia que el material original. La licencia completa se puede consultar en: http://creativecommons.org/licenses/by-sa/3.0/es/legalcode.ca
Índice
Introducción... 5
Objetivos... 6
1. Arquitecturas del software... 7
1.1. Preliminares ... 7
1.2. Objetivos de la arquitectura software ... 7
1.3. Definición de arquitectura software ... 8
1.4. Componentes y conectores ... 10
1.5. Estilos arquitectónicos ... 11
1.6. Clasificación de los estilos arquitectónicos ... 13
1.6.1. Arquitecturas de flujo de datos ... 14
1.6.2. Arquitecturas de componentes independientes ... 15
1.6.3. Arquitecturas basadas en repositorios ... 15
1.6.4. Arquitecturas de máquina virtual ... 16
1.7. Arquitecturas heterogéneas ... 16
1.8. Principales estilos arquitectónicos ... 17
1.8.1. Sistemas de flujo de datos ... 17
1.8.2. Sistemas organizados en capas o niveles ... 19
1.8.3. Arquitecturas cliente-servidor ... 22
1.8.4. Arquitecturas heterogéneas: sistemas cliente-servidor organizados en capas ... 24
1.8.5. Sistemas orientados a objetos distribuidos ... 26
1.8.6. Arquitecturas basadas en eventos ... 29
1.8.7. Arquitecturas orientadas a servicios ... 31
1.9. Criterios para la selección de un estilo arquitectónico ... 33
2. Representación de la arquitectura software... 35
2.1. UML 2.0 como lenguaje de descripción de arquitecturas ... 35
2.2. Diseño de la arquitectura de tres capas ... 37
2.2.1. Diagramas de casos de uso ... 38
2.2.2. Diagrama de componentes ... 39
2.2.3. Diagramas de interacción ... 43
2.2.4. Colaboraciones ... 44
2.3. Modelado de las dependencias entre capas ... 45
2.4. Uso de patrones en el diseño arquitectónico ... 45
2.4.1. El patrón adaptador ... 47
2.4.2. El patrón observador ... 48
Actividades... 51
Ejercicios de autoevaluación... 51
Solucionario... 52
Glosario... 53
Introducción
Tal y como se ha comentado en el módulo anterior, un aspecto fundamental a la hora de diseñar y construir aplicaciones software es el de definir su
arqui-tectura�software. Esta arquitectura define la estructura y funcionalidad de la
aplicación en términos de componentes y conectores, independientemente de los lenguajes de programación y tecnologías que se utilicen finalmente para implementarla.
El objetivo principal de la arquitectura software es aportar elementos que ayu-den a la toma de decisiones, al mismo tiempo que se proporciona un marco común que va a permitir la comunicación entre los distintos equipos que par-ticipan en un proyecto. Para conseguirlo, la arquitectura software construye abstracciones, materializándolas en forma de modelos que se representan en diagramas.
El presente módulo introduce el concepto de arquitectura software y justifica la necesidad de documentar este aspecto tan relevante dentro del diseño y la implementación de un sistema software. Seguidamente, se describen los
esti-los�arquitectónicos más conocidos y aplicados en la actualidad como
meca-nismos de abstracción para estructurar sistemas, dedicando especial atención a aquellos estilos más indicados en el modelado de sistemas abiertos y distri-buidos.
Finalmente, se describe con detenimiento el proceso de diseño arquitectónico. A modo de ejemplo, y usando UML como lenguaje de descripción de arqui-tecturas, abordaremos el diseño lógico para el caso particular de arquitecturas en tres capas.
Objetivos
En este módulo el alumno aprenderá a realizar el diseño arquitectónico de un sistema software usando UML. Este objetivo se descompone en los siguientes subobjetivos:
1. Entender el rol del diseño arquitectónico y su relevancia en el proceso de
desarrollo software.
2. Entender la importancia de reutilizar la experiencia y las soluciones
ar-quitectónicas existentes para problemas similares, como mecanismo para abordar un nuevo diseño.
3. Saber elegir un patrón arquitectónico conforme a una colección de
requi-sitos críticos funcionales, de calidad y rendimiento.
4. Aprender a elaborar y documentar el diseño lógico de una arquitectura
1. Arquitecturas del software
1.1. Preliminares
Todos hemos observado alguna vez la construcción de un edificio. En una pri-mera fase, se levantan los cimientos, luego las columnas y vigas, las distintas plantas, hasta tener un esqueleto de la finca. Después se construyen suelos, paredes, puertas y ventanas, instalaciones eléctricas y de fontanería, etc. En definitiva, primero se crea la estructura que da soporte al edificio y luego se ensamblan las distintas partes que aportan las funcionalidades básicas del in-mueble. La estructura tiene una importancia especial, pues los fallos cometi-dos durante la primera etapa podrían degenerar en un edificio no habitable, además de no ser fáciles de corregir. Por el contrario, errores no estructurales como la ausencia de alguna puerta o una instalación defectuosa de las ven-tanas serían problemas que, aunque importantes, podrían ser relativamente fáciles de subsanar.
Este modo de proceder es aplicable también a la creación de software. A dife-rencia de la construcción de un edificio "común", el software no se rige por leyes físicas ni por procedimientos conocidos, sino que es inherentemente ex-perimental, creativo y específico para un problema concreto. Desde un punto de vista abstracto, la arquitectura�software –como se conoce al esqueleto o estructura del sistema– se define a partir de un conjunto de requisitos funcio-nales críticos, de rendimiento o de calidad. Analizando cómo el software debe dar solución a tales objetivos, la arquitectura construye el conjunto de estruc-turas, clases y atributos principales del software y sus interfaces de comunica-ción. Desde un punto de vista más tangible, la arquitectura se materializa en el conjunto de componentes que implementan dicho esqueleto, lo que permite evaluar los requisitos fijados inicialmente.
La arquitectura software también proporciona elementos que ayudan en la to-ma de decisiones, al mismo tiempo que sirve de to-marco común que posibilita la comunicación entre los equipos que participan en un proyecto. Para conse-guirlo, la arquitectura del software construye abstracciones, materializándolas en forma de modelos que se representan en diferentes tipos de diagramas.
1.2. Objetivos de la arquitectura software
Sin pretender establecer una definición completa y definitiva por el momento, en un sentido amplio podríamos estar de acuerdo en que la arquitectura es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación, y que tiene la responsabilidad de:
1) Identificar los módulos�principales del sistema, posponiendo los detalles
de implementación de cada uno de ellos a fases posteriores en el diseño.
2) Identificar la funcionalidad y las responsabilidades que tendrá cada uno
de estos módulos.
3) Definir las interacciones posibles entre dichos módulos; utilizando para
ello mecanismos de control y flujo de datos, secuenciación de la información, protocolos de interacción y comunicación, etc.
Pero ¿cuál es la motivación que provoca que surja el interés por abordar de manera explícita los aspectos arquitectónicos de un sistema? En este sentido, el diseño arquitectónico es importante por varias razones:
a) La descripción de la arquitectura hace más sencilla la comprensión�de�sis-temas�complejos, al explicitar las decisiones de diseño de alto nivel sobre el
sistema software.
b) Las descripciones arquitectónicas pueden�ser�reutilizadas. Así, mientras la
reutilización normalmente se limita al uso de bibliotecas de funciones o cla-ses, el diseño arquitectónico potencia la reutilización de grandes componen-tes software y, lo que es más importante, de la arquitectura de la aplicación. De este modo, pueden crearse y catalogarse patrones arquitectónicos de uso común. Estos patrones facilitan el proceso de diseño al proporcionar solucio-nes comusolucio-nes a cierto tipo de problemas.
c) Por último, la descripción arquitectónica permite� al� diseñador� razonar
sobre la propia estructura del sistema, sus propiedades, etc.
En general, la representación de una arquitectura software se realiza en térmi-nos de una colección de componentes y de las interacciones que tienen lu-gar entre ellos. Debe prestarse pues especial atención no sólo al diseño de los componentes, sino también a cómo éstos se organizan entre sí y a cómo se conectan con los demás para realizar una determinada tarea. Pero veamos cuál es la definición de arquitectura software que ofrece la comunidad científica.
1.3. Definición de arquitectura software
A pesar del creciente interés que los aspectos arquitectónicos del desarrollo software están cobrando en los últimos años –tanto desde la comunidad cien-tífica como desde la propia industria–, no existe aún un consenso claro res-pecto a qué se entiende por la arquitectura de un sistema software.
Lista de definiciones El Software Engineering Ins-titute (SEI) de la Universidad Carnegie Mellon ofrece una recopliación muy completa e interesante de definiciones de arquitectura software en http://www.sei.cmu.edu/archi-tecture/definitions.html.
Examinando algunas recopilaciones –como la presentada por el Software En-gineering Institute (SEI)–, comprobamos que, en general, muchas definiciones entremezclan concepciones distintas que resultan en ocasiones contrapuestas. Frente a esta diversidad, dos son las definiciones más reconocidas en la litera-tura científica.
Arquitectura software (Garlan y Perry, 1995): estructura de los compo-nentes de un programa o sistema, sus interrelaciones y los principios y reglas que gobiernan su diseño y evolución en el tiempo.
Arquitectura software (Bass, Clements y Kazman, 2003): estructura o estructuras de un sistema, lo que incluye sus componentes software, las propiedades observables de dichos componentes y las relaciones entre ellos.
Aunque no exactamente iguales, ambas definiciones sugieren que:
• La�arquitectura�software�de�un�sistema�define�elementos:
componen-tes y conectores que se vinculan en el proceso de diseño. La arquitectura expresa información sobre cómo se relacionan los elementos entre sí omi-tiendo, intencionadamente, otros aspectos no relacionados con la estruc-tura y funcionalidad detallada de cada uno de ellos.
• Queda�implícito�que�todo�sistema�tiene�una�arquitectura, ya que
pue-de mopue-delarse como una composición pue-de elementos y las relaciones entre ellos.
En el caso trivial, el sistema constará de un único elemento, lo que dará como resultado una arquitectura poco interesante y probablemente poco útil, pero una arquitectura al fin. Por otro lado, que todo sistema tenga una arquitectura no implica necesariamente que ésta sea conocida; lo que demuestra la importancia de documentar la arquitectura. •
Los�detalles�de�implementación�interna�de�cada�elemento�no�son�re-levantes�en�este�nivel. El comportamiento de un elemento forma parte
de la descripción de la arquitectura siempre que dicho comportamiento sea interesante desde el punto de vista global, y pueda ser observado o percibido desde otro elemento.
Por otro lado, si examinamos con más detalle ambas definiciones, encontra-remos algunas discrepancias:
• Mientras Garlan y Perry afirman que cada sistema tiene una única arqui-tectura, Bass, Clements y Kazman consideran varias posibles representa-ciones, atendiendo a puntos de vista distintos. Así, un sistema podría com-prender más de una estructura, y ninguna estructura en particular podría atribuirse el privilegio de ser llamada "la arquitectura".
Concepto de componente En estas definiciones el con-cepto de componente es ge-nérico y en el ámbito arquitec-tónico, al tiempo que no se re-fiere en particular a ninguno de los "componentes softwa-re" que definen los modelos de componentes como CORBA Component Model, J2EE (Java-Beans o EJB), ActiveX, COM, COM+ o .NET.
• Para Garlan y Perry la arquitectura no sólo contiene información sobre su estructura, sino también sobre los motivos y las decisiones que se han to-mado a la hora de construirla, y que van a ser claves a la hora de mantener el sistema, actualizarlo o realizar modificaciones sobre él: "(...) los princi-pios y reglas que gobiernan su diseño y evolución en el tiempo".
Teniendo en cuenta los aspectos previamente citados, podemos definir la ar-quitectura software de un sistema de la siguiente manera:
La arquitectura�software: el conjunto de decisiones, principios y reglas que rigen la organización de un sistema software; la selección de los elementos estructurales que componen el sistema, sus interfaces y sus protocolos de interacción; las conexiones de esos elementos estructu-rales para formar subsistemas de tamaño cada vez mayor; y el estilo o patrón arquitectónico que guía esta organización.
Una arquitectura software va a venir descrita por una serie de modelos, que son los que componen la descripción arquitectónica del sistema. En nuestro caso utilizaremos UML para describir esos modelos.
1.4. Componentes y conectores
Las descripciones arquitectónicas vienen descritas en términos de componen-tes y conectores.
En el contexto de la arquitectura software, un componente es una uni-dad abstracta que encapsula un estado y una funcionaliuni-dad, y que in-teracciona con su entorno a través de interfaces bien definidos.
En otras palabras, un componente es definido por los interfaces que definen los servicios que proporciona a otros componentes, sin entrar en detalles ni consideraciones sobre cómo se implementan tales servicios.
En el contexto de la arquitectura software, un conector es un mecanis-mo abstracto que media en la comunicación, coordinación o coopera-ción entre componentes.
Ved también
Veremos con más detalle los modelos arquitectónicos en el apartado "Representación de la arquitectura software" de este módulo. Ejemplos de componentes • clientes, • servidores, • filtros, • capas,
Los conectores constituyen los enlaces que ensamblan a los componentes y definen su organización y conexiones. Los conectores pueden definir tanto los mecanismos y protocolos de interacción entre los componentes, como algu-nos requisitos de calidad (tiempos y capacidad de transmisión, tasas de trans-ferencia, tasas de errores, seguridad, etc.).
Internamente, un conector puede ser algo tan simple como una llamada a un procedimiento, o consistir en un nuevo sistema de componentes tan comple-jo como lo requiera la aplicación modelada. Pero desde el punto de vista ar-quitectónico esa complejidad quedará oculta y sólo será visible cuando se es-pecifiquen los detalles internos de los componentes y conectores del sistema a un nivel de abstracción menor.
Obsérvese que la descripción de la arquitectura software de un sistema se corresponde con su especificación desde el punto de vista computacio-nal de RM-ODP, donde los componentes se corresponden fielmente con los objetos computacionales y los conectores con los objetos de enlace.
Aunque, obviamente, cada diseñador puede definir los componentes y los co-nectores de la arquitectura software de un sistema como mejor crea conve-niente, siempre suele ser mejor (menos errores, más eficiente, etc.) utilizar al-guno de los estilos arquitectónicos existentes. En ese caso, los tipos de compo-nentes y conectores vienen determinados por el modelo o estilo arquitectóni-co seleccionado para el diseño. Por lo tanto, es importante arquitectóni-conocer cuáles son los estilos arquitectónicos existentes y sus aplicaciones, así como las ventajas e inconvenientes que presentan. Las siguientes secciones están destinadas a tratar estos aspectos.
1.5. Estilos arquitectónicos
Ejemplos de conectores simples
• las llamadas a procedimien-tos,
• el paso de mensajes, • los protocolos de
comuni-cación, • las tuberías, etc.
Desde los inicios de la arquitectura de software, se observó que ciertas regu-laridades en la estructura, el estilo y los elementos utilizados aparecían una y otra vez como respuesta a similares demandas. Por analogía con el uso del término en arquitectura civil, a estos patrones pronto se los llamó estilos ar-quitectónicos.
Los estilos�arquitectónicos representan formas diferentes de estructu-rar un sistema usando componentes y conectores, de acuerdo con de-cisiones esenciales sobre los elementos arquitectónicos y estableciendo restricciones importantes sobre tales elementos y sus posibles relacio-nes.
A la hora de definir un estilo arquitectónico, el campo de aplicación no es lo principal; es más importante tener en cuenta el patrón de organización general, los tipos de componentes habitualmente presentes en el estilo y las interacciones que se establecen entre ellos.
Un estilo�arquitectónico define una familia de sistemas, en términos de un conjunto de patrones estructurales.
Además, un estilo arquitectónico indicará cuáles son los patrones y restriccio-nes de interconexión o composición entre ellos, lo que se denomina
invarian-tes�del�estilo. Estos invariantes son los que diferencian unos estilos
arquitec-tónicos de otros.
Cada estilo caracteriza una estructura�general�a�alto�nivel, junto a
mi-croarquitecturas que contribuyen a la arquitectura global.
La Catedral de Reims
La Catedral de Reims (siglo XIII, mostrada al margen) pertenece al estilo gótico, uno de los numerosos estilos arquitectónicos utilizados en las catedrales de toda Europa. El estilo establece las principales reglas que han de guiar la construcción de la catedral a lo largo de su desarrollo (ocho generaciones de constructores trabajaron en ella), y tam-bién determina el modo como puede evolucionar con posterioridad. Para ello, el estilo caracteriza una estructura general a alto nivel, junto a microarquitecturas que contribu-yen a la arquitectura global.
En el caso concreto del gótico, los elementos esencialmente característicos de este estilo arquitectónico son la bóveda de crucería y el arco ojival; la primera afecta a la estructura y el otro, más particularmente, a las formas exteriores. Además, la planta de las catedrales góticas es en forma de cruz, de tres o cinco naves, con crucero más corto que el de la arquitectura románica, con la girola o deambulatorio en la cabecera y en la que se abren las capillas poligonales, todas encerradas en un gran medio círculo. También destacan altas naves laterales en las que se abren amplios ventanales y recios contrafuertes que rodean el perímetro de la catedral, rematados por pináculos. Todas estas características son las que constituyen los invariantes�del�estilo y que permiten distinguir claramente una construcción que sigue este estilo de otra.
Por último, los invariantes de cada estilo van a dotar a un sistema de una serie de propiedades que van a determinar sus ventajas e inconvenientes, y que van a condicionar la elección de uno u otro estilo a la hora de resolver un determinado problema.
En el caso de las arquitecturas del software, los invariantes de estilo van a venir dados por el conjunto de reglas y restricciones que prescriben:
1) Qué tipos de componentes (elementos estructurales), interfaces, conectores
y patrones pueden ser usados en un sistema (posiblemente introduciendo ti-pos específicos para cada dominio de aplicación concreto).
Ejemplos de estilos arquitectónicos
El proyecto ABLE de la Carne-gie Mellor University (CMU) cuenta con trabajos y ejem-plos muy útiles sobre estilos arquitectónicos de software. Se puede consultar en http:// www.cs.cmu.edu/~able.
2) Cómo los componentes y conectores pueden ser combinados (restricciones
de interconexión o composición entre ellos).
3) Cómo se comporta el sistema y cómo ciertas propiedades pueden ser
deter-minadas en función de las propiedades de sus componentes. Cada estilo lleva asociados unos determinados mecanismos de interacción, que implican cómo se transfiere el control entre los componentes y cómo éstos colaboran para implementar la funcionalidad del sistema.
Otro aspecto destacable también en cualquier diseño arquitectónico de un sistema es el de su integridad�conceptual, un principio por el cual el patrón general de diseño de un sistema se refleja en cada parte del mismo. Esto implica que las restricciones que definen los invariantes de estilo han de ser coherentes entre sí y respetar cierta armonía.
En el caso de la Catedral de Reims, su integridad conceptual se debe al uso intensivo del estilo gótico en todos y cada uno de sus elementos arquitectónicos, desde su estructura global a sus elementos internos.
En general, la integridad conceptual no obliga a que haya un único estilo ar-quitectónico puro, sino que es posible conjugar más de uno en un mismo sis-tema. Ahora bien, el modo de conjugar los estilos no puede ser heterogéneo y caprichoso, sino que debe estar sujeto a unos invariantes del estilo –para ga-rantizar la integridad conceptual–, que son los que determinan cómo y cuán-do se pueden mezclar los patrones estructurales correspondientes.
Por ejemplo, hay muchos edificios con mezclas de estilos arquitectónicos, pero que con-jugan perfectamente esas mezclas de manera armoniosa (es decir, respetando su integri-dad conceptual). Igualmente, muchos sistemas de software conjugan distintos estilos ar-quitectónicos, pero es muy importante determinar también los invariantes de estilo que van a regir dichas combinaciones. Un ejemplo muy claro ocurre con los sistemas web, diseñados usando un estilo cliente-servidor entre componentes independientes, pero que además se organizan en tres capas o niveles. Ahora bien, la asignación de componentes a capas (que constituiría esa "mezcla" de estilos) no se realiza de manera caprichosa, sino que viene determinada por unos criterios claros en cuanto a su localización física, rendi-miento, eficiencia y funcionalidad específica de cada uno de los componentes.
1.6. Clasificación de los estilos arquitectónicos
Existen numerosos estilos arquitectónicos definidos para sistemas software que, en general, pueden clasificarse como indica la figura 1.
Lo que opinan los expertos
"Conceptual integrity is the most important consideration in system design" (Brooks, The
Mythical Man Month, 1975)
"The same set of laws de-termines the structure of a city; a building; or a single room" (Alexander, A Pattern
Figura 1. Clasificación de los principales estilos arquitectónicos Lecturas complementarias
Para ver con más detenimiento los detalles presentados en esta clasificación y otras se-mejantes, pueden consultarse las siguientes referencias:
L.�Bass;�P.�Clements;�R.�Kazman (1998). Software Architecture in Practice. Addison-Wesley. Reading, MA.
D.�Garlan;�M.�Shaw (1994). An introduction to software architecture. Advances in
Softwa-re Engineering and Knowledge Engineering (vol. 1, pág. 1-40). World Scientific Publishing
Company. Hackensack, NJ, USA.
A continuación vamos a presentar muy brevemente cada una de estas clasifi-caciones, para pasar a describir aquellos estilos arquitectónicos que son espe-cialmente relevantes para los sistemas distribuidos basados en componentes.
1.6.1. Arquitecturas de flujo de datos
Este tipo de arquitecturas son adecuadas para aplicaciones que se orga-nizan en términos de datos que fluyen entre unidades de procesamien-to. Cada unidad es diseñada independientemente de las otras. Así, los datos tienen una fuente (origen) y terminan en un sumidero (destino). Por ejemplo, las aplicaciones que se desarrollan usando cualquiera de las shell de los sistemas Unix son quizá los sistemas más representativos del estilo arquitectónico basado en filtros y tuberías. Estas aplicaciones se construyen a partir de programas que actúan como filtros (cada uno recibe unos datos de entrada, los transforma y los envía por su canal de salida), que se conectan entre sí por tuberías (pipes). Este estilo arquitectónico se discutirá con más detalle en el subapartado 1.7.1.: "Arquitecturas de flujo de datos". Los sistemas que siguen un estilo arquitectónico basado en flujo de datos se suelen diseñar en torno a los datos que manejan; los componentes actúan como meros "transformadores" de tales datos. En este sentido, los datos cobran mayor relevancia que el procesamiento.
1.6.2. Arquitecturas de componentes independientes
Los modelos arquitectónicos basados en componentes independientes favorecen la distribución tanto de los datos, como del procesamiento, pues ambos se encuentran "encapsulados" en unidades
independien-tes (los componenindependien-tes) que interactúan entre sí para lograr su objetivo.
Normalmente, el acceso al estado que almacena cada componente no se efectúa de manera directa, sino a través de invocaciones a sus opera-ciones.
Los sistemas software que siguen estos estilos arquitectónicos consisten, por lo general, en procesos o entidades independientes que operan (en principio) en paralelo y se comunican a través de mensajes. Cada entidad puede enviar mensajes a otras entidades, pero no acceder al estado interno de otras entida-des directamente; de ahí que el acoplamiento entre los componentes sea mí-nimo. El intercambio de datos se realiza mediante paso de mensajes a compo-nentes nominados –habitual en los sistemas basados en comunicación entre procesos– o propagados mediante difusión (en inglés, broadcast), típico de los sistemas de eventos.
A diferencia de los estilos arquitectónicos basados en flujos de datos, que se centran en los datos que maneja el sistema y en cómo éstos van siendo trans-formados sucesivamente por los programas, los estilos basados en componen-tes individuales se concentran más en el procesamiento, esto es, en la funcio-nalidad del sistema y en su organización en unidades independientes. Una característica muy importante de estos estilos arquitectónicos es que favore-cen la reutilización de sus componentes y son muy flexibles en cuanto a su distribución en máquinas diferentes.
1.6.3. Arquitecturas basadas en repositorios
En el centro de esta arquitectura se encuentra un almacén�de�datos (por ejemplo, un documento, una "pizarra", una "sopa" de objetos, o una base de datos) al que otros componentes acceden con frecuencia para añadir, consultar, borrar o bien modificar los datos del almacén.
Ved también
Miembros de esta familia son los estilos basados en capas, cliente-servidor, objetos, even-tos o servicios. Eseven-tos subestilos serán tratados, respectivamen-te, en el apartado 1.8.
En este estilo, la comunicación entre los componentes nunca es directa, sino que se realiza siempre a través del repositorio (si un componente quiere man-dar algo a otro, lo deposita en el repositorio y este otro ya lo recogerá cuando pueda). Este modo de interacción indirecta es muy apropiado para sistemas que requieren un desacoplamiento muy elevado entre sus componentes, que no necesitan conocerse para interactuar. Las pizarras incluso permiten que la
comunicación sea anónima, pues los componentes depositan los datos sin sa-ber quién los consumirá, mientras que los consumidores buscan sus datos uti-lizando "patrones" de busca.
Además, es fácil distribuir sus componentes. Sin embargo, estos sistemas pue-den plantear algunos problemas a la hora de distribuir el repositorio en dife-rentes máquinas, ya que se trata de una estructura que desde un punto de vista conceptual es claramente centralizada.
Por otro lado, el repositorio o almacén de datos puede ser pasivo o activo. • Se dice que un repositorio es pasivo cuando los componentes dejan o
re-cogen información en el repositorio, que actúa como mero almacén de datos.
• Por el contrario, un repositorio activo envía notificaciones a los compo-nentes clientes cuando cambian los datos que a éstos les interesan.
1.6.4. Arquitecturas de máquina virtual
Las aplicaciones basadas en este estilo simulan funcionalidades no nativas del hardware y software en las que se implementan, o también capacidades que exceden a (o que no coinciden con) las capacidades del paradigma de pro-gramación que se está implementando. La funcionalidad deseada se consigue mediante una máquina de interpretación que incluye tanto la definición del intérprete, como el estado actual de su ejecución. El estilo comprende básica-mente dos formas o subestilos, que se han llamado intérpretes y sistemas ba-sados en reglas.
1.7. Arquitecturas heterogéneas
Numerosos sistemas presentan una arquitectura que puede considerarse como marginalmente perteneciente a un estilo o a otro, o bien que combina clara-mente características de varios estilos. Es normal que una misma aplicación use distintas arquitecturas para resolver distintos aspectos del mismo proble-ma. Diremos entonces que estos sistemas tienen un estilo heterogéneo. Esta heterogeneidad puede ser de tres tipos:
• Los sistemas localmente�heterogéneos tienen una arquitectura que sigue principalmente un determinado estilo, pero que en determinadas partes presenta patrones de otros estilos diferentes. Por ejemplo, algunas partes de un sistema estructurado en objetos distribuidos pueden seguir un estilo de repositorio.
• En los sistemas jerárquicamente�heterogéneos, la arquitectura interna de los componentes de un sistema conforme a un cierto estilo siguen estilos arquitectónicos distintos. Así, por ejemplo, cada uno de los integrantes
de las capas de un sistema estructurado en capas puede seguir un estilo arquitectónico basado en componentes independientes.
• Finalmente, en los sistemas simultáneamente�heterogéneos varios esti-los pueden aplicarse para describir su arquitectura, dependiendo del punto de vista, o de qué componentes consideremos más importantes. Así, por ejemplo, muchos sistemas de procesamiento por lotes pueden considerar-se tanto sistemas de flujo de datos, como sistemas centrados en los datos. Esta heterogeneidad es fruto, en muchos casos, de las similitudes existentes entre algunos estilos arquitectónicos. Por ejemplo, el lector encontrará impor-tantes semejanzas entre:
• Las máquinas virtuales y las arquitecturas multicapa. • Los repositorios de datos y las arquitecturas cliente-servidor. • Las tuberías y filtros y los procesos paralelos.
Recordemos que, tal y como se mencionó en el apartado de estilos arquitec-tónicos, la manera de conjugar los estilos no puede ser caprichosa, sino que debe estar sujeta a unos invariantes del estilo que garanticen la integridad
conceptual.
En los siguientes subapartados estudiaremos con más detalle aquellos estilos arquitectónicos relevantes desde el punto de vista de los sistemas abiertos y distribuidos.
1.8. Principales estilos arquitectónicos
1.8.1. Sistemas de flujo de datos
En los sistemas�de�flujo�de�datos, los datos fluyen de un lugar a otro y se transforman durante este movimiento. Cada paso se implementa como una transformación: los datos de entrada fluyen a través de estas trans-formaciones hasta que se convierten en salidas. Las transtrans-formaciones se pueden ejecutar secuencialmente o en paralelo y los datos se pueden procesar, para cada transformación, elemento por elemento o en lotes.
En algunas ocasiones en las que las transformaciones se presentan como pro-cesos separados, a este modelo se le denomina el�modelo�de�tuberías�y�filtros, en referencia a la terminología utilizada en los sistemas Unix (véase figura 2), donde se utiliza el término filtro porque una transformación "filtra" los datos que procesa de los flujos de datos de entrada.
Figura 2. Tuberías y filtros
Cuando las transformaciones son secuenciales, con los datos procesados por lotes, este modelo arquitectónico recibe el nombre de modelo�secuencial�por
lotes (véase figura 3). Ésta es una arquitectura común para algunas clases de
sistemas de procesamiento de datos como los sistemas de facturación, que generan gran número de informes de salida a partir de cálculos sencillos sobre varios registros de entrada.
Figura 3. Secuencial por lotes
Un ejemplo de arquitecturas de flujos de datos
Supongamos una organización que emite facturas a sus clientes. Una vez a la semana, los pagos realizados se comparan con las facturas. Para esas facturas pagadas, se emite un recibo. Para las facturas que no se pagan dentro del tiempo permitido, se emite un recordatorio. El siguiente es el modelo de una parte del sistema de procesamiento de facturas.
Figura 4. Un modelo de flujo de datos de un sistema de procesamiento de facturas
Se recomienda utilizar este estilo cuando el foco principal de la solución se centra en los datos y, además, es posible especificar una secuencia de un nú-mero conocido de pasos o procesos para resolver el problema inicial. En este sentido, los procesos son meros elementos que van transformando los datos
en cada paso. Nótese que es requisito indispensable también que todos los componentes situados más adelante en la tubería sean capaces de inspeccio-nar y actuar sobre los datos que vienen de más atrás, pero no viceversa. Las principales�ventajas de este estilo arquitectónico son:
• Los filtros son entidades independientes fácilmente reutilizables.
• Aunque en principio fuerzan un procesamiento secuencial, en muchas ocasiones los filtros se pueden colocar en paralelo o incluso estar distri-buidos.
• Los sistemas caracterizados por este estilo arquitectónico son altamente modulares y extensibles.
• El estilo es fácil de entender e implementar.
La desventaja principal del modelo proviene de que fuerza de alguna manera a un procesamiento lineal de los datos, no apto para muchos tipos de siste-mas (como por ejemplo los sistesiste-mas web y aquellos en los que hay muchas interacciones con los usuarios, que normalmente tienen flujos de control muy complejos).
1.8.2. Sistemas organizados en capas o niveles
Las arquitecturas�en�niveles (layered architectures) representan una or-ganización jerárquica de los elementos de un sistema, de modo que cada capa proporciona servicios a los elementos de la capa inmediatamente anterior, y se sirve de los servicios que le brindan los elementos de la capa inmediatamente siguiente.
En los sistemas organizados en capas, los componentes, que pueden ser tanto procedimientos como objetos, se estructuran en niveles, cada uno de los cua-les tiene asociado una funcionalidad.
En este estilo arquitectónico, cada capa puede ser definida como un conjunto de (sub)sistemas con el mismo grado de generalidad. Por otro lado, en un estilo en capas los conectores se definen mediante los protocolos que determinan las vías de la interacción.
La funcionalidad del sistema puede descomponerse en capas horizontales o verticales.
• En las capas�verticales, la descomposición suele deberse al nivel de abs-tracción de los elementos de cada capa: los niveles inferiores implemen-tan funciones simples, ligadas al hardware o al entorno, mientras que los niveles superiores implementan funciones más abstractas.
• En los sistemas en capas�horizontales, la división suele deberse a otras causas, como por ejemplo el grado de cercanía al usuario final (a la izquier-da) frente al procesamiento que realizan los mainframes y grandes gestores de bases de datos (más a la derecha).
• Las capas�intermedias suelen albergar elementos de procesamiento que sirven de intermediarios entre los clientes (a la izquierda) y los grandes ser-vidores a la derecha. En cualquier caso, esta división es muy dependiente de la forma en la que el arquitecto la dibuje.
Las restricciones topológicas del estilo pueden incluir una limitación, más o menos rigurosa, que exige a cada capa operar sólo con capas adyacentes, y a los elementos de una capa entenderse sólo con otros elementos de la misma; se supone que si esta exigencia se relaja, el estilo deja de ser puro y pierde algunas de sus propiedades. También se pierde, naturalmente, la posibilidad de reemplazar una capa sin afectar a las restantes, con lo que disminuye la flexibilidad del conjunto y se complica su mantenimiento.
Figura 5. Arquitectura de red basada en el modelo OSI
Las formas más rígidas de las arquitecturas en capas no admiten ni siquiera dejar pasar las llamadas o los datos sin hacer nada con ellos (pass-through): cada capa debe hacer algo, siempre. Muchas veces, sin embargo, se utilizan versiones más relajadas de este estilo, en las que una capa puede acceder di-rectamente a los servicios de capas no inmediatamente inferiores por motivos de rendimiento.
Casos representativos de este estilo son muchos de los protocolos de comuni-cación; el modelo OSI (Open Systems Interconnection) de ISO con los siete nive-les que todos conocemos (nivel físico, enlace de datos, red, transporte, sesión,
presentación y aplicación) es el ejemplo más característico de este estilo. Tam-bién se encuentra en forma más o menos pura en arquitecturas de bases de datos y sistemas operativos.
Sus ventajas son obvias:
• El estilo soporta un diseño basado en niveles�de�abstracción claramente identificados, lo cual a su vez permite a los arquitectos la descomposición de un problema complejo en subsistemas independientes y complemen-tarios, cada uno encargado de una misión muy concreta.
• El estilo admite optimizaciones y refinamientos de manera natural. • También permite una amplia reutilización. Se pueden utilizar diferentes
implementaciones o versiones de una misma capa siempre que soporten las mismas interfaces a las capas adyacentes. Esto conduce a la posibilidad de definir interfaces de capa que sean estándar, a partir de las cuales dife-rentes proveedores pueden construir extensiones o prestaciones específi-cas. Esto facilita, entre otras cosas, la portabilidad de los sistemas en los que el acoplamiento con el entorno está localizado en la capa inferior, co-mo sucede en los sistemas basados en la torre OSI. Para portar el sistema a un entorno diferente, basta con implementar de nuevo este nivel. Por otro lado, las desventajas más importantes de este estilo son:
• Muchos problemas no admiten ser representados siguiendo una estructu-ra jerárquica. Incluso cuando un sistema se puede establecer lógicamente en capas, consideraciones de rendimiento pueden requerir acoplamientos específicos entre capas de alto y bajo nivel.
• En ocasiones es también extremadamente difícil encontrar el nivel de abs-tracción adecuado; por ejemplo, la comunidad de las comunicaciones ha encontrado complejo representar los protocolos existentes en el modelo OSI, de modo que muchos protocolos actuales agrupan en una sola capa varias capas de las propuestas por OSI.
• Los cambios en las capas de bajo nivel tienden a filtrarse hacia las de alto nivel, en especial si se utiliza una modalidad relajada de este estilo. • La arquitectura en capas ayuda a controlar y encapsular aplicaciones
1.8.3. Arquitecturas cliente-servidor
En una arquitectura�cliente-servidor, una aplicación se modela como un conjunto de componentes servidores, que ofrecen unos servicios y un conjunto de clientes que utilizan estos servicios.
Así, podríamos decir que los integrantes principales de este modelo son:
1) Un conjunto de servidores independientes que ofrecen servicios a otros
componentes.
2) Un conjunto de clientes que solicitan a los servicios ofrecidos por los
servi-dores. Por lo general, pueden existir varias instancias de un programa cliente que se ejecutan de manera concurrente.
3) Un medio�de�comunicación, generalmente, una red que permite la
comu-nicación entre clientes y servidores, y que va a permitir abstraer detalles sobre si la comunicación es local o remota.
En el caso más simple de que los clientes y los servidores sean componentes homogé-neos y se ejecuten en una sola máquina, no sería necesario un medio de comunicación especial.
La comunicación entre clientes y servidores puede ser síncrona o asíncrona. • En el caso síncrono, el servidor devuelve el control a los clientes junto al
servicio solicitado.
• En el caso asíncrono, el cliente tiene su propio flujo de control y ambos componentes intercambian sólo datos.
Por otro lado, los roles desempeñados por los componentes no son necesaria-mente fijos. Un servidor, por ejemplo, podría solicitar un servicio a otro ser-vidor con el fin de satisfacer la petición de su cliente, actuando por lo tanto en ese momento a su vez como cliente. Análogamente, los clientes también pueden actuar como servidores para otros clientes en caso de que implemen-ten algunos servicios. El caso extremo se da en los sistemas�entre�pares
(peer-to-peer) en los que los roles de cliente y servidor se diluyen, puesto que todo
Figura 6. Un sistema cliente-servidor
Una característica muy importante de los sistemas cliente-servidor es que los clientes deben conocer los nombres de los servidores disponibles y los servicios que suministran, aunque por lo general no han de conocer la existencia de otros clientes. Sin embargo, los servidores no requieren conocer la identidad de los clientes o su número. En el caso de objetos distribuidos, los clientes acceden a los servicios suministrados por un servidor a través de llamadas a procedimientos remotos.
Una de las ventajas más importantes del modelo cliente-servidor es que se permite de manera natural la distribución de sus componentes. Además, este tipo de sistemas suelen ser fácilmente escalables, lo que permite la agregación de nuevos servidores y su integración con el resto del sistema cuando es nece-sario. Del mismo modo, es posible actualizar de modo transparente los servi-dores sin afectar al funcionamiento de otras partes del sistema.
Sin embargo, la falta de un modelo compartido de datos entre clientes y ser-vidores (y también entre los mismos serser-vidores) puede suponer un problema. Cada subsistema, por lo general, organiza y administra sus datos de manera diferente. Esto significa que los modelos de datos son específicos para cada servidor y que un cliente debe adaptar sus modelos de datos para trabajar con los diferentes servidores que utiliza.
Clientes y servidores En general, cuando se habla de clientes y servidores nos re-ferimos a procesos lógicos más que a ordenadores físicos so-bre los cuales se ejecutan estos procesos. Los clientes y servi-dores son procesos diferentes y pueden o no estar alojados en el mismo nodo físico.
Modelo maestro-esclavo
Una variante interesante del modelo cliente-servidor es el conocido como maestro-es-clavo, que se utiliza frecuentemente en dominios de cálculo científico. En una arquitec-tura de este tipo, el cliente se conoce como "maestro" y los servidores como "esclavos". El maestro es el responsable de resolver un problema de complejidad elevada y para ello utiliza algún algoritmo divide-y-vencerás o de ramificación y poda que descompone el problema en numerosos subproblemas de menor tamaño. El maestro va a encargar a los esclavos la solución de cada uno de esos subproblemas para, posteriormente, combinar las soluciones parciales y construir la solución final. En el caso particular en el que todos los subproblemas sean iguales y, por tanto, los esclavos sean del mismo tipo, estaríamos hablando de granjas�de�procesos.
Este tipo de sistemas se ha comenzado a utilizar con mucho éxito con fines científicos en proyectos que aprovechan los tiempos de inactividad de los ordenadores personales conectados a Internet, que voluntariamente ceden sus CPU para realizar cálculos. Estos ordenadores personales actúan por tanto como esclavos para un proceso maestro que trata de resolver algún problema de alta complejidad científica como puede ser la bus-ca de inteligencia extraterrestre analizando los "ruidos" recibidos del espacio (proyecto SETI@home) o procesos bioquímicos como el autoensamblado de proteínas (proyecto folding@home).
1.8.4. Arquitecturas heterogéneas: sistemas cliente-servidor organizados en capas
Habitualmente, las aplicaciones cliente-servidor se estructuran en capas. De-pendiendo de la carga y el nivel de procesamiento que realicen los componen-tes de cada capa, podemos distinguir distintos estilos arquitectónicos:
Arquitecturas cliente-servidor de dos capas con cliente fino (thin
client)
En un modelo de cliente fino, todo el procesamiento de la aplicación y la administración de datos se realiza en el servidor. El cliente sólo es responsable de ejecutar el software de presentación. En casos extremos, un cliente fino sólo actúa como un terminal.
Una gran desventaja del modelo de cliente fino es que coloca una gran carga de procesamiento tanto en el servidor como en la red. El servidor es responsable de todos los cálculos y en muchas ocasiones esto implica la generación de bastante tráfico en la red entre el cliente y el servidor.
Arquitecturas cliente-servidor de dos capas con clientes gruesos (fat client)
En este modelo el servidor es sólo responsable de la administración de los da-tos. El software del cliente implementa la lógica de la aplicación y las interac-ciones con el usuario del sistema. Esencialmente, el servidor es un servidor de transacciones que administra todas las transacciones de la base de datos. Aunque el modelo de cliente grueso distribuye el procesamiento de manera más efectiva que uno de cliente fino, la administración del sistema resulta más compleja. La funcionalidad de la aplicación se distribuye en muchos ordena-dores diferentes. Así, cuando cambia la aplicación software, es necesario reins-talarla en cada cliente del sistema.
Figura 8. Modelo de cliente grueso
Arquitecturas cliente-servidor de tres capas
Para evitar los problemas de escalabilidad y administración que presentan los dos modelos anteriores, surgió la arquitectura cliente-servidor de tres capas. En esta arquitectura, la presentación, el procesamiento de la aplicación y la administración de los datos son procesos separados lógicamente.
Figura 9. Modelo de cliente-servidor de tres capas
Una arquitectura cliente-servidor de tres capas no implica necesariamente que existan tres sistemas de cómputo conectados a la red. Los procesos servidores encargados del procesamiento y de la administración (como servidores lógicos diferentes) podrían ejecutarse en una misma máquina. Sin embargo, si surge la necesidad, es relativamente fácil separar el procesamiento de la aplicación y la distribución de datos y ejecutarlos en procesadores separados.
Variante de múltiples capas
En algunos casos, es apropiado ampliar el modelo cliente-servidor de tres ca-pas a una variante de múltiples�caca-pas (por ejemplo, cuatro) en la cual se agre-gan distintos niveles de servidores al sistema. Los sistemas de múltiples capas
se utilizan, por ejemplo, cuando las aplicaciones necesitan acceder y utilizar datos de diferentes bases de datos. En este caso, un servidor de integración se ubica entre el servidor de aplicación y los servidores de bases de datos a los que se accede. El servidor de integración recolecta los datos distribuidos y los presenta a la aplicación como si éstos estuvieran disponibles en una sola base de datos.
Observad que la capa del servidor para el procesamiento de la aplicación no implica que haya un solo servidor, sino que puede haber diferentes servidores cada uno encargado de procesar parte del funcionamiento de la aplicación.
Otros casos en los que se utiliza una cuarta capa se encuentran en los diseños arquitectó-nicos de ciertas aplicaciones web en las que se coloca una capa intermedia (denominada
proxy inverso) entre la capa del cliente y del servidor del procesamiento de la aplicación.
El proxy inverso es el encargado de servir al cliente todas las páginas y objetos estáticos, mientras que las páginas dinámicas las prepara el servidor, comunicándose a su vez con los servidores de bases de datos para obtener la información apropiada.
Como mencionamos en el apartado de arquitecturas heterogéneas, para el diseño global de muchas aplicaciones web suele ser común el uso de una arquitectura de tres capas, donde la capa intermedia se construye como un conjunto de objetos distribuidos. De esta manera, los sistemas orientados a objetos distribuidos que veremos a continuación pueden ser una vía de representar internamente la capa del procesamiento de la aplicación con arquitectura tres capas.
1.8.5. Sistemas orientados a objetos distribuidos
Una arquitectura orientada a objetos distribuidos estructura el sistema en un conjunto de objetos débilmente acoplados con interfaces bien definidas. Los objetos llaman a servicios ofrecidos por otros objetos. Así, la interacción entre objetos tiene lugar a través de invocaciones de sus operaciones.
Figura 10. Arquitectura de objetos distribuidos
Los objetos se distribuyen a lo largo de varios ordenadores sobre una red y se comunican a través de plataformas middleware. Por analogía con un bus hard-ware, el middleware se puede visualizar como un bus software que proporciona un conjunto de servicios que facilitan la comunicación, agregación y distri-bución de los objetos del sistema. Su rol es proveer una interfaz transparente entre los objetos que los abstraiga de detalles sobre su localización, o sobre si los componentes son heterogéneos o no (permitiendo conectar, por ejemplo, componentes desarrollados con lenguajes o plataformas distintas: C++, Java, Smalltalk, etc.)
Un ejemplo de sistemas orientados a objetos distribuidos
En la figura 11 se presenta un ejemplo de un sistema construido utilizando un modelo cliente-servidor. Éste es un sistema de hipertexto multiusuario que proporciona una bi-blioteca de películas y fotografías. En este sistema existen varios servidores que adminis-tran y despliegan los diferentes tipos de medios. Las películas se deben adminis-transmitir rápida-mente y de manera sincronizada, pero a una resolución relativarápida-mente baja. Pueden estar comprimidas en un almacén. Sin embargo, las imágenes se deben enviar en alta resolu-ción. El catálogo debe estar disponible para responder a una gran variedad de películas y proveer a los sistemas de información de hipertexto. El programa cliente es simplemente una interfaz de usuario integrada con esos servicios.
Figura 11. Arquitectura de alto nivel correspondiente a un sistema bibliotecario para películas e imágenes
Las principales ventajas de este estilo arquitectónico a la hora de diseñar sis-temas distribuidos son:
• Permite al diseñador del sistema retrasar�las�decisiones sobre dónde y có-mo se deben suministrar los servicios. Los objetos proveedores de servicios se pueden ejecutar en cualquier nodo de la red. Por lo tanto, la distinción entre los modelos de cliente fino y grueso es irrelevante, puesto que no existe necesidad de decidir por adelantado dónde se localizan los objetos lógicos de la aplicación.
• Ésta es una arquitectura de sistemas muy�abierta que permite agregar nue-vos recursos si es necesario. Las plataformas middleware han sido desarro-lladas e implementadas para permitir la comunicación y los servicios en-tre objetos escritos en diferentes lenguajes de programación, así como la integración de aplicaciones y componentes distribuidos.
• El sistema es flexible y escalable. Se pueden crear diferentes instancias del mismo servicio suministrado por objetos diferentes o por réplicas de obje-tos para hacer frente a sobrecargas del sistema. Si esta carga se incrementa, se pueden activar nuevos objetos sin perturbar a otros.
• Es posible reconfigurar�el�sistema de manera dinámica según las necesi-dades, migrando los objetos a lo largo de la red. Un objeto proveedor de servicios se puede trasladar al mismo procesador en el que residen los ob-jetos solicitantes del servicio.
Sin embargo, la principal desventaja de las arquitecturas de objetos distribui-dos es que son más complejas de diseñar que los sistemas cliente-servidor. La arquitectura cliente-servidor parece ser la forma más natural de concebir los sistemas, pues reflejan muchas transacciones humanas en las que la gente
so-licita y recibe servicios de otras personas especializadas en suministrar estos servicios. Es más difícil pensar en el abastecimiento de servicios generales si se carece de experiencia en el diseño y desarrollo de objetos de grano grueso.
1.8.6. Arquitecturas basadas en eventos
La idea dominante en las arquitecturas basadas en eventos es que, en lugar de invocar un procedimiento directamente (invocación explícita), como se haría en un estilo orientado a objetos, un componente puede anunciar, mediante difusión, uno o más eventos
(invocación�implíci-ta). Véase figura 12.
Figura 12. Invocación explícita e invocación implícita
De este modo, los componentes de un sistema interesados en un determina-do evento se subscriben al objeto emisor de dicho evento, notificándetermina-dole que quieren que los avise cuando se produzca el evento y pasándole al objeto emi-sor la referencia de un procedimiento al que quieren que invoque cuando se produzca dicho evento. De esta manera, en el objeto emisor quedan vincu-lados como oyentes (listeners) de dicho evento. Cuando el evento sucede, el sistema gestor de eventos invoca todos los procedimientos que solicitaron los objetos oyentes que haya registrados para el evento. De este modo, el anuncio de un evento implícitamente ocasiona la invocación de determinados proce-dimientos en todos los objetos oyentes.
Call-backs y el "principio de Hollywood"
Se denomina call-back al mecanismo que siguen los sistemas orientados a eventos, me-diante el cual el objeto interesado en un evento se suscribe a él y espera que lo llamen cuando suceda el evento (de ahí el término call-back). Se dice que este mecanismo sigue el denominado principio de Hollywood: "No llame usted; nosotros le llamaremos".
Invocación implícita En la literatura relacionada po-demos encontrar distintas de-nominaciones para este esti-lo arquitectónico, como por ejemplo "arquitecturas de in-vocación implícita", "de inte-gración reactiva", o "de difu-sión (broadcast) selectiva".
Figura 13. Arquitecturas de eventos
Este estilo debe aplicarse cuando se desea manejar, de manera aislada, varias implementaciones de una "función" específica. Desde el punto de vista arqui-tectónico, los componentes de una arquitectura basada en eventos son obje-tos o procesos cuyas interfaces proporcionan tanto una colección de procedi-mientos, como un conjunto de eventos. Los procedimientos se pueden invo-car a la manera usual en modelos orientados a objeto o mediante el sistema de suscripción que se ha descrito.
Los ejemplos de sistemas que utilizan esta arquitectura son numerosos. El es-tilo se utiliza en ambientes de integración de herramientas, en sistemas de gestión de bases de datos para asegurar las restricciones de consistencia ba-jo la forma de disparadores (triggers), en interfaces de usuario para separar la presentación de los datos de los procedimientos que los gestionan y en edi-tores sintácticamente orientados para proporcionar verificación semántica in-cremental, etc.
Entre las ventajas del modelo podemos destacar:
• Las características del estilo lo hacen muy apropiado para la implementa-ción de sistemas reactivos, y especialmente cuando existe una gran inter-acción con el usuario.
• El alto grado de desacoplamiento entre los componentes del sistema, que no se conocen entre sí ni hacen referencia unos a otros, optimiza el man-tenimiento del sistema.
• El modelo fomenta el desarrollo en paralelo, lo que puede resultar en me-joras de rendimiento.
• Las arquitecturas basadas en eventos presentan una alta versatilidad, re-utilización, reemplazabilidad y fácil evolución, lo que permite el registro, la baja o el reemplazamiento dinámico de componentes y eventos. • Es aplicable tanto si las implementaciones corren sincrónica como
• Permiten evitar la degradación de las prestaciones del sistema que sucede-ría si, en vez de esperar a que los avisen de que ha sucedido el evento que esperan, los objetos oyentes hubieran de preguntar repetidamente por su ocurrencia (haciendo lo que se conoce como polling, un mecanismo harto ineficiente por la sobrecarga de mensajes que genera en el sistema). Entre las desventajas de este estilo arquitectónico citaremos las siguientes: • Cuando un componente anuncia un evento, no sabe qué otros
compo-nentes están interesados en él, ni el orden en el que serán invocados, ni el momento en el que finalizan lo que deben hacer. Este desconocimiento puede derivar en problemas de rendimiento, de manejo de recursos cuan-do se comparte un repositorio común o de coordinación.
• Un componente no sabe cómo influyen en el resto del sistema los eventos que emite, de manera que, cuando los emite no puede asumir que otros componentes respondan a ellos. Aun cuando supiese que hay otros com-ponentes suscritos a un evento, tampoco puede asumir que estos compo-nentes se invoquen en un determinado orden.
• Por último, es difícil razonar sobre la corrección o el comportamiento del sistema, pues la reacción a un evento depende del contexto en el que se realice.
Como siempre, las ventajas o desventajas son muy relativas, pues dependen mucho del dominio de aplicación y del sistema concreto que pretendemos implementar. Lo que en algunos casos es ventaja se convierte en desventaja en otros casos.
1.8.7. Arquitecturas orientadas a servicios
Recientemente, las arquitecturas orientadas a servicios (service oriented
arquitectures,SOA) están cobrando mucho interés para el desarrollo de
aplica-ciones en Internet y están recibiendo un tratamiento especial en el análisis de los diferentes estilos arquitectónicos. Más que un subestilo de las arquitecturas basadas en componentes independientes, recientemente se las ha empezado a considerar un estilo propio.
La arquitectura�SOA está caracterizada por las siguientes propiedades: • Una vista�lógica: los servicios son una abstracción (vista lógica) de los
programas, bases de datos, procesos de negocio, etc., que intervienen en la aplicación y vienen definidos en términos de lo que hacen. De esta ma-nera, los componentes básicos de este estilo son los servicios que imple-mentan la lógica del negocio o la funcionalidad básica del sistema.
• Orientación�a�mensajes: como parte de la descripción de los servicios se
definen los mensajes intercambiados entre proveedores y solicitantes. La estructura interna del servicio (lenguaje de programación, procesos inter-nos, etc.) quedan ocultos a este nivel de abstracción.
• Orientación�a�la�descripción: un servicio se describe con metadatos
pro-cesables. La descripción da soporte a la naturaleza pública de SOA: sólo se incluyen en la descripción aquellos detalles que se exponen públicamen-te y son importanpúblicamen-tes para el uso del servicio. Así, un servicio web simple queda caracterizado por cuatro estándares: XML, SOAP, UDDI y WSDL, los cuales trabajan según el modelo básico de "solicitud/respuesta".
• Granularidad: los servicios tienden a usar un pequeño número de
opera-ciones con mensajes relativamente complejos.
• Orientación�a�la�red: los servicios tienden a usarse a través de la red,
aun-que éste no es un requisito indispensable.
• Independiente�de�la�plataforma: los mensajes se envían en un formato
estándar y neutral a la plataforma (normalmente XML).
Ahora bien, aunque SOA es general y (al menos en teoría) se basa en la idea de servicios en general comunicados mediante cualquier tipo de mensajes, lo normal es que siempre se utilice en entornos web y que se apoye en estánda-res web como HTTP, XML, SOAP, WSDL o UDDI. Por tanto, en SOA es muy importante el concepto de servicio web.
Un servicio�web es un sistema software identificado por una URI, cu-yos interfaces públicos y enlaces se definen y describen usando XML. Su definición puede ser descubierta por otros sistemas software. Estos sistemas pueden interactuar con el servicio web de la forma prescrita por su definición, usando mensajes basados en XML a través de proto-colos estándares de Internet.
URI
URI es la sigla de uniform resource identifier, una cadena de caracteres que sirve para iden-tificar de manera unívoca cualquier recurso de Internet (como un ordenador, una página web o un servicio). Ejemplos de esto son http://www.lcc.uma.es/ o ftp://www.uoc.edu. Observad que también indica el protocolo para acceder a ellos (http, https, ftp, mailto, etc.).
En definitiva, un servicio web expone su funcionalidad a posibles consumi-dores en una URI y proporciona mecanismos para invocar sus operaciones de manera remota (a través de Internet). El servicio web puede implementarse en cualquier lenguaje y en cualquier plataforma, actuando como una caja negra.
Figura 14. Esquema de funcionamiento de los servicios web
El esquema de funcionamiento de los servicios web requiere tres elementos fundamentales, y que constituyen también el esquema normal de SOA (véase la figura 14):
1)�Un�proveedor�del�servicio�web, que es quien lo diseña, desarrolla e
im-plementa y lo hace disponible para su uso, ya sea dentro de la misma organi-zación o al público en general. Las operaciones de publicación involucran el anuncio del servicio como tal, lo cual corresponde a la ubicación del servicio en un servidor específico y el uso de un servicio de descripción (para que los clientes puedan saber qué funciones tiene disponibles el servicio web y qué información debe pasarse a esas funciones para utilizarlas).
2)�Un�consumidor�del�servicio, que es quien accede al servicio web para
uti-lizar los servicios que éste presta. Cuando un consumidor desea acceder a un servicio web, éste debe contar con un servidor de descubrimiento que permita conocer la ubicación exacta del servicio, es decir, se debe contar con un direc-torio donde se tengan listas las referencias a los servicios disponibles. Esto se logra gracias a directorios UDDI.
3) Un agente�de�servicio, que sirve como enlace entre proveedor y
consumi-dor para efectos de publicación, busca y localización del servicio. En general, SOA y los servicios web son apropiados para aplicaciones: • que deben operar a través de Internet,
• donde no existe la posibilidad de gestionar la instalación de modo que todos los clientes y proveedores se actualicen a la vez,
• donde los componentes de un sistema distribuido se ejecuten en distintas plataformas y distintos productos.
1.9. Criterios para la selección de un estilo arquitectónico
A la hora de diseñar la arquitectura de una aplicación, no deberíamos partir desde cero, sino que deberíamos reutilizar aquellas soluciones que han de-mostrado en el pasado que eran buenas. Por lo tanto, es muy importante iden-tificar cuáles son los patrones�arquitectónicos más convenientes para nuestra
aplicación concreta. Una vez identificados dichos patrones, deberíamos deci-dir bajo qué condiciones y en qué casos pueden aplicarse cada uno de ellos, cómo deben ser las interfaces de los componentes con los cuales se instancie un determinado patrón, etc.
La elección correcta de un estilo arquitectónico es importante porque éste guiará todo el proceso posterior de desarrollo. En este sentido, los diseñadores deben encontrar el estilo más apropiado de acuerdo con la especificación de los requisitos concretos del sistema, incluyendo los funcionales, de escalabili-dad, disponibiliescalabili-dad, seguriescalabili-dad, mantenimiento y evolución.
Para un proyecto software dado, puede haber varias arquitecturas apropiadas. Decidir cuál es la mejor opción va a depender de una serie de criterios de cali-dad, muchos de los cuales suelen ser contradictorios entre sí (como ocurre, por ejemplo, con la modularidad frente a la eficiencia). Por tanto, no sólo habre-mos de identificar cuáles son los aspectos de calidad que se deben considerar, sino también priorizarlos.
• La extensibilidad facilita la adición de nuevas características, aunque ello puede hacer más complejo el diseño. En general, los sistemas fácilmen-te exfácilmen-tensibles presentarán mayor grado de abstracción. Generalizar (por ejemplo, decidir qué tipo de extensiones pueden surgir, los puntos de va-riabilidad, etc.) requiere invertir bastante tiempo en el diseño. La distin-ción entre los requisitos opcionales y los deseables puede ser también muy importante, ya que señala hacia dónde apuntará el desarrollo del sistema. • La modificabilidad tiene como objetivo primordial facilitar el cambio de requisitos. Observad que ésta es distinta de la propiedad anterior, aunque requiera técnicas similares.
• La simplicidad trata de hacer fácil de entender y de implementar el esti-lo. En contrapartida, esta propiedad es difícil de compaginar con las dos anteriores.
• Finalmente, la eficiencia derivará en aplicaciones de pequeño tamaño o alta velocidad. Muchas veces la eficiencia va en contra de las propiedades anteriores, ya que para aumentar la eficiencia nos podemos ver obligados a saltarnos algunas de las normas de la arquitectura (como por ejemplo, acceder a capas inferiores en una arquitectura en capas).
2. Representación de la arquitectura software
El diseño arquitectónico se centra en el modelado de la aplicación sin abordar su distribución física, es decir, no nos preocupamos de momento sobre dónde estarán ubicados físicamente los componentes que forman parte de esa arqui-tectura. Para ello, las características del sistema deben ser expresadas mediante algún lenguaje�de�descripción�de�arquitecturas software que permita descri-bir el sistema en términos de componentes y conectores.
Como lenguaje de descripción de arquitectura utilizaremos UML 2.0, que in-corpora los mecanismos adecuados para tal fin, como veremos en el apartado siguiente. A modo de ejemplo, nos centraremos en el estilo arquitectónico en tres capas, que es el utilizado habitualmente para aplicaciones web. En cual-quier caso, estas guías son genéricas y pueden ser adaptadas a cualcual-quiera de los estilos arquitectónicos descritos en el apartado anterior.
2.1. UML 2.0 como lenguaje de descripción de arquitecturas
El lenguaje de modelado unificado (unified modeling language, UML) es un len-guaje estándar, extensamente conocido en la industria del software que permi-te especificar, visualizar, construir y documentar los distintos elementos que conciernen a los sistemas software, además de realizar modelos de negocio u otros de sistemas no software.
La versión 1 de UML no disponía de los conceptos adecuados para representar la arquitectura software de un sistema. Esto ha sido subsanado ya en la versión 2.0, con la redefinición del concepto de componente para que ya no sólo sea físico, y la inclusión de los conceptos de puertos y conectores. Además, los mecanismos de extensión disponibles en UML (los perfiles) pueden utilizarse para definir otros conceptos no contemplados o para establecer restricciones que definan de manera más precisa la semántica de estos conceptos.
En concreto, las principales�mejoras que aporta UML 2.0 para la descripción arquitectónica de los sistemas software son:
• Nuevos conceptos para describir la estructura arquitectónica interna de las clases, componentes y colaboraciones a partir de la definición de partes (parts), conectores (connectors) y puertos (ports).
• Introducción de la herencia de comportamiento en máquinas de estado y encapsulación de submáquinas mediante el uso de puntos de entrada y salida.
Ved también
El lenguaje UML se ha visto en la asignatura Ingeniería del
• Mejora de la encapsulación de componentes mediante puertos complejos con máquinas de estado de protocolo, que controlan la interacción del componente con su entorno.
• Mejora de aspectos de especificación, realización y conexión en los com-ponentes.
• Mejora de los diagramas de interacción con conceptos de control más ade-cuados, tales como la composición, las referencias, las excepciones, los bu-cles, las alternativas, etc. Además, se añade un nuevo diagrama, basado en el de actividades, que permite obtener una perspectiva más amplia del conjunto de interacciones.
En la figura 15 se muestra la taxonomía de diagramas estructurales y de com-portamiento de UML 2.0.
Figura 15. Taxonomía de diagramas de UML 2.0
Para llevar a cabo el modelado y la documentación de una arquitectura softwa-re, haremos uso tanto de diagramas�estructurales (diagramas que muestran la estructura estática de los objetos del sistema sin entrar en aspectos dinámicos), como de diagramas�de�comportamiento (los cuales permiten describir los cambios que se producen en el sistema con el paso del tiempo). Ilustraremos cómo hacerlo en el caso concreto de una arquitectura de tres capas.
