Content deleted Content added
Allforrous (talk | contribs) →External links: Commonscat template. |
JairCLeite (talk | contribs) →History: new citation and reference |
||
| (29 intermediate revisions by 15 users not shown) | |||
Line 1:
{{Short description|Standardized language on architecture description}}
{{External links|date=August 2020}}
Line 10 ⟶ 11:
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]],
Most of the writing below refers primarily to the perspective
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 ([[
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
▲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 | 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. | author-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 | 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."
Since then, a thread of research on formal languages for
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 32:
==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
'''Minimal requirements'''
Line 56:
===Positive elements of ADL===
* ADLs are a formal way of representing architecture
* ADLs are intended to be both human and machine
* 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 89:
==Architecture vs. design==
Architecture, in the context of software systems, is roughly divided into categories, primarily software architecture, network architecture, and systems architecture.
Design is the abstraction and specification of patterns and organs of functionality that have been or will be implemented.
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.
The process of defining an architecture may involve heuristics, acquired by the architect or architectural team through experience within the ___domain.
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]]
* [[Architecture Analysis & Design Language]]
* [[Darwin (ADL)]]
* [[EAST-ADL]]
* [[Wright (ADL)]]
* [https://sysadl.imd.ufrn.br SysADL]
==Approaches to system architecture==▼
{{expand section|citations, an introduction, and context|date=September 2022}}
▲** [[C4 model (software)|C4 model]]
▲==Approaches to architecture==
* Academic approach
** focus on analytic evaluation of architectural models
Line 153 ⟶ 128:
* [[Architecture Analysis and Design Language|AADL]]
* [[Darwin (ADL)|Darwin]]
* [[Scripting language]]
* [https://sysadl.imd.ufrn.br SysADL]
* [[Hardware description language]]
| |||