Anas Shatnawi
email: anas.shatnawi@lip6.fr

Abdelhak-Djamel Seriai

Houari Sahraoui
email: sahraouh@iro.umontreal.ca

Tewfik Ziadi
email: tewfik.ziadi@lip6.fr

Abdelhak Seriai
email: abdelhak.seriai@lirmm.fr

Abderrahmene Seriai
email: seriai.abdelrahmene@gmail.com

Y Dubinsky

J Rubin

T Berger

S Duszynski

M Becker

Y Liu

R Cai

R Kazman

Q Mo

Ser- 1311 Zheng

ReSIde: Reusable Service Identification from Software Families

Keywords: software reuse, service-oriented reengineering, reverse engineering, variability, software families, object-oriented source code

teaching and research institutions in France or abroad, or from public or private research centers.

Introduction

It is a common practice that software developers rely on the clone-and-own approach to deal with custom-tailored software [1,2]. New software products are developed by copying and modifying codes corresponding to functionalities from existing software to meet the requirement of new needs of new customers. The resulting software products are considered Software Product Variants (SPVs) because they share features and di↵er in terms of others [1]. The existence of this phenomenon has been proved by empirical studies like [2] [3].

For monolithic object-oriented SPVs, managing the software reuse and maintenance of the cloned codes is a very hard task [4]. For reuse, e.g., it is hard to identify reusable codes from the monolithic object-oriented implementation of these SPVs [5]. For maintenance, e.g., it is di cult to propagate updates for fixing bugs related to the implementation of the cloned codes. Therefore, we are interested in SPVs to identify reusable services related to cloned functionalities and their related codes. In fact the probability of reusing a service in a new software product is proportional to the number of software products that have already used it [START_REF] Gasparic | An analysis of 1330 a project reuse approach in an industrial setting[END_REF][START_REF] Sametinger | Software engineering with reusable components[END_REF]. Thus, mining software services based on the analysis of a set of SPVs contributes to identify reusable services. Nonetheless, this has not been investigated in the literature. Identifying services by analyzing multiple SPVs makes it possible to improve the reusability of services to reduce the e↵ort when developing new software products (by reuse) and to reduce the maintenance e↵ort by making it possible to propagate any change to a service across all of the products that reuse this service.

In this paper, we propose ReSIde (Reusable Service Identification): an automated approach that identifies reusable services from a set of similar object-oriented SPVs. ReSIde analyzes the commonality and the variability between the object-oriented source code of multiple SPVs to identify the implementation of reusable functionalities corresponding to cloned codes. These identified functionalities are intended to be packaged as reusable services that can be reused across multiple products. ReSIde is motivated by the fact that services identified based on the analysis of several existing SPVs will be more useful (reusable) for the development of new SPVs than services identified from singular ones.

To validate ReSIde, we have applied it on three opensource product families of di↵erent sizes (i.e., small, medium and large-scale ones). We propose an empirical measurement to evaluate the reusability of the identified services.

According to this measurement, the results show that the reusability of the identified services using ReSIde is better than the reusability of those identified from singular software.

The idea of analyzing multiple SPVs to identify reusable components was introduced in our conference paper [START_REF] Shatnawi | Mining reusable software compo-1336 nents from object-oriented source code of a set of similar soft-1337 ware[END_REF].

In relationship with this conference paper, this journal paper addresses the identification of services and not software components. Also, it includes additional contents in terms of:

1. Proposition of a deep analysis of the problem of identifying reusable services from multiple SPVs. As presented in Figure 1, we perform similar to the ISO9126 quality model [START_REF] Iso | Iec 9126-1: Software engineering-product quality-part 1: 1340 Quality model[END_REF] to refine these three characteristics to a number of service properties that can be measured using a number of object-oriented metrics (e.g., self-containment is refined to the number of required interfaces by a given service).

The service quality model identifies service characteristics and refine them as metrics. However, to identify services, we need to put these metrics as function that can be computed to output a numerical value for evaluating the semantic of a service (i.e. what a service is) based on its implementation composed of a cluster of object-oriented classes. Therefore, we defined a quality fitness function (QFF) based on our service quality model where its input is a cluster of classes (E), and its output is a value, situated in [0-1], corresponding to the quality of this cluster of classes to form a quality-centric service. This QFF is represented by Equation 1 based on the linear combination of the three quality characteristics: Functionality (Fun), Composability (Comp) and Self-Containment (SelfCon).

QF F (E) = 1 3 P i=1 i • ( 1 • F un(E) + 2 • Comp(E)+ 3 • Self Cont(E)) (1)
Where (2)

Comp(E) = 1 I X i2I LCC(i) (3) Self Cont(E) = ExtCoupl(E) (4)
Where np(E) is the number of provided interfaces based on the number of public methods in E. LCC(i) (Loose Class Cohesion) [START_REF] Bieman | Cohesion and reuse in an object-1343 oriented system[END_REF] is the average of the cohesion of a group of methods composing the service interfaces. These We summarize the principles of ReSIde as follows.

229

• ReSIde defines a service in terms of a cluster of object- The class obtaining the highest quality value is selected to extend the current group (c.f. lines 7 and 8). We do this until all candidate classes are grouped into the service (c.f. lines 6 to 11). The quality of the formed groups is evaluated at each step, i.e., each time when a new class is added.

We select the peak quality value to decide which classes form the service (c.f. lines 10 and 11). This means that we exclude classes added after the quality fitness function reaches the peak value since they minimize the quality of the identified service. For example, in Figure 5, the 7th and the 8th added classes are putted aside from the group of classes related to service 2 because when they have been added the quality of the service is decreased compared to the peak value. Thus, classes retained in the group are those maximizing the quality of the formed service. After identifying all potential services of such a SPV, the only ones retained are services that their quality values are higher than a quality threshold that is defined by software architects (c.f. lines 12 and 13). For example, in Figure 5, suppose that the predefined quality threshold value is 70%. Thus, Service 1 does not reach the required threshold. Therefore, it should not be retained as a potential service. This means that the starting core class is not suitable to form a service.

