c


     
   

RESUMEN

Más de la arquitectura de software últimos diez años ha recibido

cada vez más atención como un subcampo importante de software
ingeniería. Durante ese tiempo ha habido una considerable
avances en el desarrollo tecnológico y la meto-
base de cal para el tratamiento de diseño arquitectónico como de ingeniería
disciplina. Sin embargo, aún queda mucho por hacer para lograr
ese objetivo. Por otra parte, la cara cambiante de la tecnología plantea
una serie de nuevos retos para la arquitectura de software. Este
documento examina algunos de los rasgos principales del software
arquitectura en la investigación y la práctica, y se especula sobre la
importante de las nuevas tendencias, retos y aspiraciones.

Palabras.clave

arquitectura de software, diseño de software, ingeniería de software

1.INTRODUCCIÓN

Una cuestión fundamental en el diseño y construcción de cualquier com-

complejo sistema de software es su arquitectura: es decir, su organización bruto
como un conjunto de componentes que interactúan. Una buena arquitectura puede
ayudar a asegurar que un sistema va a satisfacer las necesidades fundamentales en
áreas como el rendimiento, fiabilidad, portabilidad,
escalabilidad.e.interoperabilidad..Un.mal.architura.puede.ser.desastroso.

Más de la arquitectura de software últimos diez años ha recibido

cada vez más atención como un subcampo importante de software
ingeniería. Los profesionales se han dado cuenta de que conseguir
una arquitectura adecuada es un factor crítico de éxito para el sistema
diseño y desarrollo. Ellos han comenzado a reconocer la
valor de hacer explícitas las opciones de arquitectura, y la palanca-
envejecimiento últimos diseños de arquitectura en el desarrollo de nuevos
los productos. Hoy en día hay numerosos libros sobre arquitectura diseño,
regularmente.conferencias.y.talleres.dedicados.especamente a la arquitectura de
software, un número creciente de com-
herramientas comerciales para ayudar en los aspectos de diseño arquitectónico,
cursos de arquitectura de software, el gobierno y los principales proyectos de
investigación industrial centrado en arquitectura de software
tura y un número cada vez mayor de normas de arquitectura formal
securidad. La codificación de los principios arquitectónicos, métodos y prácticas ha
 '

comenzado a dar lugar a procesos repetibles de diseño arquitectónico, los criterios

para hacer concesiones de principio entre arquitecturas y estándares para la
documentación,.de.revisualización y la aplicación de arquitecturas.

Sin embargo, a pesar de este progreso, como disciplinas de la ingeniería

vaya, el campo de la arquitectura de software sigue siendo relativamente
inmaduros. Mientras que los contornos de una base de ingeniería para
arquitectura de software son cada vez más claro, sigue habiendo nu-
merosos retos y las incógnitas. Por lo tanto, puede esperar
para ver las principales novedades en el campo durante los próximos
diez años - tanto en la investigación y la práctica. Algunos de estos de-
desarrollos será una extensión natural de la corriente trayectorias-
historia. Pero también hay una serie de radicales nuevas oportunidades-
lazos, provocada por la cara cambiante de la tecnología.

En este artículo examinaremos algunas de las principales tendencias de la

arquitectura de software en la investigación y la práctica. Para establecer el
escenario, empiezo con la descripción de las funciones de la arquitectura de
software de desarrollo de sistemas. A continuación resumo el estado pasado y
actual de la investigación y la práctica. Finalmente, después de considerar algunas
de las fuerzas que están cambiando el mundo de sistemas informáticos propios,
que especulan sobre las nuevas tendencias, retos y aspiraciones.

2 EL PAPEL DE LA ARQUITECTURA DE SOFTWARE

Si bien existen numerosas definiciones de arquitectura de software

tura, en el centro de todos ellos es la noción de que el archi-
tura de un sistema se describe su estructura bruto. Esta estructura se ilumina las
decisiones de alto nivel de diseño, incluyen-
ING cosas tales como cómo el sistema se compone de interactuar-
ING partes, ¿dónde están las principales vías de interacción, y cuáles son las
propiedades esenciales de las partes. Además, una descripción arquitectónica
incluye información suficiente para permitir el análisis de alto nivel y la valoración
crítica.
 s

mr uit turm
 s twmr r mt
sm u m u
mtm


ut tr s ruisits  m mi
m
i  r Fi urm 

Ruisits

ruit
turm
  twmr


i 

Fi urm  ruit
turm
  twmr
 u ut

 rr
imr um
s
ri
i mstrm
tm
 u sistm  mr
t
turm x
irtms ri
m
s m ti u 
utm trs
L i
m srím u stm rrstm
i  r
 um it
tumt rmtm
 m m uím rm
 sistm rit m s
ism
rs m m rm
sr m
mm
i
m

 u sistm mrm smtis m
r
irts ruisits
 suir u m mrm m
stru

i
 sistm 


si
i Pr  um mruit
turm mrm u r
s
 sm
I mi
m
i 
rím sr
strui

 um r

 u

mts
 m u s 
s
 r s us
 trm
m

mts trms rmr
u s
mts  s
riir  s us
 smi
m Ls
ism
rs u
 utiimrstm

s
si
i ut
 s mrs stim
s mrm m trm
m s us


mts s
sts

utm
i  m
mm
i
m

 mrtiumit mrmrmmr
m
r
m
 sis
us
 tm ms 
si
m
s
r
urss 
mi i
mii
m

s

us

Emrmr mruit
turm
 s twmr u
 umr u m irtmt  m s
sis ms
ts

smrr
 s twmr

 rsi m mruit
turm
 s twmr sii i
m ustrm

mm
i
m


r
r s rm
s sistms 
imt m rstm
i
 s
 u i
 mstrm

i  m u u sistm


is
 mt i u
 sr 
it t
i
 ·   !" 
Pr trm mrt  su r t
s
ri
i mruit
ti
m x
mtm ms iitm
is
 mt i sr 
is
 sistm

msí
 m usti i
m
i mrm hm
r mruit
turm s
í i
m

is

 Rutiim
i Rutiim
i
 ruit
turm
 m m ms
s
ri
is
útis is E trmm m
tum sr m rutiim
i  rm 
 
m  ms iit
ms

ts E
is mruit
ti
 mm m
s
tmt m rutiim
i
 ims
 rm tmm  tmi  s mr
s  s u s
 o

componentes se pueden integrar. de trabajo existentes en el dominio

específico.de.la.suave arquitecturas de consumo, los marcos de referencia, y ar-
chitectural patrones de diseño ya ha comenzado a pro-
Véase pruebas para este

3..Construcción: Una descripción arquitectónica proporciona

un plan parcial para el desarrollo, indicando la
componentes principales y las dependencias entre ellos.
Por ejemplo, una vista de capas de una arquitectura típicamente-
camente los documentos límites entre la abstracción
partes de la aplicación de un sistema, identificar claramente-
ción de las interfaces internas de gran magnitud del sistema, y con-
esfuerzo que partes de un sistema puede depender de los servicios
proporcionada por otras partes.

4. Evolución: la arquitectura de software pueden exponer al di-

mensiones largo de la cual un sistema se espera que
evolucionar. Al hacer explícitos los "muros de carga"
de un sistema, personal de mantenimiento del sistema puede comprender mejor
las soporte las consecuencias de los cambios, y por lo tanto más
estimar con precisión los costos de las modificaciones. Más-
más, se refiere a las descripciones arquitectónicas separadas
acerca de la funcionalidad de un componente de la
formas en las que está conectado a ese componente (en-
teracts con) otros componentes, de forma clara distin-
tinguir entre los componentes y mecanismos que
les permiten interactuar. Esta separación permite que un
cambiar con más facilidad los mecanismos con
controlar la evolución de las preocupaciones sobre el desempeño de otras cosas-
operabilidad,.prototipos,.y.la.reutilización.

5. Análisis: las descripciones de arquitectura proporcionar nuevos

oportunidades para el análisis, incluyendo consistencia del sistema
comprobación de consistencia, de conformidad a las limitaciones impuestas por un
estilo arquitectónico, de conformidad con los atributos de calidad · 9 , el análisis
de la dependencia, y los análisis específicos de dominio para las arquitecturas
construidas en estilos específicos.

6. Gestión: La experiencia ha demostrado que el éxito de

proyectos de vista el logro de un ar de software viable
tectura como un hito clave en un entorno industrial suave
proceso de desarrollo de software. Evaluación crítica de una arquitectura
típicamente lleva a una mucho más clara con-
permanente de las necesidades, estrategias de ejecución, y los riesgos potenciales.
 å

3.AYER

En el pasado remoto de hace diez años, la arquitectura en gran medida se

ad hoc affair.1 descripciones se basó en informales de caja y
diagramas de líneas, que se mantuvieron casi nunca una vez un sistema de
se construyó. opciones de arquitectura se hicieron en idio-
syncratic moda - generalmente mediante la adaptación de algunos anteriores
diseño, si era o no apropiado. Los buenos arquitectos
- Aunque hayan sido clasificados como tales dentro de sus organizaciones

1 Sin duda, hubo algunas excepciones notables. Parnas reconoció la importancia de

las familias sistema 33 y principios de la arquitectura de descomposición sobre la
base.de.información ocultar. Otros, como el de Dijkstra, expuestos sistema de
determinados principios de estructuración

ciones - aprendieron su oficio por la dura experiencia, en particular,

dominios, y no fueron capaces de enseñar a otros lo que sabían.
Fue por lo general imposible analizar una arquitectura de-
receta para mantener la coherencia o para inferir propiedades no triviales
al respecto. Prácticamente no había manera de comprobar que un determinado
implementación del sistema fielmente representado su arqui-
diseño.estructural.

Sin embargo, a pesar de su informalidad, descripción arquitectónica-

