From Wikipedia, the free encyclopedia - View original article
The software engineering community uses an architecture description language as a computer language to create a description of a software architecture. In the case of a so-called technical architecture, the architecture must be communicated to software developers; a functional architecture is communicated to various stakeholders and users. Some ADLs that have been developed are: Acme (developed by CMU), AADL (standardized by the SAE), C2 (developed by UCI), Darwin (developed by Imperial College London), and Wright (developed by CMU).
The ISO/IEC/IEEE 42010 document, Systems and software engineering—Architecture description, defines an architecture description language as "any form of expression for use in architecture descriptions" and specifies minimum requirements on ADLs.
The enterprise modelling and engineering community have also developed architecture description languages catered for at the enterprise level. Examples include ArchiMate (now a standard of The Open Group), DEMO, ABACUS (developed by the University of Technology, Sydney). These languages do not necessarily refer to software components, etc. Most of them, however, refer to an application architecture as the architecture that is communicated to the software engineers.
Most of the writing below refers primarily to the perspective from the software engineering community.
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, and as such they address its shortcomings. Also important, sophisticated ADLs allow for early analysis and feasibility testing of architectural design decisions.
ADLs have been classified into three broad categories: box-and-line informal drawings, formal architecture description language, and UML-based notations. Box-and-line have been for a long time the most predominant means for describing SAs. While providing useful documentation, the level of informality limited the usefulness of the architecture description. A more rigorous way for describing SAs was required. Quoting Allen and Garlan (1997), "while these [box-and-line] descriptions may provide useful documentation, the current level of informality limits their usefulness. Since it is generally imprecise what is meant by such architectural descriptions, it may be impossible to analyze an architecture for consistency or determine non-trivial properties of it. Moreover, there is no way to check that a system implementation is faithful to its architectural design." A similar conclusion is drawn in Perry and Wolf (1992), which reports that: "Aside from providing clear and precise documentation, the primary purpose of specifications is to provide automated analysis of the documents and to expose various kinds of problems that would otherwise go undetected."
Since then, a thread of research on formal languages for SA description has been carried out. Tens of formal ADLs have been proposed, each characterized by different conceptual architectural elements, different syntax or semantics, focusing on a specific operational domain, or only suitable for different analysis techniques. For example, domain-specific ADLs have been presented to deal with embedded and real-time systems (such as AADL, EAST-ADL, and EADL), control-loop applications (DiaSpec), product line architectures (Koala), and dynamic systems (Π-ADL)). Analysis-specific ADLs have been proposed to deal with availability, reliability, security, resource consumption, data quality and real-time performance analysis (AADL, behavioral analysis (Fractal)), and trustworthiness analysis (TADL).
However, these efforts have not seen the desired adoption by industrial practice. Some reasons for this lack of industry adoption have been analyzed by Woods and Hilliard, Pandey, Clements, and others: formal ADLs have been rarely integrated in the software life-cycle, they are seldom supported by mature tools, scarcely documented, focusing on very specific needs, and leaving no space for extensions enabling the addition of new features.
As a way to overcome some of those limitations, UML has been indicated as a possible successor of existing ADLs. Many proposals have been presented to use or extend the UML to more properly model software architectures.
In fact, as highlighted in a recent study conducted with practitioners, whilst practitioners are generally satisfied with the design capabilities provided by the languages they use, they are dissatisfied with the architectural language analysis features and their abilities to define extra-functional properties; architectural languages used in practice mostly originate from industrial development instead of from academic research; more formality and better usability are required of an architectural language
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. They differ from programming languages, because ADLs do not bind architectural abstractions to specific point solutions. 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.
The language must:
ADLs have in common:
ADLs differ in their ability to:
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:
Most ADLs implement an interface connection architecture.
So what is the difference between architecture and design? Architecture casts non-functional decisions and partitions functional requirements, whereas design specifies or derives functional requirements. The process of defining an architecture may use heuristics or iterative improvements; this may require going a level deeper to validate the choices, so the architect often has to do a high-level design to validate the partitioning.
Below the list gives the candidates for being the best ADL to date
Approaches to Architecture