Architecture description language: Difference between revisions

Revision as of 02:50, 23 March 2020

Latest revision as of 13:34, 20 August 2025

(36 intermediate revisions by 21 users not shown)

Line 1:

{{Short description|Standardized language on architecture description}}

{{External links|date=August 2020}}

'''Architecture description languages''' ('''ADLs''') are used in several disciplines: [[system engineering]], [[software engineering]], and [[enterprise modelling]] and engineering.

The system engineering community uses an architecture description language as a language and/or a [[conceptual model]] to describe and represent [[system architecture]]s.

The software engineering community uses an architecture description language as a [[computer language]] to create a [[Software architecture description|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 (computer science)|functional architecture]] is communicated to various stakeholders and users. Some ADLs that have been developed are: [[Acme (ADL)|Acme]] (developed by [[Carnegie Mellon University|CMU]]), [[Architecture Analysis and Design Language|AADL]] (standardized by the [[Society of Automotive Engineers|SAE]]), [[C2 (ADL)|C2]] (developed by [[University of California, Irvine|UCI]]), SBC-ADL (developed by [[National Sun Yat-Sen University]]), [[Darwin (ADL)|Darwin]] (developed by [[Imperial College London]]), and [[Wright (ADL)|Wright]] (developed by [[Carnegie Mellon University|CMU]]).

==Overview==

