lenguaje de descripción de arquitectura

Los lenguajes de descripción de arquitectura ( ADL, por sus siglas en inglés) se utilizan en diversas disciplinas: ingeniería de sistemas , ingeniería de software y modelado e ingeniería empresarial .

La comunidad de ingeniería de sistemas utiliza un lenguaje de descripción de arquitectura como lenguaje y/o modelo conceptual para describir y representar arquitecturas de sistemas .

La comunidad de ingeniería de software utiliza un lenguaje de descripción de arquitectura (ADL, por sus siglas en inglés) como lenguaje informático para crear una descripción de la arquitectura de un software . En el caso de una arquitectura técnica , esta debe comunicarse a los desarrolladores de software; una arquitectura funcional se comunica a diversos interesados ​​y usuarios. Algunos ADL desarrollados son: Acme (desarrollado por CMU ), AADL (estandarizado por la SAE ), C2 (desarrollado por UCI ), SBC-ADL (desarrollado por la Universidad Nacional Sun Yat-sen ), Darwin (desarrollado por el Imperial College de Londres ) y Wright (desarrollado por CMU ).

El documento ISO/IEC/IEEE 42010 ^{[ 1 ]} , Ingeniería de sistemas y software: descripción de la arquitectura , define un lenguaje de descripción de arquitectura como "cualquier forma de expresión para su uso en descripciones de arquitectura" y especifica los requisitos mínimos sobre los ADL .

La comunidad de modelado e ingeniería empresarial también ha desarrollado lenguajes de descripción de arquitectura adaptados al nivel empresarial. Algunos ejemplos son ArchiMate (ahora un estándar de The Open Group ), DEMO y ABACUS (desarrollado por la Universidad Tecnológica de Sídney ). Estos lenguajes no necesariamente hacen referencia a componentes de software, etc. Sin embargo, la mayoría se refiere a la arquitectura de la aplicación como la arquitectura que se comunica a los ingenieros de software.

La mayor parte del texto que aparece a continuación se refiere principalmente a la perspectiva de la comunidad de ingeniería de software.

Una notación estándar (ADL) para representar arquitecturas facilita la comunicación, la incorporación de las decisiones de diseño iniciales y la creación de una abstracción transferible del sistema. Anteriormente, las arquitecturas se representaban principalmente mediante diagramas de cajas y líneas, anotados con información como la naturaleza del componente, sus propiedades, la semántica de las conexiones y el comportamiento general del sistema. Las ADL surgen de un enfoque lingüístico para la representación formal de arquitecturas y, por lo tanto, subsanan sus deficiencias. Además, las ADL sofisticadas permiten el análisis temprano y la comprobación de la viabilidad de las decisiones de diseño arquitectónico.

Los lenguajes de descripción arquitectónica (ADL, por sus siglas en inglés) se han clasificado en tres grandes categorías: dibujos informales de cajas y líneas, lenguaje formal de descripción arquitectónica y notaciones basadas en UML ( lenguaje unificado de modelado ).

Los diagramas de cajas y líneas han sido durante mucho tiempo el medio predominante para describir arquitecturas de software. Si bien proporcionaban documentación útil, el nivel de informalidad limitaba la utilidad de la descripción de la arquitectura. Se requería una forma más rigurosa de describir las arquitecturas de software. Citando a Allen y Garlan (1997), ^{[ 2 ]} "si bien estas descripciones [de cajas y líneas] pueden proporcionar documentación útil, el nivel actual de informalidad limita su utilidad. Dado que generalmente es impreciso lo que se entiende por dichas descripciones arquitectónicas, puede ser imposible analizar una arquitectura para verificar su coherencia o determinar propiedades no triviales de la misma. Además, no hay forma de comprobar que la implementación de un sistema sea fiel a su diseño arquitectónico". Perry y Wolf (1992), ^{[ 3 ]} llegan a una conclusión similar , donde afirman que: "Además de proporcionar documentación clara y precisa, el propósito principal de las especificaciones es proporcionar un análisis automatizado de los documentos y exponer diversos tipos de problemas que de otro modo pasarían desapercibidos".

Desde entonces, se ha llevado a cabo una línea de investigación sobre lenguajes formales para la descripción de arquitecturas de software. Se han propuesto decenas de ADL formales, cada uno caracterizado por diferentes elementos arquitectónicos conceptuales, sintaxis o semántica diferentes, centrándose en un dominio operativo específico o siendo adecuados únicamente para diferentes técnicas de análisis. Por ejemplo, se han presentado ADL específicos de dominio para tratar con sistemas embebidos y en tiempo real (como AADL, ^{[ 4 ]} EAST-ADL, ^{[ 5 ]} y EADL ^{[ 6 ]} ), aplicaciones de bucle de control (DiaSpec ^{[ 7 ]} ), arquitecturas de líneas de productos (Koala ^{[ 8 ]} ) y sistemas dinámicos (Π-ADL ^{[ 9 ]} )). Se han propuesto ADL específicos de análisis para tratar la disponibilidad, confiabilidad, seguridad, consumo de recursos, calidad de datos y análisis de rendimiento en tiempo real (AADL, análisis de comportamiento (Fractal ^{[ 10 ]} )) y análisis de confiabilidad (TADL ^{[ 11 ]} ).

