Reengineering component-based software systems with Archimetrix

Abstract

Many software development, planning, or analysis tasks require an up-to-date software architecture documentation. However, this documentation is often outdated, unavailable, or at least not available as a formal model which analysis tools could use. Reverse engineering methods try to fill this gap. However, as they process the system's source code, they are easily misled by design deficiencies (e.g., violations of component encapsulation) which leaked into the code during the system's evolution. Despite the high impact of design deficiencies on the quality of the resulting software architecture models, none of the surveyed related works is able to cope with them during the reverse engineering process. Therefore, we have developed the Archimetrix approach which semiautomatically recovers the system's concrete architecture in a formal model while simultaneously detecting and removing design deficiencies. We have validated Archimetrix on a case study system and two implementation variants of the CoCoME benchmark system. Results show that the removal of relevant design deficiencies leads to an architecture model which more closely matches the system's conceptual architecture.

Reverse engineering reusable software components from object-oriented APIs

“…Dependencies between classes composing object-oriented applications are exploited by numerous approaches that aim to identify components from object-oriented applications ( Garcia et al, 2013;Ducasse and Pollet, 2009 ). In von Detten et al (2013) , Detten et al presented the Archimetrix approach, which aims at mining the architecture of legacy software. It relies on a clustering algorithm to partition the system classes into components.…”

Recovering software product line architecture of a family of object-oriented product variants

“…They should not appear at the same levels as the functional/business components. Software architecture recovery approaches conform to this definition of architecture and identify only the functional components (e.g., Allier et al, 2011;Weinreich et al, 2012a;von Detten et al, 2013 ). The ROMANRIC approach/tool that is used in our evaluation to recover architecture of single software identifies only functional/business components.…”

“…• Source code is used to identify the system structure, i.e., high cohesive and low coupling parts, by analysis relationships among classes. Classes are grouped into disjoint clusters, such that each cluster represents a component of an architecture view ( Chardigny et al, 2008b;von Detten et al, 2013;Erdemir et al, 2011;Adjoyan et al, 2014 ). Some approaches allow the overlapping between the clusters ( Mende et al, 2008;Shatnawi and Seriai, 2013;Shatnawi et al, 2016;2015a ).…”

“…• Most of the existing approaches identify the software architecture of single software ( Erdemir et al, 2011;Hamza, 2009;Kebir et al, 2012a;Allier et al, 2011;Weinreich et al, 2012b ). Some approaches provide a documentation about the extracted architecture ( Ducasse and Pollet, 2009;von Detten et al, 2013 ). Some others support hierarchical architecture by providing a multi-layer architecture ( Boussaidi et al, 2012 ).…”

The Performance Quantitative Model Based on the Specification and Relation of the Component

“…Szyperski's definition is that the software component is a unit of composition with contractually specified interfaces and explicit context dependencies [22]. The authors of [23][24][25] adopted Szyperski's definition. This paper also adopts Szyperski's definition.…”