Software architecture: Difference between revisions

Revision as of 04:21, 6 January 2025

Latest revision as of 10:49, 27 August 2025

(5 intermediate revisions by 4 users not shown)

Line 16:

Software architecture design is commonly juxtaposed with [[software application design]]. Whilst application design focuses on the design of the processes and data supporting the required functionality (the services offered by the system), software architecture design focuses on designing the infrastructure within which application functionality can be realized and executed such that the functionality is provided in a way which meets the system's [[non-functional requirement]]s.

Software architectures can be categorized into two main types: [[Monolithic application|monolith]] and [[Distributed computing|distributed architecture]], each hashaving its own subcategories.<ref name="O'Reilly Media"/>

Software architecture tends to become more complex over time. [[Software architect]]s should use "[[fitness function]]s" to [[Continuous design|continuously]] keep the architecture in check.<ref name="O'Reilly Media"/>

Line 33:

== Software architecture style vs. software architecture pattern ==

{{Main article|List of software architecture styles and patterns}}'''Software Architecture Pattern''' refers to a reusable, proven solution to a recurring problem at the system level, addressing concerns related to the overall structure, component interactions, and quality attributes of the system. Software architecture patterns operate at a higher level of abstraction than software [[Software design pattern|design patterns]], solving broader system-level challenges. While these patterns typically affect system-level concerns, the distinction between architectural patterns and architectural styles can sometimes be blurry. Examples include [[Circuit breaker design pattern|Circuit Breaker]]. <ref name="O'Reilly Media2">{{Cite book |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |year=2020 |isbn=978-1492043454}}</ref><ref name=":0">{{Cite book |title=Design Patterns: Elements of Reusable Object-Oriented Software |isbn=978-0201633610 |last1=Larman |first1=Craig |date=2005 |publisher=Pearson Deutschland GmbH }}</ref><ref name=":1">{{Cite book |title=Patterns of Enterprise Application Architecture |isbn=978-0321127426}}</ref>

'''Software Architecture Style''' refers to a high-level structural organization that defines the overall system organization, specifying how components are organized, how they interact, and the constraints on those interactions. Architecture styles typically include a vocabulary of component and connector types, as well as semantic models for interpreting the system's properties. These styles represent the most coarse-grained level of system organization. Examples include [[Multitier architecture|Layered Architecture]], [[Microservices]], and [[Event-driven architecture|Event-Driven Architecture]]. <ref name="O'Reilly Media2" /><ref name=":0" /><ref name=":1" />

Line 52:

'''Quality-driven:''' classic [[software design]] approaches (e.g. [[Jackson Structured Programming]]) were driven by required functionality and the flow of data through the system, but the current insight<ref name="SAP2"/>{{rp|26–28}} is that the architecture of a software system is more closely related to its [[quality attributes]] such as [[fault-tolerance]], [[backward compatibility]], [[extensibility]], [[reliability (engineering)|reliability]], [[maintainability]], [[availability]], security, usability, and other such –[[ilities]]. Stakeholder concerns often translate into [[requirements]] on these quality attributes, which are variously called [[non-functional requirements]], extra-functional requirements, behavioral requirements, or quality attribute requirements.

