software Arquitectura deluoc.gitlab.io/2014/Ing.Componentes/2.pdf · a aquellos estilos más...

Arquitectura delsoftware Nathalie Moreno VergaraAntonio Vallecillo MorenoJosé Raúl Romero SalgueroFrancisco Javier Durán Muñoz PID_00201504

CC-BY-SA • PID_00201504 Arquitectura del software

Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia deReconocimiento-Compartir igual (BY-SA) v.3.0 España de Creative Commons. Se puede modificar la obra, reproducirla, distribuirlao comunicarla públicamente siempre que se cite el autor y la fuente (FUOC. Fundació per a la Universitat Oberta de Catalunya), ysiempre 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

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

Resumen....................................................................................................... 50


Actividades.................................................................................................. 51

Ejercicios de autoevaluación.................................................................. 51

Solucionario................................................................................................ 52

Glosario........................................................................................................ 53

Bibliografía................................................................................................. 54

CC-BY-SA • PID_00201504 5 Arquitectura del software

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

software.


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 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 comunes 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 UniversidadCarnegie Mellon ofrece unarecopliación muy completae interesante de definicionesde arquitectura software enhttp://www.sei.cmu.edu/archi-tecture/definitions.html.

http://www.sei.cmu.edu/architecture/definitions.html

http://www.sei.cmu.edu/architecture/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 modelarse como una composición de elementos y las relaciones entre

ellos.

En el caso trivial, el sistema constará de un único elemento, lo que dará como resultadouna arquitectura poco interesante y probablemente poco útil, pero una arquitectura alfin. Por otro lado, que todo sistema tenga una arquitectura no implica necesariamenteque é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 ningunode los "componentes softwa-re" que definen los modelos decomponentes como CORBAComponent 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 funcionalidad, 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 losmodelos arquitectónicos en elapartado "Representación de laarquitectura software" de estemódulo.

Ejemplos de componentes

• clientes,• servidores,• filtros,• capas,• bases de datos, etc.


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 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 conectoressimples

• 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 delos 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 alo 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 estilocaracteriza 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 estiloarquitectónico son la bóveda de crucería y el arco ojival; la primera afecta a la estructuray el otro, más particularmente, a las formas exteriores. Además, la planta de las catedralesgóticas es en forma de cruz, de tres o cinco naves, con crucero más corto que el de laarquitectura románica, con la girola o deambulatorio en la cabecera y en la que se abrenlas capillas poligonales, todas encerradas en un gran medio círculo. También destacanaltas naves laterales en las que se abren amplios ventanales y recios contrafuertes querodean el perímetro de la catedral, rematados por pináculos. Todas estas característicasson las que constituyen los invariantes�del�estilo y que permiten distinguir claramenteuna 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 estilosarquitectónicos

El proyecto ABLE de la Carne-gie Mellor University (CMU)cuenta con trabajos y ejem-plos muy útiles sobre estilosarquitectónicos de software.Se puede consultar en http://www.cs.cmu.edu/~able.

http://www.cs.cmu.edu/~able

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 delestilo gótico en todos y cada uno de sus elementos arquitectónicos, desde su estructuraglobal 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 quevan a regir dichas combinaciones. Un ejemplo muy claro ocurre con los sistemas web,diseñados usando un estilo cliente-servidor entre componentes independientes, pero queademás se organizan en tres capas o niveles. Ahora bien, la asignación de componentesa capas (que constituiría esa "mezcla" de estilos) no se realiza de manera caprichosa, sinoque 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 losexpertos

"Conceptual integrity is themost important considerationin system design" (Brooks, TheMythical Man Month, 1975)"The same set of laws de-termines the structure of acity; a building; or a singleroom" (Alexander, A PatternLanguage, 1977)


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 PublishingCompany. 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 lossistemas Unix son quizá los sistemas más representativos del estilo arquitectónico basadoen filtros y tuberías. Estas aplicaciones se construyen a partir de programas que actúancomo filtros (cada uno recibe unos datos de entrada, los transforma y los envía por sucanal de salida), que se conectan entre sí por tuberías (pipes). Este estilo arquitectónicose 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 componentes) 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 sonlos estilos basados en capas,cliente-servidor, objetos, even-tos o servicios. Estos subestilosserá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 transformaciones

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 emiteun recibo. Para las facturas que no se pagan dentro del tiempo permitido, se emite unrecordatorio. El siguiente es el modelo de una parte del sistema de procesamiento defacturas.

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 sistemas 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 com-

