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 ingenieros 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 ingenieros de software utiliza un lenguaje de descripción de arquitectura como lenguaje de computadora 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; se comunica una arquitectura funcional 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 National Sun Yat-Sen University ), Darwin (desarrollado por Imperial College London ) y Wright (desarrollado por CMU ).
Descripción general
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 de las ADL .
La comunidad de ingeniería y modelado empresarial también ha desarrollado lenguajes de descripción de arquitectura para las empresas. 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 se refieren necesariamente a componentes de software, etc. La mayoría de ellos, sin embargo, 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 ingenieros de software.
Una notación estándar (ADL) para representar arquitecturas ayuda a promover la comunicación mutua, la incorporación de decisiones de diseño tempranas y la creación de una abstracción transferible de un sistema. Las arquitecturas del pasado estaban representadas en gran medida por dibujos de recuadros y líneas anotados con cosas 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 arquitecturas y, como tales, abordan sus deficiencias. También es importante que las ADL sofisticadas permitan el análisis temprano y las 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 caja y línea, lenguaje de descripción de arquitectura formal y notaciones basadas en UML ( Lenguaje de modelado unificado ).
El recuadro y la línea han sido durante mucho tiempo el medio más predominante para describir las SA. Si bien proporciona documentación útil, el nivel de informalidad limitó la utilidad de la descripción de la arquitectura. Se requería 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 en general es impreciso lo que se entiende por tales descripciones arquitectónicas, puede resultar imposible analizar la coherencia de una arquitectura o determinar propiedades no triviales de la misma. Además, no hay forma de comprobar que la implementación de un sistema es fiel a su diseño arquitectónico ". Se llega a una conclusión similar en Perry y Wolf (1992), [3] que informa 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 varios tipos de problemas que de lo contrario, pasaría desapercibido ".
Desde entonces, se ha llevado a cabo un hilo 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 aptas para diferentes técnicas de análisis. Por ejemplo, se han presentado ADL de dominios específicos para hacer frente a 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 específicas de análisis para tratar la disponibilidad, confiabilidad, seguridad, consumo de recursos, calidad de datos y análisis de desempeño 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 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 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, que se centran en necesidades muy específicas y no dejan espacio para extensiones que permitan la incorporación de nuevas funciones.
Como una forma de superar algunas de esas limitaciones, se ha indicado a UML como un posible sucesor de las ADL existentes. Se han presentado muchas propuestas para usar o extender UML para modelar arquitecturas de software de manera más adecuada. [15] [16]
De hecho, como se destaca en un estudio reciente realizado con profesionales, [17] mientras que los profesionales están generalmente satisfechos con las capacidades de diseño proporcionadas por los lenguajes que utilizan, no están satisfechos con las características del análisis del lenguaje arquitectónico y su capacidad para definir propiedades extrafuncionales. ; Los lenguajes arquitectónicos utilizados en la práctica se originan principalmente en el desarrollo industrial en lugar de en la investigación académica; Se requiere más formalidad y mejor usabilidad de un lenguaje arquitectónico.
Caracteristicas
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 los espacios del problema. Se diferencian de los lenguajes de programación porque las ADL no unen abstracciones arquitectónicas a soluciones puntuales específicas. Los lenguajes de modelado representan comportamientos, donde las ADL se centran en la representación de componentes. Sin embargo, existen lenguajes de modelado específicos de dominio (DSML) que se centran en la representación de componentes.
Requisitos mínimos
El idioma debe:
- Ser apto 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.
- 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 ADL tienen en común:
- Sintaxis gráfica con a menudo una forma textual y una sintaxis y semántica formalmente definidas
- Funciones para modelar sistemas distribuidos
- Poco 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, incluida la creación de subestructuras mediante la creación de instancias de plantillas.
Las ADL difieren en su capacidad para:
- Manejar construcciones en tiempo real, como fechas límite y prioridades de tareas, a nivel arquitectónico.
- Apoyar 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
- Manejar diferentes instancias de la misma arquitectura, en relación con arquitecturas de línea de productos.
Elementos positivos de ADL
- Las ADL son una forma formal de representar la arquitectura.
- Las ADL están diseñadas para ser legibles tanto por humanos como por máquinas
- Las ADL admiten la descripción de un sistema a un nivel más alto de lo que era posible anteriormente.
- Las ADL permiten el análisis y la evaluación de arquitecturas para garantizar su integridad, coherencia, ambigüedad y rendimiento.
- Las ADL pueden admitir la generación automática de sistemas de software
Elementos negativos de ADL
- No existe un acuerdo universal sobre lo que deben representar las ADL, particularmente en lo que respecta al comportamiento de la arquitectura.
- Las representaciones actualmente en uso son relativamente difíciles de analizar y no son compatibles con herramientas comerciales.
- La mayoría de las ADL tienden a optimizarse verticalmente hacia un tipo particular de análisis.
Conceptos comunes de arquitectura
La comunidad de ADL generalmente está de acuerdo en que la Arquitectura de software es un conjunto de componentes y las conexiones entre ellos. Pero hay diferentes tipos de arquitecturas como:
Arquitectura de conexión de objetos
- La configuración consta de las interfaces y conexiones de un sistema orientado a objetos
- Las interfaces especifican las características que deben proporcionar los módulos que se ajustan a una interfaz.
- Conexiones representadas por interfaces junto con gráfico de llamadas
- Conformidad generalmente impuesta por el lenguaje de programación
- Descomposición: asociar interfaces con módulos únicos
- Conformidad de la interfaz: comprobación estática de las reglas sintácticas
- Integridad de la comunicación: visibilidad entre módulos
Arquitectura de conexión de interfaz
- Expande el rol de interfaces y conexiones
- Las interfaces especifican características tanto "requeridas" como "proporcionadas"
- Las conexiones se definen entre las funciones "necesarias" y las funciones "proporcionadas"
- Consta de interfaces, conexiones y restricciones
- Las restricciones restringen el comportamiento de interfaces y conexiones en una arquitectura.
- Restricciones en un mapa de arquitectura a los requisitos de un sistema
La mayoría de las ADL implementan una arquitectura de conexión de interfaz.
Arquitectura vs.Diseño
La arquitectura, en el contexto de los sistemas de software, se divide aproximadamente 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 difusa entre arquitectura y diseño. Para trazar esta distinción de la manera más universal y clara posible, es mejor considerar el diseño como un sustantivo en lugar de 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, 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, 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 , mantenibilidad , confiabilidad, durabilidad, 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 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 se rige por ellos.
El proceso de definir una arquitectura puede involucrar heurísticas, adquiridas por el arquitecto o el equipo de arquitectura 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 se produce un diseño e 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 detallado, puede ser necesaria otra iteración de la arquitectura o el 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) cronología. (La arquitectura generalmente precede al diseño, aunque la superposición y la iteración circular es una realidad común).
Ejemplos de
A continuación, la lista muestra los candidatos para ser la mejor [ cita requerida ] ADL hasta la fecha.
Para obtener una lista actualizada de los lenguajes arquitectónicos existentes actualmente, consulte Lista actualizada de ADL .
- Candidatos primarios
- ÁBACO (UTS)
- ACME / ADML (CMU / USC)
- ADML (ya no está en desarrollo)
- ByADL (Build Your ADL) - Universidad de L'Aquila
- LePUS3 y Class-Z (Universidad de Essex)
- Rapide (Stanford)
- Wright (CMU)
- Unicon (CMU)
- Candidatos secundarios
- Esopo (UMC)
- MetaH (Honeywell)
- AAVD (SAE) - Un rchitecture A nálisis y D iseño L anguage
- C2 SADL (UCI)
- SADL (SRI) - S istem A rchitecture D escription L anguage
- Otros (sin clasificar)
- Lileanna - L ibrary I nterconnect L anguage E XTended con Ann otated Un da
- Dually: Proporcionar interoperabilidad de herramientas y lenguajes arquitectónicos a través de tecnologías de transformación de modelos
- Al igual que ArchC SystemC , se centra en conjuntos de instrucciones y modelos de memoria .
- AO-ADL
- ArchiMate Un ejemplo de ADL para arquitectura empresarial
- Modelo C4
- DAOP-ADL
- DEMO Otro ejemplo de ADL de arquitectura empresarial
- DiaSpec un enfoque y una herramienta para generar un marco distribuido a partir de una arquitectura de software
- SSEP
- Unicon
- xADL
Aproximaciones a la arquitectura
Aproximaciones a la arquitectura
- Enfoque académico
- centrarse en la evaluación analítica de modelos arquitectónicos
- modelos individuales
- notaciones de modelado riguroso
- potentes técnicas de análisis
- profundidad sobre anchura
- soluciones especiales
- Enfoque industrial
- centrarse en una amplia gama de cuestiones de desarrollo
- familias de modelos
- practicidad sobre rigor
- la arquitectura como el panorama general en desarrollo
- amplitud sobre profundidad
- soluciones de uso general
Ver también
- AADL
- Darwin
- ÁBACO
- Lenguaje de escritura
- Lenguaje de descripción de hardware
Referencias
- ^ Comité ISO / IECJTC 1 / SC 7 (1 de marzo de 2011). "ISO / IEC FDIS42010" (PDF) . Archivado desde el original (PDF) el 26 de abril de 2012 . Consultado el 5 de diciembre de 2011 .
- ^ Allen, R .; Garlan, D. (1997). "Una base formal para la conexión arquitectónica". Transacciones ACM sobre Ingeniería y Metodología de Software . 6 (3): 213. CiteSeerX 10.1.1.40.66 . doi : 10.1145 / 258077.258078 .
- ^ Perry, DE; Wolf, AL (1992). "Fundamentos para el estudio de la arquitectura de software" (PDF) . Notas de ingeniería del software ACM SIGSOFT . 17 (4): 40. CiteSeerX 10.1.1.40.5174 . doi : 10.1145 / 141874.141884 .
- ^ "AADL - Análisis de Arquitectura y Lenguaje de Diseño" . Instituto de Ingeniería de Software, Universidad Carnegie Mellon. Julio de 2019.
- ^ "EAST-ADL" .
- ^ Li, J .; Pilkington, NT; Xie, F .; Liu, Q. (2010). "Lenguaje de descripción de arquitectura incrustado". Revista de sistemas y software . 83 (2): 235. CiteSeerX 10.1.1.134.8898 . doi : 10.1016 / j.jss.2009.09.043 .
- ^ "AADL" . Archivado desde el original el 1 de junio de 2013 . Consultado el 10 de diciembre de 2012 .
- ^ Van Ommering, R .; Van Der Linden, F .; Kramer, J .; Magee, J. (2000). "El modelo de componente Koala para software de electrónica de consumo". Computadora . 33 (3): 78. CiteSeerX 10.1.1.469.8243 . doi : 10.1109 / 2.825699 .
- ^ Oquendo, Flavio (2004). "π-ADL". Notas de ingeniería del software ACM SIGSOFT . 29 (3): 1. doi : 10.1145 / 986710.986728 . ISSN 0163-5948 .
- ^ Bruneton, E .; Coupaye, T .; Leclercq, M .; Quéma, V .; Stefani, JB (2006). "El modelo de componentes FRACTAL y su soporte en Java". Software: práctica y experiencia . 36 (11-12): 1257. CiteSeerX 10.1.1.471.4374 . doi : 10.1002 / spe.767 .
- ^ "TADL" . 2009-04-29.
- ^ Woods, E .; Hilliard, R. (2005). "Arquitectura Descripción Lenguajes en el Informe de Sesión Práctica". 5ª Conferencia de Trabajo IEEE / IFIP sobre Arquitectura de Software (WICSA'05) . pag. 243. doi : 10.1109 / WICSA.2005.15 . ISBN 978-0-7695-2548-8.
- ^ Pandey, RK (2010). "Lenguajes de descripción arquitectónica (ADLs) vs UML". Notas de ingeniería del software ACM SIGSOFT . 35 (3): 1. doi : 10.1145 / 1764810.1764828 .
- ^ Clements, PC (1996). "Un estudio de los lenguajes de descripción de la arquitectura". Actas del 8º Taller Internacional sobre Especificación y Diseño de Software . págs. 16–00. CiteSeerX 10.1.1.208.3401 . doi : 10.1109 / IWSSD.1996.501143 . ISBN 978-0-8186-7361-0.
- ^ "Garlan_TR" .
- ^ Pérez-Martínez, JE; Sierra-Alonso, A. (2004). "UML 1.4 versus UML 2.0 como lenguajes para describir arquitecturas de software". Arquitectura de software . Apuntes de conferencias en Ciencias de la Computación. 3047 . pag. 88. doi : 10.1007 / 978-3-540-24769-2_7 . ISBN 978-3-540-22000-8.
- ^ Malavolta, Ivano; Lago, Patricia; Muccini, Henry; Pelliccione, Patrizio; Tang, Antony (2013). "Qué necesita la industria de los lenguajes arquitectónicos: una encuesta". Transacciones IEEE sobre ingeniería de software . 39 (6): 869–891. doi : 10.1109 / TSE.2012.74 .
enlaces externos
- Medvidovic, N .; Taylor, RN (enero de 2000). "Un marco de clasificación y comparación para lenguajes de descripción de arquitectura de software". Transacciones IEEE sobre ingeniería de software . 26 (1): 70–93. doi : 10.1109 / 32.825767 .
- Malavolta, Ivano; Lago, Patricia; Muccini, Henry; Pelliccione, Patrizio; Tang, Antony (2013). "Qué necesita la industria de los lenguajes arquitectónicos: una encuesta". Transacciones IEEE sobre ingeniería de software . 39 (6): 869–891. doi : 10.1109 / TSE.2012.74 .
- Arquitectura Descripción Idiomas // Mälardalen University
- Clements, PC (1996). "Un estudio de los lenguajes de descripción de la 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. Archivado desde el original (PDF) el 24 de diciembre de 2013.
- ÁBACO
- CUMBRE
- ADML
- Esopo
- AO-ADL
- ArchiMate Un ejemplo de ADL para arquitectura empresarial
- ByADL (Build Your ADL) - Universidad de L'Aquila
- C2 SADL
- DAOP-ADL
- DEMO Otro ejemplo de ADL de arquitectura empresarial
- DiaSpec 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). "Proporcionar interoperabilidad de herramientas y lenguajes arquitectónicos a través de tecnologías de transformación de modelos". Transacciones IEEE sobre ingeniería de software . 36 (1): 119–140. doi : 10.1109 / TSE.2009.51 . DUALMENTE
- Rapide
- SSEP
- Unicon
- Wright