The JDEvAn Tool Suite in Support of Object ... - Semantic Scholar

The JDEvAn Tool Suite in Support of Object-Oriented Evolutionary Development Zhenchang Xing and Eleni Stroulia Computing Science Department University of Alberta Edmonton AB, T6G 2H1, Canada {xing,stroulia}@cs.ualberta.ca JDEvAn’s users specify the system snapshots/versions they want to analyze in a XML configuration file. JDEvAn allows incremental analysis: more snapshots can be added as they become available. JDEvAn implements a Java fact extractor based on Eclipse JDT DOM model to reverse engineer logical design models from source code of system snapshots. As per adopted meta-model [1], a software system is modeled as a directed graph. The vertex set contains design elements of type subsystem, package, class and interface, data type, field and operation, and parameter. The edge set contains relations among design elements, including composition, generalization and abstraction, usage dependency, and association such as associated data type, thrown and caught exception. Given two models corresponding to two versions of the subject system, JDEvAn implements the UMLDiff algorithm [1], which automatically detects design changes that the system has undergone, as it evolves from one version to the next. UMLDiff is a programming-language independent model differencing algorithm; it produces as output a set of elementary design change facts reporting additions, removals, matches, moves, renamings of design elements, changes to their attributes, and changes of their relations. Furthermore, JDEvAn implements a set of queries [1] for detecting instances of well understood design change patterns, i.e., refactorings that restructure containment and inheritance hierarchies, move features between objects, and refactor class internals. These refactorings are recognized in terms of composition of UMLDiff change facts. JDEvAn also allows users to define new queries for more design change patterns of their interests, based on UMLDiff design change facts and instances of detected refactorings. By combining relevant elementary design change facts into design change patterns, it become easier to understand the specific intent of system evolution and support evolutionary development.

Classification:

D.2.7 Software Engineering – Distribution, Maintenance, and Enhancement

General Terms: Design Keywords: Model differencing, Refactoring detection, Asynchronous API evolution, Evolutionary software development

1

Introduction

Object-oriented software is increasingly developed using evolutionary development processes. Systems, in addition to being incrementally (re)designed to fulfill their evolving requirements, have their design continuously improved through behaviorpreserving restructurings, as refactoring has become one of the most important core practices in object-oriented development. As a result, at any point in time, the system design is the product of a sequence of design-evolution decisions, a fact that should be taken into account in subsequent development and maintenance tasks. For example, when building applications that reuse evolving component frameworks, the client-application developers have to understand the nature of component’s breaking API changes, their plausible replacements and how to use them. In this paper, we present our JDEvAn (Java Design Evolution Analysis) tool suite [2], which consists of three components to date: JDEvAn captures and analyzes the design evolution history of Java software; Diff-CatchUp is an application built on JDEvAn knowledge base and it supports migrating client applications to properly use the evolved APIs of component frameworks; JDEvAn Viewer allows the interactive visualization, exploration, annotation, and persistence of JDEvAn/Diff-CatchUp’s comparison and analysis results with change tree format or UML class diagram. The JDEvAn tool suite has been evaluated with three real-world Java software systems – HTMLUnit, JFreeChart, and Eclipse. These case studies demonstrate that JDEvAn tool suite is applicable and effective in practice [1]. Our research on analyzing and supporting evolutionary software development is ongoing. In the future, we are interested in developing tools and methods for improving awareness of design evolution decisions by peer team members, merging parallel development branches based on evolution operations reported by JDEvAn, and validating code-to-design compliance. We also plan to apply the methodology implemented by the JDEvAn tool suite to software systems developed in procedural or scripting languages.

2

JDEvAn

The JDEvAn component analyzes the evolution of software design artifacts and automatically produces reports of interesting patterns during their evolution [1].

Figure 1 Design Evolution Analysis view JDEvAn’s front-end is an Eclipse plugin, which contributes a Design Evolution Analysis view (Figure 1) to Eclipse IDE. It shows a tabbed view for each opened configuration file, i.e., sys-

Copyright is held by the author/owner(s). ICSE’08, May 10–18, 2008, Leipzig, Germany. ACM 978-1-60558-079-1/08/05.

951

