Los lenguajes de descripción de arquitectura ( ADL ) se utilizan en varias 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 como lenguaje informático para crear una descripción de una arquitectura de software . En el caso de la denominada arquitectura técnica , la arquitectura debe comunicarse a los desarrolladores de software; una arquitectura funcional se comunica a varias partes interesadas y usuarios. Algunas ADL que se han desarrollado 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 Imperial College Londres ) y Wright (desarrollado por CMU ).
El documento ISO/IEC/IEEE 42010 [1] , Ingeniería de sistemas y software: descripción de 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 de las ADL .
La comunidad de ingeniería y modelado empresarial también ha desarrollado lenguajes de descripción de arquitectura pensados para el nivel empresarial. Los ejemplos incluyen ArchiMate (ahora un estándar de The Open Group ), DEMO , ABACUS (desarrollado por la Universidad de Tecnología de Sydney ). Estos lenguajes no necesariamente se refieren a componentes de software, etc. Sin embargo, la mayoría de ellos se refieren a una arquitectura de aplicación como la arquitectura que se comunica a los ingenieros de software.
La mayor parte de lo escrito 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 ayuda a promover la comunicación mutua, la materialización de decisiones tempranas de diseño y la creación de una abstracción transferible de un sistema. En el pasado, las arquitecturas se representaban en gran medida mediante dibujos de cuadros y líneas anotados con aspectos como la naturaleza del componente, las propiedades, la semántica de las conexiones y el comportamiento general del sistema. Las ADL son el resultado de un enfoque lingüístico de la representación formal de las arquitecturas y, como tales, abordan sus deficiencias. También es importante que las ADL sofisticadas permitan un análisis temprano y pruebas de viabilidad de las decisiones de diseño arquitectónico.
Los ADL se han clasificado en tres categorías amplias: dibujos informales de caja y línea, lenguaje de descripción de arquitectura formal y notaciones basadas en UML ( lenguaje de modelado unificado ).
El método de caja y línea ha sido durante mucho tiempo el medio más predominante para describir las SA. Si bien proporcionó documentación útil, el nivel de informalidad limitó la utilidad de la descripción de la arquitectura. Se necesitaba una forma más rigurosa de describir las SA. Citando a Allen y Garlan (1997), [2] "si bien estas descripciones [de recuadros 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 tales descripciones arquitectónicas, Puede ser imposible analizar la coherencia de una arquitectura o determinar sus propiedades no triviales. Además, no hay forma de comprobar que la implementación de un sistema es fiel a su diseño arquitectónico. Perry y Wolf (1992), [3] llegan a una conclusión similar : "Además de proporcionar documentación clara y precisa, el objetivo principal de las especificaciones es proporcionar un análisis automatizado de los documentos y exponer diversos tipos de problemas que De lo contrario pasaría desapercibido."
Desde entonces se ha llevado a cabo una línea de investigación sobre lenguajes formales para la descripción de SA. Se han propuesto decenas de ADL formales, cada una caracterizada por diferentes elementos arquitectónicos conceptuales, diferente sintaxis o semántica, centrándose en un dominio operativo específico o solo adecuado para diferentes técnicas de análisis. Por ejemplo, se han presentado ADL de dominio específico para tratar con sistemas integrados 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 de análisis específicos para abordar la disponibilidad, la confiabilidad, la seguridad, el consumo de recursos, la calidad de los datos y el 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 tenido la adopción deseada por parte de la práctica industrial. Woods y Hilliard, [12] Pandey, [13] Clements, [14] y otros han analizado algunas de las razones de esta falta de adopción por parte de la industria : las ADL formales rara vez se han integrado en el ciclo de vida del software, rara vez están respaldadas por Herramientas maduras, escasamente documentadas, centradas en necesidades muy específicas y que no dejan espacio para extensiones que permitan añadir nuevas funcionalidades.
Como forma de superar algunas de esas limitaciones, se ha señalado a UML como un posible sucesor de las ADL existentes. Se han presentado muchas propuestas para utilizar o ampliar UML para modelar arquitecturas de software de forma más adecuada. [15] [16]
Un estudio de 2013 [17] encontró que los profesionales estaban generalmente satisfechos con las capacidades de diseño del ADLS que utilizaban, pero tenían varias preocupaciones importantes con respecto a ellas: carecían de funciones de análisis y de la capacidad de definir propiedades extrafuncionales; los utilizados en la práctica procedían en su mayoría del desarrollo industrial más que de la investigación académica; necesitaban más formalidad y mejor usabilidad.
Existe una gran variedad de AVD desarrolladas por grupos académicos o industriales. Muchos lenguajes no estaban pensados para ser ADL, pero resultan adecuados para representar y analizar una arquitectura. En principio, las ADL se diferencian de los lenguajes de requisitos porque las ADL tienen sus raíces en el espacio de la solución , mientras que los requisitos describen espacios de problemas. 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 las ADL se centran en la representación de componentes. Sin embargo, existen lenguajes de modelado de dominio específico (DSML) que se centran en la representación de componentes.
Requisitos mínimos
El idioma debe:
Las AVD tienen en común:
Las AVD se diferencian en su capacidad para:
La comunidad ADL generalmente está de acuerdo en que la Arquitectura de Software es un conjunto de componentes y las conexiones entre ellos. Pero existen diferentes tipos de arquitecturas como:
La mayoría de las ADL implementan una arquitectura de conexión de interfaz.
La arquitectura, en el contexto de los sistemas de software, se divide a grandes rasgos en categorías, principalmente arquitectura de software, arquitectura de red y arquitectura de sistemas. Dentro de cada una de estas categorías, existe una distinción tangible pero confusa entre arquitectura y diseño. Para trazar esta distinción de la manera más universal y clara posible, es mejor considerar diseño como un sustantivo y no como un verbo, de modo que la comparación sea 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 grado superior tanto en abstracción como en granularidad. En consecuencia, la arquitectura también es de naturaleza más topológica que el diseño, en el sentido de 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, dónde residirán física o virtualmente, qué componentes disponibles en el mercado se pueden emplear de manera efectiva, en general qué interfaces expondrá cada componente, qué protocolos se emplearán entre ellos, y qué prácticas y patrones de alto nivel pueden cumplir mejor con la extensibilidad , mantenibilidad , confiabilidad, durabilidad, escalabilidad y otros objetivos no funcionales. El diseño es un detalle de estas elecciones y una clarificación más concreta de cómo se cumplirán los requisitos funcionales mediante la delegación de piezas 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.
A menudo, una parte de la arquitectura se realiza 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. Canónicamente, el diseño no se especifica en los requisitos, sino que más bien está impulsado por ellos.
El proceso de definición de una arquitectura puede implicar heurísticas, adquiridas por el arquitecto o el equipo de arquitectos a través de la experiencia dentro del dominio. Al igual que con el diseño, la arquitectura a menudo evoluciona a través de una serie de iteraciones, y así como la sabiduría de un diseño de alto nivel a menudo se prueba cuando ocurre el diseño y la implementación de bajo nivel, la sabiduría de una arquitectura se prueba durante la especificación de un diseño de alto nivel. En ambos casos, si se cuestiona la sabiduría de la especificación durante el detalle, puede ser necesaria otra iteración de la arquitectura o del diseño, según sea el caso.
En resumen, las principales diferencias entre arquitectura y diseño son de granularidad y abstracción y (en consecuencia) de cronología. (La arquitectura generalmente precede al diseño, aunque la superposición y la iteración circular son una realidad común).
{{cite web}}: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace )