Software architecture: Difference between revisions

Revision as of 19:23, 15 January 2020

Revision as of 12:22, 19 January 2020

Line 1:

<br />{{Software development process}}

'''Software architecture''' refers to the fundamental structures of a [[software system]] and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.<ref name="DSA2">{{cite book|last=Clements|first=Paul|author2=Felix Bachmann |author3-link=Len Bass|author3=Len Bass |author4=David Garlan |author5=James Ivers |author6=Reed Little |author7=Paulo Merson |author8=Robert Nord |author9=Judith Stafford |title=Documenting Software Architectures: Views and Beyond, Second Edition|publisher = Addison-Wesley|year=2010|___location=Boston|isbn=978-0-321-55268-6}}</ref> The ''architecture'' of a software system is a metaphor, analogous to the [[architecture]] of a building.<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 | url = http://users.ece.utexas.edu/~perry/work/papers/swa-sen.pdf| citeseerx = 10.1.1.40.5174 }}</ref> It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.<ref>{{Cite web|url=https://www.sei.cmu.edu/research-capabilities/all-work/display.cfm?customel_datapageid_4050=21328|title=Software Architecture|website=www.sei.cmu.edu|language=en|access-date=2018-07-23}}</ref>

Software architecture is about making fundamental structural choices that are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of the software. For example, the systems that controlled the [[Space Shuttle]] launch vehicle had the requirement of being very fast and very reliable. Therefore, an appropriate [[real-time computing]] language would need to be chosen. Additionally, to satisfy the need for reliability the choice could be made to have multiple redundant and independently produced copies of the program, and to run these copies on independent hardware while cross-checking results.