Identification of similar services between di↵erent software product variants

We define similar services as a set of services providing mostly the same functionalities and di↵ering in few ones.

These can be considered as variants of the same service. As Shared classes are identified in several SPVs to be part of one service, we consider that Shared classes form the core of the reusable service. Thus, C3, C4, C8 and C9 should be included in the service identified from the cluster presented in Figure 7. However, these classes may not form a correct service following our quality fitness function.

Thus, some Non-Shared classes need to be added to the reusable service, in order to keep the service quality high.

The selection of a Non-Shared class to be included in the service is based on the following criteria:

• The quality of the service obtained by adding a Non-Shared class to the core ones. This criterion is to increase the service quality. Therefore, classes maximizing the quality fitness function value are more preferable to be added to the service.

• The density of a Non-Shared class in a cluster of similar services. This refers to the occurrence ratio of the class compared to the services of this group. It is calculated based on the number of services including the class to the total number of services composing the cluster. We consider that a class having a high density value contributes to build a reusable service because it keeps the service belonging to a larger number of SPVs. For example, in Figure 7, the densities of C2 and C1 are respectively 66% (2/3) and 33% (1/3). Thus, C2 is more preferable to be included in the service than C1, as C2 keeps the reusable service belonging to two SPVs, while C1 keeps it belonging only to one SPV.

As results of the clone-and-own approach, classes of identified services could have di↵erent implementations across various SPVs. These di↵erent implementations of the same cloned class across SPVs should be merged by creating one suitable and representative abstraction that allows the variability configuration, e.g., using the preprocessing annotations. In literature, we identify potential approaches to be reused for merging the several implementations of cloned methods/classes [17] [18]. 534 Therefore, we propose to identify the optimal solu-535 tion only for services with a small number of Non-Shared 536 classes. Otherwise, we rely on a near-optimal solution.

537

In the following subsections, we discuss two algorithms to 538 identify an optimal solution and a near-optimal one re- Then, it divides the size of the greatest subset by the size of M (c.f. line 5) and returns SI as a final return value (c.f. line 6).

Input Object-oriented method cohesion. Methods access the same set of attributes to participate to provide the same services. Thus, cohesive methods have more probability to belong the same service interface than those that are not. To measure how much a set of methods is cohesive, we use the Loose Class Cohesion (LCC) metric [START_REF] Bieman | Cohesion and reuse in an object-1343 oriented system[END_REF]. We select LCC because it measures direct and indirect dependencies between methods. Please refer to [START_REF] Bieman | Cohesion and reuse in an object-1343 oriented system[END_REF] for more details about LCC. Interf ace(M ) = [START_REF] Tizzei | An aspect-based feature 1373 model for architecting component product lines[END_REF][START_REF] Salman | Feature-level change 1369 impact analysis using formal concept analysis[END_REF][START_REF] Martinez | Feature location benchmark with 1378 argouml spl[END_REF][START_REF] Shatnawi | Recovering software 1381 product line architecture of a family of object-oriented product 1382 variants[END_REF]. Third, the suitability of the case studies to identify services that were reused in the implementation of several SPVs. Fourth, the availability of their source code.

Method

