Architecture Description Language (ADL)

An Architecture description language (ADL) is domain-specific modeling language for EAM. Architecture description languages (ADLs) are any kind of modeling language, that can be used to express system architectures. That means, ADLs provide a set of rules and common practices for the creation of visualizations like e.g. flow diagrams or organization charts. The resulting visualizations address concerns of EAM stakeholders and can be grouped into views. ADLs are often supported by EAM tools to aid the creation, use and analysis of its models and visualizations.[1]

A software architecture describes the structure and behavior of a software system and the non-software entities the system interfaces with. In a software architecture, a system is represented as a set of software components, their connections, and their important behavioral interactions. Creating a software architecture promotes better understanding of the system, thus aiding the design process. It also provides a basis for rigorous analysis of the system design, making possible the early detection of design errors and flaws that lead to improvements in software quality and help ensure correctness. An architectural description language (ADL) is used to describe a software architecture. An ADL may be a formal or semi-formal descriptive language, a graphics language, or include both. The advantage of using an ADL lies in the ability to rigorously specify an architecture so that it can be analyzed. An ADL may have associated with it a set of tools for doing useful analysis of architectures specified in the language. In recent years, there has been a considerable amount of research into developing ADLs.[2]

What constitutes an ADL?[3]
After surveying a broad selection of languages, all of which have some claim to being ADLs, what can we conclude about what makes a language an ADL? The following seems to be a minimal set of requirements for a language to be an ADL: • An ADL must support the tasks of architecture creation, refinement, and validation. It must embody rules about what constitutes a complete or consistent architecture. • An ADL must provide the ability to represent (even if indirectly) most of the common architectural styles enumerated in. • An ADL must have the ability to provide views of the system that express architectural information, but at the same time suppress implementation or non-architectural information. • If the language can express implementation-level information, then it must contain capabilities for matching more than one implementation to the architecture level views of the system. That is, it must support specification of families of implementations that all satisfy a common architecture. • An ADL must support either an analytical capability, based on architecture-level information, or a capability for quickly generating prototype implementations.

Common ADL Constructs[4]

  • Components (Either data store or unit of computation)
    • represent the primary computational elements and data stores of a system.
    • Typical examples of component include such things as clients, servers, filters, objects, blackboards and databases.
    • Components may have multiple interfaces, each interface defining a point of interaction between a component and its environment.
  • Connectors
    • Connectors represent interaction among components.
    • They provide the glue for architectural designs.
    • From the run time perspective, connectors mediate the communication and coordination activities among components.
    • Examples include simple forms of interaction, such as pipes, procedure call, and event broadcast.
    • Connectors may also represent complex interactions, such as client-server protocol, or a SQL Link between a database and an application.
    • Connectors have interfaces that define the roles played by the participants in the interaction.
  • Systems (configurations of components and connectors)
    • System represents graphs of components and connectors.
    • A particular arrangement of components and connectors are defined as a system configuration.
    • In general, systems may be hierarchical.
    • Components and connectors may represent subsystems that have their own internal architecture
  • Ports (points of interaction with a component)
  • Representations - for modeling hierarchical composition
  • Rep-maps,
    • mapping composite component’s or connector’s internal architecture of the external interface

Choosing an Architecture Description Language[5]
There are considerations when choosing an architecture description language that will affect the choice:

  • How much of the architecture framework metamodel is it possible to represent using the ADL? Most ADLs themselves have some form of metamodel and they may or may not have the means to represent parts of your architecture framework metamodel. If they cannot then this may not matter depending on what concerns are to be addressed using the architecture description - if the framework metamodel elements for the views/viewpoints needed for the task are covered then the architecture task can be completed. If there is inadequate coverage either another ADL has to be used or a combination of ADLs has to be used (although this adds practical complications).
  • Familiarity and experience. If an ADL is commonly used then the training requirements will be smaller. modelling tool support. Some modelling tools support a limited set of ADLs and therefore choosing a new ADL might require either new tools or extension of existing ones.

A Mapping Between An ADL Metamodel and the Architecture Framework Metamodel Identifies What It Is Possible to Represent of the Architecture Framework Using the ADL (see figure below)
ADL Mapping Architecture Description Language (ADL)
source: Trak-Community.Org

