To meet Wikipedia's quality standards, this article or section may require cleanup because it is in a list format that may be better presented using prose.
You can help by converting this section to prose, if appropriate. Editing help is available. (August 2008)
The following reasons would be better served if there were a standard notation (ADL) for representing architectures:
Mutual communication
Embodiment of early design decisions
Transferable abstraction of a system
Architectures in the past were largely represented by box-and-line drawing. The following things are usually defined in such a drawing:
Nature of the component
Component properties
Semantics of connections
Behavior of a system as a whole
ADLs result from a linguistic approach to the formal representation of architectures, and as such they address its shortcomings. Also important, sophisticated ADLs allow for early analysis and feasibility testing of architectural design decisions.
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.
Programming languages, because ADLs do not bind architectural abstractions to specific point solutions
Modeling languages, because ADLs tend to focus on representation of components rather than the behavior of the whole. Although, there are domain specific modeling languages (DSMLs) that focus on representation of components.
The following list is a minimal set of requirements for a language to be an ADL. The languages 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 analysis
Handle different instantiations of the same architecture, in relation to product line architectures
Positive elements of ADL
ADLs represent a formal way of representing architecture
ADLs are intended to be both human and machine readable
ADLs support describing a system at a higher level than previously possible
ADLs permit analysis of architectures – completeness, consistency, ambiguity, and performance
ADLs can support automatic generation of software systems
Negative elements of ADL
There is not 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 ADL work today has been undertaken with academic rather than commercial goals in mind
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 :
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.
Architecture vs. design
So what is the difference between architecture and design? Architecture casts non-functional decisions and partition functional requirements, whereas design is a principle through which functional requirements are accomplished. Architectural heuristic means that it is necessary to go one level deeper to validate choices, so the architect has to do a high-level design to validate the partitioning.
Examples
Below the list gives the candidates for being the best ADL until now