nes son fundamentales para el diseño del sistema. Como la gente comenzó a
comprender el papel fundamental que desempeña en el diseño arquitectónico
determinar el éxito del sistema, sino que también empezaron a reconocer
la necesidad de un enfoque más disciplinado. Los primeros autores
comenzó a observar ciertos principios unificadores de la arquitectura
diseño, para llamar a la arquitectura como un campo en la necesidad de
atención, y establecer un vocabulario de trabajo para
arquitectos de software. los vendedores de herramientas comenzó a pensar
sobre el apoyo explícito para el diseño arquitectónico. Idioma
Los diseñadores empezaron a considerar las notaciones para representante de
arquitectura-presentación.

Dentro de la industria, dos tendencias destacó la importancia de

arquitectura. El primero fue el reconocimiento de un representante común,
ertoire de métodos, técnicas, modelos y lenguajes de
la estructuración de los sistemas complejos de software. Por ejemplo, la
 Ë

de caja y línea de diagramas y la prosa de motivos que por lo general

acompañar una descripción del sistema de alto nivel a menudo se refieren a
organizaciones como un "gasoducto'', una" pizarra orientado
diseño'', o un sistema de "cliente-servidor.''Aunque estos términos
rara vez se asigna definiciones precisas, que permiten
diseñadores para describir sistemas complejos con abstracciones
que hacen que el sistema en su conjunto inteligible. Por otra parte, que
siempre contenido semántico significativo sobre los tipos de
propiedades de interés, las rutas de espera de la evolución, la
paradigma global de cómputo, y la relación se-
entre este sistema y otros sistemas similares.
La segunda tendencia fue la preocupación por la explotación de com -
monalities en ámbitos específicos para proporcionar el marco reutilizables
trabaja para las familias de productos. Dicha explotación se basa en
la idea de que los aspectos comunes de un conjunto de asociados
sistemas pueden ser extraídos de manera que cada nuevo sistema se puede
construido a un costo relativamente bajo por "instancias''comparte la
diseño. Ejemplos conocidos son la descomposición de normas
ción de un compilador (que permite a los estudiantes con-
estructura un nuevo compilador en un semestre), comunicación estandarizada-
protocolos de comunicación (que permiten a los proveedores para interoperar con
que presten servicios en las diferentes capas de abstracción), cuarto
idiomas generación (que explotan los patrones comunes
de procesamiento de información de negocio), y la interfaz de usuario
herramientas y marcos (que proporcionan tanto una reutilizables
marco para el desarrollo de interfaces y sistemas de reutilizables
componentes, tales como menús y cuadros de diálogo).

4.HOY

Mucho ha cambiado en la última década. Aunque no es

amplia variación en el estado de la práctica, por lo general hablan-
ción, la arquitectura es mucho más visible como un importante y
actividad de diseño explícito en el desarrollo de software. Trabajo títulos
ahora rutinariamente reflejar el papel de arquitecto de software, empresas
se basan en revisiones de diseño arquitectónico como puesta en escena crítica
puntos, y los arquitectos reconocen la importancia de hacer
compensaciones explícita en el espacio de diseño arquitectónico.

Además, la base tecnológica para el diseño arquitectónico

ha mejorado de forma espectacular. Tres de los anuncios importantes
vancements han sido el desarrollo de la arquitectura de-
idiomas descripción y herramientas, la aparición de productos
 '

línea de ingeniería y normas arquitectónicas, y la codifi-

ción y la difusión de experiencia en diseño arquitectónico.

4.1 Descripción Idiomas Arquitectura y Herramientas

La informalidad de la mayoría de las representaciones de caja y línea de archi-

diseños arquitectónicos conduce a una serie de problemas. La
significado del diseño no puede ser claro. Informales diagramas
no pueden ser formalmente analizado la coherencia, integridad,
o corrección. limitaciones de arquitectura asumida en el
diseño inicial no se aplican como un sistema evoluciona. No
son pocas herramientas para ayudar a los diseñadores de arquitectura con sus
tareas.

En respuesta a estos problemas de un número de investigadores en la industria y

la academia han propuesto notaciones formales para la representación y
análisis.de.diseños.arquitectónicos..Genéricamente a que se refiere como
"Arquitectura Idiomas Descripción''(AVD), estas notaciones suelen proporcionar
un marco conceptual y una sintaxis concreta para.la.caracterización.de.soft-
Artículos arquitecturas · 9, 30 . También suelen proporcionar herramientas para
el.análisis,.visualización,.compilación,.análisis,..simulating.descripciones.arquitectó
nicas.
Ejemplos de las AVD incluyen Adagio · 10 , Esopo · 15 , C2
· 28 , Darwin · 26 , Rapide · 25 , SADL · 32 , UniCon · 39 ,
Meta-H · 6 , y Wright · 3. Mientras que todos estos idiomas
tienen que ver con el diseño arquitectónico, que cada uno proporciona cier -
mantener las capacidades distintivas: Adagio apoya la descripción
de los marcos arquitectónicos para la navegación y aviónica
orientación; Esopo apoya el uso de estilos arquitectónicos; C2
compatible con la descripción de los sistemas de interfaz de usuario utilizando una
estilo basado en eventos de Darwin apoya el análisis de dis-
buido de paso de mensajes sistemas; Meta-H proporciona una guía
para los diseñadores de tiempo real, software de control de aviónica; Rapide
permite diseños arquitectónicos a simular, y dispone de herramientas
para analizar los resultados de las simulaciones; SADL pro-
proporciona una base formal para el refinamiento arquitectónico; UniCon
tiene un compilador de alto nivel para proyectos arquitectónicos que apoyo
los puertos de una mezcla de componentes heterogéneos y el conector
tipos; Wright soporta la especificación formal y análisis de las interacciones entre
los componentes arquitectónicos.

Recientemente, la proliferación de las capacidades de los ADL ha

a una investigación de la forma de integrar las notaciones
 >

y herramientas en grandes conjuntos. Uno de los resultados ha sido

un lenguaje de intercambio de arquitectura, llamado Acme, que
proporciona un marco sencillo para describir la arquitectura
estructura y un mecanismo flexible para la introducción de anotación
semántica a que la estructura · 18 . (Acme puede ser visto como
el código XML de la descripción arquitectónica.) Acme también apoya
la definición de estilos y la ejecución de con diseño
limitaciones a través de sus herramientas.
Más ambicioso aún, varios investigadores han comenzado a buscar maneras
adicionales de la integración de herramientas basadas en la arquitectura. El
resultado promete ser flexible "ADL''kit de herramientas que permitirá a los
profesionales para crear ar dominio específico-
chitectural entornos de diseño en gran medida mediante la combinación de las
capacidades de las herramientas existentes. Otros esfuerzos han tratado de
integrar las herramientas de desarrollo arquitectónico con otra herramienta-
aspectos compatibles de desarrollo de software, tales como re-
obtención requisitos y resolución de 7 · .
Idiomas explícitamente diseñado con una arquitectura de software en mente no
son el único enfoque. No se ha consi-
interés en poder utilizar para fines generales nota objeto de diseño-
ciones para el modelado de arquitectura · 8, 24 . Además, recientemente ha
habido una serie de propuestas que intentan mostrar cómo los conceptos que se
encuentran en las AVD se pueden asignar directamente a una notación orientada a
objetos como UML · 29, 23, 17 . Estas alternativas se ilustran en la

Figura.2.

Figura 2: Arquitectura de Software como un puente

Camino de Alzheimer es una en la que un ADL se utiliza como lenguaje de

modelado. Ruta de BE es una en la que se utiliza UML como notación de modelado.
 ´

Ruta A-C-E, es aquel en el que un archi-

tura es la primera representación en un ADL, pero luego se transforma en UML
antes.de.producir.una.puesta.en.práctica.

El uso de un lenguaje de modelado más generales, tales como UML ha

las ventajas de proporcionar una indicación de que los profesionales se
más probable que esté familiarizado con, y proporcionar una más directa
enlazan con las implementaciones orientado a objetos y el desarrollo de
herramientas.

Pero las lenguas de uso general objeto sufren el problema de que el vocabulario
objeto conceptual puede no ser ideal para la representación de conceptos
arquitectónicos, y es probable que haya menos oportunidades para el análisis
automatizado.de.propiedades.arquitectónicas.

4.2.Líneas.de.Productos.y.Normas

Como se señaló anteriormente, una de las tendencias más importantes ha sido la

propósito de poner en común a través de múltiples productos.
Dos manifestaciones concretas de esta tendencia son las mejoras
en nuestra capacidad para crear líneas de productos dentro de una organización
y la aparición de las normas de integración entre proveedores.

Con respecto a las líneas de producto, un desafío clave es que un enfoque de línea
de productos requiere diferentes métodos
de desarrollo. En un enfoque de un solo producto de la arquitectura debe ser
evaluada con respecto a los requisitos de esa pro-
ducto solo. Además, los productos solo se puede construir inde-
bras, cada una con una arquitectura diferente.

Sin embargo, en un enfoque de línea de productos, también hay que con-

requisitos para considerar a la familia de sistemas, y
la relación entre dichos requisitos y los asociados-los
serie ATED con cada caso particular. Figura 3 ilustra este
relación. En particular, debe haber una por adelantado (y
en curso) la inversión en el desarrollo de una arquitectura reutilizable
que se pueden crear instancias para cada producto. Otros reutilizables
activos, tales como componentes, bancos de pruebas, herramientas, etc, por lo
general.acompañan.a.esta.
 c

Figura 3: Línea de productos de arquitecturas

Aunque la ingeniería de productos de línea no está todavía poco extendida,

estamos empezando a tener una mejor comprensión de los pro-
procesos, la economía, y los artefactos necesarios para lograr los beneficios de un
enfoque de línea de productos. Un número de estudios de casos de éxitos línea de
productos se han publicado. (Por ejemplo, véase · 13 .) Por otra parte,
organizaciones como el Instituto de Ingeniería de Software está bien en su
manera.de salas de ofrecer directrices concretas y procesos para el uso de un
enfoque de línea de productos · 37 .

Al igual que los enfoques línea de productos, la integración entre proveedores

normas,.los.marcos.arquitectónicos.que.permiten.una.desarrollador del sistema
para configurar una amplia variedad de sistemas específicos creando instancias
de.ese.marco..Integración.nordards suelen proporcionar el pegamento del sistema
(tanto conceptual como a través de la infraestructura de tiempo de ejecución) que
apoya la integración de las piezas suministradas por proveedores múltiples. Estas
normas pueden ser formales las normas internacionales (como los.patrocinado por
el IEEE o ISO), o ad hoc y las normas de facto promovida por .un.líder.industrial.

Un buen ejemplo de lo primero es el alto nivel Architec-

tura (HLA) para la simulación distribuida · 4 . Este ar-
quitectura permite la integración de las simulaciones producidas por
muchos vendedores. En él se establece la definición de estándares de interfaz
servicios para coordinar el comportamiento de varios semi-
simulaciones independientes. Además, la norma pre-
escribas requisitos de los componentes de simulación que
indicar las capacidades que debe tener, y lo que con-
limitaciones que deben observar en el uso de servicios compartidos.
Un ejemplo de una norma ad hoc es Enterprise Java de Sun-
BeansTM (EJB), la arquitectura · 27 . EJB se destina a apoyar-
puerto distribuido, basado en Java, aplicaciones de nivel empresarial, como
sistemas de gestión de la información. Entre otras cosas, se establece una
arquitectura que define una interfaz de proveedor neutral de servicios de
información, incluidas las transacciones, persistencia, y la seguridad. Es por lo
 cc

tanto compatible con las implementaciones basadas en componentes de software

empresarial de procesamiento que puede ser fácilmente reorientarse
para.implementar.diferentes.implementaciones de los servicios subyacentes.

4.3.Codificación. y Difusión

Uno de los impedimentos a la aparición temprana de diseño de la arquitectura

como una disciplina de ingeniería fue la falta de un cuerpo común de
conocimientos sobre las arquitecturas y las técnicas para el desarrollo de los
buenos. Hoy la situación ha mejorado, debido en parte a la publicación de libros
sobre.arquitectura.de signo · 5, 8, 22, 36, 40 y · 21 cursos.

Un tema común en estos libros y cursos es el uso de

estándar de estilos arquitectónicos. Un estilo arquitectónico típicamente
especifica un vocabulario de diseño, las restricciones sobre la forma que
vocabulario se utiliza, y los supuestos semánticos sobre ese vocabulario. Por
ejemplo, un estilo pipe-and-filtro puede especificar
vocabulario en el que los componentes de procesamiento de datos
transformadores (filtros), y las interacciones son a través de la orden
preservación de los arroyos (tuberías). Las restricciones pueden incluir la
prohibición de los ciclos. supuestos semánticos podrían incluir
el hecho de que las tuberías de preservar el orden y que los filtros estén en
revocados.no-determinista.

Otros estilos comunes incluyen arquitecturas de pizarra,

arquitecturas cliente-servidor, las arquitecturas basadas en eventos, y
arquitecturas basadas en objetos. Cada estilo es apropiado para
ciertos propósitos, pero no para otros. Por ejemplo, una tubería-
estilo y con filtro probable sería apropiado para una señal
aplicación de procesamiento, pero no para una aplicación en la que no es un
requisito importante para el acceso simultáneo a los datos compartidos · 38 .

Por otra parte, cada estilo es típicamente aso-

serie ATED con un conjunto de análisis asociado. Por ejemplo, tiene sentido
analizar un sistema de tuberías y filtro de la latencia del sistema, mientras que las
tasas de transacción sería un enfoque más-
análisis apropiado para un estilo orientado al repositorio.
La identificación y documentación de los estilos de este tipo (como
así como sus variantes más específicos del dominio) permite a otros
la adopción de patrones arquitectónicos anteriores como punto de partida.
A este respecto, la comunidad de arquitectura ha sido paralelo
otras comunidades en el reconocimiento del valor de las establecidas,
patrones bien documentados, como las que se encuentran en · 14 .
Sin dejar de reconocer el valor de la uniformidad estilística, realidades
 c'

de construcción de software a menudo obligan a componer sis-

temas de las partes que no estaban en una arquitectura uniforme
la moda. Por ejemplo, se puede combinar una base de datos
un solo proveedor, con el middleware de otro, y un usuario en
interterface de un tercero. En estos casos, las partes no siempre
trabajar bien juntos - en gran medida, porque hacen
hipótesis contradictorias sobre los entornos en los que
que fueron diseñados para trabajar · 16 . Esto ha llevado al reconocimiento
ción de la necesidad de identificar las estrategias de arquitectura para
puente desajustes. Aunque estamos lejos de haber
entiende bien las formas de detectarlos desajuste tal, y de
reparación cuando se descubre, una serie de técnicas
Se.han.desarrollado.[11].

5.MAÑANA

¿Y el futuro? Aunque la arquitectura de software es

sobre una base mucho más sólida que hace una década, no es
sin embargo, estableció como una disciplina que se enseña y se practica
universalmente en la industria del software. Una de las razones
esto es simplemente que se necesita tiempo para nuevos enfoques y
percepciones para propagarse. Otra razón es que la tecnología-
base tecnológica para el diseño de la arquitectura (como se indica anteriormente)
es todavía inmadura. En estas dos áreas en las que se puede esperar que un
evolución natural del campo dará lugar a avances constantes.

Sin embargo, el mundo de desarrollo de software y en contra de la-

textos en los que el software se está utilizando están cambiando en
maneras significativas. Estos cambios prometen tener un gran im-
pacto sobre cómo la arquitectura se practica. En el resto de
esta sección cuenta tres de las tendencias más destacadas
y sus repercusiones en el ámbito de la arquitectura de software.

5.1.Cambio.de.Build-Versus.Comprar.Balance

A lo largo de la historia de la ingeniería del software una crítica

se trata en el desarrollo de sistemas ha sido la decisión
sobre qué partes del sistema para obtener en otros lugares y
lo que las piezas para construir en casa. Externamente adquiridos partes
tienen la ventaja de ahorrar tiempo de desarrollo. Pero que
también tienen las desventajas de satisfacer a menudo incompleta-
 cs

ción de la necesidad, y de ser menos bajo el control de la de-

en desarrollo la organización

Si bien la cuestión en sí no ha cambiado, las presiones económicas para reducir el

tiempo de salida al mercado son un cambio drástico en el bal-
ance. Para un número cada vez mayor de productos, la introducción de un
producto un mes antes puede ser la diferencia entre el éxito-
proceso y el fracaso. En tales situaciones, la construcción de los sistemas que
utilizan software que otros han escrito se convierte en la única opción viable. No es
raro en estos días para los desarrolladores de software para el uso de un millar (o
incluso diez mil) líneas de código desarrolladas externamente por cada línea que
escriben. De hecho, muchas empresas se están encontrando más
rápidamente.en.la.posición de los integradores de sistemas que los desarrolladores
de software. Es decir, la mayoría del código que se escribe es "pegar" el código que
hace que un conjunto de componentes del sistema para trabajar.juntos.

Para muchas empresas la situación se ve agravada por la eco-

las tendencias económicas hacia las fusiones y adquisiciones como la pri-
avenida María de crecimiento. En lugar de comprar piezas individuales de software
o productos, las empresas simplemente absorber a otras empresas en total. La
integración se convierte ahora en un problema aún más grave y difícil.
Hay una serie de consecuencias para la arquitectura de software
tura. En primer lugar, esta tendencia aumenta la necesidad de normas para toda la
industria. El más común, es más probable sistemas de software de terceros a
trabajar juntos. Esta tendencia es evidente en la creciente popularidad
de''''basado.en.componentes.blandos desarrollo de software · 43 . Al elegir los
componentes que están de acuerdo sobre un marco de arquitectura común, tales
como COM, JavaBeans, o CORBA, muchos de los problemas de la arqui-
desajuste.estructural.se.alivian.

Sin embargo,''''de la ingeniería basada en componentes es sólo una parte de

la respuesta. componente de hoy en día las tecnologías de trabajo en una
relativamente bajo nivel de abstracción arquitectónica - esencialmente a
el nivel de llamada a procedimiento entre los objetos. Para obtener más
integración significativa requerirá de más alto nivel arqui-
las normas culturales. Es probable que esto nos llevará de componente''-
ingeniería''basado en'' de ingeniería basados en la arquitectura, un
cambio que se hará hincapié en el papel de la integración de dominio específico-
arquitecturas de integración (como EJB o HLA, menciona el oído
anteriores) en la promoción de componibilidad. Por lo tanto, la tendencia hacia
la.normas arquitectónicas, se ha señalado, es probable que se convierta
aún.más.pronunciada.
 co

En segundo lugar, esta tendencia está conduciendo a un nuevo software

subcontrata ING procesos. Cuando la integración es el tema crítico, podemos
Esperamos que el software contratado externamente se llevará a cabo a
mucho más altos estándares de cumplimiento de arquitectura. En
muchos casos las normas se comerciales o gobierno
normas ambientales. En otros, es probable que los sub-contratistas
tendrá que garantizar la compatibilidad con la línea de productos ar -
arquitecturas. Por ejemplo, el Departamento de Defensa de EE.UU.
exige que los subcontratistas de simulación de suministrar productos
que son''HLA compatibles.''

En tercer lugar, esta tendencia está llevando hacia la normalización de la nota-

ciones y herramientas a través de los vendedores. Cuando aguas abajo inte-
grators se recombinan los sistemas, ya no es aceptable
para tener en casa, descripciones arquitectura idiosincrásica
y herramientas. Esto ha llevado a muchos a adoptar lenguajes como UML
y XML para el modelado de arquitectura (véase la sección 4.1).

5.2.Informática.centrado.en.la.red

Hay una tendencia clara desde un PC-céntrico de cómputo

modelo a un modelo centrado en la red. equipo tradicional
centros de uso en los ordenadores, el uso de aplicaciones y datos locales que
son instalados y actualizados de forma manual. Cada vez más, el PC
y una variedad de otras interfaces (dispositivos de mano, ordenadores portátiles,
teléfonos) se utilizan principalmente como una interfaz de usuario que
proporciona el acceso a datos remotos y computación. Esta tendencia no es
sorprendente, ya que un modelo centrado en la red ofrece la po-
potencial para obtener ventajas significativas. Proporciona una mucho más amplia
base de los servicios que está disponible en un PC individual. Es
permite el acceso a un amplio conjunto de la informática y la información
servicios de recuperación a través de computadoras portátiles que pueden ser
utilizado casi en cualquier lugar (en la oficina, casa, coche, y factores
historia). Se promueve la movilidad de los usuarios mediante un acceso ubicuo
a.información.y.servicios.

Esta tendencia tiene varias consecuencias para el software en-

arquitectura de ingeniería, en general, y el software, en parti-
lar. Históricamente, los sistemas de software han sido desarrollados como
sistemas cerrados, desarrollado y operado bajo el control de
las instituciones individuales. Los component es pueden ser constitutivos
adquiridos de fuentes externas, pero cuando se incorporen en un
sistema que están bajo el control del diseñador del sistema.
Arquitecturas de estos sistemas están completamente estática
 cå

- No permitir la reestructuración de tiempo de ejecución - o permitir sólo una

forma limitada de la variación de tiempo de ejecución.
Sin embargo, en el mundo de los servicios disponibles generalizada
a través de redes, los sistemas no pueden tener tales centralizada
de control. El Internet es un ejemplo de un sistema abierto
TEM: Es mínimamente normalizado, principalmente a nivel de la
protocolos, direcciones y representaciones que permiten a los indivi-
sitios individuales para interactuar. Se admite una variación considerable
tanto en el hardware que se encuentra por debajo de estos estándares y el
aplicaciones que están por encima. No existe una autoridad central para
control o validación. Los sitios individuales son independientemente
administrados. Los desarrolladores individuales pueden proporcionar,
modificar,.y.quitar.recursos.a.su.antojo.

Para los sistemas de un nuevo conjunto de desafíos de la arquitectura de software

desafíos emerge [41]. En primer lugar, es la necesidad de arquitecturas que escala
hasta el tamaño y la variabilidad de la Internet. Mientras que
muchos de los mismos paradigmas arquitectónicos probable que se aplicará,
los.detalles.de.su.aplicación.y.especificación.necesidad.de.cambio.

Por ejemplo, una forma atractiva de la composición está implícito

invocación - a veces llamado''publicar-suscribir''Dentro.

los componentes de este estilo arquitectónico en gran medida autónoma,

interactuar con otros componentes por mes de radiodifusión sabios que pueden
ser "escuchados" por otros componentes. La mayoría de los sistemas que utilizan
este estilo, sin embargo, que muchos supuestos-
ciones acerca de las propiedades de su uso. Por ejemplo, un general, se supone que
la entrega de eventos es confiable, que centralizada de enrutamiento de mensajes
serán suficientes, y que tiene sentido definir un vocabulario común de los
acontecimientos que son entendidos por todos los componentes. En un entorno
basado en Internet todas estas suposiciones.son.cuestionables.

En segundo lugar, es la necesidad de soporte informático con dinámicamente

formado, en tareas específicas, las coaliciones de autonomía.distribuida recursos
dicotómicos. Internet alberga una gran variedad.de.fuentes: la información
primaria, mecanismos de comunicación,.aplicaciones que pueden ser invocadas, el
control que coordina.el uso de los recursos, y servicios tales como secundaria
(proc-
Essed) información, simulación, editorial de selección, o
evaluación. Estos recursos son desarrollados de forma independiente
y de manera independiente apoyado, sino que incluso puede ser tr ansitoria.

Pueden estar compuestos para llevar a cabo tareas específicas

establecidas.por.un.usuario, en muchos casos los recursos no tienen que
ser.específicamente conscientes de la forma en que se están utilizando, o
 cË

si.incluso.ellos se están utilizando. Estas coaliciones no tienen control

directo.sobre.la.recursos incorporados. Selección y composición de la re-
fuentes es probable que se realice de nuevo para cada tarea, como re-
aparecen los orígenes, el cambio, y desaparecen. Desafortunadamente, es
difícil de automatizar la actividad de selección y la composición
debido a la escasa información sobre el carácter de los servicios
y por lo tanto con el establecimiento de corrección.

