Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modelling and engineering.
The system engineering community uses an architecture description language as a language and/or a conceptual model to describe and represent system architectures.
The software engineering community uses an architecture description language as a computer language to create a description of a software architecture. In the case of a so-called technical architecture, the architecture must be communicated to software developers; a functional architecture is communicated to various stakeholders and users. Some ADLs that have been developed are: Acme (developed by CMU), AADL (standardized by the SAE), C2 (developed by UCI), SBC-ADL (developed by National Sun Yat-Sen University), Darwin (developed by Imperial College London), and Wright (developed by CMU).
Overview
The ISO/IEC/IEEE 42010 document, Systems and software engineering—Architecture description, defines an architecture description language as "any form of expression for use in architecture descriptions" and specifies minimum requirements on ADLs.
The enterprise modelling and engineering community have also developed architecture description languages catered for at the enterprise level. Examples include ArchiMate (now a standard of The Open Group), DEMO, ABACUS (developed by the University of Technology, Sydney). These languages do not necessarily refer to software components, etc. Most of them, however, refer to an application architecture as the architecture that is communicated to the software engineers.
Most of the writing below refers primarily to the perspective from the software engineering community.
A standard notation (ADL) for representing architectures helps promote mutual communication, the embodiment of early design decisions, and the creation of a transferable abstraction of a system. Architectures in the past were largely represented by box-and-line drawing annotated with such things as the nature of the component, properties, semantics of connections, and overall system behavior. ADLs result from a linguistic approach to the formal representation of architectures, and as such they address its shortcomings. Also important, sophisticated ADLs allow for early analysis and feasibility testing of architectural design decisions.
History
ADLs have been classified into three broad categories: box-and-line informal drawings, formal architecture description language, and UML (Unified Modeling Language)-based notations.
Box-and-line have been for a long time the most predominant means for describing SAs. While providing useful documentation, the level of informality limited the usefulness of the architecture description. A more rigorous way for describing SAs was required. Quoting Allen and Garlan (1997), "while these [box-and-line] descriptions may provide useful documentation, the current level of informality limits their usefulness. Since it is generally imprecise what is meant by such architectural descriptions, it may be impossible to analyze an architecture for consistency or determine non-trivial properties of it. Moreover, there is no way to check that a system implementation is faithful to its architectural design." A similar conclusion is drawn in Perry and Wolf (1992), which reports that: "Aside from providing clear and precise documentation, the primary purpose of specifications is to provide automated analysis of the documents and to expose various kinds of problems that would otherwise go undetected."
Since then, a thread of research on formal languages for SA description has been carried out. Tens of formal ADLs have been proposed, each characterized by different conceptual architectural elements, different syntax or semantics, focusing on a specific operational domain, or only suitable for different analysis techniques. For example, domain-specific ADLs have been presented to deal with embedded and real-time systems (such as AADL, EAST-ADL, and EADL), control-loop applications (DiaSpec), product line architectures (Koala), and dynamic systems (Π-ADL)). Analysis-specific ADLs have been proposed to deal with availability, reliability, security, resource consumption, data quality and real-time performance analysis (AADL, behavioral analysis (Fractal)), and trustworthiness analysis (TADL).