Date post: | 07-Aug-2015 |
Category: |
Documents |
Upload: | indra-jith |
View: | 9 times |
Download: | 0 times |
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: