1

Arquitectura de Software: programa de trabajo

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 recibidocada vez más atención como un subcampo importante de softwareingeniería. Los profesionales se han dado cuenta de que conseguiruna arquitectura adecuada es un factor crítico de éxito para el sistemadiseño y desarrollo. Ellos han comenzado a reconocer lavalor de hacer explícitas las opciones de arquitectura, y la palanca-envejecimiento últimos diseños de arquitectura en el desarrollo de nuevoslos 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 softwaretura y un número cada vez mayor de normas de arquitectura formalsecuridad. La codificación de los principios arquitectónicos, métodos y prácticas ha

2

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íavaya, el campo de la arquitectura de software sigue siendo relativamenteinmaduros. Mientras que los contornos de una base de ingeniería paraarquitectura de software son cada vez más claro, sigue habiendo nu-merosos retos y las incógnitas. Por lo tanto, puede esperarpara ver las principales novedades en el campo durante los próximosdiez 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 softwaretura, 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.

3

arquitectura de software normalmente desempeña un papel fundamental como puente entre los requisitos y la aplicación (ver Figura 1).

Requisitos

Arquitectura de Software

Código

Figura 1: Arquitectura de Software como un puente

Al proporcionar una descripción abstracta de un sistema, el ar-tectura expone ciertas propiedades, al tiempo que oculta otros.Lo ideal sería que esta representación ofrece una intelectualmente Trata-ble a la guía general del sistema, permite a los diseñadores a la razónsobre la capacidad de un sistema para satisfacer ciertos requisitos,y sugiere un plan para la construcción del sistema y com-posición. Por ejemplo, una arquitectura para un proceso de señalING aplicación podría ser construido como una red de flujo de datosen la que los nodos de leer los flujos de entrada de datos, transformarque los datos, y escribir en los flujos de salida. Los diseñadores pueden utilizar esta descomposición, junto con los valores estimados para la entrada los flujos de datos, los costos de computación, y la capacidad de amortiguamiento, para razonar acerca de posibles cuellos de botella, las necesidades.de..recursos, y planificabilidad.de.los.cálculos.

Elaborar, arquitectura de software puede jugar un papel importante en al menos seis aspectos del desarrollo de software.

1. Comprensión: la arquitectura de software simplifica nuestracapacidad de comprender los grandes sistemas mediante la presentación de ellos en un nivel de abstracción en la que un sistema dediseño de alto nivel puede ser fácilmente entendido 20, 35 .Por otra parte, en su mejor momento, descripción arquitectónica ex-plantea las limitaciones de alto nivel sobre el diseño del sistema, comoasí como la justificación para hacer arquitectura específicaopciones.

2. Reutilización: Reutilización de Arquitectura de apoyo a las descripcionesmúltiples niveles. El trabajo actual sobre la reutilización en general, fo-enfoca en las bibliotecas de componentes. El diseño arquitectónico apoya, además, tanto la reutilización de piezas de gran tamaño y también los marcos en los que los

4

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 proporcionaun plan parcial para el desarrollo, indicando lacomponentes 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ónpartes 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 serviciosproporcionada por otras partes.

4. Evolución: la arquitectura de software pueden exponer al di-mensiones largo de la cual un sistema se espera queevolucionar. 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ásestimar con precisión los costos de las modificaciones. Más-más, se refiere a las descripciones arquitectónicas separadasacerca de la funcionalidad de un componente de laformas en las que está conectado a ese componente (en-teracts con) otros componentes, de forma clara distin-tinguir entre los componentes y mecanismos queles permiten interactuar. Esta separación permite que uncambiar con más facilidad los mecanismos concontrolar 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 nuevosoportunidades para el análisis, incluyendo consistencia del sistemacomprobació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 deproyectos de vista el logro de un ar de software viabletectura como un hito clave en un entorno industrial suaveproceso 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.

5

3.AYER

En el pasado remoto de hace diez años, la arquitectura en gran medida sead hoc affair.1 descripciones se basó en informales de caja ydiagramas de líneas, que se mantuvieron casi nunca una vez un sistema dese construyó. opciones de arquitectura se hicieron en idio-syncratic moda - generalmente mediante la adaptación de algunos anterioresdiseñ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 trivialesal respecto. Prácticamente no había manera de comprobar que un determinadoimplementació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ó acomprender el papel fundamental que desempeña en el diseño arquitectónicodeterminar el éxito del sistema, sino que también empezaron a reconocerla necesidad de un enfoque más disciplinado. Los primeros autorescomenzó a observar ciertos principios unificadores de la arquitecturadiseño, para llamar a la arquitectura como un campo en la necesidad deatención, y establecer un vocabulario de trabajo paraarquitectos de software. los vendedores de herramientas comenzó a pensarsobre el apoyo explícito para el diseño arquitectónico. IdiomaLos diseñadores empezaron a considerar las notaciones para representante de arquitectura-presentación.

Dentro de la industria, dos tendencias destacó la importancia dearquitectura. El primero fue el reconocimiento de un representante común,ertoire de métodos, técnicas, modelos y lenguajes dela estructuración de los sistemas complejos de software. Por ejemplo, lade caja y línea de diagramas y la prosa de motivos que por lo general

6

acompañar una descripción del sistema de alto nivel a menudo se refieren aorganizaciones como un "gasoducto'', una" pizarra orientadodiseño'', o un sistema de "cliente-servidor.''Aunque estos términosrara vez se asigna definiciones precisas, que permitendiseñadores para describir sistemas complejos con abstraccionesque hacen que el sistema en su conjunto inteligible. Por otra parte, quesiempre contenido semántico significativo sobre los tipos depropiedades de interés, las rutas de espera de la evolución, laparadigma 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 reutilizablestrabaja para las familias de productos. Dicha explotación se basa enla idea de que los aspectos comunes de un conjunto de asociadossistemas pueden ser extraídos de manera que cada nuevo sistema se puedeconstruido a un costo relativamente bajo por "instancias''comparte ladiseño. Ejemplos conocidos son la descomposición de normasció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), cuartoidiomas generación (que explotan los patrones comunesde procesamiento de información de negocio), y la interfaz de usuarioherramientas y marcos (que proporcionan tanto una reutilizablesmarco para el desarrollo de interfaces y sistemas de reutilizablescomponentes, tales como menús y cuadros de diálogo).

4.HOY

Mucho ha cambiado en la última década. Aunque no esamplia 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 yactividad de diseño explícito en el desarrollo de software. Trabajo títulosahora rutinariamente reflejar el papel de arquitecto de software, empresasse basan en revisiones de diseño arquitectónico como puesta en escena crítica puntos, y los arquitectos reconocen la importancia de hacercompensaciones explícita en el espacio de diseño arquitectónico.

Además, la base tecnológica para el diseño arquitectónicoha mejorado de forma espectacular. Tres de los anuncios importantesvancements han sido el desarrollo de la arquitectura de-idiomas descripción y herramientas, la aparición de productoslínea de ingeniería y normas arquitectónicas, y la codifi-

7

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. Lasignificado del diseño no puede ser claro. Informales diagramasno pueden ser formalmente analizado la coherencia, integridad,o corrección. limitaciones de arquitectura asumida en eldiseño inicial no se aplican como un sistema evoluciona. Noson pocas herramientas para ayudar a los diseñadores de arquitectura con sustareas.

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 idiomastienen que ver con el diseño arquitectónico, que cada uno proporciona cier-mantener las capacidades distintivas: Adagio apoya la descripciónde los marcos arquitectónicos para la navegación y aviónicaorientación; Esopo apoya el uso de estilos arquitectónicos; C2compatible 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íapara los diseñadores de tiempo real, software de control de aviónica; Rapidepermite diseños arquitectónicos a simular, y dispone de herramientaspara analizar los resultados de las simulaciones; SADL pro-proporciona una base formal para el refinamiento arquitectónico; UniContiene un compilador de alto nivel para proyectos arquitectónicos que apoyolos puertos de una mezcla de componentes heterogéneos y el conectortipos; 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 haa una investigación de la forma de integrar las notaciones

8

