Mohamed Daoud

Asmae El Mezouari

Noura Faci

Djamal Benslimane

Zakaria Maamar

Aziz El Fazziki

A Multi-Model based Microservices Identiftcation Approach

Keywords: Business process, Control/Data/Semantic dependency, Clustering, Microservice

Microservices are hailed for their capabilities to tackle the challenge of breaking monolithic business systems down into small, cohesive, and loosely-coupled services. Indeed, these systems are neither easy to maintain nor to replace undermining organizations' efforts to cope with user's changing needs and governments' complex regulations. Microservices constitute an architectural style for developing a new generation of systems as a suite of services that, although they are separate, engage in collaborative execution and communication sessions. However, microservices success depends, among many other things, on the existence of an approach that would automatically identify the necessary microservices according to organizations' requirements. In this paper, we present such an approach and demonstrate its technical doability in the context of a case study, Bicing, for renting bikes. Some salient features of this approach are business processes as input for the identification needs, three models known as control, data, and semantic to capture dependencies between these processes' activities, and, finally, a collaborative clustering technique that recommends potential microservices. Conducted experiments in the context of Bicing clearly indicate that our approach outperforms similar ones for microservices identification and reinforce the important role of business processes in this identification. The approach constitutes a major milestone towards a better architectural style for future microservices systems.

Introduction

One of the many challenges that today's organizations have to tackle is how to adjust their business functions in response to users' new needs, competitors' new products, authorities' new regulations, to mention just some. Decomposing existing applications is becoming a critical need for modern organizations [START_REF] Beni | Infracomposer: Policy-driven adaptive and reflective middleware for the cloudification of simulation & optimization workflows[END_REF][START_REF] Wiśniewski | Decomposition of distributed edge systems based on the petri nets and linear algebra technique[END_REF]. Indeed, despite the good will of organizations to remain proactive, the monolithic nature of the information systems (systems for short) associated with their business functions, complicates the work of these organizations. Monolithic means one "sealed" block that encompasses stronglycoupled components that are neither easy to replace nor to maintain. Many stories report on how organizations, e.g., Best Buy, Cloud Elements, and Wix.com, had to "wrestle" with monolithic systems 4 .

Over the years, many Information and Communication Technologies (ICT) were put forward to address the ongoing issue of monolithic systems including Service-Oriented Architecture (SOA) [START_REF] Chung | A view on service-oriented architecture[END_REF], Component-Based Software Engineering (CBSE) [START_REF] Kouroshfar | Process patterns for component-based software development[END_REF], and Commercial-Of-The-Shelf (COTS) [START_REF] Mendez-Bonilla | Requirements patterns for cots systems[END_REF]. However, many of these ICT did not live up to their advocates' expectations overlooking factors like resistance to change, legacy practices, and biased advices, and creating more confusion about the best way to move forward. Lucklily new ICT regularly surface exemplified, in this paper, with microservices [START_REF] Hassan | Microservices and their design trade-offs: A self-adaptive roadmap[END_REF]. The term microservice was coined in 2014 and constitutes an architectural style for developing applications as a suite of small services, having each a separate but collaborative execution and communication process [START_REF] Butzin | Microservices approach for the internet of things[END_REF]. Some adopters of microservices are Amazon and Netflix. In a recent post by NGINX 5 , Netflix shares its successful experience of transitioning "from a traditional development model with 100 engineers producing a monolithic DVD-rental application to a microservices architecture with many small teams responsible for the end-to-end development of hundreds of microservices that work together to stream digital entertainment to millions of Netflix customers every day".

It is clearly difficult to easily compare microservices architectures and Service oriented architectures (SOA) as they both achieve similar objectives and adopt closed principles. SOA enables separate applications to communicate with one another by allowing them to expose their services through standardized interfaces. Microservices scope is concerned by the application itself and focuses on the structure within the application. Microservices corresponds to an architectural style for building an application with the objective to separate and decouple components within an application boundary. The separation between identified components is absolute and each component encapsulates its own database. Indeed, SOA and microservices are complementary. An existing application can expose its services through an SOA level. It can also be restructured and migrated to microservices-based architectures. This latter can be then expose its services by using SOA level. All well established techniques of SOA (Interfaces description, service discovery, etc.) can then be used after a microservices-based architecture exposes its services and not during the reorganization of a monolithic application into a microservices-based application.

In fact, this is what we did and demonstrated in [START_REF] Daoud | Automatic microservices identification from a set of business processes[END_REF] where we designed and developed a collaborative clustering-based approach to identify microservices from a set of Business Processes (BPs). To the best of our knowledge, only Amiri [START_REF] Amiri | Object-aware identification of microservices[END_REF] identifies microservices using BPs while the rest use UML class diagrams [START_REF] Baresi | Microservices identification through interface analysis[END_REF], legacy databases [START_REF] Chen | From monolith to microservices: a dataflow-driven approach[END_REF], log files [START_REF] Djogic | Monolithic to microservices redesign of event driven integration platform[END_REF], and source codes [START_REF] Escobar | Towards the understanding and evolution of monolithic applications as microservices[END_REF]. At the core of our collaborative clustering-based approach, that we extend in this paper, are first, activities of BPs that indicate who does what, when, where, and why, second, models that capture structural, data, and semantic dependencies between these activities, and finally, a collaborative clustering technique that combines these models. This technique allowed us to apply separate techniques to the three dependency models prior to consolidating their respective results into a consensual solution.

This paper 6 extends the approach we discussed in [START_REF] Daoud | Automatic microservices identification from a set of business processes[END_REF] from three perspectives. First, we add a new semantic dependency model to the existing structural-and data-dependency models. The semantic model captures the semantic relationships that could exist between a BP's activities using three techniques. The first technique is word-driven and computes the similarity between activities based on their names. The second technique is concept-driven and also computes the similarity between activities using the most similar concepts that would belong to the BP's domain ontology. Finally, the third technique is fragment-driven and, like the previous two techniques, computes the similarity between activities using a set of the most similar, eventually overlapped, fragments that each encompasses concepts belonging to the BP's domain ontology. All these techniques are formalized and then, described with their respective algorithms. On top of the semantic dependency model, we provide more details and algorithms about the collaborative clustering technique that underpins our multi-model based microservices identification approach. Last but not least, we present new experimental results that take into account the new semantic dependency model with its different techniques.

The rest of this paper is organized as follows. Section 2 presents some related works. Section 3 discusses a case study, provides an overview of our approach to automatically identify microservices from BPs, and finally, formalizes the different models associated with this automatic identification. Section 4 presents the collaborative clustering technique that underpins our identification approach and then, discusses the implementation efforts and experimental results. Section 5 concludes the paper and presents future work.

Related work

There exist a good number of works that discuss monolithic systems' limitations and how microservices could address these limitations [START_REF] Schroer | A qualitative literature review on microservices identification approaches[END_REF]. Such systems are known for incurring significant development, maintenance, and evolution costs [START_REF] Singh | Container-based microservice architecture for cloud applications[END_REF]. We discuss in this section the works related to microservices identification, which constitutes a critical step when migrating from monolithic applications to microservices-based applications.

In [START_REF] Ahmadvand | Requirements reconciliation for scalable and secure microservice (de)composition[END_REF], Ahmadvand and Ibrahim propose a microservices decomposition methodology that maps functional requirements onto microservices with taking into account non-functional requirements, mainly security and scalability. The application to decompose is expressed as a set of functional requirements where each corresponds to a functionality of the system.

The requirements are complemented by a set of security requirements captured by the use of misuse cases. Security requirements elicitation mechanism is proposed to identify security policies that correspond to each functional requirement.

The scalability level (High, Medium, Low) required for each functional requirement is also given. A requirement reconciliation algorithm based on rules is proposed where scalability and security are used as balancing factors for composing a microservice.

In [START_REF] Amiri | Object-aware identification of microservices[END_REF], a clustering-based approach is discussed where structural and data dependencies between tasks are extracted from a given set of BPs. All these dependencies are merged into one dependency matrix that is, then, submitted to a classical clustering algorithm to identify candidate microservices. As stated in Section 1, we adopted BPs like in [START_REF] Amiri | Object-aware identification of microservices[END_REF], but, considered more dependencies and a mix of clustering algorithms.

In [START_REF] Barbosa | Towards identifying microservice candidates from business rules implemented in stored procedures[END_REF], Barbosa et al. propose a process to identify candidate microservices from a set of business rules implemented as a set of stored procedures. There are three main steps to support this identification. The first one discovers the stored procedures related to the requirements and their corresponding system features. An expert is in charge of indicating the requirements. The second step analyzes the discovered stored procedures to identify the candidate microservices. The last step evaluates the source code of all these candidate microservices so, that, unnecessary ones are dropped while refactoring others if deemed necessary. The proposed approach is even relevant for exploring and exploiting stored procedures artifacts and can be extended to include other artifacts (triggers, view, etc.). The approach, unfortunately, remains manual relying heavily on expert intervention which could be time consuming, tedious, and prone to errors.

In [START_REF] Baresi | Microservices identification through interface analysis[END_REF], Baresi et al. proposed an approach to identify microservices. It uses the semantic similarity of functionalities described in openAPI 7 and a reference vocabulary. The necessary microservices are identified as a cohesive cluster of operations extracted from an UML diagram class while the semantic similarity between functionalities' names is based on the pre-computed database DISCO (DIStributionally related words using CO-occurences) 8 .

In [START_REF] Li | A dataflow-driven approach to identifying microservices from monolithic applications[END_REF], Li et al. propose a data flow-driven approach for the microservice-oriented decomposition of existing applications. The input of this approach is a set of Data Flow Diagrams (DFD) where each is generated from a business logic and describes the data flow through business processes. A DFD is represented in terms of processes/operations, data store, data flow, and external entities. The DFDs are transformed into sentences to make them machine-readable. A sentence is in the form of (I → 0) meaning that there is a connection between input I and output O. Inputs and outputs could be a process/operation, a data store, or an external entity. A clustering algorithm is then used to cluster sentences that include the same data stores to form a {microservice candidate.

In [START_REF] Gysel | Service cutter: A systematic approach to service decomposition[END_REF], Gysel et al. suggest Service Cutter framework as a systematic approach to service decomposition. The framework constitutes a process for identifying a set of services and assigning all nanoentities (data, operation, and artifact) to one and only one of these services so, that, service-coupling criteria are adopted. Sixteen of these criteria have been proposed in terms of requirements and have been divided into four categories: cohesiveness, compatibility, constraint, and communication. The input to Service Cutter corresponds to various specifications of software engineering artifacts including use cases, entity-relationship models, security access-groups, and separated security zones. These specifications are represented as a set of System Specification Artifacts (SSAs). These SSAs instances are used to extract from them nanoentities as well as coupling criteria instances. An un-directed and weighted graph is proposed to represent the link between nanoentities (nodes of the graph). A weight link between two nodes indicates to what extent two nanoentities are cohesive and/or coupled. A clustering algorithm is finally used on the produced graph to generate candidate microservice cuts.

In [START_REF] Jin | Functionality-oriented microservice extraction based on execution trace clustering[END_REF], a functionality-oriented microservice extraction by clustering execution traces of programs collected at runtime, is described. These traces are collected by using techniques of program execution monitoring and are used to collect implicit and explicit programs' functional behaviors. The traces also reveal which entities are used for which business logic. The approach clusters source code entities that are related to the same functionalities. Even if the work in [START_REF] Jin | Functionality-oriented microservice extraction based on execution trace clustering[END_REF] is interesting, it suffers from its strong dependence on the quality of the generated execution traces, and consequently on the quality of the test cases.

In [START_REF] Knoche | Using microservices for legacy software modernization[END_REF], Knoche et al. refer to industrial case studies to stress out, in the context of monolithic system shift to microservices-based systems, the importance of separating client-associated internal modules migration from platform migration as several challenges still lie ahead. They, then, present an incremental migration process to gradually decompose an application into microservices by exploiting existing source codes. An important step in the approach is to define from scratch an external and domain-oriented service facade to capture the main functionalities required by the client. All service 7 www.openapis.org.

8 www.commonspaces.eu/en/oer/disco-extracting-distributionally-related-words-us.

operations are defined from a targeted domain model. Static analysis technique is also used to identify the entry points accessed by other applications. Another step is dedicated to service operation implementation and the client application migration to service facade. The existing accesses are replaced by the service invocations. Even the approach has no foundations, it has the advantage to be applied and seems to be in production and implementations were developed for some service operations.

In [START_REF] Levcovitz | Towards a technique for extracting microservices from monolithic enterprise systems[END_REF], microservices were proposed as potential candidates to modernize a monolithic system that was described using three types of objects: interfaces, business functions, and database tables. These objects are then linked in a dependency graph using calls from interfaces to business functions, calls between business functions themselves, and accesses from business functions to database tables. Potential microservices correspond to the business rules that depend on database tables, and correspond to the facades connected to the database tables.

Table 1 presents a concise summary of the approaches presented above. We use five criteria to categorize them: main inputs, data modeling, identification algorithm, evaluation method that indicates whether the experiments adopted industrial application or case-study, and metrics used to evaluate the performance of the approach. When we examined the approaches presented above, we paid attention to initial inputs that could be business processes, API specifications, UML diagrams, domain ontologies, etc. Our approach considers business processes as a main input. In term of data modeling, other approaches use dependencies between artifacts extracted from the inputs. Such modeling is often based on graphs and relational data (matrices). Our approach considers relational data due to their simple nature. It also seems from a global perspective that clustering algorithm is often used to identify microservices. While the studied approaches adopt the same, we made this algorithm collaborative. Finally, most approaches rely on case studies to implement their solutions. A few works implemented their solution on industrial applications. We considered two case studies, one of them was used to compare the performance of our approach to others. Different metrics are used in our work: Dunn Index, Afferent Coupling, Efferent Coupling, Instability, and Relational Cohesion.

Our approach for identifying microservices

This section consists of five parts. The first part presents a case study that refers to Barcelona's bike sharing system known as Bicing. The second part discusses our approach's foundations in terms of dependencies between BPs' activities and collaborative clustering. Finally, the last parts formalize these dependencies.

Bicing case-study

Bicing is a system for renting bikes in the city of Barcelona with 400 anchor stations and 6000 bikes. Bicing's monolithic architecture is described in [START_REF] Estañol | Artefact-centric Business Process Models in UML: Specification and Reasoning[END_REF] along with the managerial and technical challenges, like coordinating large development teams and scaling application programs, that undermine its operations. For the needs of our work, we designed Fig. 1 that corresponds to a high-level BPMN representation of some key activities (a i ), gateways, dependencies, and artefacts associated with Bicing. It all starts when a user requests a bike (a 1 ) at a certain anchor station. After checking the user's credentials (a 2 ) and any late fee payment (a 3 ), Bicing updates the user's records (a 4 ) and then, approves the user's request (a 5 ). If it turns out that the bike is defective, the user puts it back (a 6 ) and eventually requests another one. Otherwise, the user starts his journey (a 10 ). Regularly all bikes are serviced (a 7 ) leading to either putting them back for rent (a 8 ) or disposing them (a 9 ). When the user arrives to destination, he returns the bike at a certain anchor station (a 11 ). Otherwise, Bicing blacklists the user (a 14 ) due to bike inappropriate return, and geo-locates the bike (a 12 ) so, that, it is collected by the competent services and then, put back into service for other users (a 13 ).

From a specification perspective, activities ({a i }) may require inputs ({i i }) and produce outputs ({o i }). We relate both inputs and outputs to specific artefacts' attributes. An activity acts upon both attributes and artefacts using read (r)/write(w) and update(u)/create(c)/delete(d) operations, respectively. Table 2 lists activities, artefacts, attributes of artefacts, and the operations that artefacts/attributes are subject to. For instance, a 5 (get bike) applies write operation to User_Destination and Rent_Date attributes, which leads to executing create operation whose outcome is Rental artefact.

Foundations

Compared to the works presented in Section 2, BPs are our main source of identifying microservices. These ones are expected to be fine-grained, strongly cohesive (i.e., degree to which activities in a microservice belong together), and loosely-coupled (i.e., degree to which microservices can be easily replaced). According to Davenport, a BP is a set of logically related activities that are performed to achieve goals [START_REF] Davenport | The new industrial engineering: Information technology and business process redesign[END_REF]. "Logically related" refers to dependencies between activities such as control (with respect to an execution flow), data (with respect to an information flow), semantics (with respect to a meaningful exchange flow) and functional (with respect to a collaboration flow).

-Control dependency refers to both the execution order (e.g., finish-to-start and start-to-start) between activities and the logical operators (e.g., XOR and AND) between activities as well. Should two activities be directly connected through a control dependency, then most probably they would form a highly-cohesive microservice to which they will belong. Contrarily, they would most probably be used to form separate microservices to which each will belong. -Data dependency refers to associating activities' outputs/inputs in a way that permits to illustrate data flowing from one activity to another. These inputs/outputs correspond to artefacts' attributes. Data dependency sheds light on both artefacts and artefacts' attributes that could be subject to operations illustrated in Table 2 like create (c) and write (w), respectively. In addition to input/output association, data dependency could indicate to what extent artefacts and/or artefacts' attributes are either mandatory or optional for a BP execution. We advocate that activities that exchange mandatory artefacts' attributes should be part of the same microservice allowing to avoid delaying this exchange, for example. -Semantic dependency uses activities' names to establish their functional similarity in term of what they do. These names refer to linguistic templates that must include a verb and object/result along with optional parameters like time and location. For instance, a 11 's name includes place (verb), bike (object), and anchor point (location). To assess activities' names similarity, we rely on either a reference vocabulary or an ontology. A highest/lowest similarity value would indicate strong/weak coupling between activities making them members of the same/different microservice/microservices. -Non-Functional dependency relies on non-functional requirements such as privacy, security, cost, and scalability that could impact the execution of a business process's activities. Compared to the control-dependency model that focuses on who executes what activities, when, where, and why (5 W's), the non-functional dependency model focuses on the quality of executing activities. Has a certain level of security achieved during execution, and has a certain cost be maintained are examples of questions that the non-functional dependency model could address.

We focus on control, data, and semantic dependencies, only, and leave functional dependency for the future. Upon establishing such dependencies, we quantify them using specific metrics. The objective is to evaluate cohesion and coupling among activities so, that, they are gathered in either same or separate microservices. To measure a control dependency between two activities (a i , a j ), we consider a j 's occurrence probability after executing a i . This probability depends on the execution order and/or logical operators between a i and a j . Let us consider the control dependency between a 5 and a 10 that is connected with a 6 through XOR (Fig. 1). After executing a 5 , a 10 's occurrence probability depends on the decision made at XOR (i.e., either a 6 or a 10 ). We note that any activity's occurrence probability is calculated over time by using the BP's execution log. To measure a data dependency between two activities (a i , a j ), we consider an artefact's and attribute's criticality level that would reflect the importance of information shared between these activities. This level denotes to what extent artefact/attribute unavailability would impact the continuity of business operations. To measure a semantic dependency between two activities (a i ,a j ), we measure the distance between their respective semantic annotations using three annotation techniques, word-driven, concept-driven, and fragment-driven. The first relies on a reference vocabulary to annotate activities with terms associated with these activities' names. The second relies on a certain domain ontology to annotate activities with concepts related to their respective names. Finally, the third refines the second by annotating the activities with ontological fragments that would refer to functional domains. More details about formalizing control, data, and semantic dependencies are given in the next sections.

Based on dependencies among activities, we gather activities into microservices by using clustering techniques. In the literature, clustering is either centralized or collaborative [START_REF] Hammouda | Collaborative document clustering[END_REF]. In the former, a single component manages the clustering by utilizing all individuals' features9 as inputs. In the latter, multiple components, each in charge of one type of features, exchange some details during clustering so, that, appropriate clusters are jointly built. Performance and appropriateness of clustering techniques are thoroughly discussed in the literature [START_REF] Cornuéjols | Collaborative clustering: Why, when, what and how[END_REF] and [START_REF] Wilkin | A practical comparison of two k-means clustering algorithms[END_REF]. Many works like [START_REF] Cornuéjols | Collaborative clustering: Why, when, what and how[END_REF] and [START_REF] Hammouda | Collaborative document clustering[END_REF] advocate for collaborative clustering to identify microservices. It provides fine-grained and accurate results contrarily to centralized clustering where individuals' features need to be aggregated before initiating any clustering. Fig. 2 depicts our three-step approach to identify microservices. The approach relies on the aforementioned dependencies and collaborative clustering to group activities into potential fine-grained, highly-cohesive, and loosely-coupled microservices. The steps denoted by collection, dependency analysis, and collaborative clustering proceed as follows. The collection step gathers all necessary details from the BP specification and BP engineer, per dependency type (i.e., control, data, and semantics). Next, the dependency analysis step examines these details per dependency type allowing to define particular measures for storage in dedicated repositories. Finally, the collaborative clustering step applies different clustering techniques (one per dependency type) to the stored measures. More details about how our collaborative clustering algorithm was defined and implemented are given in Section 4.1. Fig. 2: General representation of our microservices identification approach

Control dependency analysis

In Section 3.2, we mention that there are two types of control dependencies namely, direct and indirect. The former refers to a certain execution order (ExecOrder) between a i and a j that can be connected to other activities {a k } through a certain Operator. An execution order between two activities could be exemplified with either finish-to-start (our focus and denoted by SEQ)), finish-to-finish, start-to-start, or start-to-finish. The latter refer to an execution path (ExecPath) with a certain execution order between a i and a j that involves other activities {a k } connected through two or more operators.

Direct. Let CD(a i , a j [Operator {a k }]) ExecOrder be a direct control dependency.

We start with a simple control dependency that stands for CD(a i , a j ) SEQ (i.e., {a k } = ∅)). SEQ between a i and a j means that a j starts only after a i has successfully completed (i.e., a j 's execution remains uncertain). CD(a i , a j ) SEQ , thus, denotes a j 's occurrence probability (p) after a i 's completion as per Equation 1:

CD(a i , a j ) SEQ = p (1)
where p ∈ ]0, 1].

We now examine the control dependency CD(a i , a j Operator {a k }) SEQ (i.e., {a k } = ∅)). According to Operator's semantics, we assume that some r activities in {a k } ∪ a j will be selected for execution. Equation 2 defines the number of sets containing r activities that will be selected for execution as a combination C(n, r) where n corresponds to

card({a k } ∪ a j ). C(n, r) = n ! r ! × (n -r) ! (2)
Depending on the semantics of Operator whether AND, XOR, or OR, CD(a i , a j Operator {a k }) SEQ is calculated as follows:

1. CD(a i , a j AND {a k }) SEQ . This dependency means that a j will start only after a i has successfully completed regardless of {a k }. Formally, Equation 3computes CD(a i , a j AND {a k }) SEQ as follows:

CD(a i , a j AND {a k }) SEQ = C(n, n) * CD(a i , a j ) SEQ (3)
where

p ∈ ]0, 1] & C(n, n) = 1, as per Equation 2. 2. CD(a i , a j XOR {a k }) SEQ .
This dependency means that one activity from {a k } ∪ a j will be selected after a i has successfully completed. Formally, Equation 4computes CD(a i , a j XOR {a k }) SEQ as follows:

CD(a i , a j XOR {a k }) SEQ = 1 C(n, 1) * CD(a i , a j ) SEQ (4)
where C(n, 1) is the number of possibilities to select one activity from {a k } ∪ a j . As per Equation 2, C(n, 1) is equal to n.

3. CD(a i , a j OR {a k }) SEQ . This dependency means that a set of r activities from 2 {a k }∪aj (i.e., all possible multiple choices) will be selected after a i has successfully completed. For the sake of simplicity, we assume that any activity in {a k } ∪ a j has the same occurrence probability over 2 {a k }∪aj , that is equal to r n where r varies from 1 to n. Formally, Equation 5computes CD(a i , a j OR {a k }) SEQ as follows.

CD(a i , a j OR {a k }) SEQ = r=1,n ( r n × C(n, r)) r=1,n C(n, r) * CD(a i , a j ) SEQ (5)
where -r=1,n ( r n × C(n, r)) represents the number of a j 's occurrences among possible combinations of activities 10 . -r=1,n C(n, r) corresponds to the total number of possible combinations of activities 11 . Indirect. Let CD(a i , a j ) ExecPath be an indirect control dependency between a i and a j . We start with a simple control dependency that stands for CD(a i , a j ) Pathi,j where Path i,j refers to a single set of other peers ({a k }) connected with operators. Here, CD(a i , a j ) Pathi,j denotes the probability of conjunctive events where each event refers to an a k 's occurrence in Path i,j as per Equation 6:

CD(a i , a j ) Pathi,j = a l ,am∈Pathi,j
CD(a l , a m Operator {a km }) SEQ (6) 10 Let n be 3, r=1,n ( r n × C(n, r)) has the following value: (

1 3 × 3 + 2 3 × 3 + 3 3 × 1=4).
11 Let n be 3, r=1,n C(n, r) has the following value: (3+ 3+ 1)=7.

We now examine the control dependency CD(a i , a j ) Pathsi,j where multiple possible execution paths ({Path q i,j }) exist between a i and a j . Here, CD(a i , a j ) Pathsi,j denotes an aggregation of all simple control dependencies, each associated with as per Equation 7: CD(a i , a j ) Pathsi,j = Agg(CD(a i , a j ) {Path q i,j } q=1,... )

where Agg refers to some common aggregate function like maximum used for our experiments.

