Lenguaje de descripción de la arquitectura.

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar
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 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).

Descripción general

El documento ISO/IEC/IEEE 42010, Ingeniería de software y sistemas: 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 requisitos mínimos sobre 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.

Historia

Las ADL se han clasificado en tres categorías amplias: dibujos informales de cuadros y líneas, 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 AS. Si bien proporciona documentación útil, el nivel de la 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), “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 resultar 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 sea fiel a su diseño arquitectónico." Perry y Wolf (1992) 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 varios tipos de problemas que pueden surgir”. 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, EAST-ADL y EADL), aplicaciones de bucle de control (DiaSpec), arquitecturas de línea de productos (Koala) y sistemas dinámicos. (Π-ADL)). 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)) y el análisis de confiabilidad (TADL).

Sin embargo, estos esfuerzos no han tenido la adopción deseada por parte de la práctica industrial. Woods y Hilliard, Pandey, Clements 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 respaldo de herramientas maduras, escasamente documentadas y que se centran en objetivos muy específicos. necesidades específicas y no deja espacio para extensiones que permitan agregar nuevas funciones.

Como una forma de superar algunas de esas limitaciones, se ha indicado que UML es 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.

Un estudio de 2013 encontró que los profesionales estaban generalmente satisfechos con las capacidades de diseño del ADLS que usaban, pero tenían varias preocupaciones importantes: 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.

Características

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 se basan en el espacio de la solución, mientras que los requisitos describen espacios del problema. 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:

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

Las AVD tienen en común:

  • Sintaxis gráfica con frecuencia una forma textual y una sintaxis formalmente definida y semántica
  • Características para modelar sistemas distribuidos
  • Poco apoyo para captar información de diseño, excepto mediante mecanismos de anotación de propósito general
  • Capacidad para representar niveles jerárquicos de detalle incluyendo la creación de subestructuras mediante plantillas instantáneas

Las AVD se diferencian en su capacidad para:

  • Maneja construcciones en tiempo real, como plazos y prioridades de tarea, a nivel arquitectónico
  • Apoyar la especificación de diferentes estilos arquitectónicos. Pocas empuñaduras orientadas hacia el objeto herencia de clase o arquitecturas dinámicas
  • Apoyar el análisis de la arquitectura
  • Maneja diferentes instantáneas de la misma arquitectura, en relación con las arquitecturas de línea de productos

Elementos positivos de las AVD

  • ADLs son una forma formal de representar la arquitectura
  • ADLs are intended to be both human and machine readable
  • ADAS apoyan la descripción de un sistema a un nivel más alto que antes posible
  • Los ADL permiten el análisis y evaluación de arquitecturas, para la integridad, consistencia, ambigüedad y rendimiento
  • ADLs puede soportar la generación automática de sistemas de software

Elementos negativos de las AVD

  • No hay acuerdo universal sobre lo que deben representar los ADL, especialmente en lo que respecta al comportamiento de la arquitectura
  • Las representaciones actualmente en uso son relativamente difíciles de analizar y no cuentan con el apoyo de herramientas comerciales
  • La mayoría de los ADL tienden a ser muy optimizados verticalmente hacia un tipo particular de análisis

Conceptos comunes de arquitectura

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:

Arquitectura de conexión de objetos

  • La configuración consiste en las interfaces y conexiones de un sistema orientado al objeto
  • Las interfaces especifican las características que deben proporcionar los módulos conformes a una interfaz
  • Conexiones representadas por interfaces junto con el gráfico de llamadas
  • Conformance usually enforced by the programming language
    • Descomposición — asociando interfaces con módulos únicos
    • Conformación de la interfaz — comprobación estática de reglas sintácticas
    • Integridad de la comunicación: visibilidad entre módulos

Arquitectura de conexión de interfaz

  • Amplia el papel de las interfaces y conexiones
    • Las interfaces especifican las características "requeridas" y "provididas"
    • Las conexiones se definen entre las características "requeridas" y las características "provistas"
  • Consta de interfaces, conexiones y limitaciones
    • Limita el comportamiento de interfaces y conexiones en una arquitectura
    • Limita en un mapa de arquitectura a los requisitos para un sistema

La mayoría de los ADLs implementan una arquitectura de conexión de interfaz.

Arquitectura versus diseño

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 opciones 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 las de granularidad y abstracción y (en consecuencia) la cronología. (La arquitectura generalmente precede al diseño, aunque la superposición y la iteración circular son una realidad común).

Ejemplos

  • ArchiMate
  • Análisis de arquitectura y lenguaje de diseño
  • Modelo C4 (software)
  • Darwin (ADL)
  • EAST-ADL
  • Wright (ADL)

Aproximaciones a la Arquitectura

  • Enfoque académico
    • enfoque en la evaluación analítica de modelos arquitectónicos
    • modelos individuales
    • rigurosas notaciones de modelado
    • poderosas técnicas de análisis
    • profundidad sobre la anchura
    • soluciones para fines especiales
  • Enfoque industrial
    • centrarse en una amplia gama de cuestiones de desarrollo
    • familias de modelos
    • practicidad sobre el rigor
    • arquitectura como la gran imagen en el desarrollo
    • en profundidad
    • soluciones para fines generales

Contenido relacionado

Historia de la cámara

La historia de la cámara comenzó incluso antes de la introducción de la fotografía. Las cámaras evolucionaron desde la cámara oscura a través de muchas...

Precisión y exactitud

En un conjunto de medidas, la exactitud es la cercanía de las medidas a un valor específico, mientras que la precisión es la cercanía de las medidas entre...

Tubo de vacío

Un tubo de vacío, tubo de electrones o válvula termoiónica, es un dispositivo que controla el flujo de corriente eléctrica en un alto vacío entre...
Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save