Introduction

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., [1], [5]. Targeting at comparing and evaluating clone detection tools, four types of clones are mentioned in [2]: Type 1an exact copy without modifications (except for white space and comments); Type 2a syntactically identical copy (only variable, type, or function identifiers were changed); Type 3a copy with further modifications (statements were changed, added, or removed); Type 4a syntactically different copy which performs the same computation. Taking clone detection one step forward, a method, named ECCO (Extraction and Composition for Clone-and-Own), is introduced in [3] to enhance the clone-and-own approach with reuse capabilities. Given a selection of the desired features by the software engineer, ECCO finds the appropriate software artifacts to reuse and also provides hints whether they need adaptation. The adaptation itself, however, is left to the software engineer.

In order to provide guidance to the adaptation process and to extract reusable artifacts which make future development and maintenance easier, we suggested in [11], [12], [13] a framework for identifying variants of software artifacts and associating them with variability mechanismstechniques applied to adapt reusable artifacts to the context of particular products in Software Product Line Engineering (SPLE) [8]. The framework is based on ontological foundations, where software artifacts are viewed as things exhibiting behavior. The framework allows us to identify similar behaviors (rather than cloned realizations) and associate different variability mechanisms based on the characteristics of related similarity mappings. To support this approach, we have developed a tool called VarMeRa Variability Mechanisms Recommenderwhich gets object-oriented code artifacts (in Java) that belong to two products and provides graphs that capture the commonality and variability of the classes of those products. The tool further recommends how to increase reuse by utilizing suitable variability mechanisms on similar classes. Currently VarMeR supports recommendations on three mechanisms related to polymorphism.

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

Figure 1. A high level overview of the approach

Extracting Behaviors. Referring to a software behavior as a triplet of initial state, external event, and final state [11], this step extracts those behavioral components from the operations of the different classes. Each class operation specifies some behavior of the software product. We assume that the operation name captures the essence of the behavior and thus can describe the external event, e.g., Borrow and Return of a Book Copy class in a library management system.

For extracting initial and final states, we distinguish between two levels: shallowwhich refers to the signature of the operation, and deepwhich takes into consideration the operation's behavior in terms of attributes used and modified throughout the oper-ation1. 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 Borrow-ingPeriod 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 [10]. Alternatively, they can use type or schematic similarities, potentially ignoring the semantic roles or essence of the compared elements [6]. The similarity mapping associates to each operation's constituent (shallow or deep) all of its similar counterparts in the other operation (i.e., elements whose similarity with the given constituent exceeds some predefined threshold).

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. USEeach 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 [14]: subtype (inclusion) polymorphism (e.g., function pointers, inheritance), parametric polymorphism (e.g., C++ templates), and overloading. Table 1 presents recommendations for those polymorphism mechanisms based on the reuse mapping characteristics.

The VarMeR Tool

We implemented the approach in Java. The main inputs of the tool -VarMeRare jar files implementing the software products (or applications) to be compared. Figure 2 presents the user interface of VarMeR: besides the names and paths to the compared jar files, the tool supports selection of similarity-related information, including thresholds, weights, and measures. Similarity measures define the way similarity is calculated.

VarMeR currently supports the text semantic similarity metric of Mihalcea, Corley, and Strapparava (MCS) [10] that combines corpus-based and knowledge-based measures, the Latent Semantic Analysis (LSA) metric [9], and UMBCtop N similar words and phrase similarity metric [4]. The element and parameter name weights define the ratio between name and type similarities of elements (operations or attributes) and parameters, respectively. The weights are taken into consideration when comparing behaviors.

As the names of parameters are more often meaningless (with respect to attribute/operation names), the tool supports separate weights. Finally, the similarity threshold defines the minimal value above which elements are considered similar. The jar files of the compared products are reverse engineered into class diagrams (in XMI format) and Program Dependence Graphs (PDG)2 [7] (in JSON format). The shallow and deep levels of the behaviors are extracted from those representations. Then the behaviors are compared utilizing the similarity-related information provided as input.

Finally, variability is analyzed using the features of the three types of polymorphism (see Table 1).

Figure 2. A screenshot of VarMeR inputs

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). 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.