Table 3 depicts an excerpt of control dependencies in Bicing.

Data dependency analysis

In Section 3.2, we considered the criticality of an artefact and attribute as a means for measuring data dependency between two activities. In [START_REF] Paulsen | Criticality analysis process model[END_REF], Paulsen et al. provide a comprehensive criticality analysis for the benefit of organizations that need to identify and prioritize assets (e.g., artefacts and processes) that are vital for achieving their goals. Taping into this analysis, we distinguish two types of criticality: functional (F) that refers to an artefact's/attribute's unavailability which could hinder the BP's proper execution, and non-functional (NF) that refers to an artefact's/attribute's corruption which could undermine the BP's Quality-of-Service (QoS). To assist BP engineers classify artefacts/attributes as (to some degree) either critical or non-critical, we identify F-and NF-based critical attribute's/artefact's properties. First, we consider strategic, tactical, and operational information levels as F criticality-related properties. For instance, a strategic attribute should be more critical than tactical and operational attributes. Second, we consider privacy, confidentiality, integrity, and availability security levels as NF criticality-related properties. For instance, some BP's operations can be less concerned about confidentiality but more concerned about first availability and then, integrity. To define an artefact (ar)/attribute (at)'s Degree of Criticality (DC(ar|at)), the BP engineer needs to work out the priority among F and NF criticality-related properties by using three clusters, Low (L), Medium (M), and High (H). Then, she maps L, M, and H clusters onto [0, k[, [k, k [, and [k , k ], respectively, after setting the values of k, k , and k". Finally, the BP engineer sets DC(ar|at) based on the cluster's range to which an ar|at's property belongs. Since artefacts and attributes can be associated with F and/or NF, for instance User_Credit, we refine DC(ar|at) into DC F (ar|at) and DC NF (ar|at).

To calculate DC(ar|at), we define two strategies. The first strategy computes DC(ar|at) as a weighted sum of DC F (ar|at) and DC NF (ar|at) (Equation 8).

DC(ar|at) = w 1 × DC F (ar|at) + w 2 × DC NF (ar|at), w 1 + w 2 = 1 (8)
where w 1 and w 2 are weights (i.e., importance) associated with DC F (ar|at) | DC N F (ar|at), respectively, and set by the BP engineer. Table 5 depicts artefacts/attributes associated with criticality degrees for Bicing. For instance, Bike_Status has a higher DC than Anchor_Point. Once all DC(ar|at) are established, we now specify data dependencies (DD 1 ) between a i and a j (Equation 9). DD 1 (a i , a j ) = ari,j |ati,j ∈DAT Ai,j pair(ar i,j |at i,j ) × DC(ar i,j |at i,j )

where ar i,j |at i,j represents the artefact/attribute exchanged between a i and a j , -DAT A i,j indicates the set of ar i,j |at i,j , and pair(ar i,j |at i,j ) denotes the value associated with the operation pair (e.g., r/w, w/w, and c/r) between a i and a j , proposed by Amiri [START_REF] Amiri | Object-aware identification of microservices[END_REF].

Table 6 depicts an excerpt of data dependencies for Bicing using Equation 8. The second strategy considers DC(ar|at) as a tuple < DC F (ar|at), DC NF (ar|at) >. We, thus, specify data dependencies (DD 2 ) between a i and a j (Equation 10): DD 2 (a i , a j ) = ari,j |ati,j ∈DAT Ai,j F(pair(ar i,j |at i,j ), DC F (ar i,j |at i,j ), DC NF (ar i,j |at i,j )) [START_REF] Daoud | Automatic microservices identification from a set of business processes[END_REF] where F returns the data dependency value specified by the BP engineer for < pair(ar i,j |at i,j ), DC F (ar i,j |at i,j ), DC NF (ar i,j |at i,j ) >.

Semantic dependency analysis

Semantic dependencies between activities define whether or not there are similarities between what activities are supposed to perform like ensuring the payment of fines and and blacklisting users. Such similarities could be extracted using activities' names defined with respect to a domain ontology. We advocate that activities' names presenting semantic similarities and/or referring to the same ontology concept(s) could be inter-related and the, would likely be part of the same microservices.

Earlier, we mentioned three annotation techniques that we use to measure semantic dependencies between two activities. Let X be an annotation technique and SD X (a i , a j ) be a semantic dependency between a i and a j using X . Prior to formalizing SD X , we describe these techniques.

Word-driven technique (W). Albeit being simple, this technique measures

to what extent 2 words are similar. In our case, word would refer to an activity's name like "check user credentials" in our Bicing case-study. One of the advantages of Word-driven technique is that it does not refer to a domain ontology but relies on the word co-occurrence 12 principle. Co-occurrence refers to the above-chance frequency of occurrence of two terms and is used as an indicator to measure the semantic proximity of two terms. Algorithm 1 outlines how an activity a i is annotated using a set of the n most similar words (W ai ). To develop W ai , we adopt No et al.'s solution, DISCO [START_REF] Kolb | Disco: A multilingual database of distributionally similar words[END_REF], that assumes that words with similar meaning (co-)occur in similar bag-of-words contexts. By adopting DISCO, the set of a i 's n most distributionally similar words ({w k }) along with their respective similarity degrees (sd i,k ) (i.e., W ai ) are returned.

Besides DISCO, any other semantic textual similarity technique can be adopted in our approach. Thus, a i will be annotated with {< w k , sd i,k >}.

Algorithm 1: Word-driven annotation technique

Input: ai, n Output:

Wa i 1 begin 2 Wa i ← DISCO(ai, n) 3 return Wa i

Concept-driven technique (C).

It uses a domain ontology to annotate activities' names with closed concepts. The semantic dependency between activities is then highly dependent on the similarities that could exist between the annotated concepts. Algorithm 2 outlines how an activity a i is annotated using a set of the most similar concepts (C ai ) that would belong to the BP's domain ontology (O BP ). Fig. 3 depicts our in-house O BP for bike rental. For each concept c j , Algorithm 5 first calls for No et al.'s semantic similarity measure between a i and c j namely, DISCO 2 13 , and then stores DISCO 2 's outcome into D[i, j]. To develop C ai , the max s function will keep the concepts (c k ) with the highest similarity values stored in D[i] with respect to a certain precision σ. For instance, if the highest similarity value is 0.5 and σ is set to 0.1, then max s will include all the concepts with a similarity value between 0.4 and 0.5, as well. Thus, a i will be annotated with {< c k , D[i, k] >}. Table 7 depicts similarity values associated with Bicing.

12 en.wikipedia.org/wiki/Co-occurrence.

13 DISCO2 computes semantic similarity (i.e., relation between concepts) while DISCO computes distributional similarity (i.e., relation between words). Fragment-driven technique (F). Instead of using the most closed concept, this technique annotates an activity's name using the most closed set of concepts called fragments. In this case, semantic dependencies between two activities is highly dependent on the similarities that could exist between two fragments. Algorithm 3 outlines how an activity a i is annotated using a set of the most similar (eventually overlapped) fragments (F ai ) that each encompasses concepts belonging to O BP . To develop F ai , Algorithm 3 first computes a i 's membership degrees (M[i]) to each fragment ∈ O BP based on the set of common concepts (c j ) between this fragment and C ai along with D[i, j] obtained in Algorithm 2, Line 2. Then, the max m function considers the fragments (F k ) with the highest membership degrees (M[i]) with respect to a certain precision σ. Thus, a i will be annotated with {< F k , M[i, k] >}. Table 8 depicts an excerpt of similarity values associated with Bicing. Formally, Equation 11 computes the Semantic Dependency (SeD) between a i and a j .

Algorithm 3: Fragment-driven annotation technique

Input: Ca i , O BP , σ Output: Fa i 1 begin 2 foreach F k ∈ O BP do 3 M[i, k] ← c j ∈F k ∩Ca i D[i, j] 4 Fa i ← maxm(M[i], σ) return Fa i
SeD(a i , a j ) = 1 -d X (X ai , X aj ) (11)
where X ai corresponds to the annotation technique's outcome (either W ai , C ai , or F ai ) and d X represents the distance between X ai and X aj . We hereafter define d X per technique.

• Word-driven distance. The rationale of d W is to compare all the words in W ai to those in W aj . More W ai and W aj contain similar private words (i.e., that exclusively belong to either W ai or W aj ) with higher similarity with a i and a j , respectively, more a i and a j will be far away from each other. Formally, Equation 12 computes d W .

d W (W ai , W aj ) = w k ∈W p a i sd i,k + w k ∈W p a j sd j,k (12)
where W p ai|aj represents W ai|aj 's set of private words (i.e., W ai|aj -W ai ∩ W aj ).

Equation 13 computes the normalized d W .

d norm W (W ai , W aj ) = d W (W ai , W aj ) |W p ai | + |W p aj | (13)
Table 9 depicts an excerpt of semantic dependencies for Bicing using Equation 13. • Concept-driven distance. The rationale of d C is to compare all the concepts in C ai with those in C aj . More C ai and C aj contain closest concepts with higher similarity with a i and a j , respectively, more a i and a j will be close from each other. Formally, Equation 14 computes d C .

d C (C ai , C aj ) = c k ∈Ca i (1 -D[i, k]) * c l ∈Ca j (1 -D[j, l]) * W U (c k , c l ) (14)
where W U (c k , c l ) represents the distance between the two concepts c k and c l [START_REF] Wu | Verb semantics and lexical selection[END_REF].

Equation 15 computes the normalized d C .

d norm C (C ai , C aj ) = d C (C ai , C aj ) |C ai | * |C aj | (15)
Table 10 depicts an excerpt of semantic dependencies for Bicing using Equation 15.

Table 10: Excerpt of semantic dependencies between activities using concept-driven technique Activity Activity a1 a2 a3 a4 a5 a1 -0,488573 0,488843 0,390858 0,320864 a2 0,488573 -0,488315 0,320517 0,320517 a3 0,488843 0,488315 -0,495525 0,325429 a4 0,390858 0,320517 0,495525 -0,275969 a5 0,320864 0,320517 0,325429 0,275969 -

• Fragment-driven distance. The rationale of d F is to compare all the fragments in F ai with those in F aj . More F ai and F aj contain distinctive concepts with higher membership degrees for a i and a j , respectively, more a i and a j will be far away from each other. Formally, Equation 16 computes d C .

d F (F ai , F aj ) = F k ∈O BP (1 -|M[i, k] -M[j, k]|) (16)
Let P 2 (BP ) be the set of all distinct activity pairwises built from BP (i.e., a k = a l ). Formally, Equation 17 computes the normalized d F as follows.

d norm F (F ai , F aj ) = d F (F ai , F aj ) d max F ( 17
)
where -

d max F = max({d F (F a k , F a l )} <a k ,a l >∈P2(BP ) )
Table 11 depicts an excerpt of semantic dependencies for Bicing using Equation 17. a1 -0,97696 0,95914 0,90827 0,94119 0,90829 a2 0,97696 -0,92116 0,87033 0,92959 0,90731 a3 0,95914 0,92116 -0,94248 0,96703 0,83428 a5 0,90827 0,87033 0,94248 -0,92845 0,82091 a9 0,94119 0,92959 0,96703 0,92845 -0,82586 a10 0,90829 0,90731 0,83428 0,82091 0,82586 -

Collaborative clustering development and experimentation

In this section we discuss the technical details of our microservices identification approach with focus on the collaborative clustering technique and the experiments that were carried out.

Collaborative clustering

Clustering is one of the well known Machine Learning (ML) techniques. Given a set of objects, it consists of classifying each object into a specific group called cluster. In our work, we consider each BP's activity (a i ) a distinct object. Activities of the same cluster are expected to be as homogeneous as possible to ensure the cohesion property of a group. Contrarily, activities belonging to different groups are expected to be as distinct as possible to ensure the loose coupling of a group. Each group of activities could be a potential microservice.

Our collaborative clustering algorithm (cHAC) extends the classical Hierarchical agglomerative algorithm (HAC) [START_REF] Murtagh | Ward's hierarchical clustering method: clustering criterion and agglomerative algorithm[END_REF]. cHAC is performed by N homogeneous clustering nodes (CN 1 , CN 2 , . . . , CN n ) executing the same program. However these nodes differ in terms of inputs. Each CN node handles one and only one dependency matrix. The chosen number k of clusters at each CN is not necessary the same; it can be different from one CN to another one.

Our cHAC algorithm fosters collaboration between CN since each CN has its own dependency matrix along with "keeping an eye" on what other CN s are doing by sharing some dependencies scores about activities, if deemed necessary. Thus, prior to each new HAC clustering iteration, a CN uses both a Local Score Matrix (LSM ) that stores dependency scores between couple of activities and a Shared Score Matrix (SSM ) that stores a global dependency score between each couple of activities. Our cHAC algorithm goes over three phases:

-Initialization phase (Algorithm 4). All CN nodes are launched with their respective number of clusters k, and their respective local dependency score matrices. An empty shared dependency matrix is also created to store the shared dependency score of activities. Each activity constitutes a cluster. A shared variable is also introduced to synchronize the iteration of the nodes. A new iteration is launched at a given node if-and-only-if the other nodes have already finished their current iterations.

-Collaborative Iteration phase. A classical HAC clustering is extended to make it collaborative as per Algorithm 5.

The nearest pair of clusters C u and C v is computed by using both LSM and SSM based on calculating the distance using the formula:

SMp (Cu, Cv) = |Cu| * |Cv | (i,j)=(1,1)
SMp- // each activity is a cluster WAIT (@SIC = 0) ; // the new iteration will be started only when all oher CN nodes have finished their current clustering iteration

4 while |C| > k do 5 (Cu, Cv) ← NearestPeerCluster(C); 6 if [distance(Cu; Cv)] DM [distance(Cu; Cv)] SDSM then 7 Cp ← f usion(Cu, Cv) C ← C -(Cu ∪ Cv) C ← C ∪ Cp;
.

Then, the node updates the LSM by calculating the new scores of activities using the formula:

SMp (ai, aj ) = |Cv | j=1 SMp_1 (ai, aj ) /|Cv|
To foster similarities between couples of activities (a i , a j ), the shared score matrix is also updated as follows:

[SSM (ai, aj )]p = M ax([LDSM (ai, aj )]p, [SSM (ai, aj )]p-1)
-Selection phase. Once the different clustering results are produced by the different CN s, the distance metrics are applied to them (Algorithm 4, line 5) to choose the best one that fosters both cohesion and loose-coupling of groups.

It is important to note that our cHAC algorithm can work either in a uniform collaboration strategy where each CN collaborates with other CN ss, or in diverse collaboration strategy where each CN node has its own collaborators. For the latter case, different shared matrices are needed, one by CN node.

The cHAC algorithm we propose in this work is different from the distributed HAC (dHAC) [START_REF] Ke | Collaborative hierarchical clustering in the browser for scatter/gather on the web[END_REF]. Indeed, dHAC is described in terms of two phases. In the first phase, the entire collection of objects is divided into n disjoint segments and distributed over n HAC processes. Each HAC process is dedicated to one and only one segment to generate one separate clustering result. In the second phase, the individuals generated clusters are merged into one final cluster result. Instead of merging individuals clustering results, our cHAC algorithm allows nodes to continuously collaborate to generate their clustering results. The collaboration between the different HAC nodes is carried out between two successive iterations by sharing intermediate clustering results.

Potential microservices identification options from a set of business processes

One of the salient features of our approach and its collaborative clustering algorithm is, that, it can be applied to many BPs when identifying potential microservices. Let us assume a set of n BPs {BP 1 , BP 2 , • • • , BP n } and a set of m dependency models {M 1 , M 2 , • • • , M m } related to these BPs. Our approach generates n dependency matrices from each model, which means n * m dependency matrices. Afterwards, these matrices would be used according to one of the following options:

-No merge option. It keeps each matrix independent from the rest and then, applies the collaborative clustering algorithm to m * n nodes where each node is related to m * n independent matrices.

-Merge by model option. It merges all matrices that originate from the same model applied to the different BPs and then, applies the collaborative clustering algorithm to m nodes where each node is related to a merged matrix.

-Merge by BP option. It merges all matrices that originate from the different dependency models applied to one BP and then, applies the collaborative clustering algorithm to m nodes where each node is related to a merged matrix.

System implementation

A system demonstrating the technical doability of our approach for identifying microservices has been implemented. Fig. 5 shows the system's architecture. Once a BP is modeled, its process model is converted into XML using Camunda plugin. The system also includes two core modules, dependency analysis and microservice extraction. The first parses the XML-based BP to extract all execution paths between any couple of activities < a i , a j > and their respective artefact/attribute exchange, as well, and takes the BP's OWL domain ontology developed under Protégé 5.515 , as input. Note that artefacts/attributes will be associated with criticality values as per Section 3.4. To compute dependency values, the dependency-analysis module implements all the equations and algorithms reported in Sections 3.3, 3.4, and 3.5. All these values are stored as dependency graphs in XML. The second module, microservice extraction, implements our cHAC algorithm (Section 4.1). It first imports all the XML files produced by the first module using Java DOM Parser 16 , a Java API for Document Object Models. Then, it runs the cHAC with respect to the selected technique whether word-driven, concept-driven, or fragment-driven for the semantic perspective to build different clusters (i.e., microservices). Finally, this module maps the obtained clusters onto a given XSD format. First experiment. We evaluated the cHAC algorithm using both the quality metric, Dunn index, and the convergence time, Time index. Note that Dunn index permits to identify the clusters that are compact (i.e., minor variance between activities belonging to the same cluster) and separate (i.e., large distance between clusters). Thus, a higher Dunn index indicates better clustering. We applied the cHAC algorithm to dependencies produced by the dependencyanalysis module from the BP's Bicing. Initially, fourteen activities related to Bicing were used and then, more random activities were added to the case study to capture the complexity of real BPs. In this first experiment, we proceed with three nodes as per Section 4.1 namely, control, data, and semantic, another node, named cooperative, that aggregates all dependencies. We noted that the semantic node can be refined into either word-driven, concept-driven, or fragment-driven. In Fig. 6, we clearly observe that the Dunn index in the case of the control node is ten almost always better than the Dunn index the other two nodes (i.e., data and semantic (regardless of the annotation technique used)). This means that for a given BP, the control node gives richer and more informative analysis than the rest. This confirms that aggregating different dependencies (i.e., cooperative node) degrades the quality of the final clustering and the collaboration between nodes is the most appropriate option for achieving better clustering results. Regarding the time index (Fig. 7), the control node still gives the best results. Note that Dunn index sheds light on the quality of clustering regardless of whether the obtained clusters (i.e., microservices) are meaningful to the BP designer. To this end, we proceed with additional metrics for further analysis. As per Section 3.2, coupling and cohesion are important aspects to consider when assessing the quality of microservices. To this end, we rely on the work of [START_REF] Fritzsch | From monolith to microservices: a classification of refactoring approaches[END_REF] that quantifies both aspects using four metrics, Afferent Coupling (AC), Efferent Coupling (EC), Instability (I), and Relational Cohesion (RC) (Table 12), with focus on AC and RC. Since these metrics refer to classes and class packages, we mapped them onto concepts relevant and applicable to our work. Therefore, class/package becomes activity/cluster, service becomes refers to microservice, and internal relations among classes in the same package becomes either connector type, data transfer, or semantic similarity between activities in the same cluster. Fig. 8 depicts AC's average values over clusters obtained at iteration K for the control, data, and word|concept|fragment-driven nodes. We observe that the control node still outperforms the cooperative one, while it provides stronger coupling than data and semantic nodes. Regarding RC (Fig. 9), the control node outperforms significantly the three other nodes. Measures the ratio between the number of internal relations and the number of types in a package (service). Internal relations include inheritance between classes, invocation of methods, access to class attributes, and explicit references like creating a class instance. Higher numbers of RC indicate higher cohesion of a package (service).

Specifically, we challenge the word-driven and concept-driven annotation technique for microservices identification (Table 13). Both techniques yield into five microservices. However, the word-driven technique outperformed the concept-driven one in many aspects. First, the obtained microservices in the word-driven are more strongly-cohesive and more or less loosely-coupled compared to the second technique (i.e., higher AC and a bit lower RC). Moreover, the microservices in the word-driven are more meaningful (or consistent) than those obtained in the concept-driven. Note that due to this inconsistency, we do not name the obtained microservices. For instance, ms#2 encompasses loosely-dependent activities related to bike return and bike geo-localization, respectively. This can be explained by the lack of completeness of the ontology used. Second experiment. The objective here is to compare our approach to those presented in [START_REF] Baresi | Microservices identification through interface analysis[END_REF], [START_REF] Gysel | Service cutter: A systematic approach to service decomposition[END_REF], and [START_REF] Li | A dataflow-driven approach to identifying microservices from monolithic applications[END_REF] using the case study of cargo tracking of Gysel et al. [START_REF] Gysel | Service cutter: A systematic approach to service decomposition[END_REF]. For the needs of the second experiment, we designed a BPMNbased process model for cargo tracking (Fig. 10). In this process model, it starts when the shipping company ships a customer's containers (a 1 ) by land and sea. After checking the customer's credentials (a 2 ) and doability of the shipping options (a 3 ), the company either sends an invoice to the customer for payment (a 5 ) or notifies her of the rejection (a 4 ).

Upon payment confirmation (a 6 ), additional activities are performed. First, a 7 arranges the routing of containers by road and sea while a 8 tracks the warehouses' incoming and outgoing flows. Second, a 9 loads the containers onto the vessel while a 10 tracks the clearance of the containers during potential stopovers. Upon cargo arrival to destination, a 11 unloads the containers from the vessel onto trucks. Finally, a 12 reports irregularities that, eventually, are issued by customs. Should there be any irregularities, the containers' sender would be subject to fines ending the process (a 13 ). to the sender with fine payment ending the process (a 13 ). Contrarily, a 14 arranges the routing of cargo by road while a 15 tracks containers between warehouses before delivery. In conjunction with specifying the cargo tracking process-model, we identified artefacts between activities as per Section 3.4 and adapted the Maritime Cargo Ontology (MCO) ( [START_REF] Villa | A description logic approach to discover suspicious itineraries from maritime container trajectories[END_REF], Appendix A) to define the semantic distance between activities as per Section 3.5. We submitted these three inputs to the dependency-analysis module that produces dependency values between activities with respect to the control, data, and semantic perspectives (Appendix B -Tables 1718192021). After applying the collaborative clustering algorithm to the control, data, and word-driven dependencies, we obtained five candidate microservices namely, Preparation, Handling, Planning&Tracking, Delivery, and Return.

For the needs of benchmarking, we considered the values of the metrics presented in [START_REF] Fritzsch | From monolith to microservices: a classification of refactoring approaches[END_REF] and applied them to the candidate microservices (Table 14). For readability purposes, we merge the three sets of values, each associated with the corresponding approach, into Table 15. . This demonstrates that our approach provides better results when considering both AC and RC compared to the three other approaches. In addition, there is no real distinction for I on average across all the approaches. As for RC metric, our approach performs better than Li et al.'s and Baresi et al.'s approaches, while less appealing than Gysel et al.'s approach. This can be explained as follows. Baresi et al.'s approach has some limitations due to their assumption that interfaces are well-defined and described with meaningful names whereas Li et al.'s approach constrains the analysts to make sure that they have a consistent viewpoint between the control and data perspectives due to lack of semantics associated with whether processes or data. Since our approach heavily relies on the domain ontology at different levels (concept and fragment), ensuring the ontology quality (e.g., completeness and accuracy) is critical for the decomposition results. To deal with the lack of ontology quality, additional factors like data usage context should be incorporated into our analysis for a better microservices identification.

Conclusion

Microservices identification remains an important obstacle that is undermining ICT practitioners' efforts when migrating existing applications to a better architectural style. Existing academic and industrial approaches exploit many sources like databases, log files, UML diagrams, and domain ontologies to identify microservices. Contrarily, we adopted business processes as a primary source offering a comprehensive view of what happens in organizations in terms of who does what, when, where, and why. Thanks to this comprehensive view, we designed and demonstrated a multi-model approach for microservices identification. These models are referred to as structural, data, and semantics, and capture dependencies between a BP's activities. We also proposed a clustering algorithm to collaboratively combine all extracted dependencies for the needs of identifying microservices. Our approach fosters decoupling and cohesion of future microservices and also considers to some extent the non-functional requirements via the data dependencies model. The results are promising showing how our collaborative clustering algorithm outperforms in term of precision the cooperative clustering algorithm. In term of future work, we would like to examine the appropriateness of other activity dependency models for microservices identification. For instance, it could be interesting to examine to what extent security requirements could impact the microservices identification. Also, it could be interesting to allow users to annotate their BPs and exploit such annotations with advanced machine learning techniques including Natural Language Processing to generate new activities dependencies. A third direction could be the exploration of BP's activities code to extract useful details that could be complement to the first models we already defined.

A Cargo tracking additional description

In this appendix, we list all the elements related to the dependency analysis performed on cargo tracking. Meanwhile, Fig. 11 depicts an excerpt of the domain ontology for cargo tracking. For instance, in Table 16, a 9 (transfer container to port) applies write operation to Event_ID and Destination attributes, which leads to executing create operation whose outcome is Event artefact.

B Applying the 3 dependency models to Cargo tracking

Tables 17 and 18 depict an excerpt of the control and data dependencies for cargo tracking using Equations 7 and 8, respectively.

Tables 19,20, and 21 depict an excerpt of semantic dependencies for Cargo tracking using Equations 13, 15, and 17, respectively.

Fig. 1 :

 1 Fig. 1: An illustrative BPMN representation of Bicing

  ) Anchor_Point (r), Bike_ID (r), Bike_Status (w) User (u) User_ID (r), User_Destination (r) a2 User (u) User_ID (r), User_Credit (r), User_Destination (r) a3 User (u) User_ID (r), User_History (r), User_Validity (r) a4 User (u) User_ID (r), User_History (w) a5 Bike (u) Bike_ID (r), Bike_Status (w) User (u) User_ID (r), User_Status (w) Rental (c) User_Destination (w), Rent_Date (w) a6 Bike (u) Anchor_Point (r), Bike_ID (r), Bike_Status (w) User (u) User_ID (r), User_Status (w) Rental (d) Rent_ID (r) a7 Bike (u) Bike_Status (w) Repair (c) estimated_Repair_Cost (w), agree_Repair (w) a8 Bike (u) Anchor_Point (r), Bike_Status (w) a9 Bike (d) Bike_ID (r) a10 User (u) User_ID (r), User_Status (w) a11 Bike (u) Anchor_Point (r), Bike_ID (r), Bike_Status (w) User (u) User_ID (r) Rental (u) Rent_ID (r), Rent_Cost (w), User_History (w) a12 Bike (u) Bike_ID (r), Bike_Location (w) a13 Bike (u) Bike_ID (r), Anchor_Point (r), Bike_Status (w) a14 User (u) User_ID (r), User_Status (w), User_History (w)

Algorithm 2 :Ca i 1 begin 2 foreach cj ∈ O BP do 3 D 4 5 returnFig. 3 :

 223453 Fig. 3: Domain ontology for bike rental and its fragments F i

SSM p- 1 14

 1 [distance(Cu, Cv)] SC p computes any distance between two clusters Cu and Cv by using the score Matrix SM of the iteration p.

Algorithm 4 : 2 SIC 4 ; 2 Cu, Cv, Cp -cluster variables 3 C

 42423 cHAC -collaborative clustering initialization Input: N -number of clustering node CN , Ki i = 1..N -targeted number of clusters of each node CNi, DMi[M, M ] i = 1..N -DMi Dependency Matrix of CNi, SDSM [M, M ] -Shared dependency score matrix; Output: final cluster result fc; 1 begin ← 0 ; // shared counter between CN nodes 3 cSET [i] ← cHACn(ki, DMi, @SDSM, @SIC), i = 1..M ; // parralel execution of CN nodes f c ← chooseF inalClusterResult(cSET ); 5 return fc; Algorithm 5: cHACn -collaborative clustering of each node CN i Input: K -targeted number of clusters, N : number of clustering node CN, DM : Dependency matrix, @SDSM : Shared dependency score matrix; Output: C -clustering set 1 begin ← {{a1}, {a2}, ..., {a M }} ;

8 updateDM(); 9 [ 10 @

 8910 SDSM (ti, tj )]p = M ax([LDSM (ti, tj )]p[SDSM (ti, tj )]p-1); SIC ← @SIC + 1 mod N ; // The node indicate to other nodes that its current clustering iteration is done 11 12

Figure 4 Fig. 4 :

 44 Figure 4 illustrates these three main options for the case of n BPs and our three activity dependency models. Even if no merge option is more appropriate for the collaborative clustering algorithm as it makes the collaboration more larger, the user can, for any reason, choose the other options or define new ones such as merging matrices in a random way.Once microservices are identified, their implementation could be either proprietary or based on external resources. The choice could be based on some requirements including security and privacy.

Fig. 5 :

 5 Fig. 5: Architecture of the implemented system

  (a) Control, data, word-driven, and cooperative (b) Control, data, concept-driven, and cooperative (c) Control, data, fragment-driven, and cooperative

Fig. 6 :

 6 Fig. 6: Dunn Index -Bicing case

  (a) Control, data, word-driven, and cooperative (b) Control, data, concept-driven, and cooperative (c) Control, data, fragment-driven, and cooperative

Fig. 7 :

 7 Fig. 7: Time Index -Bicing case

  indicates a completely stable package (service) whereas I = 1 a completely unstable package

  (a) Control, data, word-driven, and cooperative (b) Control, data, concept-driven, and cooperative (c) Control, data, fragment-driven, and cooperative

Fig. 8 :

 8 Fig. 8: Afferent coupling over K -Bicing case

Fig. 9 :

 9 Fig. 9: Relational cohesion over K -Bicing case

Fig. 10 :

 10 Fig. 10: BPMN-based process model for cargo tracking

Fig. 11 :

 11 Fig.11: Excerpt of Cargo tracking's domain ontology adapted from[33] [2011]

Table 1 :

 1 Synthesis view of microservices identification approaches

	Approach	Main Input	Data modeling	Identification algorithm	Evaluation	# of	Metric details
		(starting points)						metrics
	[1]	Functional and non func-	Dependency weight	Rule-based algorithm	1 case study: online movie	0	No metrics
		tional requirements spec-	between couple of		streaming system
		ifications		functions
	[2]	Business Processes(BPs) Data and control ma-	Centralized clustering	1 case study: Plan Approval	1	Accuracy
					trices dependencies		BPMN process
	[3]	System	requirements	Stored	procedures	Source code analysis	Real large scale system	0	No metrics but implementa-
		and	existing	stored	discovery related to		tion of a Proof of Concept
		procedures codes	the system require-
					ments
	[4]	OpenAPI specifications	Co-occurrence prin-	Centralized clustering	three case studies: (1) on-	2	Precision/Recall
		of interfaces and a refer-	ciple based-semantic		line movie streaming system,
		ence vocabulary		similarities between		(2) Transfer money application
					functionalities			combined to Kanban Board ap-
										plication, and (3) real-world
										OpenAPI specifications from
										APIs. Guru
	[26]	Data Flow Diagram sen-	dependency	graph	Rule-based algorithm	1 case study: cargo tracking	4	Afferent Coupling, Efferent
		tences			between	process,		Coupling, Instability of cou-
					data	stores	and		pling, Relational Cohesion
					external entities
	[16]	Use	cases,	Entity-	Dependency graph	Centralized clustering	two case studies: cargo tracking	1	Microservice candidates rat-
		Relationship	Models,	between nanoentities		and Trading system	ing (Excellent, Expected,
		security access groups,						Unreasonable)
		separated security zones,
		etc.
	[19]	Log of execution traces	Links between source	Centralized clustering	four case studies (web appli-	5	Functional Cohesion (Cohe-
		of programs		codes and business		cations): e-commerce, discus-	sion at Domain level, Cohe-
					logics					sion board system, blogging sys-	sion at Message level), Func-
										tem,blog sites	tional Coupling (Interface
										Number, Operation Num-
										ber, Interaction Number)
	[21]	Source code, domain	nothing special		Static analysis	Industrial application: customer	0	-
		model								management application of an
										insurance company
	[25]	Objects including inter-	dependency graph of	Rules-based algorithm	industrial application: Bank	0	-
		faces, business functions,	object calls				transactions management
		and database tables
	Our work Business Processes(BPs) Data, control, and se-	Collaborative clustering	two case studies: Bike rental and	5	Dunn Index, Afferent Cou-
					mantic matrices de-		cargo tracking
					pendencies

pling, Efferent Coupling, Instability of coupling, Relational Cohesion

Table 2 :

 2 Bicing's components

Table 3 :

 3 Control dependencies with the occurrence probability (p) set to 0.5

	Activity a1	a2 a3 a4	a5
	a1	-	1/2 5/6 11/12 17/12
	a2	1/2	-1/3 7/12 11 /12
	a3	5/6 1/3 -1/4	3/4
	a4	11/12 7/12 1/4 -	1/2
	a5	7/12 11/12 3/4 1/2	-

Table 4

 4

illustrates these properties with examples for Bicing. For instance, User_Credit attribute considered as both decision-making and financial data would have operational and confidentiality as F and NF criticality-related properties, respectively.

Table 4 :

 4 Examples illustrating F and NF criticality-related properties

	Criticality	Properties	Example
		Operational	Decision-making data
	Functional	Tactical	Concurrency data
		Strategic	Customer experience data
		Privacy	Protected personal data
	Non-functional	Integrity	Identity data
		Confidentiality	Financial data

Table 5 :

 5 Artefact/Attribute criticality for Bicing

	Artefact	Attributes	DC F
	Bicycle	Anchor_Point Bike_Status	M (k'1) H (k"1)	Artefact	Attributes	DC N F
		User_Status	H (k"2)	Bicycle Bike_ID	H (k"1)
	User	User_Destination L (k2) User_History H (k"2)	User	User_ID User_Validity	H (k"2) M (k'2)
	Rental	Rent_Cost Rent_ID	M (k'3) H (k"3)	Repair estimated_Repair_Cost H (k"4)
	Repair agree_Repair	M (k'4)

Table 6 :

 6 Excerpt of data dependencies

	Activity a1	a2 a3 a4	a5
	a1	-	1/2 5/6 11/12 17/12
	a2	1/2	-1/3 7/12 11 /12
	a3	5/6 1/3 -1/4	3/4
	a4	11/12 7/12 1/4 -	1/2
	a5	7/12 11/12 3/4 1/2	-

Table 7 :

 7 Excerpt of similarity values between activities and concepts

	Activity Concept Bicycle BicycleRental U ser AchorP oint Station
	a1	0.01818	0.02632	0.18076 0.04190 0.03621
	a2	0.01924	0.04481	0.99997 0.05231 0.03667
	a3	0.00421	0.01784	0.04266 0.12018 0.14423
	a5	0.00718	0.00476	0.00962 0.05937 0.02105
	a9	0.00968	0.01392	0.15772	0.0614	0.03038
	a10	0.12016	0.06755	0.04724 0.04081 0.10965

Table 8 :

 8 Excerpt of similarity values between activities and fragments

	Activity Fragment	F1	F2	F3	F4	F5
	a1	0.98182 0.97368 0.9581 0.98182 0.97368
	a2	0.98076 0.95519 0.94769 0.98076 0.96333
	a3	0.99579 0.98216 0.95734 0.99579 0.98216
	a5	0.99524 0.99524 0.99038 0.99282 0.99524
	a9	0.99032 0.98608 0.9386 0.99032 0.98608
	a10	0.93245 0.95276 0.95919 0.95919 0.93245

Table 9 :

 9 Excerpt of semantic dependencies using word-driven technique

	Activity Activity a1	a2	a3	a4	a5	a6
	a1	1 0.180 0.034 0.015 0.010 0.041
	a2	0.180 1	0.042 0.012 0.009 0.020
	a3	0.034 0.042	1	0.0019 0.266 0.120
	a4	0.015 0.012 0.0019	1	0.0043 0.0021
	a5	0.010 0.009 0.266 0.0043	1	0.0593
	a6	0.041 0.020 0.120 0.0021 0.0593	1

Table 11 :

 11 Excerpt of semantic dependencies using fragment-driven technique

	Activity Activity	a1	a2	a3	a5	a9	a10

  1 (ai, aj ) / (|Cu| * |Cv|)where the score matrix SM p designates either LSM or SSM matrix at the p th iteration. Clusters C u and C v are merged if and only if:14

[distance(Cu, Cv)] LSM p >= [distance(Cu, Cv)]

Table 12 :

 12 Performance metrics extracted from[START_REF] Fritzsch | From monolith to microservices: a classification of refactoring approaches[END_REF]

	Aspect	Metrics	Definition
		Afferent Coupling (AC) Measures the number of classes in other packages (services) that depend upon
			classes within the package (service) itself, as such it indicates the package's (ser-
	Coupling		vice's) responsibility
	([27])	Efferent Coupling (EC) Measures the number of classes in other packages (services), that the classes in a
			package (service) depend upon, thus indicates its dependence on others
		Instability (I)	Measures a package's (service's) resilience to change and is calculated as

Table 13 :

 13 Metrics of candidate microservices using our approach -Bicing case

		Microservice	Activities	Metric AC	EC	I	RC
		RequestHandling	a1, a2		13	0	0	2
	word-driven	Revision&V alidation BikeAbandon	a3, a4, a5 a12, a13, a14	18 11	1 5	0.05 0.31	5 6
		BikeReturn	a10, a11		12	5	0.29	3
		BikeReparation	a6, a7, a8, a9	23	3	0.12	5
					15.4	2.8	0.154	4	Avg
		ms#1	a1, a2, a3, a4, a5	25	0	0	14
		ms#2	a13, a14		14	1	0.07	2
	concept-driven	ms#3	a11, a12		14	1	0.07	2
		ms#4	a9, a10		14	1	0.07	2
		ms#5	a8, a7, a6		21	1	0.05	3
					17.6	0.8	0.052	5	Avg

Table 14 :

 14 Metrics of candidate microservices using our approach -Cargo Tracking case

	Microservice Metric	AC	EC	I	RC
	Preparation	23	0	0	14
	Handling	18	3	0.14	11
	Planning&Tracking	16	2	0.11	23
	Delivery	12	8	0.4	5
	Return	7	5	0.4	-
		15.2	3.6	0.21	13.25	Avg

Table 15 :

 15 Metrics of candidate microservices per approach

		Microservice Metric	AC	EC	I	RC
		Location	14	1	0.1	21.5
	[16]	T racking V oyage&P lanning	11 15	3 4	0.2 0.2	16.7 16.7
			13.3	2.7	0.2	14.2	Avg
		P lanning	16	2	0.1	20.3
		P roduct	13	4	0.2	1.8
	[4]	T racking	15	5	0.3	14.9
		T rip	8	2	0.2	0
			13	3.3	0.2	9.3	Avg
		Cargo	13	4	0.2	1.8
		P lanning	10	3	0.2	11.5
	[26]	Location	15	1	0.1	21.5
		T racking	16	5	0.2	14.1
			13.5	3.3	0.2	12.2	Avg

Table 14

 14 shows that our approach yields into five candidate microservices that are finer-grained compared to the four microservices inBaresi et al.'s and Li et al.'s approaches and the three microservices in Gysel et al.'s approach. Moreover, we observe that our approach's microservices are more strongly-cohesive compared to Baresi et al.'s and Li et al.'s approaches and less loosely-coupled compared to Gysel et al.'s approach

Table 16 :

 16 Cargo tracking's components

	Activity	Artefacts	Attributes of artefacts

Table 17 :

 17 Control dependencies with the occurrence probability (p) set to 0.5

	Activity Activity	a 1	a 2	a 3	a 4	a 5	a 6

Table 18 :

 18 Excerpt of data dependencies

	Activity Activity	a 1	a 2	a 3	a 4	a 5	a 6
	a 1	0	0.1875 0.34375 0.03125 0.03125 0.21875
	a 2	0.1875	0	0	0.1875 0.4375	0
	a 3	0.3437	0	0	0	0	0.21875
	a 4	0.3437 0.1875	0	0	0.1875	0
	a 5	0.3425 0.4375	0	0.1875	0	0
	a 6	0.21875	0	0.21875	0	0	0

Table 19 :

 19 Semantic dependencies between activities using word-driven technique

	Activity Activity	a 1	a 2	a 3	a 4	a 5	a 6
	a 1	1	0.0214 0.0186 0.0127 0.0217 0.0135
	a 2	0.0214	1	0.042 0.012 0.009 0.020
	a 3	0.0186 0.042	1	0.0019 0.266 0.120
	a 4	0.0127 0.012 0.0019	1	0.0043 0.0021
	a 5	0.0217 0.009 0.266 0.0043	1	0.0593
	a 6	0.0135 0.020 0.120 0.0021 0.0593	1

Table 20 :

 20 Semantic dependencies between activities using concept-driven technique

	Activity Activity	a 1	a 2	a 3	a 4	a 5	a 6
	a 1	-	0.394576 0.397204 0.493221 0.493818 0.322241
	a 2	0.394576	-	0.326376 0.392990 0.393466 0.272318
	a 3	0.397204 0.326376	-	0.395607 0.396086 0.274131
	a 5	0.493818 0.393466 0.396086 0.491833	-	0.321335
	a 6	0.322241 0.272318 0.274131 0.320940 0.321335	-

Table 21 :

 21 Semantic dependencies between activities using fragment-driven technique

	Activity Activity	a 1	a 2	a 3	a 4	a 5	a 6
	a 1	-	0.735274 0.968140 0.735274 0.970280 0.789005
	a 2	0.735274	-	0.724042 1,008878 0.753490 0.842985
	a 3	0.968140 0.724042	-	0.724042 0.953346 0.780517
	a 4	0.735274 1,008878 0.724042	-	0.753490 0.842985
	a 5	0.970280 0.753490 0.953346 0.753490	-	0.820096
	a 6	0.789005 0.842985 0.780517 0.842985 0.820096	-

tinyurl.com/y6ko2k8o.

tinyurl.com/ojm9zgp.

This work was supported by the French research association (ANRT)[grant number: 2018/0216]

In our work, individuals are activities and features are control, data, and semantic dependencies.

protege.stanford.edu.