plejas, pero puede complicar las simples.


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ónespecial.

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

objeto se comporta a la vez como cliente y servidor.


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 servidores) 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 hablade clientes y servidores nos re-ferimos a procesos lógicos másque a ordenadores físicos so-bre los cuales se ejecutan estosprocesos. Los clientes y servi-dores son procesos diferentes ypueden o no estar alojados enel 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 elloutiliza algún algoritmo divide-y-vencerás o de ramificación y poda que descompone elproblema en numerosos subproblemas de menor tamaño. El maestro va a encargar a losesclavos la solución de cada uno de esos subproblemas para, posteriormente, combinarlas soluciones parciales y construir la solución final. En el caso particular en el que todoslos subproblemas sean iguales y, por tanto, los esclavos sean del mismo tipo, estaríamoshablando de granjas�de�procesos.

Este tipo de sistemas se ha comenzado a utilizar con mucho éxito con fines científicosen proyectos que aprovechan los tiempos de inactividad de los ordenadores personalesconectados a Internet, que voluntariamente ceden sus CPU para realizar cálculos. Estosordenadores personales actúan por tanto como esclavos para un proceso maestro quetrata 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 (proyectoSETI@home) o procesos bioquímicos como el autoensamblado de proteínas (proyectofolding@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 (thinclient)

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.

Figura 7. Modelo de cliente fino


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�capas (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 (denominadaproxy 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 conlos 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 modelocliente-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 transmitir rápida-mente y de manera sincronizada, pero a una resolución relativamente baja. Pueden estarcomprimidas 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 yproveer a los sistemas de información de hipertexto. El programa cliente es simplementeuna 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ándole 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 llamencuando suceda el evento (de ahí el término call-back). Se dice que este mecanismo sigueel 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 porejemplo "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 asin-

crónicamente porque no se espera una respuesta.


• 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 importantes 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áginaweb 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, disponibilidad, seguridad, 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 extensibles 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 cualquiera 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 enla asignatura Ingeniería del soft-ware.


• 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.


2.2. Diseño de la arquitectura de tres capas

La arquitectura en capas describe la organización conceptual de los elemen-

tos del diseño en grupos independientemente de su empaquetamiento o des-

pliegue físico. Cada capa representa un elemento de gran tamaño, a menudo

compuesto de varios paquetes o subsistemas.

Habitualmente, y en particular en el caso de las aplicaciones web, encontrare-

mos una división en tres niveles atendiendo a esta organización:

1)�Nivel�de�presentación

Éste es el nivel encargado de generar la interfaz de usuario en función de las

acciones llevadas a cabo por el mismo. La capa de presentación contiene los

componentes necesarios para habilitar la interacción del usuario con la aplica-

ción. Los componentes de la interfaz de usuario deben mostrar datos al usua-

rio, obtener y validar los datos procedentes del mismo e interpretar las accio-

nes de éste que indican que desea realizar una operación con los datos. Asi-

mismo, la interfaz debe filtrar las acciones disponibles con el fin de permitir

al usuario realizar sólo aquellas operaciones que le sean permitidas en un mo-

mento determinado.

2)�Nivel�de�negocio

Contiene la lógica que modela los procesos de negocio y es donde se realiza

todo el procesamiento necesario para atender las peticiones del usuario.

3)�Nivel�de�administración�de�datos

Es el encargado de hacer persistente toda la información, así como de suminis-

trar y almacenar la información para el nivel de negocio. Casi todas las apli-

caciones y servicios necesitan almacenar y obtener acceso a un determinado

tipo de datos. La aplicación puede disponer de uno o varios orígenes de datos,

los cuales pueden ser de tipos diferentes. La lógica utilizada para obtener ac-

ceso a los datos de un origen de datos se encapsulará en componentes lógicos

de acceso a datos que proporcionen los métodos necesarios para la consulta

y actualización.

Para representar la arquitectura de un sistema software utilizaremos una colec-

ción de diagramas UML: casos de uso, componentes, clases, estado, actividad,

secuencia y colaboraciones. Cada uno de ellos ilustrará un aspecto concreto.

Ved también

Los diagramas de clases, acti-vidad, estado y secuencia hansido presentados con detalleen la asignatura Ingeniería delsoftware, por lo que no insisti-remos aquí en ellos.


2.2.1. Diagramas de casos de uso

Abordar directamente el diseño lógico puede ser una tarea compleja para un

diseñador poco experimentado. Los casos de uso facilitan esta labor identifi-

cando las entidades o los actores que interaccionan con el sistema, así como

la funcionalidad básica que se desea implementar.

Establecidos los escenarios principales, puede resultarnos de especial utilidad

su agrupación en paquetes.

UML define los paquetes como un mecanismo de agrupación cuyo ob-

jetivo es el de organizar los elementos de modelado. Esta práctica básica

de aplicar la modularidad da soporte a la separación de aspectos que

apuntábamos en el módulo 1.

Partiendo de esta representación inicial, conviene refinar el diagrama de casos

de uso a fin de evitar el acoplamiento entre paquetes, así como las posibles

redundancias. Si un caso de uso figura en más de un paquete, deberemos elegir

el contexto en el que dicho caso de uso tiene mayor peso y establecer relaciones

de dependencia con otros contextos o paquetes de los cuales se haya eliminado

el citado caso de uso. Las dependencias entre paquetes se traducirán en el

futuro en ineficiencia si un cambio en la funcionalidad que implementa un

caso de uso afecta a todos los paquetes que dependen de él.

El ejemplo del banco nos servirá como guía para ilustrar el proceso de diseño

lógico y físico de la arquitectura, como ya ocurrió en el módulo anterior.

La figura 16 ilustra un extracto del diagrama de casos de uso para el ejemplo

del banco. Como puede observarse, los casos de uso han sido agrupados en tres

paquetes a partir de la funcionalidad del sistema que describen. Cada paquete

documenta parte de la funcionalidad del sistema que puede requerir uno o

más componentes software para su implementación. Los diagramas de com-

ponentes pueden ayudarnos a documentar esta relación.

Nota

Los paquetes no son instancia-bles, es decir, no se pueden te-ner instancias de paquetes, porlo que resultan invisibles parael sistema en ejecución.


Figura 16. Extracto del diagrama de casos de uso para el ejemplo del banco

2.2.2. Diagrama de componentes

Los diagramas de componentes se utilizarán para ilustrar la descomposición

de un sistema en componentes arquitectónicos de grano grueso y sus interre-

laciones a través de sus respectivas interfaces.

En versiones anteriores de UML, los componentes se consideraban como una

representación de estructuras físicas, tales como archivos, DLL, etc. En UML

2.0, los componentes pasan a constituir un potente mecanismo de especifica-

ción a nivel lógico, ya que sólo se utilizan para representar y especificar los

requisitos para cada elemento software.

En UML 2.0, un componente es una unidad modular del sistema que

encapsula una cierta funcionalidad, que posee interfaces bien definidas

y que es reemplazable dentro de su entorno.


Los componentes se conectan a través de interfaces implementadas (o propor-

cionadas) e interfaces requeridas. Por ejemplo, en la figura 17, el componente

"Gestor transacciones" implementa una interfaz que requiere el componente

"Sistema cuentas".

Figura 17. Ejemplo de componentes UML 2.0

Los componentes pueden definir comportamientos; será el diseño interno del

componente el que defina la implementación de estos comportamientos. Por

tanto, el componente debe aportar los medios para que otros componentes

puedan requerir los servicios que ofrece.

Una interfaz�implementada (o proporcionada) define cómo se debe

acceder a los servicios que ofrece un componente.

Por otra parte, puede darse el caso de que un componente necesite soporte

de otros componentes. Éste deberá, por tanto, definir de manera análoga qué

necesita exactamente de los demás.

Una interfaz�requerida define el tipo de servicios que un componente

requerirá de otros.

Además de las interfaces, UML 2.0 permite que los componentes incluyan in-

formación acerca de sus realizaciones1 y artefactos, y sobre sus propiedades

internas. UML 2.0 lo permite para poder "refinar" estos componentes arqui-

tectónicos en las siguientes fases del desarrollo, incluyendo los detalles tecno-

lógicos sobre cómo están realizados internamente. Desde el punto de vista

arquitectónico, sólo es relevante la información sobre sus interfaces e interac-

ciones con otros componentes. Sin embargo, a la hora de desarrollar el sistema

es necesario decidir cómo se implementarán internamente estos componen-

tes. Este proceso será tratado con detalle en el módulo 3.

Otro aspecto que se debe considerar es el caso en el que un componente ofrezca

diferentes tipos de servicios a sus congéneres. Por lo general, es posible imple-

mentar múltiples interfaces para expresar estas diferencias. Sin embargo, sería

preferible establecer algún criterio de agrupación, de modo que se permita es-