Composición de los componentes en este contexto es difícil se-

porque es difícil determinar lo que cada uno de los supuestos com -
componente hace acerca de su contexto de operación, y mucho menos si
un conjunto de componentes va a funcionar bien (o en absoluto) y
si su funcionalidad combinada es lo que necesita.
Por otra parte, existen muchos recursos útiles, pero no puede ser
integra sin problemas porque hacen incompatible como-
suposiciones acerca de la interacción de los componentes. Por ejemplo, es difícil de
integrar el componente de empaquetado para interactuar a
través.de.reprocedimiento de promover las llamadas con un componente
de.empaquetado.para.interactuar a través de los datos compartidos en
una.representación.de.propiedad.

Estos problemas se presentan desafíos nuevos para la arqui-

tura descripción y el análisis. En particular, la necesidad de Han-
DLE colecciones de forma dinámica en evolución de los componentes de
sostenido a partir de una variedad de fuentes se requieren nuevas tecnologías
técnicas para la gestión de modelos arquitectónicos en tiempo de ejecución, y para
evaluar las propiedades de los conjuntos.

En tercer lugar, es la necesidad de encontrar relacionados con las

arquitecturas.que.con.flexibilidad adaptarse a los proveedores comerciales de
servicios de aplicación.

En.el futuro, las solicitudes se compone de una mezcla de

locales y remotos capacidades de cómputo en cada estación,
que requieren soporte de arquitectura que soporta la facturación, seguri-
dad, etc. En cuarto lugar, es la necesidad de desarrollar arquitecturas que permiten
la final a los usuarios hacer su propio sistema de composición. Con el rápido
crecimiento de Internet, un número creciente de usuarios están en
condiciones de montaje y servicios a medida. Estos usuarios pueden
una experiencia técnica mínima, y sin embargo va a querer aún
sólidas garantías de que las partes trabajarán conjuntamente en la
manera.que.ellos.esperan.

5.3.computación.ubicua

Una tendencia relacionada tercero es hacia la computación omnipresente en

que el universo informático está poblado por una variable ricos
ETY de dispositivos informáticos heterogéneos: tostadores de pan, casa
sistemas de calefacción, sistemas de entretenimiento, los coches inteligentes, etc.
 c'

Esta tendencia puede dar lugar a una explosión en el número de

dispositivos en nuestro entorno local - de decenas de de-
vicios a cientos o miles de dispositivos. Además, estos
dispositivos es probable que sean muy heterogéneos, que requieren espe-
consideraciones sociales en términos de sus recursos físicos y
poder.de.cómputo.

Hay una serie de desafíos como consecuencia de las arquitecturas de software. En

primer lugar, vamos a necesitar arquitecturas que se adaptan a los sistemas en los
que el uso de recursos es un tema crítico. Por ejemplo, puede ser conveniente
disponer de una arquitectura que nos permite modificar la fidelidad de la
computación basada en las reservas de energía a su disposición.

En segundo lugar, las arquitecturas de estos sistemas tendrán que ser más flexible
de lo que son hoy en día. En particular, los dispositivos se puedan ir y
venir.de.una.manera.impredecible.

Handling reconfiguración dinámica, garantizando al mismo tiempo no-

procesamiento de interrupción, es un problema difícil.

En tercer lugar, es la necesidad de arquitecturas que mejor se encargará de

la movilidad del usuario. En la actualidad, nuestros entornos de computación son
configurar manualmente y gestionados explícitamente por el usuario.
Si bien esto puede ser apropiado para entornos en los que
sólo tenemos unos pocos, relativamente estable, los dispositivos de computación
(Como un par de PCs y portátiles), que no escala a
ambientes con cientos de dispositivos. Por lo tanto, debe
encontrar arquitecturas que proporcionan mucho más automatizado con-
control sobre la gestión de los servicios de cómputo, y
que permiten a los usuarios moverse fácilmente de un ambiente a
otro.

6.CONCLUSIÓN

El campo de la arquitectura de software es el que ha expande un crecimiento

considerable.durante.la.última.década,.y.promete continuar el crecimiento en el
futuro.previsible. Como el diseño arquitectónico madura para convertirse en
disciplinas de ingeniería que es universalmente reconocido y practicado, no se
una serie de importantes retos que tendrá que ser ad-
vestidos. Muchas de las soluciones a estos retos se
que pueden surgir como una consecuencia natural de la difusión
y la maduración de los estudios de arquitectura y tecnología de que sabemos
acerca de la actualidad. Otros retos surgen se-
causa del panorama cambiante de la informática y las necesidades de software:
estos se requieren importantes innovaciones. En este trabajo hemos intentado
ofrecer una visión de alto nivel de este terreno - que ilustra donde hemos llegado
en los últimos años, y especulando acerca de dónde tenemos que ir para
satisfacer.las.demandas.del.futuro.