1 P i i •( 1 •SI(M )+ 2 •LCC(M )+ 3 • 661 CS(M ) + 4 • CU (M )) (5

Research questions and their methodologies

We aim to answer four Research Questions (RQs) as follows. The results of incrementing 5% each time allow us to identify the interesting intervals as [65%, 70%], [75%, 80%] and [80%, 85%] respectively for MM, HW and AL case studies. Thus, any value in these intervals can be selected as a threshold to be considered respectively for each case study. We rely on the number of functionalities of the analyzed SPVs to select threshold values in these intervals. We use the number of classes of SPVs as indicators for the number of functionalities implemented in the SPVs (direct proportion). We assign 70%, 77% and 83% as threshold values respectively for MM, HW and AL case studies. Table 1 shows the detail results obtained based on these threshold values. It presents the total number of potential services (TNOPS) identified based on the analysis of all SPVs, the average size of these services (ASOS) in terms on number of included classes, the average value of the Functionality characteristic (AF), the average value of the Self-containment characteristic (ASC) and the average value of the Composability characteristic (AC). classes to this identified service. We find that classes added later reduce the quality of the identified service. Therefore, we reject classes added after the 18th class to be part of this identified service.

5.

RQ2: What potential services implement similar functionalities across di↵erent SPVs?

Table 2 presents the results of the process of grouping similar potential services into clusters. For each case study, it shows the number of clusters (NOC), the average number of services in the identified clusters (ANOC), with the other SPVs, in average. Thus, a reusable service 878 can be identified from these services. In the same way, AL 879 SPVs share 5.26 services. Table 3 shows an example of 880 a cluster of similar services identified from AL case study,

881

where X refers to that a class is a member in the corre-882 sponding SPV. In this example, we note that the services Table 4 summarizes the final set of reusable services identified using ReSIde. Based on our experimentation, we assign 50% to the density threshold value. For each product family (i.e., a set of SPVs), we present the number of the identified services (NOIS), the average service size in terms of number of included classes (ASS), and the average value of the Functionality (AF), the Self-containment (ASC), and the Composability (AC) of the identified services. The results show that some of the identified clusters do not produce reusable services. For instance, in Mobile Media, the 42 clusters produce only 39 services.

This means that three of the clusters are not able to form reusable services. The reason behind that is one of the following two situations. The first one is that the selection of threshold density causes to remove classes that are important to constitute the service, and hence, the service was rejected because it did not exceed the quality threshold value. The second one is that the produced service is already identified from another cluster, therefore, the

1 2 3 4 5 6 7 8 9 ArgoEventTypes X X X X X X X X X JWindow X X X X X X X X X TabFigTarget X X X X X X X X X FileConstants X X X X X X X X X OclAPIModelInterpreter X X X X X X X X X StreamSource X X X X X SortedListModel X X X X X BooleanSelection2 X X X X
service is removed to avoid the redundancy.

909 Screen. The former one deals with adding a photo to an 919 album. The letter is dedicated to the splash screen service. The results obtained from MM, HW and AL case studies are respectively presented in Figure 13, Figure 14 and Figure 15. These results show that the reusability of the services which are identified from a collection of similar software is better than the reusability of services which is identified from singular software. We note that the reusability is increased when the number of K is increased.

The reason is that the number of train SPVs is increased compared to the test SPVs. For example, there is only one test SPV when K=8. We note that the di↵erence between the reusability results of the two approaches is increased as well as the number of train SPVs is increased.

The slight di↵erence between the reusability results for small K comes from the nature of our case studies, where these case studies are very similar. Consequently, the resulting services are closely similar. In other words, there are many groups of similar services containing exactly the same classes. This yields a reusable service that is identical to cluster services. Therefore, the reusability has the same value for all of these services. However, ReSIde remains outperforming the traditional service identification approach proposed by Adjoyan et al. [6]. In Table 5.3.4, we provide a conceptional comparison between the ReSide and Adjoyan approaches based on seven attributes.

Discussion

Deployment of the identified services

ReSide currently reverse engineers the structural implementation of reusable services in terms of groups of object-oriented classes. To complete the reengineering to SOA, these groups of classes need to be transformed and packaged based on existing service-oriented models. Therefore, we plan in our near future work to extend ReSide where reusable web services (e.g., generate WSDL files) and REST services can be generated from these groups of clusters identified in this paper. In this context, we need to deal with direct dependencies between di↵erent services, exception handling of Java programs and the instantiation of services. Also, the ASTs do not consider polymorphism and dynamic binding. Consequently some dependencies are not captured (e.g., Java reflection dependencies).

This impacts the recall of the identified services.

2. We use a hierarchical clustering algorithm to group similar services. We use this hierarchical clustering algorithm because it does not need to specify the number of clusters in advance as we do not know the number of services to be identified in advance.

However, it provides a near optimal solution of the the performance of the identified services may be negatively impacted as the service technologies add communication layers between services. This impact can be amplified if the identified services rely on heavy data exchange.

The security challenge maybe emerged if the identified services are going to be accessed by third-party applications.

Related work

In this section, we discuss four research areas crosscutting with ReSIde. These are service identification, component identification, software product line architecture recovery and feature identification research areas. We decide to also include the latter three research areas because we find that they share with service identification similar input artifacts (e.g., source code) and technical analysis processes (e.g., reverse engineering, clustering algorithm), but with di↵erent conceptual identification goals (i.e., service vs component vs feature). The goal of an identification approach can be: understanding, reuse, construction, evolution, analysis or management [START_REF] Garlan | Software architecture: A roadmap[END_REF]. Software understanding is supported by providing a high level of abstraction describing the system structure. Reuse is supported by providing a coarse-grain software entities that can be easily decoupled from the system and deployed in another one. Construction is guided by explaining how software components interact with each other through their interfaces. A better comprehension of the outcome changes is provided to software maintainers.

Thus, they can be more precise in estimating cost of modifications of the software evolution. Software analysis is enriched by understanding the dependencies provided by software architectures. Managing the development tasks get success, when a clear view of the system structure is provided [START_REF] Garlan | Software architecture: A roadmap[END_REF].

The input of a service identification approach can be source codes [6, 27, 7, 28, 29], data bases [30,31,[START_REF] Del Grosso | An approach 1406 for mining services in database oriented applications[END_REF], execution and log traces [START_REF] Fuhr | Using dynamic analysis and 1410 clustering for implementing services by reusing legacy code[END_REF][START_REF] Upadhyaya | An approach to extract 1414 restful services from web applications[END_REF][START_REF] Mani | Using 1418 user interface design to enhance service identification[END_REF], business process models [START_REF] Sosa | A model-driven process to modernize legacy web 1423 applications based on service oriented architectures[END_REF][START_REF] Amiri | Multifaceted service 1427 identification: Process, requirement and data[END_REF], knowledge of human expertises [27,[START_REF] Sneed | Integrating legacy software into a service ori-1430 ented architecture, in: Software Maintenance and Reengineer-1431 ing[END_REF], documentations [START_REF] Aversano | Mining candidate web 1434 services from legacy code[END_REF][START_REF] Nakamur | Identifying 1437 services in procedural programs for migrating legacy system to 1438 service oriented architecture, Implementation and Integration 1439[END_REF][START_REF] Zhang | Incubating services in legacy systems for 1441 architectural migration[END_REF][START_REF] Sneed | Migrating to web services: A research framework[END_REF] or a combination of these input artifacts [29, [START_REF] Zhang | Service identification and packaging 1446 in service oriented reengineering[END_REF][START_REF] Fuhr | Using dynamic analysis and 1410 clustering for implementing services by reusing legacy code[END_REF].

The process of service identification approaches aims to examples, services can be web-services [START_REF] Alonso | Web services[END_REF], micro-services [START_REF] Namiot | On micro-services architec-1506 ture[END_REF], REST services [START_REF] Riva | Designing web-based mobile services 1509 with rest[END_REF], etc., while components can be OSGi [START_REF] Alliance | Osgi service platform[END_REF], Fractal [START_REF] Bruneton | The fractal component model and its support in java[END_REF], SOFA [START_REF] Plasil | Sofa/dcup: Architecture for 1517 component trading and dynamic updating[END_REF], etc. These have variations in their specification that make the implementation of services and components varied and respectively their provided and required interfaces.

Therefore, we can see that service identification and component identification are very similar in terms of identifying architectural elements that represent main reusable functionalities, but they are di↵erent in the way of packaging these functionalities following SOA or componentbased models and deployment technologies (e.g., REST services vs OSGi components).

Many approaches were proposed to identify components from object-oriented software such as [START_REF] Kebir | Quality-centric 1521 approach for software component identification from object-1522 oriented code[END_REF][START_REF] Mishra | Creating reusable software component from object-oriented legacy system through reverse engineering[END_REF][START_REF] Allier | Restructuring object-oriented applications into component-oriented applications by using consistency with execution traces[END_REF][START_REF] Shatnawi | Reverse engineering reusable software components from object-oriented apis[END_REF][START_REF] Shatnawi | Identifying components from objectoriented apis based on dynamic analysis[END_REF][START_REF] Alshara | Materializing architecture recovered from object-oriented source code in component-based languages[END_REF]. These approaches mined components from single software that limits the reusability of identified components.

In [START_REF] Kebir | Quality-centric 1521 approach for software component identification from object-1522 oriented code[END_REF] SPLA recovery approaches are similar to our approach in terms of the analysis of the variability between software products. However, compared to our service identification approach, they are di↵erent in their goal which is the identification of one architecture model that describes the design of a set of software products in the same family of software product line [START_REF] Clements | Software product lines: practices and patterns[END_REF] based on variation points and variants between architectural-elements [START_REF] Gomaa | Designing software product lines with uml[END_REF][START_REF] Lima | Product line architecture recovery: an approach proposal[END_REF][START_REF] Zahid | Evolution in software architecture recovery techniques-a survey[END_REF]. In other words, their focus is more on the understandability of the design of the family of products than the reusability of identified services.

Technically, SPLA recovery approaches identify component- The distinguish between service identification and fea-1217 ture identification approaches comes from the di↵erences 1218 between the concepts of a service and a feature. We have the variability between these products like [START_REF] Xue | Reengineering legacy software products into software 1603 product line based on automatic variability analysis[END_REF][START_REF] Ziadi | Feature identi-1607 fication from the source code of product variants[END_REF][START_REF] Ra'fat | Feature location in a collection of software product 1612 variants using formal concept analysis[END_REF][START_REF] Carbonnel | Variability represen-1615 tation in product lines using concept lattices: feasibility study 1616 with descriptions from wikipedia's product comparison matri-1617 ces[END_REF]. We consider that identifying service based on the analysis 1254 of multiple SPVs provides more guarantee for the reusabil-

2.

  Proposition of more details and deep analysis of the proposed solution, e.g., by giving more details about used algorithms and illustrating the solution based on new examples and figures. 3. Adding a new case study that is Health Watcher and consequently extending the evaluation. 4. Presentation of new detailed results and new analysis of their relevance.

5.

  Adding threats to validity discussions. 6. Important extension of related work analysis and classification. 7. The analysis of the research and practical implications of the obtained results. The rest of this paper is organized as follows. Section 2 99 presents a background needed to understand our approach. 100 In Section 3, we provide the foundations of ReSIde. Sec-101 tion 4.1 discusses how ReSIde identifies potential services 102 from each SPV. In Section 4.2, we present the identifica-103 tion of similar services between di↵erent SPVs. Reusable 104 services are recovered from the similar ones in Section 4.3. 105 Section 4.4 presents how ReSIde structures the service in-106 terfaces. The evaluation results are discussed in Section 5 107 and Section 6. In Section 7, we present the related works 108 to our approach. A conclusion of this paper is presented 109 in Section 8.

Figure 1 :

 1 Figure 1: Service quality model

  i are parameters used by the practitioners to weight each characteristic. The Functionality (Fun), the Composability (Comp) and the Self-Containment (SelfCon) of a group of classes (E) are measured based on Equation 2, Equation 3 ) + Coupl(E) + LCC(E))

186Figure 2 :Figure 3 :

 23 Figure 2: Illustrative example of two SPVs

  265 3.3. ReSIde process 266 Based on what we mentioned before, we propose a pro-267 cess presented in Figure 4 to identify reusable services from 268 a set of SPVs. This process consists of four main steps.269 1. Identification of potential services in each SPV. 270 We analyze each SPV independently to identify all 271 potential services composing each SPV. To identify 272 quality-centric potential services, we rely on object-273 oriented dependencies between classes to evaluate 274 their quality. We consider that any set of classes 275 could form a potential service if and only if it has an 276 accepted value following the quality fitness function 277 of the quality model presented in Section 2. 278 In our illustrative example, we identify the 5 clus-279 ters of classes corresponding to potential services in 280

290 2 .Figure 4 :

 24 Figure 4: The process of reusable services identification from multiple SPVs

Input: 8 service = service + c1; 9 candidateClasses = candidateClasses -c1; 10 if

 8910 Object-Oriented Source Code(OO) Output: A Set of Potential Services(P S) 1 classes = extractInformation(OO); 2 for each c in classes do 3 service = c; Q(service)) > Q(bestService) then 11 bestService = service; end end 12 if Q(bestService) > Q threshold then 13 P S = P S + bestService; end end 14 return P S Algorithm 1: Identifying Potential Services 4.2.1. Method to identify similar services 404 SPVs are usually developed using the clone and own 405 technique. Thus, we consider that classes having simi-406 lar names implement almost the same functionalities. Al-407 though some of the composed methods are overridden, 408 added or deleted, the main functionalities are still the same 409 ones from the architectural point of view. Therefore, the 410 similarity as well as the di↵erence between services are 411 calculated based on the object-oriented classes composing 412 these services. Thus, similar services are those sharing the 413 majority of their classes and di↵ering considering the other 414 ones. 415 Groups of similar services are built based on a lexical 416 similarity metric. Thus, services are identified as simi-417 lar compared to the strength of similarity links between 418 classes composing them. A survey of text similarity met-419 rics is conducted in [16]. Practitioners could use any of 420 these similarity metrics based on their needs. For our ex-421 perimentation, we selected the cosine similarity metric be-422 cause it is based on the angle between vectors instead of 423 points [15]. Following this cosine similarity metric each 424 service is considered as a text document, which consists of 425 a list of service classes' names. The similarity between a 426 set of services is calculated based on the ration between 427 the number of shared classes to the total number of dis-428 tinguished classes.

Figure 5 :c1

 5 Figure 5: Forming potential services by incremental selection of classes

Figure 6

 6 Figure 6 shows an example of a dendrogram, where S i refers to Service i . The second algorithm aims at traveling through the built dendrogram, in order to extract the best clusters, representing a partition. To build a dendrogram of similar services, we rely on Algorithm 2. It takes a set of potential services as an input. The result of this algorithm is a dendrogram representing candidate clusters, similar to Figure 6. The algorithm starts by considering individual services as initial leaf nodes in a binary tree, i.e., the lowest level of the dendrogram in Figure6(c.f. line 1). Next, the two most similar nodes are grouped into a new one, i.e., as a parent of them (c.f. lines 3 and 4). For example, in Figure6, the S 2 and S 3 are grouped. This is continued until all nodes are grouped in the root of the dendrogram (c.f. lines 2 to 7).

Figure 6 :

 6 Figure 6: An example of a dendrogram

468

  Input: Dendrogram(dendrogram) Output: A Set of Clusters of Potential Services(clusters) 1 Stack traversal; 2 traversal.push(dendrogram.getRoot()); 3 while (! traversal.isEmpty()) do 4 Node father = traversal.pop(); 5 Node lef t = dendrogram.getLeftSon(father); 6 Node right = dendrogram.getRightSon(father); 7 if similarity(father) > (similarity(lef t) + similarity(right) / 2) then 8 clusters.add(father) 9 else 10 traversal.push(lef t); 11 traversal.push(right); end end 12 return clusters Algorithm 3: Dendrogram Traversal to Identify Cluster of Similar Services 4.3. Identification of one reusable service from similar po-469 tential services 470 As previously mentioned, similar services are consid-471 ered as variants of a common one. Thus, from each cluster 472 of similar services, we extract a common service which is considered as the most reusable compared to the members of the analyzed group. 4.3.1. Method to identify reusable service based on similar ones Classes composing similar services are classified into two types. The first one consists of classes that are shared by these services. We call these classes as Shared classes. In Figure 7, C3, C4, C8 and C9 are examples of Shared classes in the three services belonging to the cluster of similar services. The second type is composed of other classes that are diversified between the services. These are called as Non-Shared classes. C1, C2, C5, C6, C7 and C10 are examples of Non-Shared classes in the cluster of similar services presented in Figure 7.

Figure 7 :

 7 Figure 7: An example of a cluster of three similar services

540 7 nonShared = allClasses shared; 8 allSubsets 9 reusableService = shared; 10 bestService = reusableService; 11 for each subset 2 allSubsets do 12 if

 789101112 Algorithm providing optimal solution for reusable service 541 identification. Algorithm 4 computes an optimal reusable 542 service from similar ones, where Q refers to the service 543 quality fitness function, Q threshold refers to the prede-544 fined quality threshold and D threshold refers to the pre-545 defined density threshold. First, for each cluster of similar 546 services, we extract all candidate subsets of classes among 547 the set of Non-Shared ones (c.f. lines 1 to 8). Then, the 548 subsets that reach a predefined density threshold are only 549 selected (c.f. line 12). The density of a subset is the aver-550 age densities of all classes in this subset. Next, we evaluate 551 the quality of the service formed by grouping core classes 552 with classes of each subset resulting from the previous step 553 (c.f. lines 13 and 14). Thus, the subset maximizing the 554 quality value is grouped with the core classes to form the 555 reusable service. Only services with a quality value higher 556 than a predefined threshold are retained (c.f. lines 15 to 557 17). 558 Algorithm providing near-optimal solution for reusable ser-559 vice identification. We defined a heuristic algorithm pre-560 Input: Clusters of Services(clusters) Output: A Set of Reusable Services(RC) 1 for each cluster 2 clusters do 2 shared = cluster.getFirstservice().getClasses; 3 allClasses = ;; 4 for each service 2 cluster do 5 shared = shared \ service.getClasses(); 6 allClasses = allClasses [ service.getClasses(); end = generateAllsubsets(nonShared); Density(subset) > D threshold then 13 if Q(reusableService [ subset)) > Q(bestService) then 14 bestService = reusableService [ subset; end end end 15 if Q(bestService) >= Q threshold then 16 add(RC,bestService); end end 17 return RC Algorithm 4: Optimal Solution for Reusable Service Identification sented in Algorithm 5, where Q refers to the quality fit-561 ness function, Q threshold refers to the predefined quality 562 threshold and D threshold refers to the predefined density 563 threshold. First of all, Non-Shared classes are evaluated 564 based on their density. The Classes that do not reach a 565 predefined density threshold are rejected (c.f. lines 9 to 566 11). Then, we identify the greater subset that reaches a 567 predefined quality threshold when it is added to the core 568 classes. To identify the greater subset, we consider the 569 set composed of all Non-Shared classes as the initial one 570 (c.f. lines 9 to 11). This subset is grouped with the core 571 classes to form a service. If this service reaches the pre-572 defined quality threshold, then it represents the reusable 573 service (c.f. lines 12 to 15). Otherwise, we remove the 574 Non-Shared class that reduces the quality of the service 575 when this Non-Shared class is added to the correspond-576 ing core classes (c.f. line 17). We do this until a service 577 reaching the quality threshold or the subset of Non-Shared 578 classes becomes empty (c.f. line 12).

5794. 4 . 7 nonShared = allClasses shared; 8 reusableService = shared; 9 for each class 2 nonShared do 10 if

 478910 Identification of object-oriented methods correspond-580 ing to service interfaces 581 A service is used based on its provided and required 582 interfaces. For object-oriented services, the interaction Input: Clusters of Services(clusters) Output: A Set of Reusable Services(RC) 1 for each cluster 2 clusters do 2 shared = cluster.getFirstservice().getClasses; 3 allClasses = ;; 4 for each service 2 cluster do 5 shared = shared \ service.getClasses(); 6 allClasses = allClasses [ service.getClasses(); end Density(class) < D threshold then 11 nonShared = nonSharedclass; end end 12 while (|nonShare| > 0) do 13 if Q(reusableService [ nonShare) >= Q threshold then 14 add(RC,reusableservice); Algorithm 5: Near-Optimal Solution for Reusable Service Identification between the services is realized through object-oriented 584 method calls (i.e., method invocations). A service pro-585 vides its services through a set of object-oriented methods 586 that can be called by the other services that require func-587 tionalities of this service. Thus, the provided interfaces 588 are composed of a set of public methods that are imple-589 mented by classes composing this service. On the other 590 hand, required interfaces are composed of methods that 591 are invoked by classes of this service and belong to classes 592 of other services (i.e., the provided interfaces of the other 593 services). The identification of service interfaces is based 594 on grouping a set of object-oriented methods into a set of 595 service interfaces. We rely on the following heuristics to 596 identify these interfaces: 597 Object-oriented methods belonging to the same 598 object-oriented entities. In object-oriented, meth-599 ods implementing cohesive functionalities are gen-600 erally implemented by the same object-oriented en-601 tities (e.g., object-oriented interface, abstract class 602 and concrete class). Therefore, we consider any object-603 oriented entity that groups together a set of methods 604 as an indicator of high probability that these meth-605 ods belong to the same service interface. We propose 606 Algorithm 6 to measure how much a set of methodsM belongs to the same service interface. This algorithm calculates the size of the greatest subset of M which consists of methods that belong to the same object-oriented class or interface (c.f. lines 1 to 4).

  lexical similarity. The lexical similarity of methods probably indicates to similar implemented services. Therefore, methods having a lexical similarity likely belong to the same interface. To this end, we utilize Conceptual Coupling metric [19] to measure methods lexical similarity based on the semantic information obtained from the source code, encoded in identifiers and comments. Method correlation of usage: when a service provides functionalities for another service, it provides them through the same object-oriented entities (e.g., objectoriented interface, abstract class and concrete class). Thus, methods that have got called together by objectoriented classes the other services are likely to belong to the same service interface. To this end, we propose Algorithm 7 to calculate the Correlation of Usage (CU ) of a given set of methods M. It is based on the size of the greatest subset of M that has got called together by the same service (c.f, lines 2 to 4). The final value of CU is the percentage between the 644 identified size of the greatest subset and the size of 645 M (c.f, line 5). 646 Input: A Set of Methods(M ), a Set of services(Services) Output: Correlation of Usage Value(CU ) 1 sizeGreatest = |M \ Services.getFirstservice().getCalledMethods()|; 2 for each service 2 Services do 3 if |M \ service.getCalledMethods()| > sizeGreatest then 4 sizeGreatest = |M \ interf ace.getCalledMethods()|; end end 5 CU = sizeGreatest / M.size(); 6 return CU Algorithm 7: Correlation of Usage (CU) According to these heuristics, we define a fitness func-647 tion for measuring the quality of a group of methods M to 648 form a service interface. We rely on a set of parameters 649 (i.e., i ) to allow architects to weight each characteristic 650 as needed. The values of these parameters are situated in 651 [0-1]. The selection of values of these parameters is based 652 on the knowledge of architects about the SPVs. Further-653 more, architects could use these parameters to analyze the 654 relationships between each characteristic and the quality 655 of the obtained service interfaces by changing the values of 656 parameters. Once architects identify the best values based 657 on a set of test cases of service interfaces, they could gen-658 eralize these values to the remaining of the SPVs in the 659 same family.660

753Methodology.Figure 8 :

 8 Figure 8: The process of validating the reusability of services identified by ReSIde

  835

Figure 9 :

 9 Figure 9: Changing threshold value to extract potential services from MM

Figure 12 presents

 12 Figure 12 presents an example of a potential service extracted from AL. This service is identified by considering GoClassToNavigableClass as the core class. The quality fitness function reaches the peak value when we add 18

Figure 10 :

 10 Figure 10: Changing threshold value to extract potential services from HW

TNOPS

  : total number of potential services. ASOS : average size of potential services in classes. AF : average value of the Functionality characteristic of potential services. ASC : average value of the Self-containment characteristic of potential services. AC : average value of the Composability characteristic of potential services. the average number of Shared classes in these clusters 869 (ANSC), the average value of the Functionality charac-870 teristic (AFS), the average value of the Self-containment 871 characteristic (ASCS), and the average value of Compos-872 ability characteristic of the Shared classes (ACS) in these 873 clusters. The results show that SPVs sharing a bunch of 874 similar services. For instance, each SPV of MM has 24.5 875 services in average. These services are grouped into 42 876 clusters. This means that each SPV shares 5.38 services 877

883 have 5

 5 Shared classes. These classes have been identified 884 to be part of the same service in 9 SPVs of AL. Thus, 885 they can be considered as core classes to form a reusable 886 service that is reused in the 9 SPVs.

  887

Figure 11 :

 11 Figure 11: Changing threshold value to extract potential services from AL

NOC

  : the number of clusters. ANOC : the average number of services in the identified clusters. ANSC : the average number of Shared classes in these clusters. AFS : the average value of the Functionality of the Shared classes in the identified clusters. ASCS : the average value of the Self-containment of the Shared classes in the identified clusters. ACS : the average value of Composability of the Shared classes in the identified clusters. 5.3.3. RQ3: What are the reusable services identified based on ReSide?

Figure 12 :

 12 Figure 12: An instance of a potential service extracted from AL case study

NOV

  : the number of SPVs that contain the services. NOC : the number of classes that form the services. F : the value of the Functionality characteristic of the services. S : the value of the Self-containmentcharacteristic of the services. C : the value of the Composability characteristic of the services. 5.3.4. RQ4: What is the reusability of services identified based on ReSide?

Figure 13 :Figure 14 :

 1314 Figure 13: The results of reusability validation of MM services

  by two types of threats to validity.973These are internal and external.

  974 6.3.1. Threats to internal validity 975 There are three aspects to be considered regarding the 976 internal validity. These are as follows.977

Figure 15 :

 15 Figure 15: The results of reusability validation of AL services

  partitioning. Other grouping techniques may provide more accurate solutions, such as search-based 5 https://www.eclipse.org/jdt/ algorithms. This will be a future extension of Re-1005 SIde to implement simulated annealing and genetic 1006 algorithms.1007 3. Due to the lack of models that measure the reusabil-1008 ity of object-oriented services, we propose our own 1009 empirical measurement to validate the reusability of 1010 the identified services. This can threat the reusabil-1011 ity validation results.1012 6.3.2. Threats to external validity 1013 There are two aspects to be considered regarding the 1014 external validity. These are as follows: 1015 1. ReSIde is experimented via SPVs that are imple-1016 mented by Java. As other object-oriented languages 1017 (e.g., C++, C#) include other concepts than Java 1018 (e.g., templates and preprocessor directives in C++), 1019 we need to develop new parsers to handle these new 1020 concepts properly to allow ReSide to work with these 1021 other languages.1022 2. Only three case studies have been collected in the ex-1023 perimentation (Mobile Media, Health Watcher and 1024 ArgoUML). However these are used in several re-1025 search papers that address the problem of migrat-1026 ing SPVs into software product line. On average, 1027 the selected case studies obtained the same results.

  7.1. Service identificationSeveral service identification approaches have been proposed to identify services based on the analysis of objectoriented software[6,[START_REF] Rodríguez-Echeverría | Generating a rest service layer from 1321 a legacy system[END_REF][START_REF] Gysel | Service 1324 cutter: A systematic approach to service decomposition[END_REF][START_REF] Abdellatif | Toward service identification to support legacy object-1328 oriented software systems migration to soa[END_REF]. According to the life cycle of service identification approaches, we classify approaches presented in the literature based on four axes; the goal, the input, the applied process and the resulting output of service identification approaches. In our classification, we select approaches based on two criteria. The first one focuses on the approaches that are frequently cited since they are considered as the most known approaches presented in the state-of-the-art. The second one is related to the comprehension of the classification axes. This means that we select approaches that cover all of the classification axes to give concrete examples of these classification axes.

  , Kebir et al. extracted the component-based architecture based on partitioning classes into clusters corresponding to components. The partitions are based on static code dependencies. Mishra et al. [67] also extracted the component-based architecture. Components are extracted based on information realized in use cases, sequence diagrams, and class diagrams. Unlike source code, sequence diagrams, use cases, and class diagrams are not always available. Hamza [72] identified components from requirements and use cases using formal concept analysis. He focused on the component stability rather than the component reusability. Allier et al. [68] depended on dynamic dependencies between software classes to extract a component-based architecture. They relied on the use-cases to identify the execution trace scenarios. Classes that frequently occur in the execution traces are grouped into a component. Liu et al. [73] identified interfaces of identified components. Similar to our approach, they defined a component interface as a group of methods belonging to the cluster of classes of an identified component. They relied on process mining tools to analyze the direct connections between the clusters of classes.7.3. Software product line architecture identification

1203

  based architecture (not potential reusable services) from 1204 each software product as disjoint clusters of classes that 1205 describe the system structure of this product. Then, they 1206 analyze the variability between the recovered architectures 1207 to identify variation points and variants using clone de-1208 tection algorithm [78, 79, 80], clustering algorithm [25],1209 or user-defined heuristics[START_REF] Pinzger | Architecture recovery for product families[END_REF][START_REF] Kang | Feature-oriented reengineering of legacy systems into product line assets-a case study[END_REF]. They identify di↵er-1210 ent aspects of SPLA such as mandatory components[START_REF] Shatnawi | Recovering software 1381 product line architecture of a family of object-oriented product 1382 variants[END_REF], 1211 optional components[START_REF] Shatnawi | Recovering software 1381 product line architecture of a family of object-oriented product 1382 variants[END_REF], component variability[78, 81, 1212[START_REF] Shatnawi | Recovering software 1381 product line architecture of a family of object-oriented product 1382 variants[END_REF][START_REF] Koschke | Extending the reflexion method for consolidating software variants into product lines[END_REF][START_REF] Kang | Feature-oriented reengineering of legacy systems into product line assets-a case study[END_REF][START_REF] Kolb | A case study in refactoring a legacy component for reuse in a product line[END_REF], variability dependencies between di↵erent 1213 components[START_REF] Shatnawi | Recovering software 1381 product line architecture of a family of object-oriented product 1382 variants[END_REF][START_REF] Koschke | Extending the reflexion method for consolidating software variants into product lines[END_REF][START_REF] Kang | Feature-oriented reengineering of legacy systems into product line assets-a case study[END_REF], and feature model of architecture

1246

  In this paper, we presented ReSIde (Reusable Service 1247 Identification): an automated approach that identifies reusable 1248 services based on the analysis of a set of similar object-1249 oriented SPVs. ReSIde identifies reusable functionalities 1250 of cloned codes that can be qualified as services across 1251 multiple SPVs based on the analysis of the commonality 1252 and the variability between the source code ofthese SPVs.

  1253

  We applied the second step of ReSide to

	730
	731	the quality fitness function, we apply the second strategy
	732	which consists of exploring the values in this interval by a
	733	finer increment which is 1. We show the impact of thresh-
	734	old values on the average number of identified services for
	735	each software family of SPVs.
	736	5.2.2. RQ2: What potential services implement similar
	737	functionalities across di↵erent SPVs?
	738	Goal. The goal of this RQ is to study the characteristics
		of potential services identified as similar across SPVs.
	740
	741	cluster similar potential services based a hierarchical clus-
	742	tering technique. For each case study, we identify the num-
	743	ber of clusters, the average number of services in the identi-
		fied clusters, the average number of Shared classes in these
	Methodology. To support software architects choosing a
	proper threshold value, we assign the quality threshold
	values situated in [0%, 100%]. The goal of changing the
	threshold values is to explicitly identify the general rela-
	tionship between the number of identified services and the
	selected threshold values. To do this, we need to explore
	all the values of the interval [0%-100%]. To segment this
	interval, we can start from 0% and increment using any
	value (1%, 1.55%, 5%, 8,09%, 23%, etc.). We rely on two
	strategies applied successively.
	The first strategy is to explore the threshold values based
	on a 5% increment. We consider that 5% is a fair empirical
	increment for two reasons. First it provides a finite num-

2.1. RQ1: What are good threshold values to identify potential services from each SPV? Goal. As the selection of threshold values a↵ects both the quality and the number of the identified potential services, the aim of this RQ is to help software architects selecting proper threshold values to consider a group of classes forming a potential service or not. ber of values that are distributed uniformly compared to this interval (i.e. 0%, 5%, 10%, 15%... 100%). Second, the variation of values obtained based on successive increments allows the interpolation of other unconsidered values. As soon as we identify an interesting interval based on the number of identified services and the maximum value of 739 Methodology. 744 clusters, the average value of the Functionality character-745 istic, the average value of the Self-containment character-746 istic, and the average value of Composability characteristic 747 of the Shared classes in these clusters.

748 5.2.3. RQ3: What are the reusable services identified based 749 on ReSide? 750 Goal. The aim of this RQ is to to study the characteris-751 tics of reusable services identified from clusters of similar 752 potential services.

Table 1 :

 1 The results of potential services extraction

	Family Name TNOPS ASOS AF ASC AC
	MM	24.50	6.45	0.56	0.71	0.83
	HW	96.6	5.55	0.61	0.76	0.99
	AL	811	11.38	0.64	0.83	0.89

Table 2 :

 2 The results of service clustering

	Family Name NOC ANOC ANSC AFS ASCS ACS
	MM	42	5.38	5.04	0.59	0.71	0.89
	HW	504	6.17	5.33	0.62	0.74	0.99
	AL	325	5.26	8.67	0.57	0.87	0.93

Table 4 :

 4 The final set of identified reusable services. : the number of the identified reusable services. ASS : the average size of identified reusable services in terms of number of included classes. AF : the average value of the Functionality of identified reusable services. ASC : the average value of the Self-containment of identified reusable services. AC : the average value of the Composability of identified reusable services.

	Family Name NOIS ASS AF ASC AC
	MM	39	5.61 0.58	0.74	0.90
	HW	443	6.90 0.63	0.75	0.99
	AL	324	9.77 0.61	0.84	0.84

NOIS

Table 5

 5

	910	shows examples of a set of reusable services
	911	that are identified based on the analysis of Mobile Me-
	912	dia. Where, NOV refers to the number of SPVs that con-
	913	tain the service, NOC represents the number of classes
	914	that form the service. S, A and C respectively represent
		the Functionality, the Self-containment, and the Compos-
	918

915

ability of each service. As it is shown in Table 5, the 916 second service provides two functionalities, which are Add 917 Constants Photo Album, and Count Software Splash Down

Table 5 :

 5 Some services

	Description of the functionalities	NOV NOC	S	A	C
	New Constants Screen Album Image	6	6	0.59 0.75 0.94
	Add Constants Photo Album Count Software Splash Down Screen	8	10	0.57 0.75 0.89
	Base Image Constants Album Screen Accessor List Controller Image Interface Thread	6	9	0.67 0.50 0.85

Table 6 :

 6 Comparisons between ReSide and Adjoyan's approaches

	Attributes	ReSide approach	Adjoyan's approach
	Goal	Service identification	Service identification
	Input artifacts	Multiple software product variants	Single software product
	Target development paradigm Object-oriented	Object-oriented
	Quality metrics	Structural and co-existence together dependencies	Structural dependencies
	Used Algorithms	Authors' defined heuristic and clustering algorithms Clustering algorithm
	Service interface identification Yes	No
	Output	Clusters of classing corresponding to services	Clusters of classing corresponding to services

  1102 cluster elements of input artifacts into services. Existing 1103 approaches uses several algorithm including clustering al-1104 gorithm, genetic algorithm [27, 44], Formal Concept Anal-1105 ysis [45, 32, 46] or user-defined heuristics [27, 8]. These 1106 algorithms rely on various quality characteristics in their 1107 fitness functions to maximize the service quality of iden-1108 tified clusters. Such quality characteristics are loose cou-1109 pling [6, 27, 28, 47, 40, 43, 48, 49, 41], cohesion [6, 27, 28, 1110 architectural elements and functions. Services and components are di↵erent in terms of deployment technologies and models that are used to technically implement them. For

Available at http://homepages.dcc.ufmg.br/⇠figueiredo/spl/icse08

Available at http://ptolemy.cs.iastate.edu/designstudy/#healthwatcher

 4 Available at http://argouml-spl.tigris.org/

A component is "abstract, self-contained packages of functionality performing a specific business function within a technology framework. These business components are reusable with well-defined interfaces"[START_REF] Baster | Business components: A 1497 case study of bankers trust australia limited[END_REF]

].[START_REF] Rodríguez-Echeverría | Generating a rest service layer from 1321 a legacy system[END_REF] A component is "a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third

parties"[START_REF] Szyperski | Component software: beyond object-oriented pro-1500 gramming[END_REF].[START_REF] Gysel | Service 1324 cutter: A systematic approach to service decomposition[END_REF] A component is "a software element that (a) encapsulates a reusable implementation of functionality, (b) can be composed without modification, and (c) adheres to a component model"[59].