Sin embargo, estos esfuerzos no han logrado la adopción deseada por parte de la práctica industrial. Algunas razones para esta falta de adopción industrial han sido analizadas por Woods y Hilliard, ^{[ 12 ]} Pandey, ^{[ 13 ]} Clements, ^{[ 14 ]} y otros: los ADL formales rara vez se han integrado en el ciclo de vida del software, rara vez son compatibles con herramientas maduras, están escasamente documentados, se centran en necesidades muy específicas y no dejan espacio para extensiones que permitan la adición de nuevas características.

Para superar algunas de esas limitaciones, UML se ha señalado como un posible sucesor de los ADL existentes. Se han presentado numerosas propuestas para utilizar o extender UML con el fin de modelar de forma más adecuada las arquitecturas de software. ^{[ 15 ] [ 16 ] [ 17 ]}

Un estudio de 2013 ^{[ 18 ]} encontró que los profesionales estaban generalmente satisfechos con las capacidades de diseño de los ADLS que utilizaban, pero tenían varias preocupaciones importantes con ellos: carecían de características de análisis y la capacidad de definir propiedades extrafuncionales; los que se utilizaban en la práctica provenían principalmente del desarrollo industrial en lugar de la investigación académica; necesitaban más formalidad y mejor usabilidad.

Existe una gran variedad de lenguajes de descripción de arquitectura (ADL, por sus siglas en inglés) desarrollados por grupos académicos e industriales. Muchos lenguajes no fueron concebidos como ADL, pero resultan adecuados para representar y analizar una arquitectura. En principio, los ADL se diferencian de los lenguajes de requisitos, ya que los ADL se basan en el espacio de soluciones , mientras que los requisitos describen espacios de problemas. También se diferencian de los lenguajes de programación, porque los ADL no vinculan abstracciones arquitectónicas a soluciones puntuales específicas. Los lenguajes de modelado representan comportamientos, mientras que los ADL se centran en la representación de componentes. Sin embargo, existen lenguajes de modelado específicos de dominio (DSML, por sus siglas en inglés) que se centran en la representación de componentes.

Requisitos mínimos

El idioma debe:

• Debe ser adecuado para comunicar una arquitectura a todas las partes interesadas.
• Apoyar las tareas de creación, refinamiento y validación de la arquitectura.
• Proporcionar una base para una implementación posterior, por lo que debe poder agregar información a la especificación ADL para permitir que la especificación final del sistema se derive de la ADL.
• Ofrecer la capacidad de representar la mayoría de los estilos arquitectónicos comunes.
• Ofrecer soporte para capacidades analíticas o proporcionar implementaciones de prototipos de generación rápida.

Las actividades de la vida diaria (AVD) tienen en común:

• Sintaxis gráfica con una forma textual frecuente y una sintaxis y semántica definidas formalmente.
• Características para el modelado de sistemas distribuidos
• Escaso soporte para capturar información de diseño, excepto a través de mecanismos de anotación de propósito general.
• Capacidad para representar niveles jerárquicos de detalle, incluyendo la creación de subestructuras mediante la instanciación de plantillas.

Las actividades de la vida diaria (AVD) difieren en su capacidad para:

• Gestionar elementos en tiempo real, como plazos y prioridades de tareas, a nivel arquitectónico.
• Admite la especificación de diferentes estilos arquitectónicos. Pocos manejan la herencia de clases orientada a objetos o arquitecturas dinámicas.
• Apoyar el análisis de la arquitectura
• Gestionar diferentes instancias de la misma arquitectura, en relación con las arquitecturas de la línea de productos.

La comunidad ADL generalmente coincide en que la arquitectura de software es un conjunto de componentes y las conexiones entre ellos. Pero existen diferentes tipos de arquitecturas, como:

En el contexto de los sistemas de software, la arquitectura se divide, a grandes rasgos, en categorías principales: arquitectura de software, arquitectura de redes y arquitectura de sistemas. Dentro de cada una de estas categorías, existe una distinción tangible, aunque difusa, entre arquitectura y diseño. Para establecer esta distinción de la forma más universal y clara posible, conviene considerar el diseño como un sustantivo en lugar de un verbo, de modo que la comparación se establezca entre dos sustantivos.

