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 una denominada arquitectura técnica , la arquitectura debe comunicarse a los desarrolladores de software; una arquitectura funcional se comunica a varias partes interesadas y usuarios. Algunos ADL que se han desarrollado son: Acme (desarrollado por CMU ), AADL (estandarizado por la SAE ), C2 (desarrollado por UCI ), SBC-ADL (desarrollado por National Sun Yat-Sen University ), Darwin (desarrollado por Imperial College London ) 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 la arquitectura como "cualquier forma de expresión para su uso en descripciones de la arquitectura" y especifica los requisitos mínimos de los ADL .
La comunidad de ingeniería y modelado empresarial también ha desarrollado lenguajes de descripción de arquitectura pensados para el nivel empresarial. Algunos ejemplos son ArchiMate (ahora un estándar de The Open Group ), DEMO y ABACUS (desarrollado por la Universidad de Tecnología de Sídney ). Estos lenguajes no necesariamente hacen referencia a componentes de software, etc. Sin embargo, la mayoría de ellos hacen referencia 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 de diseño tempranas 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 cajas y líneas anotados con elementos 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 tal, abordan sus deficiencias. También es importante destacar que las ADL sofisticadas permiten un análisis temprano y la prueba de viabilidad de las decisiones de diseño arquitectónico.
Los ADL se han clasificado en tres grandes categorías: dibujos informales de cajas y líneas, lenguaje de descripción de arquitectura formal y notaciones basadas en UML ( lenguaje de modelado unificado ).
Durante mucho tiempo, el método de cajas y líneas ha sido el método predominante para describir las arquitecturas de sistemas. Si bien proporciona documentación útil, el nivel de informalidad limita la utilidad de la descripción de la arquitectura. Se requería una forma más rigurosa de describir las arquitecturas de sistemas. 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 no se sabe con precisión qué se entiende por tales descripciones arquitectónicas, puede resultar imposible analizar una arquitectura para comprobar 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 , y 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 SA. Se han propuesto decenas de ADL formales, cada uno caracterizado por diferentes elementos arquitectónicos conceptuales, diferente sintaxis o semántica, centrados en un dominio operativo específico, o solo adecuados para diferentes técnicas de análisis. Por ejemplo, se han presentado ADL específicos del dominio 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ínea de productos (Koala [8] ) y sistemas dinámicos (Π-ADL [9] )). Se han propuesto ADL específicos de análisis para tratar con 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 tenido la adopción deseada por parte de la industria. 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 cuentan con el apoyo de herramientas maduras, están escasamente documentadas, se centran en necesidades muy específicas y no dejan espacio para extensiones que permitan la incorporación de nuevas funciones.
Como forma de superar algunas de esas limitaciones, se ha señalado a UML como un posible sucesor de los 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 de los ADLS que utilizaban, pero tenían varias preocupaciones importantes con ellos: carecían de características de análisis y de la capacidad de definir propiedades extrafuncionales; los utilizados en la práctica en su mayoría se originaron a partir del desarrollo industrial en lugar de la investigación académica; necesitaban más formalidad y mejor usabilidad.
Existe una gran variedad de lenguajes ADL desarrollados por grupos académicos o industriales. Muchos lenguajes no fueron pensados para ser ADL, pero resultan ser adecuados para representar y analizar una arquitectura. En principio, los ADL se diferencian de los lenguajes de requisitos, porque los ADL tienen su raíz en el espacio de soluciones , 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 los ADL se centran en la representación de componentes. Sin embargo, existen lenguajes de modelado específicos del dominio (DSML) que se centran en la representación de componentes.
Requisitos mínimos
El idioma debe:
Las actividades de la vida diaria tienen en común:
Las actividades de la vida diaria se diferencian en su capacidad para:
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:
La mayoría de los ADL implementan una arquitectura de conexión de interfaz.
La arquitectura, en el contexto de los sistemas de software, se divide en categorías, principalmente arquitectura de software, arquitectura de redes y arquitectura de sistemas. Dentro de cada una de estas categorías, existe una distinción tangible pero difusa entre arquitectura y diseño. Para trazar esta distinción de la forma más universal y clara posible, es mejor considerar el diseño como un sustantivo en lugar de 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 han sido o serán implementados. 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 listos para usar 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 , la capacidad de mantenimiento , la confiabilidad, la durabilidad, la escalabilidad y otros objetivos no funcionales. El diseño es un detalle de estas opciones y una aclaración más concreta de cómo se cumplirán los requisitos funcionales a través de la delegación de partes de esa funcionalidad a componentes más granulares y cómo se organizarán estos componentes más pequeños dentro de los más grandes.
A menudo, una parte de la arquitectura se realiza durante la conceptualización de una aplicación, un sistema o una red y puede aparecer en las secciones no funcionales de la documentación de requisitos. En teoría, el diseño no se especifica en los requisitos, sino que 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 pone a prueba cuando se produce un diseño e implementación de bajo nivel, la sabiduría de una arquitectura se pone a prueba durante la especificación de un diseño de alto nivel. En ambos casos, si la sabiduría de la especificación se pone en duda durante la elaboración de los detalles, puede ser necesaria otra iteración de la arquitectura o del diseño, según sea el caso.
En resumen, las principales diferencias entre la arquitectura y el 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}}: CS1 maint: nombres numéricos: lista de autores ( enlace )