The [[ISO/IEC 42010|ISO/IEC/IEEE 42010]]<ref>{{Cite web |url=http://www.iso-architecture.org/42010/docs/ISO-IEC-IEEE-latest-draft-42010.pdf |author=ISO/IECJTC 1/SC 7 Committee |title=ISO/IEC FDIS42010 |date=2011-03-01 |access-date=2011-12-05 |archive-url=https://web.archive.org/web/20120426010747/http://www.iso-architecture.org/42010/docs/ISO-IEC-IEEE-latest-draft-42010.pdf |archive-date=2012-04-26 |url-status=dead }}</ref> document, ''Systems and software engineering—Architecture description'', defines an architecture description language as "any form of expression for use in architecture descriptions" and specifies [[ISO/IEC 42010#Architecture Description Language|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]]), [[Jan Dietz#DEMO|DEMO]], [[Avolution|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 fromof 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.

==History==

ADLs have been classified into three broad categories: box-and-line informal drawings, formal architecture description language, and UML ([[Unifiedunified Modelingmodeling Languagelanguage]])-based notations.

Box-and-line have been for a long time the most predominant means for describing software architectures. While providing useful documentation, the level of informality limited the usefulness of the architecture description. A more rigorous way for describing SAssoftware architectures was required. Quoting Allen and Garlan (1997),<ref name="Allen1997">{{Cite journal | last1 = Allen | first1 = R. | last2 = Garlan | first2 = D. | doi = 10.1145/258077.258078 | title = A formal basis for architectural connection | journal = ACM Transactions on Software Engineering and Methodology | volume = 6 | issue = 3 | pages = 213 | year = 1997 | pmid = | pmc = | citeseerx = 10.1.1.40.66 | s2cid = 326385 }}</ref> "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),<ref name="PERRY1992">{{Cite journal | last1 = Perry | first1 = D. E. | last2 = Wolf | first2 = A. L. | authorlink2author-link2 = Alexander L. Wolf| doi = 10.1145/141874.141884 | title = Foundations for the study of software architecture | journal = [[ACM SIGSOFT Software Engineering Notes]]| volume = 17 | issue = 4 | pages = 40 | year = 1992 | pmid = | pmc = | url = http://users.ece.utexas.edu/~perry/work/papers/swa-sen.pdf| citeseerx = 10.1.1.40.5174 | s2cid = 628695 }}</ref> 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."

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),<ref name="Allen1997">{{Cite journal | last1 = Allen | first1 = R. | last2 = Garlan | first2 = D. | doi = 10.1145/258077.258078 | title = A formal basis for architectural connection | journal = ACM Transactions on Software Engineering and Methodology | volume = 6 | issue = 3 | pages = 213 | year = 1997 | pmid = | pmc = | citeseerx = 10.1.1.40.66 }}</ref> "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),<ref name="PERRY1992">{{Cite journal | last1 = Perry | first1 = D. E. | last2 = Wolf | first2 = A. L. | authorlink2 = Alexander L. Wolf| doi = 10.1145/141874.141884 | title = Foundations for the study of software architecture | journal = [[ACM SIGSOFT Software Engineering Notes]]| volume = 17 | issue = 4 | pages = 40 | year = 1992 | pmid = | pmc = | url = http://users.ece.utexas.edu/~perry/work/papers/swa-sen.pdf| citeseerx = 10.1.1.40.5174 }}</ref> 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 SAsoftware architecture 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,<ref name=AADL>{{cite web |title= AADL — Architecture Analysis and Design Language |publisher=Software Engineering Institute, Carnegie Mellon University |date=July 2019 |url= http://www.aadl.info}}</ref> EAST-ADL,<ref>{{cite web|title= EAST-ADL |url= http://www.east-adl.info/}}</ref> and EADL<ref name="EADL">{{Cite journal | last1 = Li | first1 = J. | last2 = Pilkington | first2 = N. T. | last3 = Xie | first3 = F. | last4 = Liu | first4 = Q. | title = Embedded architecture description language | doi = 10.1016/j.jss.2009.09.043 | journal = Journal of Systems and Software | volume = 83 | issue = 2 | pages = 235 | year = 2010 | pmid = | pmc = | citeseerx = 10.1.1.134.8898 | s2cid = 8075069 }}</ref>), control-loop applications (DiaSpec<ref>{{cite web |title= AADL |url= http://www.diaspec.com/ |access-date= 2012-12-10 |archive-url= https://web.archive.org/web/20130601210552/http://diaspec.com/ |archive-date= 2013-06-01 |url-status= dead }}</ref>), product line architectures (Koala<ref name="KOALA">{{Cite journal | last1 = Van Ommering | first1 = R. | last2 = Van Der Linden | first2 = F. | last3 = Kramer | first3 = J. | last4 = Magee | first4 = J. | title = The Koala component model for consumer electronics software | doi = 10.1109/2.825699 | journal = Computer | volume = 33 | issue = 3 | pages = 78 | year = 2000 | pmid = | pmc = | citeseerx = 10.1.1.469.8243 }}</ref>), and dynamic systems (Π-ADL<ref name="Oquendo2004">{{cite journal|last1=Oquendo|first1=Flavio|title=π-ADL|journal=ACM SIGSOFT Software Engineering Notes|volume=29|issue=3|year=2004|pages=11–14|issn=0163-5948|doi=10.1145/986710.986728|s2cid=10781129}}</ref>)). 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<ref name="FRACTAL">{{Cite journal | doi = 10.1002/spe.767| title = The FRACTAL component model and its support in Java| journal = Software: Practice and Experience| volume = 36| issue = 11–12| pages = 1257| year = 2006| last1 = Bruneton | first1 = E. | last2 = Coupaye | first2 = T. | last3 = Leclercq | first3 = M. | last4 = Quéma | first4 = V. | last5 = Stefani | first5 = J. B. | citeseerx = 10.1.1.471.4374| s2cid = 12541723}}</ref>)), and trustworthiness analysis (TADL<ref>{{cite webthesis|title= TADL|url= http://spectrum.library.concordia.ca/7057/|date= 2009-04-29|publisher= Concordia University|type= phd|last1= Mohammad|first1= Mubarak Sami}}</ref>).

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,<ref name="Woods2005">{{Cite book | last1 = Woods | first1 = E. | last2 = Hilliard | first2 = R. | doi = 10.1109/WICSA.2005.15 | chapter = Architecture Description Languages in Practice Session Report | title = 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05) | pages = 243 | year = 2005 | isbn = 978-0-7695-2548-8 | pmids2cid = | pmc =18175375 }}</ref> Pandey,<ref name="Pandey2010">{{Cite journal | last1 = Pandey | first1 = R. K. | title = Architectural description languages (ADLs) vs UML | doi = 10.1145/1764810.1764828 | journal = ACM SIGSOFT Software Engineering Notes | volume = 35 | issue = 3 | pages = 11–5 | year = 2010 | pmids2cid = | pmc =18848376 }}</ref> Clements,<ref name="ClementsSurvey">{{Cite book | last1 = Clements | first1 = P. C. | chapter = A survey of architecture description languages | doi = 10.1109/IWSSD.1996.501143 | title = Proceedings of the 8th International Workshop on Software Specification and Design | pages = 16–00 | year = 1996 | isbn = 978-0-8186-7361-0 | pmid = | pmc = | citeseerx = 10.1.1.208.3401 | s2cid = 7307554 }}</ref> 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, [[Unified Modeling Language|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.<ref>{{cite web|title= Garlan_TR |date= 31 March 2004|url= http://www.sei.cmu.edu/library/abstracts/reports/04tr008.cfm}}</ref><ref>{{Cite book | last1 = Pérez-Martínez | first1 = J. E. | last2 = Sierra-Alonso | first2 = A. | chapter = UML 1.4 versus UML 2.0 as Languages to Describe Software Architectures | doi = 10.1007/978-3-540-24769-2_7 | title = Software Architecture | series = Lecture Notes in Computer Science | volume = 3047 | pages = 88 | year = 2004 | isbn = 978-3-540-22000-8 | pmidchapter-url = http://oa.upm.es/33081/ }}</ref><ref name="SysADL">{{Cite book | pmclast1 = Oquendo| first1 = F. | last2 = Leite | first2 = J.C. | last3 = Batista| first3 = T.B. | title = Software Architecture in Action: : Designing and Executing Architectural Models with SysADL. | year = 2016 | isbn = 978-3319443379 }}</ref>

InA fact, as highlighted in a recent2013 study conducted with practitioners,<ref name="IndustrySurvey">{{cite journal| first1 = Ivano| last1 = Malavolta| first2 = Patricia| last2 = Lago| first3 = Henry| last3 = Muccini| first4 = Patrizio| last4 = Pelliccione| first5 = Antony| last5 = Tang | year = 2013 | title = What Industry Needs from Architectural Languages: A Survey | journal = IEEE Transactions on Software Engineering | volume = 39 | issue = 6 | pages = 869–891| doi = 10.1109/TSE.2012.74| s2cid = 6383726}}</ref> whilstfound that practitioners arewere generally satisfied with the design capabilities provided byof the languagesADLS they useused, theybut arehad dissatisfiedseveral major concerns with thethem: architecturalthey languagelacked analysis features and theirthe abilitiesability to define extra-functional properties; architectural languagesthose used in practice mostly originateoriginated from industrial development insteadrather of fromthan academic research; they needed more formality and better usability are required of an architectural language.

==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. They differ from programming languages, because ADLs do notdon't 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.

'''Minimal requirements'''

Line 54 ⟶ 56:

===Positive elements of ADL===

* ADLs are 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 and assessment of architectures, for completeness, consistency, ambiguity, and performance

Line 87 ⟶ 89:

==Architecture vs. design==

Architecture, in the context of software systems, is roughly divided into categories, primarily software architecture, network architecture, and systems architecture. Within each of these categories, there is a tangible but fuzzy distinction between architecture and design. To draw this distinction as universally and clearly as possible, it is best to consider design as a noun rather than as a verb, so that the comparison is between two nouns.

Design is the abstraction and specification of patterns and organs of functionality that have been or will be implemented. Architecture is both a degree higher in both abstraction and coarser in granularity. Consequentially, architecture is also more topological (i.e. overall structure and relationship between components) in nature than design (i.e. specific details and implementation), in that it specifies where major components meet and how they relate to one another. Architecture focuses on the partitioning of major regions of functionality into high level components, where they will physically or virtually reside, what off-the-shelf components may be employed effectively, in general what interfaces each component will expose, what protocols will be employed between them, and what practices and high level patterns may best meet [[extensibility]], [[maintainability]], reliability, durability, [[scalability]], and other non-functional objectives. Design is a detailing of these choices and a more concrete clarification of how functional requirements will be met through the delegation of pieces of that functionality to more granular components and how these smaller components will be organized within the larger ones.

Oftentimes, a portion of architecture is done during the conceptualization of an application, system, or network, and may appear in the non-functional sections of requirement documentation. Canonically, design is not specified in requirements, but is rather driven by them.

The process of defining an architecture may involve heuristics, acquired by the architect or architectural team through experience within the ___domain. As with design, architecture often evolves through a series of iterations, and just as the wisdom of a high level design is often tested when low level design and implementation occurs, the wisdom of an architecture is tested during the specification of a high level design. In both cases, if the wisdom of the specification is called into question during detailing, another iteration of either architecture or design, as the case may be, may become necessary.

In summary, the primary differences between architecture and design are ones of granularity and abstraction, and (consequentially) chronology. (Architecture generally precedes design, although overlap and circular iteration is a common reality.)

==Examples==

* [[ArchiMate]]

Below the list gives the candidates for being the best {{citation needed|date=March 2012}} ADL to date.

* [[Architecture Analysis & Design Language]]

* [[C4 model (software)]]

For an up-to-date list of currently existing architectural languages, please refer [https://web.archive.org/web/20151121185404/http://www.di.univaq.it/malavolta/al/ Up-to-date list of ADLs].

* [[Darwin (ADL)]]

* [[EAST-ADL]]

* Primary candidates

* [[Wright (ADL)]]

** [http://www.avolution.com.au ABACUS (UTS)]

* [https://sysadl.imd.ufrn.br SysADL]

** [http://www-2.cs.cmu.edu/~acme/ ACME / ADML (CMU/USC)]

** [http://www.opengroup.org/architecture/adml/adml_home.htm ADML (No longer in development)]

** [http://byadl.di.univaq.it ByADL (Build Your ADL) - University of L'Aquila]

** [http://lepus.org.uk/ LePUS3 and Class-Z (University of Essex)]

** [http://complexevents.com/stanford/rapide/ Rapide (Stanford)]

** [http://www-2.cs.cmu.edu/afs/cs/project/able/www/wright/index.html Wright (CMU)]

** Unicon (CMU)

* Secondary candidates

** [https://www.cs.cmu.edu/afs/cs/project/able/www/aesop/aesop_home.html Aesop (CMU)]

** MetaH (Honeywell)

** [[Architecture Analysis & Design Language|AADL]] (SAE) - '''A'''rchitecture '''A'''nalysis & '''D'''esign '''L'''anguage

** [https://web.archive.org/web/20010813004108/http://www.ics.uci.edu/pub/arch/ C2 SADL] (UCI)

** SADL (SRI) - '''S'''ystem '''A'''rchitecture '''D'''escription '''L'''anguage

* Others (unclassified)

** Lileanna - '''L'''ibrary '''I'''nterconnect '''L'''anguage '''E'''xtended with '''Ann'''otated '''A'''da

** [http://dually.di.univaq.it Dually: Providing Architectural Languages and Tools Interoperability through Model Transformation Technologies]

** [http://archc.sourceforge.net/ ArchC] [[SystemC]]-like, focus on [[instruction set]]s & [[memory model (computing)|memory models]].

** [http://caosd.lcc.uma.es/AO-ADL.htm AO-ADL]

** [https://web.archive.org/web/20080821101652/http://www.archimate.org/ ArchiMate] An example of an ADL for enterprise architecture

** [https://web.archive.org/web/20070702200852/http://caosd.lcc.uma.es/CAM-DAOP/DAOP-ADL.htm DAOP-ADL]

** [https://www.amazon.com/dp/3540291695 DEMO] Another example of an enterprise architecture ADL

** [https://web.archive.org/web/20130823003552/http://diaspec.bordeaux.inria.fr/ DiaSpec] an approach and tool to generate a distributed framework from a software architecture

** [http://www.mcc.com/projects/ssepp SSEP]

** [https://www.cs.cmu.edu/afs/cs/project/vit/www/unicon/index.html Unicon]

** [http://www.isr.uci.edu/projects/xarchuci/ xADL]

==Approaches to system architecture==

{{expand section|citations, an introduction, and context|date=September 2022}}

Approaches to architecture

* Academic approach

** focus on analytic evaluation of architectural models

Line 150 ⟶ 128:

* [[Architecture Analysis and Design Language|AADL]]

* [[Darwin (ADL)|Darwin]]

* [[Avolution|ABACUS]]

* [[Scripting language]]

* [https://sysadl.imd.ufrn.br SysADL]

* [[Hardware description language]]

Line 158 ⟶ 136:

==External links==

{{Commonscat}}

* {{cite journal |first=N. |last=Medvidovic |first2=R.N. |last2=Taylor |doi=10.1109/32.825767 | title = A Classification and Comparison Framework for Software Architecture Description Languages | journal = IEEE Transactions on Software Engineering | volume = 26 | issue = 1 | date = January 2000 |pages=70–93}}

* {{cite journal |first1=N. |last1=Medvidovic |first2=R.N. |last2=Taylor |doi=10.1109/TSE32.2012.74825767 | title = WhatA IndustryClassification Needsand fromComparison ArchitecturalFramework Languages:for ASoftware SurveyArchitecture Description Languages | journal = IEEE Transactions on Software Engineering | volume = 3926 | issue = 61 | pagesdate = 869–891January | year = 20132000 | last1 pages= Malavolta | first1 = Ivano | last2 = Lago | first2 = Patricia | last3 = Muccini | first3 = Henry | last4 = Pelliccione | first4 = Patrizio | last5 = Tang | first5 = Antony 70–93}}

* {{cite journal |doi=10.1109/TSE.2012.74 | title = What Industry Needs from Architectural Languages: A Survey | journal = IEEE Transactions on Software Engineering | volume = 39 | issue = 6 | pages = 869–891 | year = 2013 | last1 = Malavolta | first1 = Ivano | last2 = Lago | first2 = Patricia | last3 = Muccini | first3 = Henry | last4 = Pelliccione | first4 = Patrizio | last5 = Tang | first5 = Antony | s2cid = 6383726 }}

* [https://web.archive.org/web/20150909170715/http://www.mrtc.mdh.se/han/FoPlan/ass2-bjornander.pdf Architecture Description Languages] // Mälardalen University

* {{cite book |first=P.C. |last=Clements |chapter=A survey of architecture description languages |chapterurlchapter-url=http://splc.sei.cmu.edu/library/assets/Survey_of_ADLs.pdf |title=Proceedings of the 8th International Workshop on Software Specification and Design |year=1996 |isbn=0-8186-7361-3 |pages=16–25 |doi=10.1109/IWSSD.1996.501143 |s2cid=7307554 |archive-url=https://web.archive.org/web/20131224115957/http://splc.sei.cmu.edu/library/assets/Survey_of_ADLs.pdf |archive-date=2013-12-24 }}

* [http://www.avolution.com.au ABACUS]

* [https://www.cs.cmu.edu/~acme ACME]

Line 173 ⟶ 152:

* [https://www.amazon.com/dp/3540291695 DEMO] Another example of an enterprise architecture ADL

* [https://web.archive.org/web/20130823003552/http://diaspec.bordeaux.inria.fr/ DiaSpec] an approach and tool to generate a distributed framework from a software architecture

* {{cite journal |firstfirst1=I. |lastlast1=Malavolta |first2=H. |last2=Muccini |first3=P. |last3=Pelliccione |first4=D. |last4=Tamburri |title=Providing Architectural Languages and Tools Interoperability through Model Transformation Technologies |journal=IEEE Transactions on Software Engineering |volume=36 |issue=1 |pages=119–140 |date=January–February 2010 |doi=10.1109/TSE.2009.51 |s2cid=6825192 }} [http://dually.di.univaq.it DUALLy]

* [http://complexevents.com/stanford/rapide/ Rapide]

* [http://www.mcc.com/projects/ssepp SSEP]

Line 182 ⟶ 161:

{{DEFAULTSORT:Architecture Description Language}}

[[Category:Architecture description language| ]]

[[Category:Computer languages]]

[[Category:Systems architecture]]

[[Category:Software architecture]]

[[Category:Architecture description language]]

[[Category:Programming language classification]]

[[Category:Modeling languages]]