y herramientas en grandes conjuntos. Uno de los resultados ha sidoun lenguaje de intercambio de arquitectura, llamado Acme, queproporciona un marco sencillo para describir la arquitecturaestructura y un mecanismo flexible para la introducción de anotaciónsemántica a que la estructura 18 . (Acme puede ser visto comoel código XML de la descripción arquitectónica.) Acme también apoyala definición de estilos y la ejecución de con diseñolimitaciones 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.

9

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 halas ventajas de proporcionar una indicación de que los profesionales semás probable que esté familiarizado con, y proporcionar una más directaenlazan 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 mejorasen nuestra capacidad para crear líneas de productos dentro de una organizacióny 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-losserie ATED con cada caso particular. Figura 3 ilustra esterelación. En particular, debe haber una por adelantado (yen curso) la inversión en el desarrollo de una arquitectura reutilizableque se pueden crear instancias para cada producto. Otros reutilizablesactivos, tales como componentes, bancos de pruebas, herramientas, etc, por lo general.acompañan.a.esta.

10

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 proveedoresnormas,.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 pormuchos vendedores. En él se establece la definición de estándares de interfazservicios para coordinar el comportamiento de varios semi-simulaciones independientes. Además, la norma pre-escribas requisitos de los componentes de simulación queindicar 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

11

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 deestándar de estilos arquitectónicos. Un estilo arquitectónico típicamenteespecifica 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 especificarvocabulario en el que los componentes de procesamiento de datostransformadores (filtros), y las interacciones son a través de la ordenpreservación de los arroyos (tuberías). Las restricciones pueden incluir laprohibición de los ciclos. supuestos semánticos podrían incluirel hecho de que las tuberías de preservar el orden y que los filtros estén enrevocados.no-determinista.

Otros estilos comunes incluyen arquitecturas de pizarra,arquitecturas cliente-servidor, las arquitecturas basadas en eventos, yarquitecturas basadas en objetos. Cada estilo es apropiado paraciertos propósitos, pero no para otros. Por ejemplo, una tubería-estilo y con filtro probable sería apropiado para una señalaplicació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 (comoasí como sus variantes más específicos del dominio) permite a otrosla adopción de patrones arquitectónicos anteriores como punto de partida.A este respecto, la comunidad de arquitectura ha sido paralelootras 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

12

de construcción de software a menudo obligan a componer sis-temas de las partes que no estaban en una arquitectura uniformela moda. Por ejemplo, se puede combinar una base de datosun solo proveedor, con el middleware de otro, y un usuario eninterterface de un tercero. En estos casos, las partes no siempretrabajar bien juntos - en gran medida, porque hacenhipótesis contradictorias sobre los entornos en los queque fueron diseñados para trabajar 16 . Esto ha llevado al reconocimientoción de la necesidad de identificar las estrategias de arquitectura parapuente desajustes. Aunque estamos lejos de haberentiende bien las formas de detectarlos desajuste tal, y dereparación cuando se descubre, una serie de técnicasSe.han.desarrollado.[11].

5.MAÑANA

¿Y el futuro? Aunque la arquitectura de software essobre una base mucho más sólida que hace una década, no essin embargo, estableció como una disciplina que se enseña y se practicauniversalmente en la industria del software. Una de las razonesesto es simplemente que se necesita tiempo para nuevos enfoques ypercepciones 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 unevolució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 deesta sección cuenta tres de las tendencias más destacadasy 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íticase trata en el desarrollo de sistemas ha sido la decisiónsobre qué partes del sistema para obtener en otros lugares ylo que las piezas para construir en casa. Externamente adquiridos partestienen la ventaja de ahorrar tiempo de desarrollo. Pero quetambién tienen las desventajas de satisfacer a menudo incompleta-

13

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 softwaretura. 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 dela respuesta. componente de hoy en día las tecnologías de trabajo en unarelativamente bajo nivel de abstracción arquitectónica - esencialmente ael nivel de llamada a procedimiento entre los objetos. Para obtener másintegració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, uncambio 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ídoanteriores) en la promoción de componibilidad. Por lo tanto, la tendencia hacia la.normas arquitectónicas, se ha señalado, es probable que se conviertaaún.más.pronunciada.

