ONLINE TESTS EDITING BOARD
RO
EN
×
▼ BROWSE ISSUES ▼
Issue 55

Architecture Description Languages

Gelu Vac
Software Engineering Manager @ Crossover
PROGRAMMING

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:

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.

Architecture and ADLs

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:

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.

UML and ADL

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.

Haskell as an ADL example

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
}

ADLs and their relationship to other languages

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:

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-Oriented Domain Analysis (FODA)

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

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

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

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.

Conclusions

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.

Bibliography

  1. Bharathi B., Sridharan D.; "UML as an Architecture Description Language", International Journal of Recent Trends in Engineering, Vol. 1, No. 2, May 2009

  2. 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

  3. Paul C. Clements; "A Survey of Architecture Description Languages", Software Engineering Institute, Carnegie Mellon University, March 1996

  4. Martijn M. Schrage, S. Doaitse Swierstra; "Haskell as an Architecture Description Language", Department of Information and Computing Sciences, Utrecht University, Netherlands, 2008

Sponsors

  • Endava
  • 3PillarGlobal
  • Gemini Solutions
  • Betfair
  • Accenture
  • Telenav
  • Siemens
  • Bosch
  • ntt data
  • FlowTraders
  • Crossover
  • Colors in projects
  • Ullink

IT Days