Software architectures change propagation tool (SACPT)

Abdelmoez, Walid; Shereshevsky, M.; Gunnalan, R.; Ammar, H.H.; Yu, Bo; Bogazzi, S.; Korkmaz, Mustafa; Mili, Ali

doi:10.1109/icsm.2004.1357860

Cited by 8 publications

(10 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…While there are re-engineering strategies (such as splitting overlarge components (Fahmy and Holt 2000), reducing inter-component interactions (Abdelmoez et al 2004), and removing "clones" in different components (Fanta and Rajlich 1999)), our analysis of hotspots and DPFRs complements these strategies. In particular, the hotspot interrelationship and persistence profile (see Sections 5.3 and 5.4) can help in determining: (a) whether or not a particular system area should be re-engineered, and (b) which specific components and inter-relationships should be re-engineered with priority.…”

Section: Architectural Qualitymentioning

confidence: 87%

“…Knowing the interrelationship and persistence of architectural hotspots can help management and practitioners to prioritise the areas of architectures that require deep surgery. Integrating our methods of identifying fix relationships in architectural tools such as ROSE (Zimmermann et al 2004) and SACPT (Abdelmoez et al 2004) can support detection of inter-connection problems at the architecture level and identification of MCDs at the code level.…”

Section: Discussionmentioning

confidence: 99%

“…), the work described in this paper is yet another trigger for making further progress in tool-technology. For examples, the prototype tool, ROSE (Zimmermann et al 2004), can determine the change-coupling relationships at different systemgranularity levels, and the SACPT tool (Abdelmoez et al 2004) can measure the architecture-level change propagation among components. Such tools could benefit from the work on fix relationships as described in this paper.…”

Section: Architectural Methods and Toolsmentioning

confidence: 99%

“…An association mining technique is also used in Ying et al (2004) to find the potential change patterns (pairs or sequences) in source code from the defect histories of the Eclipse 2 and Mozilla 3 projects. Later, the tool SACPT (Software Architecture Change Propagation Tool) is developed (Abdelmoez et al 2004) to measure the likelihood that a change that arises in one component of the architecture propagates to other components. These three approaches focused on changes to related objects at varying levels of granularity.…”

Section: Components and Coupling Relationshipsmentioning

confidence: 99%

“…Likewise, Zimmermann et al (2004), Ying et al (2004 and Abdelmoez et al (2004) have focused on changes to related objects at varying levels of granularity (such as directories, modules, files, methods and variables) in a system. This, previous work, focuses on components and their relationships in general.…”

Section: Introductionmentioning

confidence: 97%

See 4 more Smart Citations

Characteristics of multiple-component defects and architectural hotspots: a large system case study

Madhavji

Murtaza

et al. 2011

Empir Software Eng

View full text Add to dashboard Cite

The architecture of a large software system is widely considered important for such reasons as: providing a common goal to the stakeholders in realising the envisaged system; helping to organise the various development teams; and capturing foundational design decisions early in the development. Studies have shown that defects originating in system architectures can consume twice as much correction effort as that for other defects. Clearly, then, scientific studies on architectural defects are important for their improved treatment and prevention. Previous research has This paper is an enhanced version of paper (Li et al. 2009). 668Empir Software Eng (2011) 16:667-702 focused on the extent of architectural defects in software systems. For this paper, we were motivated to ask the following two complementary questions in a case study: (i) How do multiple-component defects (MCDs)-which are of architectural importance-differ from other types of defects in terms of (a) complexity and (b) persistence across development phases and releases? and (ii) How do highly MCDconcentrated components (the so called, architectural hotspots) differ from other types of components in terms of their (a) interrelationships and (b) persistence across development phases and releases? Results indicate that MCDs are complex to fix and are persistent across phases and releases. In comparison to a non-MCD, a MCD requires over 20 times more changes to fix it and is 6 to 8 times more likely to cross a phase or a release. These findings have implications for defect detection and correction. Results also show that 20% of the subject system's components contain over 80% of the MCDs and that these components are 2-3 times more likely to persist across multiple system releases than other components in the system. Such MCDconcentrated components constitute architectural "hotspots" which management can focus upon for preventive maintenance and architectural quality improvement. The findings described are from an empirical study of a large legacy software system of size over 20 million lines of code and age over 17 years.

show abstract

Section: Architectural Qualitymentioning

confidence: 87%

Section: Discussionmentioning

confidence: 99%