Characteristics of Architecture Description Language (ADL)[6]
There is a large variety in ADLs developed by either academic or industrial groups. Many languages were not intended to be an ADL, but they turn out to be suitable for representing and analyzing an architecture. In principle ADLs differ from requirements languages, because ADLs are rooted in the solution space, whereas requirements describe problem spaces. They differ from programming languages, because ADLs do not bind architectural abstractions to specific point solutions. Modeling languages represent behaviors, where ADLs focus on representation of components. However, there are domain specific modeling languages (DSMLs) that focus on representation of components.

  • Minimal requirements

The language must:

    • Be suitable for communicating an architecture to all interested parties
    • Support the tasks of architecture creation, refinement and validation
    • Provide a basis for further implementation, so it must be able to add information to the ADL specification to enable the final system specification to be derived from the ADL
    • Provide the ability to represent most of the common architectural styles
    • Support analytical capabilities or provide quick generating prototype implementations
  • ADLs have in common:
    • Graphical syntax with often a textual form and a formally defined syntax and semantics
    • Features for modeling distributed systems
    • Little support for capturing design information, except through general purpose annotation mechanisms
    • Ability to represent hierarchical levels of detail including the creation of substructures by instantiating templates
  • ADLs differ in their ability to:
    • Handle real-time constructs, such as deadlines and task priorities, at the architectural level
    • Support the specification of different architectural styles. Few handle object oriented class inheritance or dynamic architectures
    • Support the analysis of the architecture
    • Handle different instantiations of the same architecture, in relation to product line architectures
  • Positive elements of ADL
    • ADLs are a formal way of representing architecture
    • ADLs are intended to be both human and machine readable
    • ADLs support describing a system at a higher level than previously possible
    • ADLs permit analysis and assessment of architectures, for completeness, consistency, ambiguity, and performance
    • ADLs can support automatic generation of software systems
  • Negative elements of ADL
    • There is no universal agreement on what ADLs should represent, particularly as regards the behavior of the architecture
    • Representations currently in use are relatively difficult to parse and are not supported by commercial tools
    • Most ADLs tend to be very vertically optimized toward a particular kind of analysis

ADLs and their Relationship to Other Languages[7]
How do ADLs differ from programming languages, requirements languages, modeling languages, and the like? Given a language for expressing properties or behaviors of a system, what are the criteria for deciding if it is an ADL or not? Unfortunately, it isn't clear.

  • In principle, ADLs differ from requirements languages because the latter category describes problem spaces, whereas the former category is rooted in the solution space.
  • In practice, requirements are often divided into behavioral chunks for ease of presentation, and the languages used for representing those behaviors are sometimes well-suited to representing architectural components, even though that was not the original goal of the language. For example, Modechart, a requirements language similar to Statechart, exhibited stronger analytical capabilities than most ADLs because of the presence of a model-checking verifier. Modechart was considered to be an ADL because its componentry (state machines) could be interpreted as architectural components. However, Modechart was not designed to be an ADL, and so it is easy to produce artifacts in Modechart that do not, under any reasonable semantic interpretation, correspond to an architectural view of a system.
  • In principle, ADLs differ from programming languages because the latter category binds all architectural abstractions to specific point solutions whereas ADLs intentionally suppress or vary such binding.
  • In practice, architecture is embodied in and recoverable from code, and many languages provide architecture-level views of the system. For example, Ada offers the ability to view a system just in terms of its package specifications, which are the interfaces to components. However, Ada offers little or no architecture-level analytical capabilities, nor does it provide architecture level insight into how the components are "wired" together.
  • In principle, ADLs differ from modeling languages because the latter category is more concerned with the behaviors of the whole rather than of the parts, whereas ADLs concentrate on representation of components.
  • In practice, many modeling languages allow the representation of cooperating components and can represent architectures reasonably well.

Architecture Description Languages: Mainstream and Experimental[8]

See Also

Architectural Style
Architectural Risk
Architectural Pattern
Architectural Principles
Architecture Development Method (ADM)
Service Oriented Architecture (SOA)
Software Architecture
The Open Group Architecture Framework (TOGAF)
Architecture-Driven Modernization
Design Pattern
Enterprise Architecture Unified Modeling Language (UML) ArchiMate


  1. Defining Architecture Description Language (ADL)
  2. What are Architecture Description Languages (ADLs)? NIST
  3. What constitutes an ADL? Paul C. Clemens
  4. Common ADL Constructs Prof. Duane Truex
  5. Factors Affecting Choice of Architecture Description Language
  6. What are the Characteristics of an Architecture Description Language (ADL)? Wikipedia
  7. How do ADLs relate to other languages? [^ TSM]
  8. Architecture Description Languages: Mainstream and Experimental IASA

Further Reading