Software reuse is the practice of using artifacts from existing systems to build new ones. It has been shown effective for improving quality and maintainability and for reducing cost and development time. Human factors have been identified as significant barriers to a wider adoption of reuse practices in industry. In this paper we consider a tool-supported approach for systematic reuse of object-oriented programs (written in Java) based on polymorphism-inspired mechanisms. The suggested tool gets as input implementations of multiple products, and produces a visual representation of the similarities and variabilities between their classes in terms of exhibits behaviors, as well as presents possible reuse options. We discuss the suitability of this approach for educational and training settings, and specifically for supporting reuse decisions of novice developers.
Development has become increasingly complex while reducing time-to-market remains
a critical issue. Software reuse has been shown to be effective for reducing cost and
development time [
Recently more attention has been drawn to the human factors of reuse practices,
focusing mainly on decision making processes of developers [
In this paper we propose a tool-supported approach for educating and training
novices and supporting reuse decisions. In [
We particularly explore the suitability of VarMeR to assist novice developers in reuse decisions. To this end, VarMeR was extended to compare an arbitrary number of software artifacts (rather than pairs of artifacts). In other words, the input of VarMeR is object-oriented code artifacts (in Java) that belong to multi software systems and the output is a graph that captures the similarities and variabilities of the classes of those systems in terms of their exhibited behavior. The tool further recommends how to increase reuse by utilizing suitable polymorphism-inspired mechanisms.
The rest of this paper is structured as follows. Section 2 provides an overview of our proposed approach, while Section 3 presents the capabilities of the extended version of the VarMeR tool (for supporting reuse when multi software products are available). Section 4 describes the benefits of the tool and its possible use scenarios in educational and training contexts, as well as some preliminary usability feedback. Finally, Section 5 summarizes and refers to future plans. 2
VarMeR analyzes the commonality and variability of products behaviors and presents the analysis outcomes in the form of polymorphism-inspired mechanisms among classes that behave similarly (even if their realizations are different). Specifically, the approach is composed of three steps, shown in Figure 1: Extract Behaviors, Compare Behaviors, and Analyze Variability.
Products’ representations
Similar elements Extract Behaviors
Ontological foundation
Compare Behaviors
Similarity measures
Analyze Variability
Variability mechanisms
Reuse Recommendations . . .
P1 Pn
Based on ontological considerations [
InitialState = {AvailabilityStatus:Boolean, BorrowingPeriod:int} ExternalEvent = Borrow FinalState = {AvailabilityStatus:Boolean, Borrow:void}
For extracting initial and final states, we distinguish between two levels of operation descriptor: shallow – which refers to the signature of the operation, and deep – which takes into consideration the behavior in terms of attributes used and modified throughout the operation (including those that are used and modified indirectly by operations called from the analyzed operation). We consider only attributes and ignore local variables, as the later can be defined for implementation and realization purposes and may hinder the operation’s behavior essence. The initial state of the behavior is composed of all the parameters passed to the operation (part of shallow) and all the class attributes used (read) by the operation (part of deep). The final state consists of the operation name and its returned type (part of shallow) and all the class attributes modified (set) by the operation (part of deep). Figure 2 exemplifies the behavior extraction outcome for the operation Borrow of the Book Copy class. Note that each attribute is presents via its name and type which provide the basis for comparison. 2.2
Different methods have been proposed for measuring the similarity of applications
or software systems. McMillan et al. [
To this end, a similarity mapping between the behavior constituents (namely, initial
state, external event, and final state) is applied. This mapping can be based on existing
general-purpose or domain-specific similarity metrics or some combination of such
metrics. The metrics can be based on semantic nets or statistical techniques to measure
the distances among words and terms [
Returning to our example of Book Copy, assume a class named Car which has an
operation named Rent that changes the In Agency status of a car from true to false. It
further calculates the Back Date according to the Rental Period. Figure 3 exemplified
two potential similarity mappings: the first one (a) is based on a schematic type-based
similarity according to which two attributes are similar if and only if their types are
similar. The second mapping (b) is based on a semantic measure named Latent
Semantic Analysist (LSA) [
book copy car book copy car 3.
EXT (abbreviation for extension) – at least one constituent in operation 1 has no counterpart in operation 2.
Note that REF and EXT are not mutually exclusive; we refer to a combination of both as REF-EXT (abbreviation for refined extension).
Aggregating the above notions from the level of operations to the level of classes, we take inspiration from the polymorphism mechanisms. Polymorphism is the provision of a single interface to entities of different types. Therefore, the cases of polymorphism are characterized by similar signatures of operations (namely, the USE category in the shallow level of the operations). We further focus on three types of polymorphism which are widely used in industry: 1. Subtyping (inclusion) polymorphism which includes refinement or extension of behaviors (e.g., function pointers, inheritance). 2. Parametric polymorphism which includes name or type analogy (e.g., C++ templates). 3. Overloading which includes behavior change while maintaining the same signature.
In order to make our approach accessible to developers (potentially novice ones and
students), we developed a tool named VarMeR – Variability Mechanisms
Recommender. While the first version of the tool, described in [
The inputs of the tool, namely the software products, are provided as (paths to) jar
files. Those files are reverse engineered into class diagrams (in XMI format) and
Program Dependence Graphs (PDG)2 [
In the product and class levels, the size of the nodes is proportional to the size of objects they represent; the larger the node is, the more operations the class have or the more classes the product has. The width of an edge, as well as its length, represents the degree of evidence (e.g., the number of operations related with a certain type of polymorphism); the thicker/longer the link is, the more evidence exist.
An example of VarMeR output at the class level is depicted in Figure 4. The comparison is done between three different software products, the classes of which are represented using different colors. To support scalability, VarMer provides the user with several possibilities for fine-tuning and information hiding, which are further discussed in the next section. 4
Although lack of training has been identified as a major barrier to a wider adoption of
reuse practices in industry, no systematic way to address this problem has been
proposed [
Intuitive abstractions. Krueger [
VarMeR makes use of graph-based abstractions which are intuitive and easy to
understand: nodes to represent (different types of) elements, and edges to represent their
similarity relations. It also supports switching between different abstraction levels by
supporting multi-level analysis (product-, class- and operation-levels). Another kind of
abstraction made by the VarMeR approach is that comparison between software
elements is made in terms of intensions (i.e., exhibited behavior) rather than in terms of
realizations and implementations. Starting with understanding behavior may be much
easier than starting by understanding old code, especially for novices. As highlighted
by Agresti [
Visualization. While a large body of research on software visualization exists [
Scalability: fine-tuning and information hiding. Reuse decisions might be easy when considering two simple operations such as Borrow and Rent from Figure 3, but dealing with large scale projects with hundreds of classes and thousands of behaviors introduces an additional dimension of complexity when making reuse decisions. To reduce the user cognitive load, VarMeR supports several ways of information hiding and fine-tuning at the class level analysis (see Figure 4): - Modifying thresholds for presenting recommendations for each type of polymorphism (namely, the minimal percentages of “similar” operations to present parametric, subtyping, and overloading edges can be set; the lower these thresholders are, the more abstraction is needed to apply reuse for those classes). - Hiding classes which have no similarity to other classes (Hide Classes button). - Filtering the graph-based visualization according to different software packages of the product (Filter Files button).
The above features provide a starting point for developing a method for supporting novice developers and software engineering students in reuse decisions. Consider, e.g., a scenario in which a novice developer, or a student in a programming course, needs to develop a software system. In an industrial setting, the company may have already developed various similar systems and maintain a repository of software artifacts. In other settings, some open-source applications may be available. Searching in such repositories, e.g., using keywords or queries, our developer may discover several similar systems, not all of which have informative descriptions, and each of which may have many different versions. Let us assume that our developer finally decides to select five systems, which according to their descriptions are quite similar to the system he/she needs to develop. For making a decision which system (or system parts) to reuse, it is useful to comprehend how the five systems differ.
This is exactly the point where VarMeR enters the scene, providing assistance to support such decisions. The developer can run the tool on the five selected systems3 and browse the similarity analysis and recommendations at different levels of abstraction. The product-level analysis will show him/her which of the systems are most similar. Zooming into class level, he/she can identify clusters of classes which can potentially be reused for implementing different behaviors. Zooming again into the operation level, we obtain information on the reuse relations among operations. At this stage the developer can zoom into the implementation itself, by looking at the relevant segment of code in an Eclipse-like environment and adapt the code to the task at hand.
We are currently in the process of evaluating VarMeR’s usability. In a pilot setting, we gave the tool to two pairs of students studying in the Information Systems department at the University of Haifa. Each pair received two portions of similar Java projects from SourceForge. They were requested to inspect VarMeR’s outcomes, and grade the appropriateness of its recommendations. Our analysis of the open-text feedback, provided by the students and classified by us according to VarMeR’s features, shows that visualization was positively mentioned – and particularly the use of colors and size. 3 Note that theoretically the developer could run VarMeR on all the game applications. However, the complexity of multi-object comparison dramatically increases as the number of objects increases. Hence, some a-priori filtering is recommended. The intuitive abstractions, and specifically the ability to zoom-in and zoom-out between the product, class, and operation levels, was also considered very useful. The scalability support was also mentioned as important, but the comprehensibility of three independent bars (for parametric, subtyping, and overloading mechanisms) was questioned. 5
The human factor is one of the most significant barriers in wider adoption of reuse practices in industry. Yet aspects of reuse training and decision support have so far been overlooked in the software engineering literature. We addressed this problem by presenting a tool-supported approach aiming to support developers in making reuse decisions, and discussed its applications in training settings. The VarMeR tool, supporting our approach, has several features which make it attractive in the context of reuse education. It applies intuitive abstractions of software artifacts, and allows for easy switching between abstraction levels. Furthermore, it uses visualization which employs intuitive visual constructs and variables, and aims to reduce cognitive load of developers when dealing with large scale software projects by allowing for fine-tuning and information hiding.
In the future, we intend to explore several paths for further development of VarMeR for educational purposes. First, we intend to develop a querying language on top of VarMeR, in order to retrieve the most relevant artifacts to a given development task. Second, we intend to systematically support reuse activities. After retrieving the relevant (portions of) software artifacts, we need to explore how to guide the developer in applying the reuse recommendations. Finally, we are in the process of adapting VarMeR in an academic software engineering course. Empirical studies with the students are planned to evaluate the benefits and limitations of the tool and further improve the tool. Our long term vision is for VarMeR to be fully integrated in standard development environments to promote reuse thinking as an integral part of development. Acknowledgment. The authors thank Jonathan Liberman for his help in the implementation of the VarMeR tool. We also thank Alex Kogan and Asaf Mor for their assistance in the initial steps of the development. The first author was supported by the Israel Science Foundation under grant agreement 817/15.