Documenting software architecture facilitates communication between [[Stakeholder (corporate)#In management|stakeholders]], captures early decisions about the high-level design, and allows reuse of design components between projects.<ref name="SAP2">{{cite book|last=Bass|first=Len|author2=Paul Clements |author3=Rick Kazman |title=Software Architecture in Practice, Third Edition|publisher = Addison-Wesley|year=2012|___location=Boston|isbn=978-0-321-81573-6}}</ref>{{rp|29–35}}

{{cite book|last=Bass|first=Len|author2=Paul Clements |author3=Rick Kazman |title=Software Architecture in Practice, Third Edition|publisher = Addison-Wesley|year=2012|___location=Boston|isbn=978-0-321-81573-6}}</ref>{{rp|29–35}}

==Scope==

Opinions vary as to the scope of software architectures:<ref>{{cite web|author=SEI|title= How do you define Software Architecture?|url= http://www.sei.cmu.edu/architecture/start/glossary/definition-form.cfm |year=2006|accessdate=2012-09-12}}</ref>

* ''Overall, macroscopic'Macroscopic system structure'';<ref>{{cite web|author=Garlan & Shaw |title= An Introduction to Software Architecture |url= https'://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf |year=1994|accessdate=2012-09-13}}</ref> this refers to architecture as a higher -level [[Abstraction (computer science)|abstraction]] of a software system that consists of a collection of computational ''components'' together with ''connectors'' that describe the interaction between these components.<ref>{{cite web|author=Garlan & Shaw |title= An Introduction to Software Architecture |url= https://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf |year=1994|accessdate=2012-09-13}}</ref>

* '''The important stuff—whatever that is'';': this refers to the fact that software architects should concern themselves with those decisions that have high impact on the system and its stakeholders.<ref name="FOWL2003">{{Cite journal | last1 = Fowler | first1 = M.Martin | title = Design – Who needs an architect? | doi = 10.1109/MS.2003.1231144 | journal = IEEE Software | volume = 20 | issue = 5 | pages = 11–44 | year = 2003 }}</ref> this refers to the fact that software architects should concern themselves with those decisions that have high impact on the system and its stakeholders.

* '''That which is fundamental to understanding a system in its environment"'''<ref>[http://www.iso-architecture.org/42010/defining-architecture.html ISO/IEC/IEEE 42010: Defining "architecture"]. Iso-architecture.org. Retrieved on 2013-07-21.</ref>

* '''Things that people perceive as hard to change'';<ref name="FOWL2003"/>': since designing the architecture takes place at the beginning of a software system's lifecycle, the architect should focus on decisions that "have to" be right the first time. Following this line of thought, architectural design issues may become non-architectural once their irreversibility can be overcome.<ref name="FOWL2003"/>

* '''A set of architectural design decisions'';<ref name="jansen05" />': software architecture should not be considered merely a set of models or structures, but should include the decisions that lead to these particular structures, and the rationale behind them.<ref name="jansen05" /> This insight has led to substantial research into software architecture [[knowledge management]].<ref name="AKM">{{cite book |title=Software Architecture Knowledge Management |last1=Ali Babar |first1=Muhammad|last2=Dingsoyr|first2=Torgeir|last3=Lago|first3=Patricia|last4=van Vliet|first4=Hans|year=2009 |publisher=Springer|___location=Dordrecht Heidelberg London New York |isbn=978-3-642-02373-6}}</ref>

There is no sharp distinction between software architecture versus design and requirements engineering (see [[#Related fields|Related fields]] below). They are all part of a "chain of intentionality" from high-level intentions to low-level details.<ref name="FAIRBANKS2010">{{cite book|author=George Fairbanks|title=Just Enough Software Architecture|year=2010|publisher=Marshall & Brainerd}}</ref>{{rp|18}}

Line 54:

==History==

The comparison between software design and (civil) architecture was first drawn in the late 1960s,<ref>{{cite web |editor1=P. Naur |editor2=B. Randell |title=Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968 |publisher=NATO, Scientific Affairs Division |___location=Brussels |year=1969 |url=http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF |accessdate=2012-11-16}}</ref> but the term ''"software architecture''" becamedid prevalentnot onlysee inwidespread theusage beginning ofuntil the 1990s.<ref>{{Cite journal|author1=P. Kruchten |author2=H. Obbink |author3=J. Stafford |title=The past, present and future of software architecture|journal=IEEE Software |volume=23 |issue=2 |pages=22 |year=2006|doi=10.1109/MS.2006.59 }}</ref> The field of [[computer science]] had encountered problems associated with complexity since its formation.<ref>{{cite web|author=University of Waterloo|title= A Very Brief History of Computer Science |url=http://www.cs.uwaterloo.ca/~shallit/Courses/134/history.html |year=2006|accessdate=2006-09-23}}</ref> Earlier problems of complexity were solved by developers by choosing the right [[data structure]]s, developing [[algorithm]]s, and by applying the concept of [[separation of concerns]]. Although the term "software architecture" is relatively new to the industry, the fundamental principles of the field have been applied sporadically by [[software engineering]] pioneers since the mid-1980s. Early attempts to capture and explain software architecture of a system were imprecise and disorganized, often characterized by a set of box-and-line [[diagram]]s.<ref>{{Cite journal|author=IEEE Transactions on Software Engineering|title= Introduction to the Special Issue on Software Architecture |year=2006|doi= 10.1109/TSE.1995.10003 }}</ref>

The field of [[computer science]] had encountered problems associated with complexity since its formation.<ref>{{cite web|author=University of Waterloo|title= A Very Brief History of Computer Science |url=http://www.cs.uwaterloo.ca/~shallit/Courses/134/history.html |year=2006|accessdate=2006-09-23}}</ref> Earlier problems of complexity were solved by developers by choosing the right [[data structure]]s, developing [[algorithm]]s, and by applying the concept of [[separation of concerns]]. Although the term "software architecture" is relatively new to the industry, the fundamental principles of the field have been applied sporadically by [[software engineering]] pioneers since the mid-1980s. Early attempts to capture and explain software architecture of a system were imprecise and disorganized, often characterized by a set of box-and-line [[diagram]]s.

<ref>{{Cite journal|author=IEEE Transactions on Software Engineering|title= Introduction to the Special Issue on Software Architecture |year=2006|doi= 10.1109/TSE.1995.10003 }}</ref>

Software architecture as a concept has its origins in the research of [[Edsger Dijkstra]] in 1968 and [[David Parnas]] in the early 1970s. These scientists emphasized that the structure of a software system matters and getting the structure right is critical. During the 1990s there was a concerted effort to define and codify fundamental aspects of the discipline, with research work concentrating on architectural styles ([[patterns]]), [[architecture description language]]s, [[Software documentation#Architecture/Design documentation|architecture documentation]], and [[formal method]]s.<ref>{{cite web|author=Garlan & Shaw |title= An Introduction to Software Architecture |url= https://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf |year=1994|accessdate=2006-09-25}}</ref>

Line 62 ⟶ 60:

Research institutions have played a prominent role in furthering software architecture as a discipline. [[Mary Shaw (computer scientist)|Mary Shaw]] and David Garlan of [[Carnegie Mellon]] wrote a book titled ''Software Architecture: Perspectives on an Emerging Discipline'' in 1996, which promoted software architecture concepts such as [[software component|components]], connectors, and styles. The [[University of California, Irvine]]'s Institute for Software Research's efforts in software architecture research is directed primarily in architectural styles, architecture description languages, and dynamic architectures.

[[IEEE 1471]]-2000, ''"Recommended Practice for Architecture Description of Software-Intensive Systems''", was the first formal standard in the area of software architecture. It was adopted in 2007 by ISO as [[IEEE 1471|ISO/IEC 42010:2007]]. In November 2011, IEEE 1471–2000 was superseded by [[ISO/IEC 42010|ISO/IEC/IEEE 42010:2011]], ''"Systems and software engineering – Architecture description''" (jointly published by IEEE and ISO).<ref name="ISO42010">{{cite web|author=ISO/IEC/IEEE|title=ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description|url=http://www.iso.org/iso/catalogue_detail.htm?csnumber=50508|year=2011|accessdate=2012-09-12}}</ref>

While in [[IEEE 1471]], software architecture was about the architecture of "software-intensive systems", defined as "any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole", the 2011 edition goes a step further by including the [[ISO/IEC 15288]] and [[ISO/IEC 12207]] definitions of a system, which embrace not only hardware and software, but also "humans, processes, procedures, facilities, materials and naturally occurring entities". This reflects the relationship between software architecture, [[enterprise architecture]] and [[solution architecture]].

Line 92 ⟶ 90:

* '''Knowledge management and communication''' is the act of exploring and managing knowledge that is essential to designing a software architecture. A software architect does not work in isolation. They get inputs, functional and non-functional requirements, and design contexts, from various stakeholders; and provides outputs to stakeholders. Software architecture knowledge is often tacit and is retained in the heads of stakeholders. Software architecture knowledge management activity is about finding, communicating, and retaining knowledge. As software architecture design issues are intricate and interdependent, a knowledge gap in design reasoning can lead to incorrect software architecture design.<ref name="Kruchten 2008" /><ref name="SAKM">{{cite book|last1=Babar|first1=M.A.|last2=Dingsøyr|first2=T.|last3=Lago|first3=P.|last4=Vliet|first4=H. van|title=Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition|publisher = Springer|year=2009|isbn=978-3-642-02373-6}}</ref> Examples of knowledge management and communication activities include searching for design patterns, prototyping, asking experienced developers and architects, evaluating the designs of similar systems, sharing knowledge with other designers and stakeholders, and documenting experience in a wiki page.

* '''Design reasoning and decision making''' is the activity of evaluating design decisions. This activity is fundamental to all three core software architecture activities.<ref name="jansen05">{{Cite book | last1 = Jansen | first1 = A. | last2 = Bosch | first2 = J. | doi = 10.1109/WICSA.2005.61 | chapter = Software Architecture as a Set of Architectural Design Decisions | title = 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05) | pages = 109 | year = 2005 | isbn = 978-0-7695-2548-8 | pmid = | pmc = | citeseerx = 10.1.1.60.8680 }}</ref><ref name="tang09">{{Cite journal | last1 = Tang | first1 = A. | last2 = Han | first2 = J. | last3 = Vasa | first3 = R. | doi = 10.1109/MS.2009.46 | title = Software Architecture Design Reasoning: A Case for Improved Methodology Support | journal = IEEE Software | volume = 26 | issue = 2 | pages = 43 | year = 2009 | pmid = | pmc = | hdl = 1959.3/51601 }}</ref> It entails gathering and associating decision contexts, formulating design decision problems, finding solution options and evaluating tradeoffs before making decisions. This process occurs at different levels of decision granularity while evaluating significant architectural requirements and software architecture decisions, and software architecture analysis, synthesis, and evaluation. Examples of reasoning activities include understanding the impacts of a requirement or a design on quality attributes, questioning the issues that a design might cause, assessing possible solution options, and evaluating the tradeoffs between solutions.

* '''Documentation''' is the act of recording the design generated during the software architecture process. System design is described using several views that frequently include a static view showing the code structure of the system, a dynamic view showing the actions of the system during execution, and a deployment view showing how a system is placed on hardware for execution. Kruchten's 4+1 view suggests a description of commonly used views for documenting software architecture;<ref name="Kru95">{{cite journal |last=Kruchten |first=Philippe |year=1995 |url=http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf |title=Architectural Blueprints – The '4+1' View Model of Software Architecture |journal=IEEE Software |volume=12 |issue=6 |pages=42–50 |doi=10.1109/52.469759}}</ref> ''Documenting Software Architectures: Views and Beyond'' has descriptions of the kinds of notations that could be used within the view description.<ref name="DSA2" /> Examples of documentation activities are writing a specification, recording a system design model, documenting a design rationale, developing a viewpoint, documenting views.

== Software architecture topics ==