General Navigation Buttons - Home | Search | Contact Us | Site Map | Whats New
products graphic
white space
products
Software Technology Roadmap
What's New
Background & Overview
Technology Descriptions
Defining Software Technology
Technology Categories
Template for Technology Descriptions
Taxonomies
Glossary & Indexes
Feedback & Participation
Software Engineering Information Repository (SEIR)
white space
About SEI|Mgt|Eng|Acq|Collaboration|Prod.& Services|Pubs
pixel
Rollover Popup Hints for Topic Navigation Buttons above
pixel
Architecture Description Languages


Status

Complete

Purpose and Origin

When describing a computer software system, software engineers often talk about the architecture of the system, where an architecture is generally considered to consist of components and the connectors (interactions) between them.1 Although architectural descriptions are playing an increasingly important role in the ability of software engineers to describe and understand software systems, these abstract descriptions are often informal and ad hoc.2 As a result

  • Architectural designs are often poorly understood and not amenable to formal analysis or simulation.
  • Architectural design decisions are based more on default than on solid engineering principles.
  • Architectural constraints assumed in the initial design are not enforced as the system evolves.
  • There are few tools to help the architectural designers with their tasks [Garlan 93].
In an effort to address these problems, formal languages for representing and reasoning about software architecture have been developed. These languages, called architecture description languages (ADLs), seek to increase the understandability and reusability of architectural designs, and enable greater degrees of analysis.

Technical Detail

In contrast to Module Interconnection Languages (MILS), which only describe the structure of an implemented system, ADLs are used to define and model system architecture prior to system implementation. Further, ADLs typically address much more than system structure. In addition to identifying the components and connectors of a system, ADLs typically address:

  • Component behavioral specification. Unlike MILs, ADLs are concerned with component functionality. ADLs typically provide support for specifying both functional and non-functional characteristics of components. (Non-functional requirements include those associated with safety, security, reliability, and performance.) Depending on the ADL, timing constraints, properties of component inputs and outputs, and data accuracy may all be specified.
  • Component protocol specification. Some ADLs, such as Wright [Garlan 94a] and Rapide [Luckham 95], support the specification of relatively complex component communication protocols. Other ADLs, such as UniCon [Shaw 95], allow the type of a component to be specified (e.g., filter, process, etc.) which in turn restricts the type of connector that can be used with it.
  • Connector specification. ADLs contain structures for specifying properties of connectors, where connectors are used to define interactions between components. In Rapide, connector specifications take the form of partially-ordered event sequences, while in Wright, connector specifications are expressed using Hoare's Communicating Sequential Processes (CSP) language [Hoare 85].
As an example, consider the component shown in Figure 1. This component defines two data types, two operations (op), and an input and an output communication port. The component also includes specifications constraining the behavior of its two operations.

Figure 1: Component

A protocol specification for this component, written in CSP, defines how it interacts with its environment. Specifically, component Simple will accept a data value x of type in_type on its input port, and, if the data value is valid, will output f(x) on its output port. If the data value is not valid, Simple will output an error message on its output port. Note that component Simple is a specification, not an implementation. Implementations of ADL components and connectors are expressed in traditional programming languages such as Ada (see Ada 83 and Ada 95) or C. Facilities for associating implementations with ADL entities vary between ADLs.

Usage Considerations

ADLs were developed to address a need that arose from programming in the large; they are well-suited for representing the architecture of a system or family of systems. Because of this emphasis, several changes to current system development practices may occur:

  • Training. ADLs are formal, compilable languages that support one or more architectural styles; developers will need training to understand and use ADL technology and architectural concepts/styles effectively (e.g., the use of dataflow, layered, or blackboard architectural styles).
  • Change/emphasis in life-cycle phases. The paradigm currently used for system development and maintenance may be affected. Specifically, architectural design and analysis will precede code development; results of analysis may be used to alter system architecture. As such, a growing role for ADLs is expected in evaluating competing proposed systems during acquisitions. An ADL specification should provide a good basis for programming activities [Shaw 95].
  • Documentation. Because the structure of a software system can be explicitly represented in an ADL specification, separate documentation describing software structure is not necessary. This implies that if ADLs are used to define system structure, the architectural documentation of a given system will not become out of date.3 Additionally, ADLs document system properties in a formal and rigorous way. These formal characterizations can be used to analyze system properties statically and dynamically. For example, dynamic simulation of Rapide [Luckham 95] specifications can be analyzed by automated tools to identify such things as communication bottlenecks and constraint violations. Further, these formal characterizations provide information that can be used to guide reuse.
  • Expanding scope of architecture. ADLs are not limited to describing the software architecture; application to system architecture (to include hardware, software, and people) is also a significant opportunity.

Maturity

Several ADLs have been defined and implemented that support a variety of architectural styles, including

  • Aesop, which supports the specification and analysis of architectural styles (formal characterizations of common architectures such as pipe and filters, and client-server) [Garlan 94b].
  • Rapide, which uses event posets to specify component interfaces and component interaction [Luckham 95].
  • Wright, which supports the specification and analysis of communication protocols [Garlan 94a].
  • MetaH, which was developed for the real-time avionics domain [Vestal 96].
  • LILEAnna, which is designed for use with Ada and generalizes Ada's notion of generics [Tracz 93].
  • UniCon, which addresses packaging and functional issues associated with components [Shaw 95].
Further information about these and other languages used to describe software architectures can be found in the Software Architecture Technology Guide and Architectural Description Languages [SATG 96, SEI 96].

Because ADLs are an emerging technology, there is little evidence in the published literature of successful commercial application. However, Rapide and UniCon have been used on various problems,4 and MetaH appears to be in use in a commercial setting [Vestal 96]. ADLs often have graphical tools that are similar to CASE tools.

Costs and Limitations

The lack of a common semantic model coupled with differing design goals for various ADLs complicates the ability to share tool suites between them. Researchers are addressing this problem; an ADL called ACME is being developed with the goal that it will serve as an architecture interchange language.5 Some ADLs, such as MetaH, are domain-specific.

In addition, support for asynchronous versus synchronous communication protocols varies between ADLs, as does the ability to express complex component interactions.

Dependencies

Simulation technology is required by those ADLs supporting event-based protocol specification.

Alternatives

The alternatives to ADLs include Module Interconnection Languages (which only represent the defacto structure of a system), object-oriented CASE tools, and various ad-hoc techniques for representing and reasoning about system architecture.

Another alternative is the use of VHSIC Hardware Description Language (VHDL) tools. While VHDL is often thought of exclusively as a hardware description language, its modularization and communication protocol modeling capabilities are very similar to the ones under development for use in ADLs.

Complementary Technologies

Behavioral specification technologies and their associated theorem proving environments are used by several ADLs to provide capabilities to define component behavior. In addition, formal logics and techniques for representing relationships between them are being used to define mappings between architectures within an ADL and to define mappings between ADLs.

Index Categories

This technology is classified under the following categories. Select a category for a list of related topics.

Name of technology

 Architecture Description Languages

Application category

 Architectural Design (AP.1.3.1),
Compiler (AP.1.4.2.3),
Plan and Perform Integration (AP.1.4.4)

Quality measures category

 Correctness (QM.1.3),
Structuredness (QM.3.2.3),
Reusability (QM.4.4)

Computing reviews category Software Engineering Tools and Techniques (D.2.2),
Organization and Design (D.4.7),
Performance (D.4.8),
Systems Programs and Utilities (D.4.9)

References and Information Sources

