ADL

Architectural description language (ADL)

ADL 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. A number of experimental ADLs have been devised. These include:  ACME, AESOP, UNICON, and WRIGHT (Carnegie-Mellon

University) xADL (University of California, Irvine)

Contd… In the system engineering community, an Architecture Description

Language (ADL) is a language and/or conceptual model used to describe and represent system architectures.

In the software engineering community, an Architecture Description Language (ADL) is a computer language used to describe and represent software architectures. This means in case of technical architecture, the architecture must be communicated to software developers. With functional architecture, the software architecture is communicated with stakeholders and enterprise engineers.

By the software engineering community several ADLs have been developed, such as Acme (developed by CMU), AADL (standardized by SAE), C2 (developed by UCI), Darwin (developed by Imperial College London), and Wright (developed by CMU).

Introduction

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.

Characteristics

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.

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 architectureADLs are intended to be both human and machine

readableADLs support describing a system at a higher level than

previously possibleADLs 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

Common concepts of architecture

The ADL community generally agrees that Software Architecture is a set of components and the connections among them. But there are different kind of architectures like 

a. Object Connection Architecture

b. Interface Connection Architecture

Object Connection Architecture

Configuration consists of the interfaces and connections of an object-oriented system

Interfaces specify the features that must be provided by modules conforming to an interface

Connections represented by interfaces together with call graph

Conformance usually enforced by the programming language

◦ Decomposition - associating interfaces with unique modules

◦ Interface conformance - static checking of syntactic rules

◦ Communication integrity - visibility between modules

Interface Connection Architecture

Expands the role of interfaces and connections

◦ Interfaces specify both “required” and “provided” features

◦ Connections are defined between “required” features and “provided” features

Consists of interfaces, connections and constraints

◦ Constraints restrict behavior of interfaces and connections in an architecture

◦ Constraints in an architecture map to requirements for a system

Most ADLs implement an interface connection architecture.

Examples

Below the list gives the candidates for being the best ADL until now Primary candidates

◦ ACME / ADML (CMU/USC)◦ ADML (No longer in development)◦ Rapide (Stanford)◦ Wright (CMU)◦ Unicon (CMU)◦ ByADL (Build Your ADL) - University of L'Aquila◦ LePUS3 and Class-Z (University of Essex)

  Secondary candidates

◦ Aesop (CMU)◦ MetaH (Honeywell)◦ AADL (SAE) - Architecture Analysis & Design Language◦ C2 SADL (UCI)◦ SADL (SRI) - System Architecture Description Language

Unicon (CMU)

UniCon is an architectural description language whose focus is on supporting the variety of architectural parts and styles found in the real world and on constructing systems from their architecture descriptions.

Here is a short example An architecture description in UniCon consists of a set of

components and connectors. A component is a locus of data or computation, while a connector mediates the interaction among components.

Each component has an interface that exports a set of players. These players engender the ways in which the component can interact with the outside world.

Contd… Similarly, a connector's protocol exports a set of roles that

engender the ways in which the connector can mediate interaction.

To illustrate, here's an example diagram produced using UniCon's graphical editor:

Contd… The diagram features two components, labelled A and B,

which are Unix filters. Each of them exports three players, drawn as triangles; the

player on the left represents the input stream "standard in", while the players on the right represent the output streams "standard out" and "standard error.“

Between the two components is a connector, which represents a Unix pipe.

The connect exports two roles: the one dangling to the left represents the pipe's source; the one dangling to the right represents the pipe's sink.

Contd… In the picture above, there is no interactive among the

components and connectors; nothing is "hooked up." To specify that there should be a connection, a player must be associated with a role.

In the graphical editor, this is done by dragging the role over the player and dropping it. The result of dragging the pipe's sink and dropping it on B's input is shown here:

Contd… By associating players and roles, a whole configuration of

interacting parts can be specified. The current version of UniCon supports not only pipe-and-

filter systems like those above, but also modules interacting with procedure calls and shared data, distributed systems with RPC calls, processes that share processors according to various real-time disciplines, and databases accessed with SQL commands.

ACME

Acme started back in 1995 as an ADL interchange language but has evolved to an ADL itself

Three fundamental capabilities:1) Architectural interchange2) Extensible foundation for new design and analysis

tools3) Architecture descriptionAcme language definition and tool developer library

(java and C++) available for download. AcmeStudio IDE and HTML documentation generator also available

Acme Code ExampleDescribe a simple pipe-filter family. This family definition demonstrates Acme's ability to specify a family of// architectures as well as individual architectural instances. An Acme family includes a set of component,

connector, port and// role types that define the design vocabulary provided by the family.Family PipeFilterFam = {// Declare component typesComponent Type FilterT = {// All filters define at least two ports

Ports { stdin; stdout; };Property throughput : int;};// Extend the basic filter type with a subclass (inheritance)Component Type UnixFilterT extends FilterT with {Port stderr;Property implementationFile : String;};// Declare the pipe connector type. Like component types, a connector type also describes required structure.Connector Type PipeT = {Roles { source; sink; };Property bufferSize : int;};

AcmeStudio

Graphical editor for architectural designs Edit designs in existing families (styles), or create

new families and types Create new diagram styles based on visualization

conventions you define Integrated Armani constraint checker to check

architectural design rules Implemented as Eclipse plug-in for portability and

extensibility Available for Windows, Linux, and (soon) MacOS X

xADL Based on xArch: standard, extensible XML-based

representation for software architectures Features:

1) Highly extensible

2) Tool support

3) Clear distinction between architecture prescription and description (design and runtime)

General set of extensions JavaAPI for DOM based access. Tool to generate API using

the schema

xADL example

Component: At circuit structural level, components are NMOS/PMOSConnector: connectors are wire,Interface: input/output portsLink: