Mohamed Daoud

Asmae El Mezouari

Noura Faci

Djamal Benslimane

Zakaria Maamar

Aziz El Fazziki

Towards an Automatic Identification of Microservices from Business Processes

Keywords: Microservices, Semantics, Business Process, Disco, Data dependencies

Microservices have emerged as an alternative solution to many existing technologies allowing to break monolithic applications into "small" fine-grained, highly-cohesive, and loosely-coupled units. However, identifying microservices remains a challenge that could undermine this migration success. This paper proposes an approach for microservices automaticidentification from a set of business processes (BP). The approach is multi-models combining different independent models that represent a BP's control dependencies, data dependencies, semantic dependencies, respectively. the approach is also based on collaborative clustering. A case study about renting bikes is adopted to illustrate and demonstrate the approach. In term of precision, the results show how BPs as inputs permit to generate better microservices compared to other approaches discussed in the paper, as well.

I. INTRODUCTION

There is a consensus that existing solutions like Commercial-Of-The-Shelf and Component-Based Software Engineering have already shown their limitations to tackle the challenge of managing monolithic (legacy) systems. Monolithic means one block of strongly-coupled components that complexify the process of accommodating functional, non-functional, and structural changes that all organizations experience on a daily basis. Contrarily, microservices have emerged as an alternative solution allowing to break such systems into "small" units that are finegrained, highly-cohesive, and loosely-coupled. However to sustain the benefits of microservices their successful discovery is a must. This paper presents a novel approach to discover microservices. First we use a set of Business Processes (BP) as an input for discovery while others use log files [START_REF] Djogic | Monolithic to microservices redesign of event driven integration platform[END_REF], source codes [START_REF] Escobar | Towards the understanding and evolution of monolithic applications as microservices[END_REF], UML class diagram [START_REF] Baresi | Microservices identification through interface analysis[END_REF], and legacy databases [START_REF] Chen | From monolith to microservices: A dataflow-driven approach[END_REF]. Second, we use clustering technique to capture the dependencies that characterize BPs' activities in terms of control, data, and functional.

Referred to as organizations' main assets, BPs could constitute an important source for identifying microservices. According to Weske, "... A business process consists of a set of activities that are performed in coordination in an organizational and technical environment. These activities jointly realize a business goal. Each business process is enacted by a single organization, but it may interact with business processes performed by other organizations" [START_REF] Weske | Business Process Management: Concepts, Languages, Architectures[END_REF]. Despite being a rich reservoir of many details like who does what, when, where, and why, BPs seem overlooked during the exercise of identifying microservices. To the best of our knowledge, Amiri is the only one who adopted BPs in this exercise [START_REF] Javad | Object-aware identification of microservices[END_REF].

In this paper, we design and develop a collaborative clustering-based approach to automatically identify microservices. At the core of our approach is the idea of extracting microservices from BPs' activities by using first, a set of separate models that individually identify different kinds of information related to these activities and their dependencies and second, a collaborative clustering technique instead of a classical clustering technique to avoid aggregating extracted data that could lead to losing some implicit details. Our approach is multi-models in the sense that it combines independent models to represent a BP's structural dependencies, data dependencies, semantic dependencies, and so on. It is also based on collaborative clustering in the sense that all data that could be extracted from the different models are kept independent instead of aggregating them. Each data set is then handled by a separate clustering algorithm.

The rest of the paper is organized as follows. Section 2 describes related work. Section 3 presents a case study and gives an overview of our approach to automatically identify microservices from existing BPs. Section 4 formalizes the structural and semantic dependencies models. Section 5 details the collaborative clustering in this approach and then, the system implementing this approach along with some experiments' results. Section 6 concludes the paper.

II. RELATED WORK

Decomposing existing monolithic applications into a set of microservices is one of the main challenges in migrating such applications to a microservices-based architecture. In this section, we discuss different approaches that pursue such objective.

In' [START_REF] Chen | From monolith to microservices: A dataflow-driven approach[END_REF], a 3-step approach to break a business logic into potential microservice is presented. The first step manually refines a traditional Data-Flow Diagram (DFD) to shed light on data flows with respect to a business logic. During this step details about data stores and external entities are discarded. The next step uses some rules to abstract the refined DFD into a decomposable DFD allowing to improve the quality of the future microservices to obtain. Finally, the third step proceeds with identifying the microservices based on the operations of the DFD and their output data.

In [START_REF] Jin | Functionality-oriented microservice extraction based on execution trace clustering[END_REF], an approach based on functionality-oriented microservice extraction by clustering execution traces of programs collected at run-time is presented. These traces are collected using program execution monitoring techniques and permit to examine the implicit and explicit program functional behavior. They 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 the strong dependence on the quality of the generated execution traces, and consequently on the quality of the test cases.

In [START_REF] Javad | 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 business processes. All these dependencies are merged into one dependency matrix. This latter is used by a classical clustering algorithm to identify candidate microservices.

In [START_REF] Gysel | Service cutter: A systematic approach to service decomposition[END_REF], a service-cutter system is presented allowing to decompose monolithic systems into "small" services. The decomposition uses the systems' functions and considers 3 criteria that are cohesion between entities at the property level, coherence between data of each microservice, and communication cost between services. In [START_REF] Chen | From monolith to microservices: A dataflow-driven approach[END_REF], an approach to identify microservices is proposed. It uses the semantic similarity of functionalities that are described in openAPI and a reference vocabulary.

III. OUR APPROACH FOR IDENTIFYING MICROSERVICES

This section consists of 4 parts. The first part presents a case study that refers to Barcelona's bike sharing system known as Bicing. The second and third parts discuss our approach's foundations in terms of dependencies between BPs' activities and collaborative clustering.

A. Bicing case-study

Bicing includes more than 400 bike anchor-stations spread across Barcelona and about 6000 bikes that users rent for a fee. Bicing's monolithic system 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 that undermine its operations. For the needs of our work, we suggest in Fig. 1 a high-level representation of Bicing from a BP perspective. We resorted to the standard Business Process Model and Notation (BPMN) to illustrate this representation. We have identified different activities (a 1 : request bike and a 9 : dismantle bike), different dependencies (between a 1 and a 2 ), different logical operators (XOR between a 6 and a 10 and OR between a 2 and a 3 ), and, finally, different artefacts (bike and user) and their respective attributes (e.g., ID and status). In the rest of this paper the discussion about Bicing is not restricted to renting bikes but includes other aspects like reporting and fixing bikes' defects and disposing bikes, if necessary.

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 ), the Bicing system 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 point (a 11 ). Otherwise, the Bicing system blacklists the user (a 14 ) due to bike inappropriate return and geo-locates the bike (a 12 ) so that From a specification perspective, activities ({a i }) may require inputs ({i i }) and produce outputs ({o i }) that both correspond to specific artefacts' attributes. An activity acts upon an attribute through 2 operations that are read (r) and/or write (w), which could lead to updating (u), creating (c), and/or deleting (d) artefacts.

B. Foundations

Simply put, 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" means connecting activities using dependencies such as control (execution order), semantics (functional similarity), data (information sharing), and organisational (cross-functional operations).

-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 2 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. -Semantic dependency uses activities' names to establish their functional similarity in term of what they do. Activities' 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. -Data dependency is about data flows between activities' outputs/inputs that constitute artefacts' attributes that could be subject to create (c) and write (w) operations and could be labeled as either optional or mandatory for BP execution. We advocate that activities exchanging mandatory artefacts' attributes should be part of the same microservice allowing to comply with the strong coupling principle.

-Organizational dependency refers to horizontal (cross) and vertical (silo) business operations. We advocate that activities that fall into horizontal interactions would more likely be part of the same microservices. We focus on control and semantic dependencies, only. Upon establishing such dependencies, we quantify them using specific metrics that evaluate the cohesion and coupling among activities so they are gathered in either same or separate microservices. To evaluate a control dependency between 2 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 continuously calculated using BP's execution logs.

To evaluate semantic dependency between 2 activities (a i , a j ), we consider the distance between their respective semantic annotations. We identify 3 annotation strategies referred to as word-driven (W), concept-driven (C), and fragment-driven (F). The first relies on a reference vocabulary to annotate activities with terms associated with their respective names. The second relies on some specific 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.

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' features 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]. 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 approach for microservices identification. It relies on the aforementioned dependencies and collaborative clustering to group activities that would form fine-grained, highly-cohesive, and loosely-coupled microservices. Our approach consists of the following steps. After examining activity dependencies, their details are stored in dedicated repositories. Then, these repositories' contents are submitted for collaborative clustering where different clustering techniques (one per dependency) are used to obtain consensual clustering solutions. More details are given in Section V-A.

IV. ANALYZING DEPENDENCIES

A. Control dependency analysis

Let CD(a i , a j [Operator {a k }]) ExecOrder be a direct control dependency referring to a certain execution order between a i and a j that is connected to other activities {a k } through a certain Operator. An execution order between Fig. 2: General representation of our microservice identification approach 2 activities could be exemplified with either finish-to-start (our focus and denoted by SEQ)), finish-to-finish, start-tostart, or start-to-finish.

Let us start with the control dependency CD(a i , a j ) SEQ (i.e., {a k } = ∅)). Since SEQ between a i and a j means that a j starts only after a i has successfully completed, CD(a i , a j ) SEQ 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 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 3 computes 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 [START_REF] Davenport | The new industrial engineering: Information technology and business process redesign[END_REF] where -r=1,n ( r n × C(n, r)) represents the number of a j 's occurrences among possible combinations of activities 1 . -r=1,n C(n, r) corresponds to the total number of possible combinations of activities 2 .

We now look into indirect control dependency between a i and a j where there is a set of other peers connected with operators. This dependency, denoted as CD(a i , a j ) path 1 i,j , refers to a certain execution path (path 1 i,j ) and is computed as per Equation 6:

CD(a i , a j ) path 1 i,j = al,am∈path 1 i,j
CD(a l , a m Operator {a km }) SEQ [START_REF] Djogic | Monolithic to microservices redesign of event driven integration platform[END_REF] When multiple execution paths exist between a i and a j , we refer to this control dependency as CD(a i , a j ) pathsi,j and is computed as per Equation 7:

CD(a i , a j ) paths i,j = max q=1,... (CD(a i , a j ) path q i,j ) (7) where path q i,j represents the q th possible execution path between a i and a j . Table I

B. Semantic dependency analysis

Let X be the annotation strategy 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 first describe our 3 proposed annotation strategies.

Word-driven strategy (W). Algorithm 1 outlines how to annotate an activity a i 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] Vo | Disco: A system leveraging semantic search in document review[END_REF], that assumes that words with similar meaning (co-)occur in similar bag-of-words contexts. Thus, W ai represents the set of a i 's most distributionally similar words (w k ) along with their respective similarity degrees (sd i,k ). It is worth mentioning that any other semantic textual similarity solution can be used. 1 Let n be 3, r=1,n ( r n × C(n, r)) has the following value: ( For instance, if the highest value is 0.5 and σ is set to 0.1, then max s also includes all the concepts with a similarity degree between 0.4 and 0.5.

1 3 × 3 + 2 3 × 3 + 3 3 × 1=4). 2 Let n be 3, r=1,n C(n,
Algorithm 2: Concept-driven annotation strategy

Input: ai, O BP , σ Output: Ca i 1 begin 2 foreach cj ∈ O BP do 3 D[i, j] ← DISCO2(ai, cj ) 4 Ca i ← maxs({D[i, j]}, σ) 5 return Ca i
Fragment-driven strategy (F). Algorithm 3 outlines how to annotate an activity a i using a set of the most similar (eventually overlapped) fragments (F ai ) that each encompasses concepts belonging to O BP . Lines 2-3 compute a i 's membership degrees (M[i]) to each fragment F k ∈ O BP based on the set of common concepts that belong to F k and C ai along with sd i,j associated with each c j . In Line 4, max m function develops F ai by considering the fragments with the highest similarity degrees with respect to a certain precision σ.

Algorithm 3: Fragment-driven annotation strategy

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], σ) 5 return Fa i
Formally, Equation 8 computes the Semantic Dependency (SD) between a i and a j .

SD(a

i , a j ) = 1 -d X (X ai , X aj ) (8)
where X ai reflects the annotation strategy's outcome (i.e., either W ai , C ai , or F ai ) and d X represents the distance between X ai and X aj . We hereafter define each d X .

• d W compares all the words in W ai to those in W aj . Formally, Equation 9 computes d W as follows.

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

Equation 10 computes the normalized d W as follows.

d norm W (W ai , W aj ) = d W (W ai , W aj ) |W p ai | + |W p aj | (10)
• d C compares all the concepts in C ai with those in C aj . Formally, Equation 11 computes d C as follows.

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 )) (11)
Equation 12 computes the normalized d C as follows.

d norm C (C ai , C aj ) = d C (C ai , C aj ) |C ai | * |C aj | ( 12
)
• d F compares all the fragments in F ai with those in F aj . Formally, Equation 13 computes d C as follows.

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