'''Recurring styles:''' like building architecture, the software architecture discipline has developed standard ways to address recurring concerns. These "standard ways" are called by various names at various levels of abstraction. Common terms for recurring solutions are architectural style,<ref name="FAIRBANKS2010"/>{{rp|273–277}} tactic,<ref name="SAP2"/>{{rp|70–72}} [[reference architecture]] and [[architectural pattern]].<ref name="REFARCHPRIMER">{{cite web |url=http://www.gaudisite.nl/ReferenceArchitecturePrimerPaper.pdf |archive-url=https://web.archive.org/web/20111219235909/http://www.gaudisite.nl/ReferenceArchitecturePrimerPaper.pdf |archive-date=2011-12-19 |url-status=live |title=A Reference Architecture Primer |last1=Muller |first1=Gerrit |date=August 20, 2007 |website=Gaudi site |access-date=November 13, 2015}}</ref><ref name="REFARCHCLASS">{{cite book |last1=Angelov |first1=S. |last2=Grefen |first2=P. |last3=Greefhorst |first3=D. |title=2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture |chapter=A classification of software reference architectures: Analyzing their success and effectiveness | url=https://ieeexplore.ieee.org/document/5290800| publisher=IEEE| pages=141–150 |year=2009| access-date=15 December 2023| doi=10.1109/WICSA.2009.5290800|isbn=978-1-4244-4984-2}}</ref><ref name="SAP2"/>{{rp|203–205}}

'''Conceptual integrity:''' a term introduced by [[Fred Brooks]] in his 1975 book ''[[The Mythical Man-Month]]'' to denote the idea that the architecture of a software system represents an overall vision of what it should do and how it should do it. This vision should be separated from its implementation. The architect assumes the role of "keeper of the vision", making sure that additions to the system are in line with the architecture, hence preserving [[The Mythical Man-Month#Conceptual integrity|conceptual integrity]].<ref name="BROOKS">{{cite book | last=Brooks | first=Frederick P. Jr. |date=1975|title=The Mythical Man-Month – Essays on Software Engineering |publisher=Addison-Wesley |isbn=978-0-201-00650-6|title-link=The Mythical Man-Month }}</ref>{{rp|41–50}}

Line 81:

==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 |archive-url=https://web.archive.org/web/20030607182458/http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF |archive-date=2003-06-07 |url-status=live |access-date=2012-11-16}}</ref> but the term "software architecture" did not see widespread usage until 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 |bibcode=2006ISoft..23b..22K |s2cid=2082927 }}</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|access-date=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|website=IEEE.org|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|access-date=2006-09-25}}</ref>

Line 111:

* business requirements and environmental contexts of a system that may change over time, such as legal, social, financial, competitive, and technology concerns<ref>{{cite book|author=Osterwalder and Pigneur| title = Value Creation from E-Business Models| chapter = An Ontology for e-Business Models|pages=65–97|year=2004| doi = 10.1016/B978-075066140-9/50006-0| isbn = 9780750661409|chapter-url=https://pdfs.semanticscholar.org/8513/9070e23b0b3278d73ea51b873acd99352e9c.pdf|citeseerx=10.1.1.9.6922| s2cid = 14177438| archive-url = https://web.archive.org/web/20181117063152/https://pdfs.semanticscholar.org/8513/9070e23b0b3278d73ea51b873acd99352e9c.pdf| archive-date = 2018-11-17}}</ref>

The outputs of the analysis activity are those requirements that have a measurable impact on a software system's architecture, called architecturally significant requirements.<ref name="ASR_Chen">{{Cite journal |doi = 10.1109/MS.2012.174|title = Characterizing Architecturally Significant Requirements|journal = IEEE Software|volume = 30|issue = 2|pages = 38–45|year = 2013|last1 = Chen|first1 = Lianping|last2 = Ali Babar|first2 = Muhammad|last3 = Nuseibeh|first3 = Bashar| bibcode=2013ISoft..30b..38C |hdl = 10344/3061|s2cid = 17399565|hdl-access = free}}</ref>

'''Architectural synthesis''' or design is the process of creating an architecture. Given the architecturally significant requirements determined by the analysis, the current state of the design and the results of any evaluation activities, the design is created and improved.<ref name="hofmeister07"/><ref name="SAP2"/>{{rp|311–326}}

'''Architecture evaluation''' is the process of determining how well the current design or a portion of it satisfies the requirements derived during analysis. An evaluation can occur whenever an architect is considering a design decision, it can occur after some portion of the design has been completed, it can occur after the final design has been completed or it can occur after the system has been constructed. Some of the available software architecture evaluation techniques include [[Architecture tradeoff analysis method|Architecture Tradeoff Analysis Method (ATAM)]] and TARA.<ref name="woods2012" >{{Cite journal | last1 = Woods | first1 = E. | title = Industrial architectural assessment using TARA | doi = 10.1016/j.jss.2012.04.055 | journal = Journal of Systems and Software | volume = 85 | issue = 9 | pages = 2034–2047 | year = 2012 | s2cid = 179244 }}</ref> Frameworks for comparing the techniques are discussed in frameworks such as ''SARA Report''<ref name="SARA" /> and ''Architecture Reviews: Practice and Experience''.<ref>{{Cite journal | last1 = Maranzano | first1 = J. F. | last2 = Rozsypal | first2 = S. A. | last3 = Zimmerman | first3 = G. H. | last4 = Warnken | first4 = G. W. | last5 = Wirth | first5 = P. E. | last6 = Weiss | first6 = D. M. | doi = 10.1109/MS.2005.28 | title = Architecture Reviews: Practice and Experience | journal = IEEE Software | volume = 22 | issue = 2 | pages = 34 | year = 2005 | bibcode = 2005ISoft..22b..34M | s2cid = 11697335 }}</ref>

'''Architecture evolution''' is the process of maintaining and adapting an existing software architecture to meet changes in requirements and environment. As software architecture provides a fundamental structure of a software system, its evolution and maintenance would necessarily impact its fundamental structure. As such, architecture evolution is concerned with adding new functionality as well as maintaining existing functionality and system behavior.

Line 125:

* '''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 provide 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">{{Cite journal |last1=Kruchten |first1=P. |year=2008 |title=What do software architects really do? |journal=Journal of Systems and Software |volume=81 |issue=12 |pages=2413–2416 |doi=10.1016/j.jss.2008.08.025}}</ref><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 on 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 | citeseerx = 10.1.1.60.8680 | s2cid = 13492610 }}</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 | bibcode = 2009ISoft..26b..43T | hdl = 1959.3/51601 | s2cid = 12230032 | hdl-access = free }}</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 [[Trade-off|tradeoffs]] between solutions.

* '''Documentation''' is the act of recording the design generated during the software architecture process. [[Software design|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|arxiv=2006.04975 |s2cid=219558624 }}</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.

Line 152:

Software architecture erosion refers to a gradual gap between the intended and implemented architecture of a software system over time.<ref name="Ruiyin2022">{{Cite journal | last1 = Li | first1 = Ruiyin | last2 = Liang | first2 = Peng | last3 = Soliman | first3 = Mohamed | last4 = Avgeriou | first4 = Paris | doi = 10.1002/smr.2423 | title = Understanding software architecture erosion: A systematic mapping study | journal = [[Journal of Software: Evolution and Process]]| volume = 34 | issue = 3 | pages = e2423 | year = 2022 | url = https://onlinelibrary.wiley.com/doi/abs/10.1002/smr.2423| arxiv = 2112.10934 }}</ref> The phenomenon of software architecture erosion was initially brought to light in 1992 by Perry and Wolf alongside their definition of software architecture.<ref name="PERRY1992"/>

Software architecture erosion may occur in each stage of the software development life cycle and has varying impacts on the development speed and the cost of maintenance. Software architecture erosion occurs due to various reasons, such as ''architectural violations'', ''the accumulation of technical debt'', and ''knowledge vaporization''.<ref name="Ruiyin2021">{{Cite book | last1 = Li | first1 = Ruiyin | last2 = Liang | first2 = Peng | last3 = Soliman | first3 = Mohamed | last4 = Avgeriou | first4 = Paris | doi = 10.1109/icpc52881.2021.00037 | title = The 29th IEEE/ACM International Conference on Program Comprehension (ICPC) | chapter = Understanding architecture erosion: The practitioners' perceptive | pages = 311–322 | year = 2021 | urlisbn = https://ieeexplore.ieee.org/document/9463012978-1-6654-1403-6 }}</ref> A famous case of architecture erosion is the failure of Mozilla Web browser.<ref>van Gurp, J. and Bosch, J.: 2002, Design erosion: Problems and causes, Journal of Systems and Software 61(2), 105–119.</ref> Mozilla is an application created by Netscape with a complex codebase that became harder to maintain due to continuous changes. Due to initial poor design and growing architecture erosion, Netscape spent two years redeveloping the Mozilla Web browser, showingdemonstrating howthe importantimportance itof is to manageproactive architecture erosionmanagement to avoidprevent extensive repair efforts,costly timerepairs and costproject lossesdelays.

Architecture erosion can decrease software performance, substantially increase evolutionary costs, and degrade software quality. Various approaches and tools have been proposed to detect architecture erosion. These approaches are primarily classified into four categories: consistency-based, evolution-based, and defect-based, and decision-based approachapproaches.<ref name=" Ruiyin2022"/> BesidesFor instance, theautomated measuresarchitecture usedconformance tochecks, addressstatic architecturecode erosionanalysis containstools, twoand refactoring maintechniques types:help preventativeidentify and remedialmitigate measureserosion early.<ref name=" Ruiyin2022"/>

Besides, the measures used to address architecture erosion contain two main types: preventative and remedial measures.<ref name=" Ruiyin2022"/> Preventative measures include enforcing architectural rules, regular code reviews, and automated testing, while remedial measures involve refactoring, redesign, and documentation updates.

=== Software architecture recovery ===

Line 224 ⟶ 226:

*{{Cite book| last = Bell | first = Michael | editor1-first = Michael | editor1-last = Bell | year = 2008 | title = Service-Oriented Modeling: Service Analysis, Design, and Architecture | publisher = Wiley|isbn=9780470255704|doi=10.1002/9781119198864}}

*{{Cite book |first1=Tony |last1=Shan |first2=Winnie |last2=Hua |title=2006 10th IEEE International Enterprise Distributed Object Computing Conference (EDOC'06) |chapter=Solution Architecting Mechanism |date=October 2006 |pages=23–32|doi=10.1109/EDOC.2006.54 |isbn=978-0-7695-2558-7 |s2cid=8361936 }}

*{{cite journal |first1=Javier |last1=Garzás |first2=Mario |last2=Piattini |title=An ontology for micro-architectural design knowledge |journal=[[IEEE Software]] |volume=22 |issue=2 |year=2005 |pages=28–33 |doi=10.1109/MS.2005.26|bibcode=2005ISoft..22b..28G |s2cid=17639072 }}

*{{Cite journal|last=Fowler|first=Martin|date=September 2003|title=Who Needs an Architect?|url=http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf|journal=[[IEEE Software]]|volume=20|issue=5|page=11 |doi=10.1109/MS.2003.1231144|bibcode=2003ISoft..20e..11F |s2cid=356506}}

*{{Cite journal|last=Kazman|first=Rick|date=May 2003|title=Architecture, Design, Implementation|url=https://resources.sei.cmu.edu/asset_files/WhitePaper/2003_019_001_29559.pdf |archive-url=https://web.archive.org/web/20150921170650/http://resources.sei.cmu.edu/asset_files/WhitePaper/2003_019_001_29559.pdf |archive-date=2015-09-21 |url-status=live|journal=Software Engineering Institute}} - On the distinction between architectural design and detailed design.

*{{cite journal |last=Kruchten |first=Philippe |year=1995 |url=http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf |archive-url=https://web.archive.org/web/20060613222204/http://www.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf |archive-date=2006-06-13 |url-status=live |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|arxiv=2006.04975 |s2cid=219558624 }}

Line 236 ⟶ 238:

* Collection of [http://www.sei.cmu.edu/architecture/start/definitions.cfm software architecture definitions] at [[Software Engineering Institute]] (SEI), [[Carnegie Mellon University]] (CMU)

* [http://www.iasaglobal.org/ International Association of IT Architects (IASA Global)], formerly known as the International Association for Software Architects (IASA)

* [http://www.softwarearchitectureportal.org/ SoftwareArchitecturePortal.org] – website of [[IFIP Working Group 2.10]] on Software Architecture

* [http://www.softwarearchitectures.com/ SoftwareArchitectures.com] – an independent resource of information on the discipline

* [http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm Software Architecture], chapter 1 of [[Roy Fielding]]'s REST dissertation