clarecer qué tipo de servicio da una determinada interfaz. Para ello, UML 2.0

(1)Una realización se refiere a la im-plementación de un requisito.


hace uso de los puertos, en los que se agrupan conjuntos de interfaces (tanto

requeridas como implementadas), según criterios de diseño y de los servicios

que requieran o proporcionen.

Un puerto puede tener dos tipos de interfaz

Con las interfaces�proporcionadas, el puerto exhibe un conjunto de operaciones almundo exterior.

Con las interfaces�requeridas, el puerto establece qué conjunto de operaciones utilizarádel mundo exterior.

Un puerto es una característica del componente que especifica un pun-

to de interacción diferenciado entre el componente y su entorno, o en-

tre el comportamiento del componente y sus partes internas.

Con ello, UML 2.0 permite especificar puntos de interacción, que expondrá a

su entorno el componente, y aportar explícitamente la correspondencia entre

las interfaces publicadas y los mecanismos de implementación internos.

• Hacia�el�exterior, los puertos se conectan con otros puertos mediante co-

nectores, a través de los cuales se realizan las peticiones al componente

para invocar un determinado comportamiento.

• Hacia�el�interior, un puerto conecta los mecanismos internos de imple-

mentación del componente (las clases, asociaciones u otros componentes

que lo componen) con su entorno. Esto implica que el puerto sirve al com-

ponente como apertura al exterior.

Los puertos son una importante aportación de UML 2.0, ya que permiten en-

capsular la entrada o salida de las interacciones hacia el componente. Este fac-

tor es crucial a la hora de la reusabilidad, puesto que, manteniendo el puerto,

es posible modificar la parte interna del componente sin que afecte al modo

como éste se muestra ante su entorno.

En un nivel de abstracción superior, el concepto de puerto se corres-

ponde con el de servicio. De este modo, definiremos un puerto por ca-

da uno de los servicios que implementa o requiere un componente, y

que definen su funcionalidad. Las interfaces UML asociadas al puerto

definen la signatura de las operaciones que definen el servicio.

Utilizando todos estos elementos estructurales describiremos la arquitectura

software de un sistema centrando la atención en la estructura global del mis-

mo, y destacando su descomposición en paquetes, componentes e interfaces

y relaciones de dependencia entre ellos.

Uso de paquetes pararepresentar capas

Cada capa a nivel lógico se re-presenta en UML mediante unpaquete.


Figura 18. Ejemplo de representación de la arquitectura de tres capas para el ejemplo de la banca electrónica

Basándonos en el modelo de casos de uso refinado, organizaremos los paquetes

en niveles o capas conceptuales independientes para el caso concreto que nos

ocupa: las arquitecturas de tres capas. El diseño de cada capa comprenderá dos

tareas claramente diferenciadas:

• El diseño�interno tiene como finalidad el modelado de los elementos per-

tenecientes a ese nivel.

• El diseño�externo define la interacción entre esa capa y las demás.

Para el diseño interno nos ayudaremos de cuantos diagramas de componen-

tes sean necesarios: cada uno de ellos proporcionando un mayor nivel de de-

talle o descomposición de los paquetes y componentes si es preciso. A modo

de ejemplo, la figura 18 ilustra un diagrama de componentes correspondien-

te a una distribución o arquitectura en tres capas para el ejemplo del banco

en línea. Como vemos, cada capa es modelada como un paquete UML, pro-

porcionando un límite bien definido alrededor de un conjunto de elementos


relacionados. A su vez, cada capa exporta sólo aquellos elementos que otros

paquetes precisan ver realmente e importa sólo aquellos elementos requeridos

para que los elementos del paquete puedan llevar a cabo su tarea.

Observad cómo en la figura 18 sólo han sido presentados los elementos más

significativos. Cuando se revela el contenido de un paquete, deben mostrarse

sólo los elementos necesarios para transmitir de manera concisa su finalidad.

Sin embargo, podríamos refinar el diagrama anterior con una descripción más

detallada de los componentes y elementos que figuran en cada nivel, como

veremos en el módulo 3. Cuanto más detallado es el diseño, más cercano re-

sultará el modelo a la implementación.

2.2.3. Diagramas de interacción

Si bien los diagramas de componentes sólo muestran información estática,

los diagramas de interacción se utilizan para documentar y proporcionar in-

formación sobre la dinámica y el modo como se conectan y comunican los

objetos dentro de una capa y entre capas.