14

En segundo lugar, esta tendencia está conduciendo a un nuevo software subcontrata ING procesos. Cuando la integración es el tema crítico, podemosEsperamos que el software contratado externamente se llevará a cabo amucho más altos estándares de cumplimiento de arquitectura. Enmuchos casos las normas se comerciales o gobiernonormas ambientales. En otros, es probable que los sub-contratistastendrá 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 productosque 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 aceptablepara tener en casa, descripciones arquitectura idiosincrásicay herramientas. Esto ha llevado a muchos a adoptar lenguajes como UMLy 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ómputomodelo a un modelo centrado en la red. equipo tradicionalcentros de uso en los ordenadores, el uso de aplicaciones y datos locales queson instalados y actualizados de forma manual. Cada vez más, el PCy 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 essorprendente, 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. Espermite el acceso a un amplio conjunto de la informática y la informaciónservicios de recuperación a través de computadoras portátiles que pueden serutilizado casi en cualquier lugar (en la oficina, casa, coche, y factoreshistoria). Se promueve la movilidad de los usuarios mediante un acceso ubicuoa.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 comosistemas cerrados, desarrollado y operado bajo el control delas instituciones individuales. Los componentes pueden ser constitutivosadquiridos de fuentes externas, pero cuando se incorporen en unsistema que están bajo el control del diseñador del sistema.Arquitecturas de estos sistemas están completamente estática

15

- 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 generalizadaa través de redes, los sistemas no pueden tener tales centralizadade control. El Internet es un ejemplo de un sistema abiertoTEM: Es mínimamente normalizado, principalmente a nivel de laprotocolos, direcciones y representaciones que permiten a los indivi-sitios individuales para interactuar. Se admite una variación considerabletanto en el hardware que se encuentra por debajo de estos estándares y elaplicaciones que están por encima. No existe una autoridad central paracontrol o validación. Los sitios individuales son independientementeadministrados. 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 quemuchos 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ícitoinvocació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, oevaluación. Estos recursos son desarrollados de forma independientey de manera independiente apoyado, sino que incluso puede ser transitoria.

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

16

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, esdifícil de automatizar la actividad de selección y la composicióndebido a la escasa información sobre el carácter de los serviciosy 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 siun conjunto de componentes va a funcionar bien (o en absoluto) ysi su funcionalidad combinada es lo que necesita.Por otra parte, existen muchos recursos útiles, pero no puede serintegra 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 delocales 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ápidocrecimiento de Internet, un número creciente de usuarios están encondiciones de montaje y servicios a medida. Estos usuarios puedenuna experiencia técnica mínima, y sin embargo va a querer aúnsólidas garantías de que las partes trabajarán conjuntamente en lamanera.que.ellos.esperan.

5.3.computación . ubicua

Una tendencia relacionada tercero es hacia la computación omnipresente enque el universo informático está poblado por una variable ricosETY de dispositivos informáticos heterogéneos: tostadores de pan, casasistemas de calefacción, sistemas de entretenimiento, los coches inteligentes, etc.

17

Esta tendencia puede dar lugar a una explosión en el número dedispositivos en nuestro entorno local - de decenas de de-vicios a cientos o miles de dispositivos. Además, estosdispositivos es probable que sean muy heterogéneos, que requieren espe-consideraciones sociales en términos de sus recursos físicos ypoder.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á dela movilidad del usuario. En la actualidad, nuestros entornos de computación sonconfigurar manualmente y gestionados explícitamente por el usuario.Si bien esto puede ser apropiado para entornos en los quesólo tenemos unos pocos, relativamente estable, los dispositivos de computación (Como un par de PCs y portátiles), que no escala aambientes con cientos de dispositivos. Por lo tanto, debeencontrar arquitecturas que proporcionan mucho más automatizado con-control sobre la gestión de los servicios de cómputo, yque permiten a los usuarios moverse fácilmente de un ambiente aotro.

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 seuna serie de importantes retos que tendrá que ser ad-vestidos. Muchas de las soluciones a estos retos seque pueden surgir como una consecuencia natural de la difusióny 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.