[Garlan 93] Garlan, David & Shaw, Mary. "An Introduction to Software Architecture," 1-39. Advances in Software Engineering and Knowledge Engineering Volume 2. New York, NY: World Scientific Press, 1993.
[Garlan 94a] Garlan, D. & Allen, R. "Formalizing Architectural Connection," 71-80. Proceedings of the 16th International Conference on Software Engineering. Sorrento, Italy, May 16-21, 1994. Los Alamitos, CA: IEEE Computer Society Press, 1994.
[Garlan 94b] Garlan, D.; Allen, R.; & Ockerbloom, J. "Exploiting Style in Architectural Design Environments." SIGSOFT Software Engineering Notes 19, 5 (December 1994): 175-188.
[Luckham 95] Luckham, David C., et al. "Specification and Analysis of System Architecture Using Rapide." IEEE Transactions on Software Engineering 21, 6 (April 1995): 336-355.
[Hoare 85] Hoare, C.A.R. Communicating Sequential Processes. Englewood Cliffs, NJ: Prentice Hall International, 1985.
[Paulisch 94] Paulisch, Frances. "Software Architecture and Reuse- An Inherent Conflict?" 214. Proceedings of the 3rd International Conference on Software Reuse. Rio de Janeiro, Brazil, November 1-4, 1994. Los Alamitos, CA: IEEE Computer Society Press, 1994.
[Perry 92] Perry, D.E. & Wolf, A.L. "Foundations for the Study of Software Architectures."SIGSOFT Software Engineering Notes 17,4 (October 1992): 40-52.
[SATG 96] Software Architecture Technology Guide [online]. Available WWW <URL: http://www-ast.tds-gn.lmco.com/arch/guide.html> (1996).
[SEI 96] Architectural Description Languages [online]. Available WWW
<URL: http://www.sei.cmu.edu/architecture/adl.html> (1996).
[Shaw 95] Shaw, Mary, et al. "Abstractions for Software Architecture and Tools to Support Them." IEEE Transactions on Software Engineering 21, 6 (April 1995): 314-335.
[Shaw 96] Shaw, M. & Garlan, D. Perspective on an Emerging Discipline: Software Architecture. Englewood Cliffs, NJ: Prentice Hall, 1996.
[STARS 96] Scenarios for Analyzing Architecture Description Languages Version 2.0 [online]. Originally available WWW
<URL: http://www.asset.com/WSRD/abstracts/ABSTRACT_1183.html> (1996).
[Tracz 93] Tracz, W. "LILEANNA: a Parameterized Programming Language," 66-78. Proceedings of the Second International Workshop on Software Reuse. Lucca, Italy, March 24-26, 1993. Los Alamitos, CA: IEEE Computer Society Press, 1993.
[Vestal 93] Vestal, Steve. A Cursory Overview and Comparison of Four Architecture Description Languages [online]. Originally available FTP
<URL: ftp://ftp.htc.honeywell.com/pub/dssa/papers/four_adl.ps> (1996).
[Vestal 96] Vestal, Steve. Languages and Tools for Embedded Software Architectures [online]. Available WWW
<URL: http://www.htc.honeywell.com/projects/dssa/dssa_tools.html> (1996).

Current Author/Maintainer

Mark Gerken, Air Force Rome Laboratory

External Reviewers

Paul Clements, SEI
Paul Kogut, Lockheed Martin, Paoli, PA
Will Tracz, Lockheed Martin Federal Systems, Owego, NY

Modifications

10 Jan 97 (original)

Footnotes

1 While definitions of architecture, component, and connector vary among researchers, this definition of architecture serves as a baseline for this technology description. A generally accepted definition describing the difference between a "design" and an "architecture" is that while a design explicitly addresses functional requirements, an architecture explicitly addresses functional and non-functional requirements such as reusability, maintainability, portability, interoperability, testability, efficiency, and fault-tolerance [Paulisch 94].

2 Source: Garlan, David, et al. "ACME: An Architecture Interchange Language." Submitted for publication.

3 However, one can easily imagine a case where an ADL is used to document the architecture, but then the project moves to the implementation phase and the ADL is forgotten. The code or low-level design migrates, but the architecture is lost. This is often referred to as architectural drift [Perry 92].

4 For example, Rapide has been used to specify/ analyze the architecture model of the Sparc Version 9 64-bit instruction set, a standard published by Sparc International. Models of the extensions for the Ultra Sparc have also been done; they are used extensively in benchmarking Rapide simulation algorithms. Further information is available via the World Wide Web at http://anna.stanford.edu/rapide/rapide.html.

5 Source: Garlan, David, et al. "ACME: An Architecture Interchange Language." Submitted for publication.


The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.

Copyright 2007 by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/adl_body.html
Last Modified: 11 January 2007