Content deleted Content added
No edit summary Tags: nowiki added Visual edit |
Magioladitis (talk | contribs) m Moved punctuation mark to correct place + other fixes, References after punctuation per WP:CITEFOOT and WP:PAIC |
||
Line 1:
{{short description|High level structures of a software system}}
{{Software development process}}
'''Software architecture''' is the set of structures needed to reason about 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 |title=Documenting Software Architectures: Views and Beyond, Second Edition |author2=Felix Bachmann |author3=Len Bass |author4=David Garlan |author5=James Ivers |author6=Reed Little |author7=Paulo Merson |author8=Robert Nord |author9=Judith Stafford |publisher=Addison-Wesley |year=2010 |isbn=978-0-321-55268-6 |___location=Boston |language=en-US |author3-link=Len Bass}}</ref><ref>{{Cite web |title=Software Architecture |url=https://www.sei.cmu.edu/research-capabilities/all-work/display.cfm?customel_datapageid_4050=21328 |access-date=2018-07-23 |website=www.sei.cmu.edu |language=en-US}}</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. | 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> It functions as the blueprints for the system and the development project, which [[project management]] can later use to extrapolate the tasks necessary to be executed by the teams and people involved.
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 [[Software design|the design of the software]]. There are two fundamental laws in software architecture:<ref>{{Cite book |title=Head First Software Architecture |publisher=O'Reilly Media |year=2024 |isbn=978-1098134358}}</ref><ref name="O'Reilly Media">{{Cite book |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |year=2020 |isbn=978-1492043454}}</ref>
# Everything is a trade-off
# "Why is more important than how"
"Architectural Kata" is a teamwork which can be used to produce an architectural solution that fits the needs. Each team extracts and prioritizes architectural characteristics (aka [[Non-functional requirement|non functional requirements]]) then models the components accordingly. The team can use [[C4 model|C4 Model]] which is a flexible method to model the architecture just enough.
[[Software documentation|Documenting software]] architecture facilitates communication between [[Stakeholder (corporate)#In management|stakeholders]], captures early decisions about the high-level design, and allows the 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}}
▲"Architectural Kata" is a teamwork which can be used to produce an architectural solution that fits the needs. Each team extracts and prioritizes architectural characteristics (aka [[Non-functional requirement|non functional requirements]]) then models the components accordingly. The team can use [[C4 model|C4 Model]] which is a flexible method to model the architecture just enough. <ref>{{Cite book |title=Fundamentals of Software Architecture An Engineering Approach |publisher=O'Reilly Media |year=2020 |isbn=9781492043423}}</ref>
▲[[Software documentation|Documenting software]] architecture facilitates communication between [[Stakeholder (corporate)#In management|stakeholders]], captures early decisions about the high-level design, and allows the 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}}
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 has its own subcategories.<ref
Software architecture tends to become more complex over time. [[Software architect]]<nowiki/>s should use "[[
[[File:Software Architecture Activities.jpg|thumb|Software architecture activities]]
Line 46 ⟶ 45:
'''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}}
'''Cognitive constraints:''' An observation first made in a 1967 paper by computer programmer [[Melvin Conway]] that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.<ref>{{cite web|url=http://www.melconway.com/Home/Conways_Law.html|title=Conway's Law|last=Conway|first=Melvin|website=Mel Conway's Home Page|url-status=live|archive-url=https://web.archive.org/web/20190929004831/http://www.melconway.com/Home/Conways_Law.html|archive-date=2019-09-29|access-date=2019-09-29}}</ref> Fred Brooks introduced it to a wider audience when he cited the paper and the idea in ''The Mythical Man-Month'', calling it [[Conway's law|
== Motivation ==
Line 157 ⟶ 156:
* [[Shared nothing architecture]]
* [[Space-based architecture]]
* Serverless architecture
Some treat architectural patterns and architectural styles as the same,<ref name=MSDN>[http://msdn.microsoft.com/en-us/library/ee658117.aspx Chapter 3: Architectural Patterns and Styles]. Msdn.microsoft.com. Retrieved on 2013-07-21.</ref> some treat styles as specializations of patterns. What they have in common is both patterns and styles are idioms for architects to use, they "provide a common language"<ref name=MSDN/> or "vocabulary"<ref name=SG/> with which to describe classes of systems.
Line 168 ⟶ 167:
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 =
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 approach.<ref name=" Ruiyin2022"/> Besides, the measures used to address architecture erosion contains two main types: preventative and remedial measures.<ref name=" Ruiyin2022"/>
| |||