Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Software architecture
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
=== 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| 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 | isbn = 978-1-6654-1403-6 | 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, demonstrating the importance of proactive architecture management to prevent costly repairs and project delays. 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, defect-based, and decision-based approaches.<ref name=" Ruiyin2022"/> For instance, automated architecture conformance checks, static code analysis tools, and refactoring techniques help identify and mitigate erosion early. 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.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)