Atomic architectural component recovery for program understanding and evolution

Abstract

Component recoveryOver time, ad-hoc changes deteriorate the system structure. These changes make program understanding increasingly more difficult; they decrease cohesion within components and increase coupling among components aggravating subsequent changes. Ad-hoc changes are rarely well documented making architectural descriptions obsolete. All these negative effects lead to increased maintenance costs. To get back control on large and complex legacy systems suffering from ad-hoc changes, it is necessary to recover the software architecture as built, to improve the architecture, and to restructure the system accordingly. Component recovery is a means to this end. Its purpose is to retrieve logical components from existing systems. Component are structural entities used to group elements. Types of components considered in this thesis are modules and subsystems. As opposed to the actual physical components of a system, i.e., the files, packages, or source directories of the system, logical components may only contain related elements that jointly contribute to a common purpose. This thesis is on automatic and semiautomatic methods for component recovery. Historic perspective -the impact of this dissertationThis dissertation was published two years ago -too little time to fully develop its impact. Yet, a look back in the history of component recovery and the recent reception of this dissertation allows at least a glimpse on the impact of this dissertation on research in that area. Period of pioneering featComponent recovery and remodularization techniques have been studied since the early eighties. Belady and Evangelisti in 1982 [9] and Hutchens and Basili in 1985 [10] were among the first researchers in that area. Since then, component recovery has been a very active research area. At the time when the research to this dissertation started, more than 20 research papers had been published on fully automatic and semi-automatic techniques for component recovery, and their number is still growing .These papers proposed many new interesting techniques. However, many of these techniques were not really evaluated quantitatively. If authors did evaluate their techniques, the evaluation was not comparable to evaluations of other authors because different evaluation techniques were used for different subject systems. Therefore, it was not clear which techniques one should use under which circumstances; it was not even clear whether these automatic techniques compare to manual remodularization at all.The abundance of published methods called for frameworks to unify, classify, and compare them in order to make informed selections of appropriate component recovery techniques. The dissertation's contribution in the period of consolidationThe dissertation is the first contribution to a consolidation in component recovery. Its contributions are explained in the following.

Real-Time Reflexion Modelling in architecture reconciliation: A multi case study

“…However, even though software architects were often allowed to confirm or refute the suggestions of such analyses, they did not drive the process, thus limiting their ability to impose their desired architecture on the system [6]. In addition, these approaches often suffered from the 'garbage-in, garbage-out' phenomenon [7], whereby any architecture derived from analysis of a system without an initial architecture (defined or adhered to) is likely to be flawed.…”

Dimensions of reengineering environment infrastructures

“…Koschke's thesis discusses the relevance for modeled information of the Bauhaus Resource Graph model for reengineering C programs [7]. Likewise, Datrix has a clear description of what is modeled, namely abstract syntax trees with added semantic information [6].…”

“…There is nearly no description and analysis of the trade-offs made while developing the meta-model and the reengineering environments. Only [5,7,11] elaborate on certain aspects of the modeled information but in a rather limited way because the criteria we describe are often related to the internal aspects of reengineering environments.…”

“…Apart from a few exceptions, the documentation of existing meta-models and tool environments does not describe why the modeled information is relevant for a given set of reengineering activities [5][6][7]. Especially, no trade-off analysis exists of the different modeling alternatives that one may choose from.…”

“…Little analysis about the design and implementation of reengineering environments exists [5][6][7]. Koschke's thesis discusses the relevance for modeled information of the Bauhaus Resource Graph model for reengineering C programs [7].…”