Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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
CC-BY-SA • PID_00201504 Arquitectura del software
Í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
CC-BY-SA • PID_00201504 Arquitectura del software
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.
CC-BY-SA • PID_00201504 6 Arquitectura del software
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.
CC-BY-SA • PID_00201504 7 Arquitectura del 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:
CC-BY-SA • PID_00201504 8 Arquitectura del software
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.
CC-BY-SA • PID_00201504 9 Arquitectura del software
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.
CC-BY-SA • PID_00201504 10 Arquitectura del software
• 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.
CC-BY-SA • PID_00201504 11 Arquitectura del software
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.
CC-BY-SA • PID_00201504 12 Arquitectura del software
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.
CC-BY-SA • PID_00201504 13 Arquitectura del software
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)
CC-BY-SA • PID_00201504 14 Arquitectura del software
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.
CC-BY-SA • PID_00201504 15 Arquitectura del software
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
CC-BY-SA • PID_00201504 16 Arquitectura del software
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
CC-BY-SA • PID_00201504 17 Arquitectura del software
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.
CC-BY-SA • PID_00201504 18 Arquitectura del software
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
CC-BY-SA • PID_00201504 19 Arquitectura del software
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.
CC-BY-SA • PID_00201504 20 Arquitectura del software
• 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,
CC-BY-SA • PID_00201504 21 Arquitectura del software
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.
CC-BY-SA • PID_00201504 22 Arquitectura del software
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.
CC-BY-SA • PID_00201504 23 Arquitectura del software
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.
CC-BY-SA • PID_00201504 24 Arquitectura del software
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
CC-BY-SA • PID_00201504 25 Arquitectura del software
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
CC-BY-SA • PID_00201504 26 Arquitectura del software
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.
CC-BY-SA • PID_00201504 27 Arquitectura del software
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.
CC-BY-SA • PID_00201504 28 Arquitectura del software
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-
CC-BY-SA • PID_00201504 29 Arquitectura del software
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".
CC-BY-SA • PID_00201504 30 Arquitectura del software
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.
CC-BY-SA • PID_00201504 31 Arquitectura del software
• 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.
CC-BY-SA • PID_00201504 32 Arquitectura del software
• 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.
CC-BY-SA • PID_00201504 33 Arquitectura del software
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
CC-BY-SA • PID_00201504 34 Arquitectura del software
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).
CC-BY-SA • PID_00201504 35 Arquitectura del software
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.
CC-BY-SA • PID_00201504 36 Arquitectura del software
• 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.
CC-BY-SA • PID_00201504 37 Arquitectura del software
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.
CC-BY-SA • PID_00201504 38 Arquitectura del software
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.
CC-BY-SA • PID_00201504 39 Arquitectura del software
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.
CC-BY-SA • PID_00201504 40 Arquitectura del software
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.
CC-BY-SA • PID_00201504 41 Arquitectura del software
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.
CC-BY-SA • PID_00201504 42 Arquitectura del software
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
CC-BY-SA • PID_00201504 43 Arquitectura del software
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.
CC-BY-SA • PID_00201504 44 Arquitectura del software
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
CC-BY-SA • PID_00201504 45 Arquitectura del software
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.
CC-BY-SA • PID_00201504 46 Arquitectura del 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-
CC-BY-SA • PID_00201504 47 Arquitectura del software
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
CC-BY-SA • PID_00201504 48 Arquitectura del software
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.
CC-BY-SA • PID_00201504 49 Arquitectura del software
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.
CC-BY-SA • PID_00201504 50 Arquitectura del software
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.
CC-BY-SA • PID_00201504 51 Arquitectura del software
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?
CC-BY-SA • PID_00201504 52 Arquitectura del software
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.
CC-BY-SA • PID_00201504 53 Arquitectura del software
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.
CC-BY-SA • PID_00201504 54 Arquitectura del software
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.