Software architecture: Difference between revisions

Revision as of 15:18, 25 April 2024

Revision as of 08:50, 9 May 2024

Line 158:

=== Software architecture erosion ===

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}}</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 (or "decay") refers to the gap observed between the planned and actual architecture of a software system as realized in its implementation.<ref>Terra, R., M.T. Valente, K. Czarnecki, and R.S. Bigonha, "Recommending Refactorings to Reverse Software Architecture Erosion",

16th European Conference on Software Maintenance and Reengineering, 2012.

http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf</ref> Software architecture erosion occurs when implementation decisions either do not fully achieve the architecture-as-planned or otherwise violate constraints or principles of that 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 | url = https://ieeexplore.ieee.org/document/9463012}}</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, showing how important it is to manage architecture erosion to avoid extensive repair efforts, time and cost losses.

As an example, consider a strictly [[Abstraction (computer science)#Layered architecture|layered]] system, where each layer can only use services provided by the layer immediately below it. Any source code component that does not observe this constraint represents an architecture violation. If not corrected, such violations can transform the architecture into a monolithic block, with adverse effects on understandability, maintainability, and evolvability.

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"/>

Various approaches have been proposed to address erosion.

"These approaches, which include tools, techniques, and processes, are primarily classified into three general categories that attempt to minimize, prevent and repair architecture erosion. Within these broad categories, each approach is further broken down reflecting the high-level strategies adopted to tackle erosion. These are process-oriented architecture [[Conformance testing|conformance]], architecture evolution management, architecture design enforcement, architecture to implementation linkage, self-adaptation and architecture restoration techniques consisting of recovery, discovery, and reconciliation."<ref>{{cite journal |last1=de Silva |first1=L. |first2=D. |last2=Balasubramaniam |title=Controlling software architecture erosion: A survey |journal=Journal of Systems and Software |year=2012 |volume=85 |issue=1 |pages=132–151 |doi=10.1016/j.jss.2011.07.036}}</ref>

There are two major techniques to detect architectural violations: reflexion models and ___domain-specific languages. Reflexion model (RM) techniques compare a high-level model provided by the system's architects with the source code implementation. There are also [[___domain-specific language]]s with a focus on specifying and checking architectural constraints.

=== Software architecture recovery ===