Figura 19. Diagrama de interacción

En el diseño lógico de la arquitectura, los diagramas�de�interacción se

centran en las colaboraciones que cruzan los límites de las capas y los

paquetes.

En general, resultará conveniente contar con un conjunto de diagramas de

interacción que ilustren los escenarios más significativos desde el punto de

vista de la arquitectura.


2.2.4. Colaboraciones

Finalmente, completaremos el diseño de la arquitectura software con el mo-

delado de las colaboraciones. En el contexto de la arquitectura de un sistema,

una colaboración permite nombrar un bloque conceptual que incluye tanto

aspectos estáticos como dinámicos.

Una colaboración denota una sociedad de clases, interfaces y otros

elementos que colaboran para proporcionar algún comportamiento

cooperativo mayor que la suma de los comportamientos de sus elemen-

tos.

Las colaboraciones incluyen tanto elementos estructurales como de compor-

tamiento:

• La parte estructural engloba cualquier combinación de clases, interfaces,

componentes y nodos que previamente fueron declarados en los diagra-

mas estáticos. Una colaboración es no instanciable y describe sólo los as-

pectos relevantes de la cooperación de un conjunto de instancias identifi-

cadas por los roles específicos que juegan dichas instancias. Por eso, una

colaboración da nombre a un bloque conceptual de la arquitectura, no a

un bloque físico.

• Los diagramas de comportamiento, como por ejemplo los diagramas de

interacción, pueden añadirse a una colaboración para mostrar más clara-

mente cómo los roles se relacionan unos con otros en varios escenarios.

Figura 20. Diagrama de colaboración


2.3. Modelado de las dependencias entre capas

En UML, si modelamos cada capa con un paquete, usaremos relaciones

de dependencia entre los paquetes para mostrar las dependencias entre

las distintas capas. Una relación de dependencia entre dos paquetes in-

dica que alguno de los elementos del paquete "cliente" invoca o requiere

los servicios de uno o más elementos del paquete "servidor", pero sin

especificar dichos elementos concretos.

Sin embargo, en muchas arquitecturas en capas existe un fuerte acoplamiento

entre los elementos de las distintas capas, lo que se conoce como arquitectura

de "capas transparentes". En este modelo, los elementos de una capa colabo-

ran o se comunican con varios elementos de otras capas, por lo que de alguna

manera han de ser conscientes de la estructura interna de las capas que utili-

zan (véase el diagrama a la izquierda de la figura 21). En estos casos, lo que

suele hacerse es detallar las relaciones de dependencia entre los paquetes UML,

representando las relaciones de dependencia entre los elementos internos de

los paquetes implicados en dichas interacciones individuales.

Además de las relaciones de dependencia, otra vía de canalizar y modelar las

dependencias entre capas viene dada de la mano de los patrones de diseño.

Cómo usarlos en una arquitectura para conectar capas es alguna de las cues-

tiones que trataremos en el siguiente apartado.

2.4. Uso de patrones en el diseño arquitectónico

Nota

El acoplamiento y las depen-dencias entre capas se docu-mentan en UML mediante re-laciones de dependencia.

Mientras la arquitectura en capas guía la definición de las partes importantes

del sistema, los patrones de diseño pueden ser utilizados para el diseño de las

conexiones entre capas y paquetes UML.

Los patrones permiten identificar y completar los casos de uso básicos

expuestos por el cliente, comprender la arquitectura del sistema que se

va a construir y su problemática, así como buscar componentes ya desa-

rrollados que cumplan con los requisitos del tipo de sistema que se va a

construir. Es decir, nos permiten obtener de una manera sencilla la ar-

quitectura base que buscamos durante la fase de diseño arquitectónico.

Ved también

Los patrones de diseño han si-do presentados con detalle enla asignatura Ingeniería del soft-ware orientado a objetos. En es-te apartado repasaremos bre-vemente algunos conceptosasociados a este término de-tallando su utilidad desde elpunto de vista de la arquitec-tura software.


Figura 21. Organización de una capa sin aplicar el patrón fachada (izq.) y aplicándolo (der.)

El patrón fachada

Por ejemplo, para el caso concreto de una arquitectura en tres capas será de gran ayudadotar de una fachada a cada nivel de subsistemas y utilizarla como punto de acceso almismo. El patrón fachada ayuda a controlar o eliminar las dependencias complejas ocirculares entre objetos y permite hacer cambios en los componentes de un subsistemasin afectar a los clientes. De este modo se simplificará al máximo el mantenimiento delas dependencias entre niveles.

El uso de patrones se documenta en UML mediante diagramas de colabora-

ción. Una colaboración describe tanto un contexto, como una interacción. El

contexto referencia a los objetos/roles involucrados en la colaboración, mien-

tras que la interacción documenta la colaboración que los objetos/roles llevan

a cabo, bien sea a través de paso de mensajes, invocación directa, etc.

Figura 22. Ejemplo de modelado del patrón fachada en un diagrama UML

En realidad, la estructura de un patrón se describe por medio de una colabora-

ción�parametrizada. Se sabe que en cada diseño en el que se utiliza el patrón

fachada existe una clase que actúa como tal, pero, por supuesto, esa clase varía

de un sistema a otro. La colaboración parametrizada que representa la estruc-


tura de un patrón puede aparecer en un diagrama de clases como un óvalo

discontinuo, con líneas discontinuas uniéndolo a los rectángulos de clase que

representan las clases que son los parámetros.

Además del patrón fachada, hay otros muchos que son de interés para el dise-

ño arquitectónico de los sistemas distribuidos. En particular, nos referimos a

los patrones adaptador y observador, que se describen a continuación.

2.4.1. El patrón adaptador

En primer lugar, el patrón adaptador (adapter) es un patrón estructural

que se utiliza para convertir la interfaz de una clase en otra, que es la

esperada por los clientes. Permite resolver las diferencias e incompatibi-

lidades entre la interfaz que requiere un componente y la que propor-

ciona un servidor. La adaptación puede variar desde un mero cambio

de nombres en las operaciones hasta haber de implementar un conjun-

to totalmente nuevo de operaciones, dependiendo de lo parecidas que

sean la clase que hay que adaptar y la clase objetivo.

Figura 23. Estructura del patrón adaptador

Asociados al patrón adaptador encontramos algunos patrones, como por ejem-

plo:

• Puente�(bridge)

Tiene una estructura similar, pero distinto propósito: está pensado para sepa-

rar una interfaz de su implementación, de modo que ambas puedan variar in-

dependientemente. El patrón adaptador, por el contrario, está pensado para

cambiar la interfaz de un objeto existente.

• Decorador�(wrapper)

Este patrón se utiliza para añadir nuevas funcionalidades a un objeto concreto

sin cambiar su interfaz, esto es, no se trata de añadir la funcionalidad a la

clase completa de objetos mediante el mecanismo de herencia, sino de añadir

dicha funcionalidad a un objeto concreto, y de manera dinámica en tiempo


de ejecución (a través de un objeto wrapper) y dejar el resto inalterado. De este

modo, el decorador aporta flexibilidad al diseño, frente al determinismo y el

aspecto estático de otras alternativas.

• Apoderado�(proxy)

De manera general, un apoderado es un objeto que funciona como represen-

tante de otro, cuya interfaz permanece invariable, al contrario que ocurriera

con el patrón adaptador. El objetivo del apoderado de un objeto es represen-

tarlo en otros sistemas o entornos, de manera que los clientes piensen que

están dialogando con el objeto original como si éste estuviera en su propio

sistema (ocultando, por tanto, los aspectos relativos a su posible localización o

reubicación). El apoderado sencillamente conoce dónde está en todo momen-

to el objeto original, y le delega las peticiones de los clientes.

2.4.2. El patrón observador

Por otro lado, el patrón observador (observer) es un patrón de compor-

tamiento que define una dependencia uno-a-muchos entre objetos, de

modo que cuando un objeto cambia su estado, todos los demás objetos

dependientes se modifican y actualizan automáticamente. Este patrón

es el que normalmente se utiliza en las arquitecturas orientadas a even-

tos, pues es el que se encarga de implementar los mecanismos de publi-

car y suscribir (publish and subscribe).

Aplicaremos el patrón observador cuando un cambio en un objeto requiera

que cambien otros y se desconoce a priori cuáles y cuántos son, e incluso pue-

den variar dinámicamente. El objeto observado notificará a sus observadores ca-

da vez que ocurre un cambio a fin de que el estado de ambos permanezca

consistente. Después de ser informado de un cambio en el objeto observado,

cada observador concreto puede pedirle la información que necesita para re-

conciliar su estado con el de aquél.


Figura 24. Estructura del patrón observador

Como se observa en el diagrama UML de la figura 24, participan en este patrón

los siguientes roles:

1)�Observable (Observable): la interfaz en la que se define cómo pueden

