Architecture description languages (ADLs) are formal languages that can be used to represent the architecture of a software-intensive system. As architecture becomes a dominating theme in large system development, methods for unambiguously specifying architecture will become indispensable.
By architecture, we mean the components that comprise a system, the behavioral specifications for those components, and the patterns and mechanisms for interactions among them. Note that a single system is usually composed of more than one type of component: modules, tasks, functions, etc. An architecture can choose the type of component most appropriate or informative to show, or it can include multiple views of the same system, each illustrating different componentry.
To date, architectures have largely been represented by informal circle-and-line drawings in which the nature of the components, their properties, the semantics of the connections, and the behavior of the system as a whole are poorly (if at all) defined. Even though such figures often give an intuitive picture of the system's construction, they usually fail to answer such questions as:
What are the components? Do the modules exist only at design-time, or are they compiled together before run time? Are these tasks or processes threaded together from different modules, assembled at compile-time, and do they form run time units? Are they something as nebulous as "functional areas," as in data flow diagrams, or something else entirely?
What do the components do? How do they behave? What other components do they rely on?
What do the connections mean? Do they mean "sends data to," "sends control to," "calls," "is a part of," some combination of these, or something else? What are the mechanisms used to fulfill these relations?
ADLs trace their roots to module interconnection languages of the 1970s. Today, ADLs are in a maturing phase, but several exist. Current examples include Rapide, UniCon, ArTek, Wright and Meta-H.
An architecture plays several roles in project development, all of them important, and all of them facilitated by a formal representation of the architecture, such as with an ADL. A formal architecture representation is more likely to be maintained and followed than an informal one, because a formal architecture can more readily be consulted and treated as authoritative, and can more easily be transferred to other projects as a core asset. Roles include:
Basis for communication: Project team members, managers, and customers all turn to the architecture as the basis for understanding the system, its development, and how it works during execution.
Project blueprint: The choice of architectural components is institutionalized in the developing organization's team structure, work assignments, management units, schedule and work breakdown structures, integration plans, test plans, and maintenance processes. Once it is made, an architectural decision has an extremely long lifetime and survives even outside of the software that it describes.
Blueprint for product line development. An architecture may be re-used on other systems for which it is appropriate. If managed carefully, an entire product family may be produced using a single architecture. In this case, the importance of an appropriate architecture is magnified across all the projects it will serve.
Embodiment of earliest design decisions: The architecture represents the first mapping from requirements to computational components. The selection of components and connections, as well as the allocation of functionality to each component, is a codification of the earliest design decisions about a project. All downstream design decisions must be consistent with the architectural choices. As such, architectural decisions are the hardest to change, and have the most far-reaching consequences.
Some ADLs provide an opportunity for architecture-level analysis, such as automatic simulation generation, schedulability analysis, and the like. However, even in the absence of automated analysis capabilities, other evaluative strategies can be applied to the architecture. Thus, these early design decisions and quality attribute tradeoffs can be tested before they are too expensive to change.
Architecture Description Language (ADL) is defined as "a language (graphical, textual, or both) for describing a software system in terms of its architectural elements and the relationship among them".
In other words, ADL is a language enabling formalization, description, specification, modeling and reasoning on software architectures. Each of these features should be fulfilled by a language that is proclaimed to be ADL. A good ADL must provide abstractions that are adequate for modeling a large system. Each ADL embodies a particular approach to the specification and evolution of architecture.
Unified Modeling Language (UML) is formal graphical language considered a de facto industrial stand. Although the language has been initially created as a graphical language that supports object oriented software analysis and design, the language has been revised a couple of times and today, it is a general formal language capable of describing a software system. The UML has a well-defined formal syntax and semantics, and can be machine checked and processed. UML includes a set of graphical notation techniques to create abstract models of specific systems.
The architecture description combinators in this example have been designed for the generic presentation-oriented structure editor Proxima. Proxima supports the editing of document structure as well as its presentation. Because of the complexity of the actual Proxima architecture, we introduce a simple layered architecture for a presentation-oriented editor to explain the architecture description methods.
The figure above shows the data flow for the layer functions in the normalized Simple type. The definition of the normalized Simple is:
data Simple state map doc pres gest upd =
Simple { present :: LayerFn state doc
(map, state) pres
, interpret :: LayerFn (map, state) gest
state upd
}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.
Two leading ADL researchers offer their desiderata for ADLs. Shaw lists the following as important properties that ADLs should exhibit:
ability to represent components (primitive or composite) along with property assertions, interfaces and implementations;
ability to represent connectors, along with protocols, property assertions, and implementations;
abstraction and encapsulation;
types and type checking;
ability to accommodate analysis tools openly.
Luckham lists the following as requirements for an ADL:
component abstraction;
communication abstraction;
communication integrity (limiting communication to those components connected to each other architecturally);
ability to model dynamic architectures;
ability to reason about causality and time;
hierarchical refinement support;
These lists illustrate different points of view about what constitutes an ADL. There is no clear line between ADLs and non-ADLs. Languages can, however, be distinguished from one another according to how much architectural information they represent. Languages that were born as ADLs show a clear advantage in this area over languages built for some other purpose and later co-opted to represent architectures.
Feature analysis is a tool for certain domain analysis methods such as the Feature-Oriented Domain Analysis (FODA) method; it proceeds by cataloguing user-visible system features in a structured fashion.
Features are structured into the following three categories: system-oriented features, language-oriented features, and process-oriented features.
System-oriented features are related to the application system derived from the architecture description. For example, certain ADLs may not be able to express real-time constraints about a system's architectural components, while others can. All features in this category are attributes of an end system; however, they reflect on the ability of the ADL to express or describe those attributes at the architectural level.
Language-oriented features are features of the ADL itself, independent of the system(s) it is being used to develop. These attributes include the kind of information usually found in a language reference manual. An example is how the ADL's syntax and semantics are formally specified, and what architectural abstractions the ADL embodies.
Process-oriented features are features of a process related to using the ADL to create, validate, analyze, and refine an architecture description, and build an application system from it. The components included here are the attributes that measure or describe how or to what extent an ADL allows predictive evaluation of the application system based on architecture-level information. These attributes measure whether or not the ADL contains enough information to make an architecture analyzable, independently of whether or not tools actually exist that exploit that capability.
Architecture, in the context of software systems, is divided into software architecture, network architecture, and systems architecture. Within each of these categories, there is a tangible but fuzzy distinction between architecture and design.
Design is the abstraction and specification of patterns and organs of functionality that have been or will be implemented. Architecture is a degree higher in both abstraction and granularity.
Architecture is done during the conceptualization of an application, system, or network and may appear in the non-functional sections of requirement documentation. Canonically, design is not specified in requirements, but is rather driven by them.
The process of defining an architecture may involve heuristics, acquired by the architect or architectural team through experience within the domain. As with design, architecture often evolves through a series of iterations.
Bharathi B., Sridharan D.; "UML as an Architecture Description Language", International Journal of Recent Trends in Engineering, Vol. 1, No. 2, May 2009
Kang, Kyo C.; Cohen, Sholom G.; Hess, James A.; Novak, William E.; & Peterson, A. Spencer. "Feature Oriented Domain Analysis (FODA)", Feasibility Study (CMU/SEI-90-TR-21, ADA235785). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, November 1990
Paul C. Clements; "A Survey of Architecture Description Languages", Software Engineering Institute, Carnegie Mellon University, March 1996