Software is typically not developed from scratch and reuse of existing artifacts is a common practice. Consequently, variants of artifacts exist, challenging maintenance and future development. In this paper, we present a tool for identifying variants in object-oriented code artifacts (in Java) and guiding their systematic reuse. The tool, called VarMeR - a Variability Mechanisms Recommender, utilizes known variability mechanisms, which are techniques applied to adapt generic (reusable) artifacts to the context of particular products, for both identification of variants and recommendation on systematic reuse. Building on ontological foundations for representing variability of software behaviors, VarMeR visually presents the commonality and variability of the classes in different products and recommendations on suitable polymorphism variability mechanisms to increase systematic reuse.
In practice, software reuse takes in many cases an ad-hoc form. Often while artifacts
are not developed with reuse in mind, it is later achieved by duplicating artifacts and
adapting them to the particular needs (a clone-and-own approach). Such an approach is
easy to follow and intuitive, but has deficiencies in maintenance and future
development. Thus, various methods have been suggested to detect variants, mainly in code,
e.g., [
In order to provide guidance to the adaptation process and to extract reusable
artifacts which make future development and maintenance easier, we suggested in [
The rest of this paper is structured as follows. Section 2 provides the background of the approach, while Section 3 presents the capabilities of the VarMeR tool. Finally, Section 4 summarizes and refers to future development plans. 2
The Approach The approach at the heart of VarMeR analyzes the commonality and variability of products behaviors and provides reuse recommendations in the form of associating polymorphism mechanisms to classes that behave similarly (even if their realizations are different). Accordingly, the approach is composed of three steps, which are shown in Figure 1 and elaborated next: Extract Behaviors, Compare Behaviors, and Analyze Variability.
Products representations
Similar elements P1 P2
Extract Behaviors
Ontological foundation Analyze Variability
Variability mechanisms
Reuse Recommendations
Extracting Behaviors. Referring to a software behavior as a triplet of initial state,
external event, and final state [
Compare Behaviors
Similarity measures
For extracting initial and final states, we distinguish between two levels: shallow – which refers to the signature of the operation, and deep – which takes into consideration the operation’s behavior in terms of attributes used and modified throughout the operation1. 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 returned type (part of shallow) and all the class attributes modified (set) by the operation (part of deep). For the operation Borrow of the Book Copy class, we can consider the attributes AvailabilityStatus and BorrowingPeriod for the initial state, as they are needed for the operation to be executed. The attribute AvailabilityStatus is further modified as a result of the operation execution and hence is considered part of the operation’s final state.
Compare Behaviors. After extracting the behaviors and their shallow and deep
levels, a similarity mapping between their constituents 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 take into account semantic considerations
using semantic nets or statistical techniques to measure the distances among words and
terms [
Analyze Variability. Suppose that the constituents of two operations o1 and o2 in classes C1 and C2 respectively are mapped using a similarity mapping sim, namely, the similarity of their constituents exceeded some predefined threshold. We can distinguish between the following situations with respect to sim: 1. USE – each constituent of o1 has exactly one counterpart in o2 and vice versa. 2. REF (abbreviation for refinement) – at least one constituent in o1 has more than one counterpart in o2. 3. EXT (abbreviation for extension) – at least one constituent in o1 has no counterpart in o2.
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 aim at recommending on appropriate variability mechanisms. Our current focus is
on the common 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 [
The jar files of the compared products are reverse engineered into class diagrams (in
XMI format) and Program Dependence Graphs (PDG)2 [
The outcome of VarMeR is presented visually in the form of graphs. Each graph, comparing two products, shows the classes of the two products in different colors (one for the first product and one for the second product). The size of the nodes is proportional to the number of operations in the corresponding classes (the larger the node is, the more operations the class have). When hovering a node with the mouse, a tooltip showing the behavior appears, presenting the list of all operations of the current class. This way the user (e.g., a programmer or a code reviewer) can get a general idea on the role of each class, not just by its name, but also by the behavior it is expected to support.
The edges of the graphs (links between classes) represent recommendation on variability mechanisms, where: the label on the edge (link) indicates which variability mechanisms were identified: parametric, subtyping, and/or overloading. the width of the edge (link), as well as its length, represents the degree of evidence (i.e., the number of operations related with a certain type of polymorphism; the thicker/longer the link is, the more evidence to use the recommended variability mechanism exist).
An example of VarMeR’s output is depicted in Figure 3. The numbers in parentheses in the tooltip indicate the numbers of operations with certain names (but different signatures). The top of the screen includes controls that allow defining the thresholds above which a given mechanism (parametric, subtyping, or overloading) will be presented. In other words, these weights separately control the minimal numbers of operation pairs that need to satisfy certain constraints (USE, REF, EXT, REF-EXT) so that the given mechanism will be recommended. In the top right part of the screen, the user can hide classes unrelated to classes in the other product (such as testFlight in Figure 3). The bottom of the screen supports selecting colors for the classes of each of the two products and the links between them. Note that currently, VarMeR compares classes from different products (and not classes from the same product that may further increase reuse). Hence, links connect nodes of alternating colors, potentially connecting a single node to several nodes representing classes in the other product (see scribeFilter in Figure 3 as an example).
The tool further enables zooming into relations (links) among classes to have better understanding how the recommendations are generated and how to apply the recommended variability mechanisms and systemize reuse of the corresponding classes. This option presents the related operations of the classes and the categories to which the links among them belong: USE, REF, EXT, REF-EXT. Figure 4 zooms into the subtyping link of Figure 3 presenting EXT and REF-EXT relations among operations of the corresponding classes. This mapping can be used by a programmer in order to create a class from which the two compared classes (ScribeGui and ScribeBinder) can inherit through sub-typing polymorphism. We presented a tool, called VarMeR – A Variability Mechanisms Recommender, which is based on ontological foundations for representing variability of behaviors of software products. The inputs of VarMeR are object-oriented code artifacts (jar files) belonging to different software products. The outputs are graphs which can be used for analyzing the commonality and variability of the classes in different products and recommending on suitable polymorphism variability mechanisms to increase systematic reuse.
In the future, we intend to extend the tool support in several ways. First, VarMeR will be extended to support further variability mechanisms besides polymorphisms. Another direction is incorporating VarMeR into existing programming environments, so that it will be relatively easy to apply the recommendations generated by VarMeR. Furthermore, we intend to empirically explore the usefulness of VarMeR and the quality of its outcomes.
Acknowledgment. The authors would like to thank Jonathan Liberman, Alex Kogan and Asaf Mor for their help in the implementation of the VarMeR tool. The second author was supported by the Israel Science Foundation under grant agreement 817/15.