interactuar los observadores/clientes con un Observable. Estos métodos in-

cluye la introducción y eliminación de observadores, y uno o más métodos de

notificación para enviar información a través de Observable a su cliente.

2)�Observable�concreto (ConcreteObservable): la clase que proporciona

implementaciones para todos los métodos de la interfaz Observable. Nece-

sita mantener una colección de Observer.

3) Los métodos de notificación copian la lista de objetos Observer, iteran

sobre la lista y llaman a los métodos oyentes específicos de cada Observer.

4)�Observador (Observer): la interfaz utilizada por los observadores para co-

municarse con los clientes.

5)�Observador�concreto (ConcreteObserver): implementa la interfaz Ob-

servable y determina en todos los métodos implementados cómo responder

a los mensajes recibidos de Observable.

Por tanto, el patrón permite variar objetos observados y observadores

independientemente. Se pueden reutilizar los objetos observados sin

sus observadores y viceversa. Y se pueden añadir nuevos observadores

sin modificar ninguna de las clases existentes. Dado el acoplamiento

abstracto establecido entre sujetos y observadores (todo lo que un objeto

sabe de sus observadores es que tiene una lista de objetos que satisfacen

la interfaz Observer), podrían incluso pertenecer a dos capas distintas de

la arquitectura de la aplicación.


Resumen

El proceso de diseño entraña una secuencia de actividades y decisiones que

reducen el nivel de abstracción con el que se representa el software. Una de

estas decisiones tiene que ver con la elección de un estilo arquitectónico para

abordar la estructura y organización de nuestro sistema. Cada estilo describe

una categoría de sistemas, un conjunto de conectores que posibilitan la comu-

nicación, la coordinación y cooperación entre los componentes y una serie de

restricciones que definen cómo se integran los componentes que conforman

el sistema.

Seleccionado el estilo arquitectónico, el siguiente paso consiste en trasladar

nuestros requisitos funcionales a componentes y conectores arquitectónicos

respetando las restricciones y características del patrón arquitectónico selec-

cionado. Para llevar a cabo esa traslación, el modelado y la documentación de

la arquitectura software es descrita haciendo uso tanto de diagramas estructu-

rales, como de diagramas de comportamiento siguiendo la notación de UML

2.0.

Llegados a este punto, la siguiente etapa de diseño se centra en el modelado

físico de los componentes arquitectónicos mediante componentes software

implementados utilizando tecnologías concretas. Para ello, los diagramas pre-

vios habrán de ser refinados hasta alcanzar un grado de especificación y deta-

lle más fino. Pasaremos de componentes arquitectónicos de grano grueso a su

implementación en componentes software de grano más fino; en definitiva,

representaciones más cercanas a la implementación final, como se discute en

el siguiente módulo.


Actividades

1. Diseñad la arquitectura software del sistema bancario descrito en el módulo anterior, peroen donde los clientes pueden usar no sólo los servicios bancarios a través de cajeros automá-ticos, sino también a través de Internet. Utilizad un estilo arquitectónico cliente-servidor y entres capas. Justificad el criterio utilizado para asignar los componentes a las diferentes capas.

2. Diseñad la arquitectura software de un sistema de granjas de procesos como puede ser elSETI@home.

Ejercicios de autoevaluación

1. ¿Qué estilo (o estilos arquitectónicos) elegiríais para cada uno de los supuestos que ospresentamos a continuación?

a) Si son centrales los datos de la aplicación, su manejo y su representación.

b) Si su problema puede ser descompuesto en etapas sucesivas, siguiendo un proceso linealde transformación de la información.

c) Si su problema involucra transformaciones sobre flujos continuos de datos (como puedenser vídeos) o sobre flujos muy prolongados.

d) Si las tareas están divididas entre productores y consumidores.

e) Si ha diseñado un algoritmo de computación abstracto pero no quiere fijar una máquinaconcreta para ejecutarlo.

f) Si tiene motivos para no vincular receptores de señales con sus originadores.

2. ¿Qué relación existe entre los conceptos estilo arquitectónico, arquitectura de software ypatrón de diseño?

3. ¿Cuál es la diferencia fundamental entre un enfoque de cliente grueso y uno de clientedelgado para el desarrollo de sistemas cliente-servidor?


Solucionario

1. Soluciones:

a) El estilo secuencial por lotes o tuberías y filtros, o bien una arquitectura de repositorio.

b) Una arquitectura secuencial por lotes o tuberías y filtros.

c) Una arquitectura en tuberías y filtros.

d) Una arquitectura cliente-servidor o de objetos distribuidos

e) Una arquitectura de máquina virtual.

f) Una arquitectura basada en eventos.

2. Los estilos arquitectónicos definen invariantes de estilo, que van a caracterizar a gruposo familias de arquitecturas software (aquellas que satisfacen los invariantes de estilo). Lospatrones de diseño conforman la microarquitectura de la aplicación y son utilizados en lasdescripciones arquitectónicas para describir muchos de los mecanismos de interconexión yorganización de los componentes.

3. En un enfoque de cliente grueso, algunas de las funcionalidades del sistema se ejecutanen el propio cliente, aprovechando la potencia que suelen tener los ordenadores persona-les, y descargando así al servidor. De este modo, se consigue también que el servidor puedadespreocuparse de muchos aspectos "locales" al cliente, como su navegador web, su sistemaoperativo, etc.


Glosario

arquitectura cliente-servidor f Estilo arquitectónico organizado como un conjunto decomponentes servidores, que ofrecen unos servicios, y un conjunto de clientes que utilizanestos servicios.

arquitectura en capas o niveles f Estilo arquitectónico que representa una organizaciónjerárquica de los elementos de un sistema, de modo que cada capa proporciona servicios alos elementos de la capa inmediatamente superior (o anterior), y se sirve de los servicios quele brindan los elementos de la capa inmediatamente inferior (o siguiente).

arquitectura software f El conjunto de decisiones, principios y reglas que rigen la or-ganización de un sistema software; la selección de los elementos estructurales que componenel sistema, sus interfaces y sus protocolos de interacción; las conexiones de esos elementosestructurales para formar subsistemas de tamaño cada vez mayor; y el estilo o patrón arqui-tectónico que guía esta organización.

componente (arquitectónico) m Unidad abstracta que encapsula un estado y una fun-cionalidad, y que interacciona con su entorno a través de interfaces bien definidas.

conector (arquitectónico) m Mecanismo abstracto de una arquitectura software quemedia en la comunicación, coordinación o cooperación entre componentes.

estilo arquitectónico m Conjunto de patrones estructurales que caracterizan a una fa-milia de sistemas, de acuerdo con una serie de decisiones esenciales sobre la estructura dealto nivel y composición de los sistemas, y estableciendo restricciones importante sobre suselementos y las posibles relaciones entre ellos.


Bibliografía

Albin, S. T. (2003). The Art of Software Architecture: Design Methods and Techniques. Indiana-polis, Indiana: John Wiley & Sons.

Bass, L.; Clements, P.; Kazman, R. (1998). Software Architecture in Practice. Reading, MA:Addison-Wesley.

Referencias bibliográficas

Abowd, G.; Allen, R.; Garlan, D. (1993). "Using Style to Give Meaning to Software Archi-tecture Proceedings of SIGSOFT'93". Software Engineering Notes (vol. 3, núm. 118, pág. 9-20).

Garlan, D.; Allen, R.; Ockerbloom, J. (1994). Exploiting Style in Architectural Design Envi-ronments. Proceedings of SIGSOFT'94: Foundations of Software Engineering (pág. 175-188). ACMPress.

Garlan, D.; Perry, D. (1995). Special Issue on Software Architectures IEEE Transactions onSoftware Engineering (vol. 4, núm. 21, pág. 269-274).

Perdita, S.; Pooley, R. (2002). Utilización de UML en Ingeniería del Software con Objetos yComponentes. Madrid: Addison Wesley.

Morris, C.; Fergunson, C. (1993). "How Architecture Wins Techology Wars". Harvard Bu-siness Review (núm. 71 pág. 86-96).

Larman, C. (2002). UML y Patrones. Una introducción al análisis y diseño orientado a objetos yal proceso unificado. Madrid: Addison Wesley.

Pressman, Roger S. (2001). Ingeniería del Software. Un enfoque práctico. Madrid: Mc GrawHill.

Shaw M; Garlan, D. (1996). Software Architecture: Perspectives on an Emerging Discipline. NewYork: Prentice Hall.

Sommerville, I. (2002). Ingeniería de software. Madrid: Addison-Wesley.

software Arquitectura deluoc.gitlab.io/2014/Ing.Componentes/2.pdf · a aquellos estilos más...

Documents

Transcript of software Arquitectura deluoc.gitlab.io/2014/Ing.Componentes/2.pdf · a aquellos estilos más...