d norm F (F ai , F aj ) = d F (F ai , F aj ) d max F ( 14
)
where

• d max F = max({d (F a k , F a l )} <a k ,a l >∈P2(BP ) )

V. COLLABORATIVE CLUSTERING ALGORITHM AND EXPERIMENTAL EVALUATION

In this section, we first describe our proposed collaborative clustering of BPs' activities and then discuss the experiments and evaluation.

A. Collaborative clustering

We designed a collaborative clustering algorithm (cHAC) that 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 they differ with respect to their inputs. Each CN node handles one and only one dependency matrix.

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 3 phases: Then, the node updates The Local Score Matrix 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 = Max([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 to choose the best one that fosters both cohesion and loose-coupling of groups.

B. Experiments

We implemented the collaborative clustering approach in Java. To this end, different modules have been developed. Some of these modules permitted to extract control dependencies and data dependencies from BPs and to run the collaborative clustering algorithm that took the number of clusters and dependency matrices as inputs. Bicing system's 14 activities were initially used to test the algorithm. Then, more activities were randomly generated to capture the complexity of real BPs.

For evaluation needs we considered the internal validation metric Dunn index that measures the quality of clustered results by identifying the clusters that are compact (minor In the first experiment, we measured the Dunn index of the clustering algorithm by using Control, Data and Semantic dependencies matrices. Fig. 3a and Fig. 3b illustrate the obtained results clearly showing that the Dunn index that results from the Control dependencies node is almost always better than the Dunn index that results from both Data and Semantic dependencies nodes. This means that for a given BP, the control dependency model is richer and more informative than the other models. We also computed the Dunn index of the clustering result by aggregating the three control, data and semantic dependencies in one matrix.

The obtained results show that the clustering quality of the Control dependency node is often better than the one obtained by merging control, data and semantic dependencies. It confirms that aggregating different dependency matrices degrades the quality of the final microservice generation and the collaboration between nodes is the appropriate option.

VI. CONCLUSION

Automatic identification of microservices is one step allowing to migrate from monolithic systems to microservicesbased systems. This paper proposed a multi-model basedapproach to support this migration using BPs as an input to this identification. Each model represents dependencies between BPs' activities from one perspective (control, semantics, data, etc.). The generated data dependencies are then used by a collaborative clustering algorithm to identify groups of cohesive activities that could become potential microservices. The technical results are promising showing how our collaborative clustering algorithm outperforms the cooperative clustering algorithm in term of precision.

Fig. 1 :

 1 Fig. 1: An illustrative BPMN-based representation of the Bicing system

11 @Fig. 3 :

 113 Fig. 3: Dunn Index of clustering results

  depicts an excerpt of control dependencies in the Bicing system.

TABLE I :

 I Control dependencies with p = 0.5

	Activity	a 1	a 2	a 3	a 4	a 5
	a 1	-	1/2	5/6	11/12	17/12
	a 2	1/2	-	1/3	7/12	11 /12
	a 3	5/6	1/3	-	1/4	3/4
	a 4	11/12	7/12	1/4	-	1/2
	a 5	7/12	11/12	3/4	1/2	-

  r) has the following value: (3+ 3+ 1)=7.Concept-driven strategy (C). Algorithm 2 outlines how toannotate an activity a i using a set of the most similar concepts (C ai ) that would belong to the BP's domain ontology (O BP ). For each concept c j , the algorithm uses No et al.'s similarity measure between a i and c j , namely DISCO 2 . In line 3, max s function develops C ai by considering the concepts with the highest similarity values with respect to a certain precision σ.

	Algorithm 1: Word-driven annotation strategy
		Input: ai, n
	Output: Wa i 1 begin
	2 3	Wa i ← DISCO(ai, n) return Wa i

  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 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:

	Algorithm 4: cHAC -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
	2	SIC ← 0 ;	// shared counter between CN nodes
	3	cSET [i] ←cHACn(ki, DMi, @SDSM, @SIC), i = 1..M ;
		// parralel execution of CN nodes
	4	;
	5	fc ← chooseF inalClusterResult(cSET);
	6	return fc;
		new iteration is launched at a given node if-and-only-
		if the other nodes have already finished their current
		iterations.
			|Cu | * |Cv |
		SMp (Cu, Cv) =
			(i,j)=(1,1)
			LSM p	>= [distance(Cu, Cv)]	SSM p-1
		.

• • SMp-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: 3 [distance(Cu, Cv)]