tem snapshots under investigation. The General Query view allows users to execute predefined queries for UMLDiff design change facts and refactorings or to define new queries. The users can then select some of the query results of their interests and inspect the involved design elements, relations and their changes in JDEvAn’s Containment (or Inheritance) Change Tree View or JDEvAn Viewer. JDEvAn’s backend repository is PostgreSQL database, which store the reverser-engineered design model facts, the UMLDiff design change facts, the instances of detected refactorings, and the evolution profiles of the system and its components. This knowledge base has been use for longitudinal evolution analysis, design mentoring, and supporting API migration in reuse-based software development [1].

3

replacements have been used in the evolved framework code base to deliver what the broken API used to do. Finally, it formulates a set of replacement and usage example proposals and returns them to the client-application developer for consideration. The generated replacement and usage example proposals are shown in Diff-CatchUp’s front-end API Proposals and Usage Examples views respectively (Figure 2). If the developer considers a proposed API as a promising candidate for replacing the broken API, he can then request the code differences of its usage example methods from within JDEvAn Viewer, which will demonstrate how to actually migrate his application code.

4

JDEvAn Viewer

The JDEvAn Viewer component is an Eclipse plugin built on Eclipse Graphical Editor Framework. It offers two visualizations (i.e., change tree and UML class diagram) of the comparison and analysis results produced by JDEvAn and Diff-CatchUp. The change-tree visualization is also a built-in feature of the JDEvAn component. It is easier to locate an element in change tree, while it is easier to inspect the dependencies among design elements with class diagram. Both views support the same set of features: • Inspection of the logical design models that JDEvAn compares and the comparison results; the models are visualized in tree format following containment (or inheritance) hierarchy or in UML class diagram; • Editing of the UMLDiff change report, in order to correct erroneously identified and missed changes; • Exploration of the neighbourhood (i.e., related elements) of selected elements; • Navigation of the evolution trace of selected elements, i.e., in which version they are introduced, what changes they undergo in a particular version, and in which version they are removed; • Annotation of design elements, relations and their changes with user comments; • Viewing the source code of selected model elements and reporting code differences; • Persistence of the evolution concerns into files. These visualizations enable developers to start with key design elements and relations of an evolution concern, such as instances of refactorings or API migration proposals. Then, they can iteratively augment the evolution concern with the relevant elements, relations, and their changes by querying logical design models and their evolution history and by determining which of the returned design elements and relations contribute to the evolution concern of their interest. In this manner, they can incrementally build up their knowledge about what has been changed, how and why. This essentially enables a compact and local view of otherwise scattered design elements and relations and their changes by collecting them together and by eliding irrelevant ones. This localization helps developers understand the nature of design changes and the motivations behind them. It also helps developers determine whether the Diff-CatchUp’s proposals are worth examining closely.

Diff-CatchUp

The Diff-CatchUp component supports the migration of client applications to appropriately use the evolved APIs of component framework, based on “voluntary” working examples of the evolved framework code base [1]. The Diff-CatchUp front-end, an Eclipse plugin, allows the client-application developer to highlight the code fragments or compile errors/warnings as the locality of the API migration problem to be addressed. Its server hosts a JDEvAn repository of the evolved component framework, which must have been populated by JDEvAn component before Diff-CatchUp can be used. In response to application developer’s request to “CatchUp API Evolution”, Diff-CatchUp searches this repository for the changes to the broken APIs, the plausible replacements and their potential usage examples.

Figure 2. API Proposals and Usage Examples view Diff-CatchUp first determines the changes to the broken API of the offending component involved in the migration problem, as reported by JDEvAn’s UMLDiff. And then, it takes different actions for adapting different types of API changes. For renamed/moved API elements, it returns their renaming/move counterpart elements as identified by JDEvAn’s UMLDiff. For changes to element attributes and relations, it presents the concerned API element and its attribute/relation changes in JDEvAn Viewer [1] for inspection. For removed (deprecated, visibilityrestricted, class-made-abstract) APIs, it examines the places that used to use the removed APIs but are not broken in new version of component framework and selects a set of replacing APIs. The underlying assumption is that the places within the evolved component framework that a removed API used to be used should have been properly updated to use its replacement(s). Having formulated a set of API elements that can potentially replace a broken API, Diff-CatchUp then collects examples of how these

References 1. 2.

952

Z. Xing. Supporting Object-Oriented Evolutionary Development by Design Evolution Analysis, Ph.D. thesis, University of Alberta, 2007. JDEvAn tool suite, http://www.cs.ualberta.ca/~xing, 2007