Combating architectural degeneration: a survey

Hochstein, Lorin; Lindvall, Mikael

doi:10.1016/j.infsof.2004.11.005

Cited by 78 publications

(83 citation statements)

References 65 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Their paper focuses on the methodological aspect of describing these templates and not on how they can be used when evolving an architecture as in our approach. In the architecture evolution field, Lindvall et al presented a survey on techniques employed in diagnosing or researching degeneration in software architectures and treating it [8]. Architecture degeneration is seen as the deviation of the actual architecture from the planned one.…”

Section: Related Workmentioning

confidence: 99%

On-Demand Quality-Oriented Assistance in Component-Based Software Evolution

Tibermacine

Fleurquin

Sadou

2006

Component-Based Software Engineering

View full text Add to dashboard Cite

Abstract. During an architectural evolution of a component-based software, certain quality attributes may be weakened. This is due to the lack of an explicit definition of the links between these non-functional characteristics and the architectural decisions implementing them. In this paper, we present a solution that aims at assisting the software maintainer during an evolution activity on his demand. It requires the definition of a documentation during development, organized in the form of bindings between formal descriptions of architectural decisions and their targeted quality attributes. Through an assistance algorithm, the approach uses this documentation in order to notify the maintainer of the possible effects of architectural changes on quality requirements. We also present a prototype tool which automates our proposals. This tool and the overall approach has been experienced on a real-world software in order to validate them.

show abstract

Section: Related Workmentioning

confidence: 99%

On-Demand Quality-Oriented Assistance in Component-Based Software Evolution

Tibermacine

Fleurquin

Sadou

2006

Component-Based Software Engineering

View full text Add to dashboard Cite

show abstract

“…A design problem can be introduced when certain decisions are made before programming. In addition, when software changes are made, the system's design can degrade due to new design problems being introduced (Hochstein & Lindvall 2005). We refer to an individual manifestation of a design problem as a design problem instance.…”

Section: Software Design Problemmentioning

confidence: 99%

“…Design problems have caused the discontinuation or reengineering of several software projects (Hochstein & Lindvall 2005). As previously mentioned, programmers frequently need to detect such problems in the source code due to the lack of formal design documentation.…”

Section: Studies On the Relation Of Code Anomalies And Design Problemsmentioning

confidence: 99%

“…As previously mentioned, programmers frequently need to detect such problems in the source code due to the lack of formal design documentation. In other words, it is expected that a wide range of design problems are reflected in a system's implementation through code anomalies (Fowler 1999) (Hochstein & Lindvall 2005). A method infected by Long Method (Fowler 1999), for example, is highly complex and contains excessive functionality.…”

Section: Studies On the Relation Of Code Anomalies And Design Problemsmentioning

confidence: 99%

“…For a long time, some authors simply assumed (Fowler 1999) (Hochstein & Lindvall 2005) most design problems can be observed in a system's implementation through the detection of single code anomalies. However, recent studies showed that this assumption is too simplistic (Macia et al 2012b) (Oizumi, Garcia, Colanzi, Ferreira & Staa 2014a).…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Synthesis of Code Anomalies: Revealing Design Problems in the Source Code

Oizumi¹

View full text Add to dashboard Cite

Understanding software architecture erosion: A systematic mapping study

Liang

Soliman

et al. 2022

J Software Evolu Process

View full text Add to dashboard Cite

Architecture erosion (AEr) can adversely affect software development and has received significant attention in the last decade. However, there is an absence of a comprehensive understanding of the state of research about the reasons and consequences of AEr, and the countermeasures to address AEr. This work aims at systematically investigating, identifying, and analyzing the reasons, consequences, and ways of detecting and handling AEr. With 73 studies included, the main results are as follows: (1) AEr manifests not only through architectural violations and structural issues but also causing problems in software quality and during software evolution; (2) non-technical reasons that cause AEr should receive the same attention as technical reasons, and practitioners should raise awareness of the grave consequences of AEr, thereby taking actions to tackle AEr-related issues; (3) a spectrum of approaches, tools, and measures has been proposed and employed to detect and tackle AEr; and (4) three categories of difficulties and five categories of lessons learned on tackling AEr were identified. The results can provide researchers a comprehensive understanding of AEr and help practitioners handle AEr and improve the sustainability of their architecture. More empirical studies are required to investigate the practices of detecting and addressing AEr in industrial settings.

show abstract

Combating architectural degeneration: a survey

Cited by 78 publications

References 65 publications

On-Demand Quality-Oriented Assistance in Component-Based Software Evolution

On-Demand Quality-Oriented Assistance in Component-Based Software Evolution

Synthesis of Code Anomalies: Revealing Design Problems in the Source Code

Understanding software architecture erosion: A systematic mapping study

Contact Info

Product

Resources

About