Using Feature Modeling for Program Comprehension and Software Architecture Recovery Ilian Pashov, Matthias Riebisch Technical University Ilmenau, Max-Planck-Ring 14, P.O. Box 100565 98684 Ilmenau, Germany {idpashov|matthias.riebisch}@tu-ilmenau.de Abstract: The available evidence in a legacy software their life cycle. Evolving often means refactoring or system, which can help in its understanding and recovery migrating to a new approach, for example component based systems or product lines. However, to succeed in of its architecture are not always sufficient. Very often the system’s documentation is poor and outdated. One such a step, a full understanding of the software system may argue that the most reliable resource of information is required leading to the need for its architecture and design decisions to be recovered. is the system’s source code. Nevertheless a significant knowledge about the problem domain is required in Due to the long life cycle of these systems, in most of order to facilitate the extraction of the system’s useful the cases it is impossible to keep the same development architectural information. team. A lot of knowledge about the system is lost along In this approach feature modeling is introduced as an with the developers. Often the system’s documentation is additional step in a system’s architectural recovery out of date and insufficient. This means that additional process. Feature modeling structures the system’s help is required for the architectural recovery of the system from the reverse engineers and the reverse functionality and supports reverse engineering by detecting the relations between source code elements and engineering methods. Their task is to extract and reconstruct the system’s design, based solely on the requirements. Tracing these relations may lead to a better understanding of the program’s behavior and the available information. recovery of various architectural elements. In this way, It is true that the most reliable information resource for by providing a mapping between source code and the reverse engineer is the system’s source code, features, the system’s feature model supports program although this proves most of the times to be insufficient. comprehension and architectural recovery. In order to succeed, the reverse engineer needs to The approach is developed as first part of a migration combine the information gained from the source code with knowledge about the problem and programming methodology towards a component-based architecture of legacy systems. Recovered information about features domain. In the case of large systems a well-defined and architecture is collected in a repository to enable a recovery process is needed so as to minimize the risk of the whole process. refactoring as next step. The approach is currently applied in a large project for reengineering of an This paper presents an approach to program industrial Image Processing System. comprehension and software architecture recovery of Keywords: Feature modeling, software refactoring, legacy systems based on the use of feature diagrams and feature modeling. architectural recovery, program comprehension, design recovery, legacy systems, reengineering, reverse In general, the approach elaborates the idea of engineering, traceability combining system domain knowledge and program understanding. It uses feature modeling as a way of 1 Introduction expressing domain knowledge when at the same time Due to the rapid development of the software technology bridges between system experts, users and reverse during the last decades and the increased demand for engineers. Finally, it serves as a means of generation and software products, a large number of software systems verification of hypotheses. has been developed. Many of them have a long life cycle This approach defines an architecture recovery process and contain a lot of company “know-how”. On the other initiated at the Feature Modeling level. In this respect, hand, the continuously changing needs of the business Feature Diagrams provide an orientation for the environment require those systems to be always up to establishment of architectural element hypotheses. A date with the latest technologies and to evolve during mechanism for the verification of those hypotheses based on cross-references is presented, along with model contains knowledge of domain boundaries, different types of feature models, respectively terminology and possible architectures. This knowledge corresponding to design and decisions objectives. can help an analyst set expectations for program content. A case study taken from an ongoing industrial project Moreover, a domain model can provide information on illustrates the applicability of this new technique. how domain concepts are related. The author has described a number of ways for presenting the domain 2 State of the art knowledge. In this paper, they are extended by feature modeling to build a bridge to later architectural The presented approach is based on several software development. engineering methodologies, both in the field of forward and reverse engineering. 2.2 Architecture recovery 2.1 Program comprehension The software architecture represents the problem solution on a higher abstraction level than the source Most of program comprehension methodologies are code, thus reducing the complexity of software systems. based on source code analysis. Program understanding This makes architecture recovery the most important and problem domain knowledge are connected for the task in reverse engineering. Additionally, a well defined first time in [Brooks et al. 1983]. More precisely, this process definition, as well as appropriate tool support is paper presents the establishment of a top-down required. hypothesis, according to which, program comprehension leads to the construction of a mental model for The workbench Dali ([Kazman et al. 1997]) helps the successive knowledge domains. Each of these domains reverse engineer in extracting, manipulating, and consists of objects, properties, relations and operations. interpreting architectural information. Dali defines a The succession of domains may include the problem framework for architecture recovery, a process and the domain, the domain of a mathematical model of the needed tool support. The Architecture Tradeoff Analysis problem, the algorithm domain, the programming Method (ATAM) [Kazman et al. 1998b] developed by language domain, and so on. One must also achieve the Software Engineering Institute (SEI) focuses into comprehension of the relationships that exist between analyzing software systems with respect to specific adjacent domains. quality attributes. ATAM also provides techniques to reconstruct an architecture from a system’s In [Letovsky et al. 1986] the ideas of Brooks are implementation. Even if contributing to architecture elaborated. According to this paper, the task of recovery techniques, Dali and ATAM do not exploit understanding a program is one of uncovering the domain knowledge. intention “behind” the code. Intentions are described as goals. Techniques for realizing goals in a particular The authors in [Finnigan et al. 1997] introduce the implementation are called plans. Plans are similar to concepts of a reverse engineering environment called algorithms, but they may involve non-contiguous “software bookshelf” as a means to capture, organize elements and may be combined in ways not usually and manage information in legacy software systems. considered for algorithms. For example, two plans They distinguish three roles directly involved in the involving loops may be combined into a solution using a construction, population and use of such a bookshelf: the single loop implementing two distinctive goals. builder, the librarian and the patron. From these perspectives they describe requirements for the The authors in [Rajlich et al. 1994] take the development bookshelf as well as a generic architecture and a of top-down program understanding techniques one step prototype implementation. This approach supports re- further. According to their approach, the programmer documentation of the legacy systems very well, however creates a chain of hypotheses along with subsidiary no overview over domain knowledge is provided. This hypotheses. These are consequently verified in the code. has to be added to enable architecture recovery and later Similar hypotheses are used here. refactoring. These three approaches apply only a top-down Storey in [Storey et al. 1997] presents the reverse procedure, thus missing low level dependencies, which engineering tool, Rigi. The Rigi system provides two usually are visible only within source code. contrasting approaches for presenting software structures A recent discussion about the role of domain knowledge in its graph editor. The first approach displays the in program understanding can be found in [Rugaber et al. structures through multiple, individual windows. while 2000]. The author shows how a model of an application's the second one (Simple Hierarchical Multi-Perspective domain is able to serve as a supplement to programming- (SHriMP) views) employs fisheye views of nested language-based analysis methods and tools. A domain graphs. Rigi is an open environment and could be extended in order to further support architecture 2.4 Architectural modeling recovery. Extensions of Rigi for a tool-based feature Architectural modeling represents the framework for oriented architectural recovery could support the constructing an application. An