El diseño es la abstracción y especificación de patrones y órganos de funcionalidad que se han implementado o se implementarán. La arquitectura es un nivel de abstracción más elevado y de granularidad más gruesa. En consecuencia, la arquitectura también es de naturaleza más topológica (es decir, la estructura general y la relación entre componentes) que el diseño (es decir, los detalles específicos y la implementación), ya que especifica dónde se encuentran los componentes principales y cómo se relacionan entre sí. La arquitectura se centra en la partición de las principales regiones de funcionalidad en componentes de alto nivel, su ubicación física o virtual, qué componentes comerciales pueden emplearse eficazmente, en general qué interfaces expondrá cada componente, qué protocolos se emplearán entre ellos y qué prácticas y patrones de alto nivel pueden satisfacer mejor la extensibilidad , la mantenibilidad , la fiabilidad, la durabilidad, la escalabilidad y otros objetivos no funcionales. El diseño es un detalle de estas decisiones y una aclaración más concreta de cómo se cumplirán los requisitos funcionales mediante la delegación de partes de esa funcionalidad a componentes más granulares y cómo estos componentes más pequeños se organizarán dentro de los más grandes.

Con frecuencia, una parte de la arquitectura se define durante la conceptualización de una aplicación, sistema o red, y puede aparecer en las secciones no funcionales de la documentación de requisitos. Tradicionalmente, el diseño no se especifica en los requisitos, sino que se deriva de ellos.

El proceso de definir una arquitectura puede implicar heurísticas, adquiridas por el arquitecto o el equipo de arquitectura a través de la experiencia en el ámbito. Al igual que el diseño, la arquitectura suele evolucionar mediante una serie de iteraciones, y así como la validez de un diseño de alto nivel se pone a prueba durante el diseño e implementación de bajo nivel, la validez de una arquitectura se pone a prueba durante la especificación de un diseño de alto nivel. En ambos casos, si la validez de la especificación se cuestiona durante la fase de detalle, puede ser necesaria una nueva iteración, ya sea de la arquitectura o del diseño, según corresponda.

En resumen, las principales diferencias entre arquitectura y diseño radican en el nivel de detalle y la abstracción, y (por consiguiente) en la cronología. (Generalmente, la arquitectura precede al diseño, aunque la superposición y la iteración circular son habituales).

• ArchiMate
• Lenguaje de análisis y diseño arquitectónico
• Modelo C4 (software)
• C4InterFlow
• Darwin (ADL)
• ESTE-ADL
• Wright (ADL)
• Sistema ADL

• Enfoque académico
  • centrarse en la evaluación analítica de modelos arquitectónicos
  • modelos individuales
  • notaciones de modelado rigurosas
  • potentes técnicas de análisis
  • profundidad sobre anchura
  • soluciones para fines especiales
• Enfoque industrial
  • centrarse en una amplia gama de cuestiones de desarrollo.
  • familias de modelos
  • La practicidad por encima del rigor
  • La arquitectura como visión general del desarrollo.
  • amplitud sobre profundidad
  • soluciones de uso general

• AADL
• Darwin
• Lenguaje de scripting
• Sistema ADL
• lenguaje de descripción de hardware

• Medvidovic, N.; Taylor, RN (enero de 2000). "Un marco de clasificación y comparación para lenguajes de descripción de arquitectura de software". IEEE Transactions on Software Engineering . 26 (1): 70– 93. Bibcode : 2000ITSEn..26...70M . doi : 10.1109/32.825767 .
• Malavolta, Ivano; Lago, Patricia; Muccini, Henry; Pelliccione, Patrizio; Tang, Antony (2013). "Lo que la industria necesita de los lenguajes arquitectónicos: una revisión". IEEE Transactions on Software Engineering . 39 (6): 869– 891. Bibcode : 2013ITSEn..39..869M . doi : 10.1109/TSE.2012.74 . S2CID 6383726 . 
• Lenguajes de descripción arquitectónica // Universidad de Mälardalen
• Clements, PC (1996). «Un estudio de los lenguajes de descripción de arquitectura» (PDF) . Actas del 8.º Taller Internacional sobre Especificación y Diseño de Software . págs. 16-25 . doi : 10.1109/IWSSD.1996.501143 . ISBN  0-8186-7361-3. S2CID 7307554 . Archivado del original (PDF) el 24-12-2013. 
• ÁBACO
• CUMBRE
• ADML
• Esopo
• AO-ADL
• ArchiMate Un ejemplo de ADL para arquitectura empresarial
• ByADL (Construye tu ADL) - Universidad de L'Aquila
• C2 SADL
• DAOP-ADL
• DEMO Otro ejemplo de una arquitectura empresarial ADL
• DiaSpec es un enfoque y una herramienta para generar un marco distribuido a partir de una arquitectura de software.
• Malavolta, I.; Muccini, H.; Pelliccione, P.; Tamburri, D. (enero-febrero de 2010). "Provisión de interoperabilidad de lenguajes y herramientas arquitectónicas a través de tecnologías de transformación de modelos". IEEE Transactions on Software Engineering . 36 (1): 119– 140. Bibcode : 2010ITSEn..36..119M . doi : 10.1109/TSE.2009.51 . S2CID 6825192 . DOBLEMENTE
• Rápido
• SSEP
• Unicon
• Wright