Architecture description language: Difference between revisions

Revision as of 12:31, 24 April 2025

Latest revision as of 13:34, 20 August 2025

(4 intermediate revisions by 4 users not shown)

Line 26:

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 | s2cid = 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 = 1–5 | year = 2010 | s2cid = 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 | 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 | chapter-url = http://oa.upm.es/33081/ }}</ref><ref name="SysADL">{{Cite book | last1 = 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>

A 2013 study<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> found that practitioners were generally satisfied with the design capabilities of the ADLS they used, but had several major concerns with them: they lacked analysis features and the ability to define extra-functional properties; those used in practice mostly originated from industrial development rather than academic research; they needed more formality and better usability.

Line 91:

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 abstraction and coursercoarser 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.

Line 106:

* [[EAST-ADL]]

* [[Wright (ADL)]]

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

==Approaches to system architecture==

Line 128 ⟶ 129:

* [[Darwin (ADL)|Darwin]]

* [[Scripting language]]

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

* [[Hardware description language]]