Davide Buscaldi
email: davide.buscaldi@univ-orleans.fr

Paolo Rosso
email: prosso@dsic.upv.es

Explicit Query Diversification for Geographical Information Retrieval

In this paper we make a first attempt to evaluate the potential of diversity in the Geographical Information Retrieval task. This task represent an opportunity to take advantage of diversity, given that documents are not relevant only from a thematic point of view, but also spatially. A user of a GIR system may be interested in results that are geographically distributed and equally relevant. We attempted to diversify results explicitly, reformulating queries with meronyms of the places contained in the original queries, with the help of a geographical ontology. The obtained results show that a theoretical improvement is possible, but this approach may be effective only in the case that the relevant documents do not contain enough geographical data.

Introduction

Diversity search is an Information Retrieval (IR) paradigm that is somehow opposed to the classic IR vision of "similarity search", in which documents are ranked accordingly to their similarity to the query. In the case of diversity dearch, similarity to the query is not the only criterion to determine relevant results: they should be different one from each other under some aspect, in order to satisfy the user information needs from different points of view which may be known to the user or not. For instance, if the user submit an ambiguous query, it is possible that he is not aware of its ambiguity, and the system should return a mixture of documents which may provide a complete picture of all interpretations, allowing the user to take a further step and decide which aspect of the query is more relevant to him. However, ambiguity is not the only source of diversity. Information is often temporally and/or geographically constrained, such that the results of a given query may be diversified in the temporal or spatial dimension, in order to provide the user with a picture of the evolution of a topic in time or giving him an idea of how the topic may be relevant to a specific sub-region of a region described in the query. For instance, the temporal diversification of the query "Countries of the European Union" may result in a list of documents where each document describes the countries entering into the Union in a specific year (the complete set of retrieved documents show the history of the adhesions); the geographical diversification of the same query may return documents where the perspective is switched to the membership of a single country (the complete set of retrieved documents provide a full coverage, from a geographical point of view, of the topic).

In most of the research works over diversity the objective has been to provide multiple distinct interpretations for ambiguous queries [START_REF] Santos | Explicit Search Result Diversification through Sub-queries[END_REF][START_REF] Agrawal | Diversifying search results[END_REF][START_REF] Clarke | Novelty and diversity in information retrieval evaluation[END_REF]; less works have dealt with the representation of sub-topics within search results for queries with broad thematic scope [START_REF] Vee | Efficient computation of diverse query results[END_REF]. Spatial diversity has been successfully applied to image search in [START_REF] Paramita | Generic and Spatial Approaches to Image Search Results Diversification[END_REF]; Tang and Sanderson [START_REF] Tang | Spatial Diversity, Do Users Appreciate It?[END_REF] showed that spatial diversity is appreciated by users. Clough et al. [START_REF] Clough | Multiple Approaches to Analysing Query Diversity[END_REF] analysed query logs and found that in the case of place names ambiguities users tend to reformulate queries more often.

The objective of this paper is to determine the potential of geographical diversity in the context of Geographical Information Retrieval (GIR). In GIR, queries are geographically constrained: therefore, it is possible, with the help of a geographical ontology, determine the sub-topics directly from the query (for instance: Europe is diversified in all the component countries) and build a set of reformulated queries, one for each subtopic. With the help of GeoWorSE [START_REF] Buscaldi | Using GeoWordNet for Geographical Information Retrieval[END_REF], a GIR-enabled search engine, and the evaluation framework (queries and documents) of GeoCLEF3 we attempted to determine the effects of the diversified sub-queries on the retrieval results.

The remainder of this paper is structured as follows: in Section 2 we describe the retrieval framework, in Section 3 we describe the collection used and the experiments carried out; in Section 4 we present the results of the experiments and an analysis of these results; finally in Section 5 we draw some conclusions and set the path for future works.

The GeoWorSE Retrieval System

This system is built around the Lucene search engine and a geographical ontology based on Geonames4 and WordNet [START_REF] Miller | Wordnet: A lexical database for english[END_REF]. It is based on the enrichment of the index with terms that are not contained in the examined document but which can be inferred from the geographical entities in the document text.

During the indexing phase, the documents are examined in order to find location names (toponyms) by means of the Stanford conditional random fieldsbased NER system. When a toponym is found, in the case it has more than one referent according to the geographical ontology, a disambiguator [START_REF] Buscaldi | A conceptual density-based approach for the disambiguation of toponyms[END_REF] determines the correct reference for the toponym, depending on the other toponyms contained in the document. Then, holonyms and synonyms of the toponym are extracted from the ontology and added to an expanded index, together with the original toponym. For instance, consider the following text from document GH950630-000000 in the GeoCLEF collection: ...The British captain may be seen only once more here, at next month's world championship trials in Birmingham, where all athletes must compete to win selection for Gothenburg... Let us suppose that in the ontology there are two possible referents for "Birmingham": "Birmingham/Alabama", and "Birmingham/England". "Gothenburg" is found only once but with synonyms Goteborg (the original Swedish name) and the alternate spelling "Goetenborg". Let us suppose that the disambiguator correctly identifies "Birmingham" with the English referent, then its holonyms are England, United Kingdom, Europe. In the case of "Gothenburg" we obtain Sweden and Europe as holonyms, "Goetenborg" and "Goteborg" as synonyms. Therefore, the words added to the expanded index for the above paragraph are: Birmingham, England, United Kingdom, Europe,Gothenburg, Goteborg, Goeteborg, Sweden.

Then, the geo index contains the geographical coordinates associated to the above toponyms; finally, all document terms are stored in the text index. The text and expanded indices are used during the search phase; the geo index was not used for search in this work. In Figure 1 we show the architecture of the indexing module. The topic text is searched by Lucene in the text index. All the toponyms are extracted by the NER system and searched for by Lucene in the expanded index The result of the search is a list of documents ranked using the tf • idf weighting scheme, as implemented in Lucene.

Query Diversification

The query terms t 0 . . t n ∈ Q are grouped into two subsets, a content set C q , containing the words which represent the "focus" or thematic part of the query, and a geographic footprint set G q , which contains the place names P identifying the geographical constraint associated to the query. For every toponym t ∈ G q , we search the geographical ontology for meronyms M t = {m 0 , . . . m k } (i.e., places contained in the place represented by toponym t). The diversified queries are assembled by taking the terms in C q together with a meronym m ∈ M t , for every t. Therefore, the number or queries built in such a way is t∈Gq |M t |. For instance, the query "golf tournaments in Europe" would be diversified into: "golf tournaments Spain", "golf tournaments Italy", "golf tournaments UK", "golf tournaments France", etc.

Among all the produced queries, we selected the ν most promising queries as the ones having the highest mutual information (MI) between the content terms and the terms in the geographic footprint:

I(C q ; G q ) = p(C q ∩ G q ) log p(C q ∩ G q ) p(C q )p(G q ) (1)
Where probabilities are calculated as the number of hits (obtained with the baseline ranking and the indicated set of terms) divided the number of documents in the collection. If there are less than ν possible reformulations, all reformulated queries are taken into account. This selection process has the objective of identifying the relative importance of the geographical aspects underlying the original query.

Experimental Setup

Our experiments were conducted over the GeoCLEF 2005-2008 test collection, including a total of 100 topics with the relative relevance judgements. The document collection consists of 169, 477 documents and is composed of stories from the British newspaper "The Glasgow Herald", year 1995, and the American newspaper "The Los Angeles Times", year 1994. We run the experiments using only the topic title. Of the 100 topics, it was possible to build reformulation for 45 of them. This means that of the 100 topics, 55 did not include a place name or the included place names did not have meronyms in the geographical ontology (this may happen if the place can be approximated to a point or a line, such as cities or rivers). We used two baselines: the first baseline is constituted by the result obtained with the original query, without reformulation. The second baseline is made of the merged results of reformulations, using the cmbMNZ fusion algorithm [START_REF] Fox | Combination of Multiple Searches[END_REF]. The potential of diversification was examined using an oracle, that is, a system which returns the results that could be obtained if the best reformulation is known apriori. Since we are still at the beginning of our work on diversity search, we implemented a naïve round robin technique (subsequently indicated as "RR") for the fusion of the results of the reformulated queries, consisting in building a list by taking one document in turn from each individual list and alternating them in order to construct the final merged output. This is how a user would behave while examining different sets of results (examining the top ones from each set, then the second best results, and so on). Duplicate results are removed. In this way, the merged result set can be compared with the ones obtained with the baselines.

The metrics used in the evaluation are: Mean Average Precision (MAP), Mean Relevance Rank (MRR), Precision at 5 (P@5), and Normalized Cumulative Discounted Gain (NDCG). NDCG ability to handle degrees of relevance was not exploited since the relevance judgements in GeoCLEF are binary judgements.

Experimental Evaluation

We carried out two evaluations, one with ν = 5 (Table 1) and another with ν = 10 (Table 2). In all measures, the baseline is better than the fused results, while the oracle is always better than the baseline. It is interesting to note that the round-robin technique allowed to obtain better results than CombMNZ with MRR and NDCG (although the difference in NDCG is not statistically relevant). NDCG has been observed in [START_REF] Sanderson | Do user preferences and evaluation measures line up?[END_REF] to be the measure that most effectively models user preferences.

Table 1. Results with ν = 5 base CombMNZ RR Oracle MAP 0,2074 0,1935 0,1818 0,2543 MRR 0,5301 0,4923 0,5185 0,7131 NDCG 0,4710 0,4605 0,4644 0,5401 P@5 0,3435 0,3087 0,2696 0,4304 Table 2. Results with ν = 10 base CombMNZ RR Oracle MAP 0,2074 0,1862 0,1777 0,2612 MRR 0,5301 0,4323 0,4948 0,7512 NDCG 0,4710 0,4555 0,4616 0,5510 P@5 0,3435 0,3217 0,2783 0,4522

We analysed the data and found some queries that obtained always a significant improvement over the baseline with the RR fusion, and others for which the oracle was not able to obtain a result better than the baseline. These "critical" topics are shown in Table 3. In order to understand the reason of such behaviour, we examined the distributions of places in the set of relevant documents in order to understand whether geographical diversity is supported by the data contained in the test collection or not. For each query q we carried out a k-means clustering, with k = ν, of the points contained in the set R q of relevant documents. The desired behaviour was to obtain clusters centred on geographic areas corresponding to the places identified in the query diversification process.

We found that reformulation of queries in group 1 was effective because actually the centroids did not match the diversified places, while for queries in group 2, the data showed clusters centred mostly on relevant areas (we plotted these clusters in Figure 2 and Figure 3 for topics 10.2452/GC -006 and 10.2452/GC -010, respectively). It can also be observed that many places are distributed accordingly the sources of the news (Glasgow and Los Angeles). Therefore, the diversification of the queries based on the geographical ontology seems to be effective only when the data do not offer enough clues to group results from a geographical viewpoint.

Conclusions and Further Work

We developed a simple method to geographically diversify GIR queries, based on the knowledge provided by a geographical ontology. With this method, if the original query contains the name of a region which includes n places, the ν ≤ n most significant places (according to the mutual information between the query content and the geographical constraint) are selected, and ν queries are submitted to the search engine. We evaluated this method over the GeoCLEF test set. The results showed that an oracle selecting always the best result obtains better results in all measures than the baseline, indicating that a theoretical improvement is possible; however, the tested fusion methods are not able to capture this potential. The error analysis showed that apriori diversification of the query was useful when the geographical data are sparse, and therefore it is necessary to "drive" the query towards possible relevant results. If the geographical data in the relevant documents are dense enough to support the diversification of results, then diversity can be inferred from data and query reformulation adds noise.

In order to validate these conclusions, we will have to carry out more experiments. We will have to design a data-driven diversification algorithm (or use an existing one, such as the one proposed by [START_REF] Santos | Explicit Search Result Diversification through Sub-queries[END_REF]) and verify that in this way it is possible to exploit the geographical diversity contained in the data to improve the results in GIR. We should also evaluate the results using metrics specifically aimed to diversity.

Fig. 1 .

 1 Fig. 1. Diagram of the Indexing module

Fig. 2 .

 2 Fig. 2. Distribution of places in documents judged relevant for topic 10.2452/GC -006. Cluster centroids indicated with star-shaped markers. Data are sparse and do not reflect the geographic footprint of the query.

Fig. 3 .

 3 Fig. 3. Distribution of places in documents judged relevant for topic 10.2452/GC -010. Cluster centroids indicated with star-shaped markers. Data mostly reflect the geographic footprint of the query.

Table 3 .

 3 "Critical" topics Topics mostly benefitted by query reformulation (group 1) 10.2452/GC-001 Shark Attacks off Australia and California 10.2452/GC-006 Oil Accidents and Birds in Europe 10.2452/GC-008 Milk Consumption in Europe 10.2452/80-GC Politicians in exile in Germany Topics negatively affected by query reformulation (group 2) 10.2452/GC-048 Fishing in Newfoundland and Greenland 10.2452/GC-013 Visits of the American president to Germany 10.2452/GC-010 Flooding in Holland and Germany 10.2452/51-GC Oil and gas extraction found between the UK and the Continent

http://ir.shef.ac.uk/geoclef/

http://www.geonames.org


Karim Dahman

François Charoy

Claude Godart

Towards Consistency Management for a Business-Driven Development of SOA

Towards Consistency Management for a Business-Driven Development of SOA Karim Dahman, Franc ¸ois Charoy, Claude Godart Université de Lorraine, UHP -LORIA BP 239 54506 Vandoeuvre-lès-Nancy Cedex, France {karim.dahman, francois.charoy, claude.godart}@loria.fr Abstract-The usage of the Service Oriented Architecture (SOA) along with the Business Process Management has emerged as a valuable solution for the complex (business process driven) system engineering. With a Model Driven Engineering where the business process models drive the supporting service component architectures, less effort is gone into the Business/IT alignment during the initial development activities, and the IT developers can rapidly proceed with the SOA implementation. However, the difference between the design principles of the emerging domainspecific languages imposes serious challenges in the following re-design phases. Moreover, enabling evolutions on the business process models while keeping them synchronized with the underlying software architecture models is of high relevance to the key elements of any Business Driven Development (BDD). Given a business process update, this paper introduces an incremental model transformation approach that propagates this update to the related service component configurations. It, therefore, supports the change propagation among heterogenous domainspecific languages, e.g., the BPMN and the SCA. As a major contribution, our approach makes model transformation more tractable to reconfigure system architecture without disrupting its structural consistency. We propose a synchronizer that provides the BPMN-to-SCA model synchronization with the help of the conditional graph rewriting.

Index Terms-Incremental Model Transformation, Structural Consistency Management, Business-IT Alignment

I. INTRODUCTION

The Business Driven Development (BDD) refers to the discipline of building the business processes of an enterprise or between several organizations. It is used to develop the software solutions that directly satisfy the new business goals (or the requirements of the existing systems), and to provide a path from the business settings to the application code. During the BDD the business processes are mapped into the IT level, where they describe the configuration of the software applications that are organized in a Service-Oriented Architecture (SOA [START_REF] Papazoglou | Serviceoriented computing: State of the art and research challenges[END_REF]). Moreover, with the SOA principles, the software applications are implemented as components with remotely published interfaces in loosely-coupled architectures. Generally, the SOA development extends the Component Based Development (CBD) paradigms [START_REF] Karhunen | Service-oriented software engineering (sose) framework[END_REF], [START_REF] Wermelinger | A graph based architectural (Re)configuration language[END_REF] that offers the means to define platform-independent architectures with the Service Dominant Logic [START_REF] Chen | From software architecture analysis to service engineering: An empirical study of methodology development for enterprise soa implementation[END_REF]. In many cases, the experience shows that the initial business requirements vision is lost when the software architecture is instantiated [START_REF] Levi | A goal-driven approach to enterprise component identification and specification[END_REF]. One reason is the conceptual disparity between the BDD and the CBD disciplines and their domain-specific languages [START_REF] Dumas | Service-enabled process management[END_REF].

In a previous work [START_REF] Dahman | Generation of Component Based Architecture from Business Processes: Model Driven Engineering for SOA[END_REF], we have already introduced a Model Driven Engineering (MDE [START_REF] Lopes | Generating transformation definition from mapping specification: Application to web service platform[END_REF]) approach that automates the generation of (target) canonical software architecture models that are organized in a SOA from business process models. It is undeniable, however, that the flexibility to adapt a (source) business process model in order to respond to evolving business needs and automatically propagate its evolution to the (target) software architecture model is the most relevant trend in the success of this development method. What sounds so straightforward and easy in theory with the model transformation techniques turns out to a very challenging endeavor in practice. Even, if the used metamodels assume the same SOA concepts for building the software applications that provide and consume business meaningful services [START_REF] Karhunen | Service-oriented software engineering (sose) framework[END_REF], however, not all source metamodel constructs correspond to target metamodel constructs due to the difference between their abstraction levels. The existing general model synchronization frameworks and transformation languages [START_REF] Antkiewicz | Generative and transformational techniques in software engineering ii[END_REF] cannot work well here. First, they require to manually write the synchronization code to deal with each update kind on each of the assorted models. Second, the complexity of the combinatorial change mapping is inherently compounded with decisions regarding the potential information loss or gain related to the different levels of the model's expressiveness.

When a source business process model evolves and a transformation has previously generated a corresponding technology-neutral SOA model, it is necessary to keep the models synchronized to enable rapid iteration of process redesigns and improvements of the underlying SOA implementations. This paper presents a unidirectional model incremental transformation approach. Its central contribution is the definition and the realization of an automatic synchronizer for managing and re-establishing the structural consistency of those heterogeneous source and target models. From a designtime perspective, an evolution describes the update on model's internal structures that can be assimilated to a graph. We express the model evolutions and their transformation with the help of the conditional graph rewriting techniques [START_REF] Biermann | Precise Semantics of EMF Model Transformations by Graph Transformation[END_REF], [START_REF] Giese | From model transformation to incremental bidirectional model synchronization[END_REF]. We consider that the application of an update corresponds to the execution of a compound sequence of primitive graph productions [START_REF] Mens | Transformational Software Evolution by Assertions[END_REF] such as vertex or edge additions, removals, relocations, and attribute value changes. Our synchronization algorithm, that we implemented in a business process editor, works by translating the consistent source updates into con-sistent updates onto the target software architecture model. If the update seems to be appropriate, then the IT developers can synthesize the platform-specific SOA implementations.

The remainder is structured as follows. In Section II, we introduce the languages that we use to describe the business process and the software architecture models with a case study. Then, we present the requirements of our incremental model transformation approach, and explain the consistency management for our MDE in Section III. This section gives also the details of our synchronization algorithm and its implementation. Finally, we situate our approach with the related research in Section IV, and conclude the paper in Section V.

II. DESIGN-TIME MODEL TRANSFORMATION

Typically, the Business Process Modeling (BPM) combines graphical and textual annotations to specify complex processenabled systems that are decoupled from their supporting SOA architectures [START_REF] Dumas | Service-enabled process management[END_REF]. Several languages can be used to specify the business service interaction models at different levels of abstraction. The Business Process Modeling Notation (BPMN [START_REF]Business Process Model and Notation (BPMN) 2.0, Beta 1[END_REF]) allows to specify systems that support crossdomain sharing capability as the lingua franca of the BPM. In particular, the BPMN collaboration models express and put in logical relation the messages exchanged between the internal processes of complex service-enabled business networks. They relate to coordinate an explicit exchange of information through (automated) business service interactions under the control of a single endpoint, called service orchestration [START_REF] Papazoglou | Serviceoriented computing: State of the art and research challenges[END_REF]. During the BDD those business process models are mapped to the implementation models with a lower abstraction level, where they stand as a business service interaction specifications organized in a SOA. The SOA is an architectural style and a design principle for building software applications which promote loose coupling between the software components. It is often presented as an enabler of the Business Process Management because it enables the business process optimization along with flexible IT architectures [START_REF] Dumas | Service-enabled process management[END_REF]. The SOA has introduced a wide range of technologies and languages.

With the recent Service Component Architecture (SCA [START_REF]SCA Assembly Model Specification 1.1, Open SOA[END_REF]) specifications, the CBD becomes a prominent and mainstream paradigm for implementing, composing and deploying of flexible software architecture models. The SCA defines an Architecture Description Language that can be used across many vendor environments. It can logically modularize and compose the service-enabled business functions in a manner that is decoupled from their implementations. With a graphical notation support, it describes composite assemblies of servicecomponents, their connections and other related artifacts which specify how they are externally consumed and/or offered by other components. The so-called SCA assembly models specify a path from the business requirements and the business service interaction specifications to the executable processes and their implementations. At the execution-time, the assembly models are instantiated for the SCA runtime environments and benefit from those frameworks for the deployment and the monitoring. In [START_REF] Dahman | Generation of Component Based Architecture from Business Processes: Model Driven Engineering for SOA[END_REF], we have presented a MDE approach for an automatic transformation of a (target) canonical SCA assembly model from a (source) BPMN collaboration model, and specified relations among the BPMN and the SCA metamodels as conceptual mappings. However, the incremental BPMNto-SCA tranformation remains an open question. We refer to the program executions that implement these conceptual mappings as transformations. Note that the usage of the BPMN along with the SCA is not only intended for modeling the process-enabled logics of the business services, but also for specifying the architectural settings of the cross-organizational business service that drive the SOA implementations. Section IV provides a detailed discussion on this choice.

A. Case Study

To study the issues of an incremental model transformation, we have chosen a motivating example that represents a dealing network [START_REF]Business Process Model and Notation (BPMN) 2.0, Beta 1[END_REF]. In this service-enabled business network, a supplier participant provides an order status business service to a customer partner. This service is used when the customer has beforehand ordered goods, and thus it stands for their shipping. The two partners play both consumer and provider roles in this business service. Depending on the design choices, this service network can be modeled in different ways. For example, the Figure 1 shows the high-level diagrams of two source BPMN collaboration models, e.g., s and s , and their transformations into target SCA assembly models, e.g., t and t . Each element on the target model is labeled with the label's first letters of the source model from which it is generated. The business links between the partner processes can be modeled with a single order status conversation construct in s that contains all the service interactions, or as two different conversations in s that logically separates the exchanged between the participants. In the collaboration model s , the business service is designed as two send/receive interaction pattern [START_REF] Van Der Aalst | Service Interaction: Patterns, Formalization, and Analysis[END_REF] that belong to a compound conversation. Whereas, in s the business service is designed with the order status request and order status response conversations that separate the service interaction patterns. In both cases, the BPMN participants are transformed into the SCA components. To interact with each other the components expose provided ports, i.e., called services, and consume provided services by means of references, i.e., required ports. They are connected to each other with the help of the wires (i.e., connectors). Since, the BPMN participants play both consumer and provider roles in the collaboration s that it contains a single conversation, then two callbacks are defined for the services and references for the generated SCA components in t . They are configured to interact with the OS wire. However, the produced target SCA assembly model t contains two different wires representing the separation of the service interaction logic. Finally, each component contains the implementation of the business process realizing the participant orchestrations. This allows appropriate technologies to be used for each component. It has to be noticed that we do not make any recommendation on the use of any implementation technology.

For the reminder, consider that the model s has evolved to s , and that a transformation has previously generated the model t from s . Then, what we require from the model synchronization is that it produces the target model t in Figure 1. In particular, it has to preserve the structural correctness of the used metamodels and consistently translate the alteration of the BPMN collaboration model into an update on the wiring topology of the SCA assembly model. Those models are respectively conform to the constructs of the BPMN collaboration metamodel and SCA assembly metamodel presented in Figure 2. In this figure, the simplified UML meta-class diagrams define the abstract syntax of the graphical language subsets in which the models are expressed. They represent the types of the assorted model objects, and the models are conform to a metamodel.

B. Requirements of the Model Synchronizer

Before specifying the synchronization and its details, we need to formalize the problem of the model synchronization. Following Antkiewicz [START_REF] Antkiewicz | Generative and transformational techniques in software engineering ii[END_REF], let S and T be two metamodels at different levels of abstraction (e.g., the BPMN and the SCA) and C ⊆ (S × T ) be the consistency relation established between them. This relation captures the BPMN-to-SCA conceptual mapping that we introduce in the next section. Let a source model s, i.e., which conforms to S, and a target model t, i.e., which conforms to T , be consistent (i.e., synchronized) with respect to the relation C, i.e., (s, t) ∈ C. Given a source update U ∆S that alters s to s , the problem is to translate the update of the source U ∆S into a consistent update of the target U ∆T , such that the application of both updates results in consistent models, i.e, (U ∆S (s), U ∆T (t)) ∈ C. The synchronizer that provides this function is defined as follows:

Definition 1 (Synchronizer): A unidirectional incremental source-to-target synchronizer using update translation is a partial function of type S × ∆S × T → T . For s ∈ S, U ∆S , t ∈ T and (s, t) ∈ C it determines U ∆T such that (U ∆S (s), U ∆T (t)) ∈ C and then computes t = U ∆T (t).

The ∆S (resp., ∆T ) is an abbreviation for the update types on the models that conform to S (resp., T ). They represent the space of all partial functions S S (resp., T T ). To make the model transformation effectively incremental, we use the socalled update translation operator [START_REF] Antkiewicz | Generative and transformational techniques in software engineering ii[END_REF]. This operator takes as a parameters the previously transformed models and the update of the source model U ∆S . It enforces the translation U ∆S into U ∆T not through a model translation (i.e., a diff-based method [START_REF] Konemann | Model-independent differences[END_REF]), but by synchronizing in-place (i.e., computing U ∆T (t)) the existing target model t with the updated s . The reason is that in the case where U ∆S is small, generally, it corresponds to a small target update U ∆T , and the performance savings for the computation of t are expected to be high [START_REF] Antkiewicz | Generative and transformational techniques in software engineering ii[END_REF]. Taking into account a small fractions of source and target models, the effort to determine U ∆T and compute t = U ∆T (t) should be much less than to compute a model translation from s (i.e., as a function of type S → T ). The speedup of the incremental model transformation results in a reasonable decoupling from the source model size [START_REF] Giese | From model transformation to incremental bidirectional model synchronization[END_REF]. A discussion of the properties of such a synchronizer can be found in [START_REF] Xiong | Towards automatic model synchronization from model transformations[END_REF].

C. The BPMN-to-SCA Conceptual Mapping

At a business level with a Service Dominant Logic, the processes are focused on the services composition in a business driven-fashion (i.e., the orchestration process), and in that sense the business services become process activities. Moreover, the processes become composite services that orchestrates other business services. With the BPMN, the business services can be modeled by participant constructs with explicit process definitions, and their tasks specify the business service interactions. For a modeling purpose, we consider that the (core) subset of the BPMN constructs shown in Figure 2 is sufficient to capture the service orchestration concepts. To design the service networks as BPMN collaborations, we make the following definition: Definition 2 (Source Core BPMN Collaboration Model): A source core BPMN collaboration model, i.e., assimilated to a single collaboration, is a tuple (P, A , A , F , M, U ) where P is a set of participants which can be partitioned into disjoint sets of send tasks A , receive tasks A , A = (A ∪ A ) is the set of interaction tasks, F ⊆ ∪ p∈P (Ap × Ap) is a sequence flow relation between the tasks, M ⊆ ∪ p,p ∈P (A p × A p ) is a conversation relation, and U ⊆ (P × A) is a process relation.

In this definition, we intentionally hide the BPMN message flows between the interaction tasks since they can be subsumed by the conversation relation. We also consider the minimal well-formedness requirements on the process structure, e.g., there is a unique start event, there is one or more end events, and every interaction task is on a path from the start event to an end event. When mapped to the SCA, the business services become components with published remote interfaces. A SCA assembly is defined below. Definition 3 (Canonical SCA Assembly Model): A canonical SCA assembly model, i.e., assimilated to a single composite, is a tuple

(N , O , O , Q , Q , W, K) where N is a set of components which can partitioned into disjoint sets of services O , references O , service callbacks Q , reference callback Q , implementations K, and W ⊆ (O × O ) is a wire relation.
We refer to [START_REF] Dahman | Generation of Component Based Architecture from Business Processes: Model Driven Engineering for SOA[END_REF] for detailed structural requirements on a SCA model that can be expressed in term of interface equivalence and inclusion [START_REF] Léger | Reliable Dynamic Reconfigurations in a Reflective Component Model[END_REF]. Also, the readers can find there, a classification of the conceptual mapping rules between the core BPMN collaboration and the SCA meta-classes of Figure 2 and their associations. Table I presents a non-exhaustive list of those rules. Summarily, it defines an explicit mapping between the BPMN types and the SCA types. The SCA composite modularize and compose the business functions (i.e., contained in components) in a manner that is decoupled from their implementations. Consequently, the conversations between the BPMN participants can map to the SCA wires. Likewise, the processes map to the component implementations. We mainly focus on the control and message flow, and put the data flows out of this article scope. In the following, we introduce the correctness checking of the model updates propagated by the analysts. In the SCA, it is necessary to differentiate the constructs that are used to expose services, from those used for the service consumption. Refer to Section III-B for the detailed explanations on this mapping.

III. INCREMENTAL MODEL TRANSFORMATION

In the previous section, we have shown that the considered models are assorted collections of typed objects and links among them. In this section, we introduce our incremental model transformation framework that uses graph rewritings.

In Definitions 2, the relation F defines a directed graph over the process task set A, and the relation M defines a directed graph over the tasks of the interacting participant.

Analogously, a SCA assembly can be seen as a directed graph of components linked through the relation W given in Definitions 3. Thus, a core BPMN collaboration model and a canonical SCA assembly model can be uniformly represented by directed graphs. We have made this choice for various reasons. The Labeled nested typed rooted graphs [START_REF] Biermann | Precise Semantics of EMF Model Transformations by Graph Transformation[END_REF] provide an intuitive, mathematically well-understood and general formalism with a tool support to represent the model structures. The edges in a graph are used to represent all kinds of relations between the model objects that are represented by the nodes given in Definition 4. Each node and each edge has a label and a type that unambiguously identify the objects in each model. Nesting is used as a mean to reduce the graph complexity, by allowing nodes to contain other nodes.

Definition 4 (Model Assimilated to a Graph): Let a model be a set of objects and links that can be partitioned into disjoint sets of node identifiers V and edge identifiers E. It is assimilated to a tuple (V, E, B, Y, I, ⊥, label, type, source, target, parent, child) where B is the set of node labels, Y is the set of nodes and edge types, I a set of indexes for the ordered object nesting, ⊥ is a root node identifier (i.e., the model container), and the functions label

: V → B, type : V ∪ E → Y, source, target : E → V, parent : V → V, child : V → V × I define the graph structure. (label(⊥) = type(⊥) = parent(⊥) =⊥)
The Figure 3 Through the case study and the previous definitions, we have introduced a graph structure to describe the source and the target models. In the next section, we explain how the updates on the considered models are expressed with the help of the conditional graph rewriting.

A. Conditional Graph Rewriting

The conditional graph rewriting [START_REF] Giese | From model transformation to incremental bidirectional model synchronization[END_REF], [START_REF] Wermelinger | A graph based architectural (Re)configuration language[END_REF] approaches has been intensively explored for expressing software artifacts updates. In this paper, we are particularly interested in treating complex sequences of graph production as model updates. However, in order to guarantee the correctness of a model update there is no alternative than to reduce its granularity into primitive updates. Otherwise, the problem becomes unsolvable, as it is inherently compounded with the combinatorial changes of the model's object patterns. An update describes the change of model's internal structure. We consider that the application of a structural model update correspond to the execution of a sequence of primitive graph productions such as node and edge additions, removals, relocations operations [START_REF] Mens | Transformational Software Evolution by Assertions[END_REF]. For example, Table II shows a list of such primitive operations. One way for obtaining a sequence of primitive update operations is by recording editing operations performed by the business analysts on the BPMN models. (v,b,y,v ,i Sets the target of the edge e from v to v setIndex (v, i, i , v ) Sets the index of the node v from i to i in the parent node v

For instance, an addition of a process fragment into a BPMN collaboration model can be seen as a composite production of several graph productions (i.e., primitive operations). For example, the Figure 4 depicts the operations that produce the models of Figure 3. The graph productions U ∆S construct the graph G s representing the source core BPMN collaboration model s. The graph productions U ∆T construct the graph G t representing the target core SCA assembly model t. Consider the operation addN ode(5, SOSR, SendT ask, 3, init) in U ∆S . It adds the send task node to the process P 1, and for example, insertEdge(17, CL1, ConversationSource, 16, 5) inserts an edge between the conversation OS and the former SOSR send task. Note that we assume the well-behavedeness of the updates propagated by the business analysts. It means that the graph production on a core BPMN collaboration model are consistent with the behavioral requirements as defined in [START_REF] Van Der Aalst | Service Interaction: Patterns, Formalization, and Analysis[END_REF].

B. Consistency Management

In Section II-B, we stated that a consistency relation, denoted C, has to be established between the subsets of BPMN and SCA metamodels (i.e., the model object types). It is guaranteed by a first transformation and should be preserved through the change propagation. In practice, the relation C partially covers S or T because the BPMN and the SCA are conceptually different. This means that, when the transformation take place, only the BPMN objects with types that has proper conceptual mapping into the SCA types are transformed. For example, in Figures 1 and3 only the BPMN constructs that specify service interactions are transformed into elements of the core SCA assembly model. The other process constructs such as events and sequence flows (i.e., see Figure 2) are not relevant in the generation of the canonical SCA topology [START_REF] Dahman | Generation of Component Based Architecture from Business Processes: Model Driven Engineering for SOA[END_REF]. For this purpose, we introduce an explicit structural correctness relation between the node and edge types of the assorted models. This relation should be used for the assessment of the graph production application.

Definition 5 (Structural Correctness):

The structural correctness for a model assimilated to a graph, i.e., given in Definition 4, is a binary relation

Z = {(y, y ) ∈ Y × (Y∪ ⊥) | ∃v, v ∈ (V∪ ⊥), i ∈ I, type(v) = y ∧ type(v ) = y ∧ cons(y) = y ∧ child(v ) = (v, i)} ∪ {(y, y ) ∈ Y × Y | ∃e ∈ E, v, v ∈ V, i ∈ I, type(e) = y ∧ type(v) = y ∧ type(v ) = y ∧ cons(y) = y ∧ cons(y ) = y ∧ (source(e) = v ∨target(e) = v) ∧ child(v ) = (v, i)} ∪ {(⊥, ∅)} where cons : Y → (Y ∪ ⊥)
is the constraint function between the model types.

For example, Table III shows the structural correctness relations for a core BPMN collaboration s and a canonical SCA assembly models t as tuples of the model types defined in Definitions 2 and 3. The relations Z s and Z t express the imbrications between the types depicted in Figure 2, or the associations between them, i.e., their names are abbreviated in the table. For instance, (P art., Collab.) in Z s means that all node typed with P articipant must be contained in nodes typed with Collaboration. Also, (W.T ar, Serv.) and (W.Sour., W.) in Z t mean that edges typed with W ireT arget should have nodes with Service type as a source and a W ire as target.

Furthermore, to assess a consistent incremental model transformation each node or edge type must hold in the consistency relation C. This relation is given in Definition 6. It is the invariant of the transformation between the source and target models. The simplified consistency relation C shown in Table III transcribes the BPMN-to-SCA conceptual mapping rules presented in Table I. For example, the tuple ((Conv., Collab., ∅), (W ire, Composite)) mean that source nodes typed with Conversation and contained in a collaboration should be

{((y, y , i), (y , y )) ∈ (Ys × Ys × Is) × (Yt × Yt) | (y, y ) ∈ Z s ∧ (y , y ) ∈ Z t ∧ map(y, i) = (y , i) ∧ map(y , i ) = (y , i )}
where map : (Y s × I s ) → (Y t × I t ) is the partial function that conceptually maps the model types.

Note that not all the BPMN tasks are straightly mapped to the SCA ports. In the SCA, the component ports are differentiated into services or references [START_REF]SCA Assembly Model Specification 1.1, Open SOA[END_REF]. Each of them characterizes the direction of the first exchanged message between two components. The invoker of the first service call through a reference is considered to be the consumer of a service of another (provider) component. Thus, in order to correctly compose the SCA components that play both provider and consumer roles (i.e., with callbacks), it is necessary to determine which BPMN task sends the first and the last messages. A simple static analysis of the process flow is considered to distinguish tasks by outgoing or incoming message interactions with the other participants. For this purpose, we define an index function as ∀p,

p ∈ P, ∃a ∈ A p , a ∈ A p , (a, a ) ∈ M we have index(a) = init, if a ∈ A p | a ∈ prev * (a), and index(a) = f in, if a ∈ A p | a ∈ next * (a). The functions denoted prev * (a) = {a ∈ Ap | (a, a ) ∈ F * } and next * (a) = {a ∈ Ap | (a, a ) ∈ F * }
give the set of all direct and transitive predecessors and successors of the task a, where F * is the reflexive transitive closure of F.

By introspecting the indexes of the interaction tasks, it is possible to find the tasks which capture the service interaction points. A first receive task, i.e., with an index "init", is mapped to a service. This is expressed by the tuple ((SendT ask, P roc., init), (Ref., Component)) in C. Accordingly, a first send task maps to a reference. Obviously, the processes can contain a range of other send tasks (resp., receive tasks) after the first receive task (resp., a first service task) to interact with the same participant. In this case, a send task (resp., a receive task) with an index "fin" is mapped to a callback and it is associated with the first mapped reference (resp., the first service), i.e., ((SendT ask, P roc., f in), (Serv.Callb., Serv.)). The other tuples such ((Conv.Sour., SendT ask, init), (W.Sour., Ref.)) and ((Conv.T ar., Conv., ∅), (W.T ar., W.)) capture the mapping between edges that are attached to Conversation and W ire.

Since the relation C is not functional, then, there maybe multiple canonical SCA transformations of the same BPMN model, and different BPMN models can be implemented by the same SCA model. Also, the transformation may results in empty target models due to the lack of the source model expressiveness. In order to preserve the transformation execution context, we introduce a binary relation between the identifier of the related models as

D = {(⊥s, ⊥t)} ∪ {(v, v ) ∈ Vs × Vt | ∃v ∈ Vs, i ∈ Is, v ∈ Vt | labels(v) = labelt(v ) ∧ childs(v) = (v , i) ∧ childt(v ) = (v , i)∧ ((type s (v), type s (v ), i)), (type t (v ), type t (v ))) ∈ C} ∪ {(e, e ) ∈ E s × E t | ∃v, v ∈ V s , v , v ∈ V t , i, i ∈ I s | label s (e) = label t (e ) ∧ source s (e) = v ∧ target s (e) = v ∧ source t (e ) = v ∧ targett(e ) = v
∧ ((types(e), types(v), i), (typet(e ), typet(v ))), ((types(e), types(v ), i ), (typet(e ), typet(v ))) ∈ C}. It is used by our trace-aware synchronizer for the incremental transformation. For example, consider the transformation execution context of Figure 4. This relation represents the structural correspondence between the BPMN model and its related SCA model of Figure 3.

C. Model Synchronization Algorithm

According to the requirement of Definition 1, let a target canonical SCA assembly model t being previously obtained from a transformation of source core BPMN collaboration model s. Given a well-formed production sequence on the source model, i.e., U ∆S , that alters s to s , first, our synchronizer locates the corresponding constructs in the transformation execution context D that are affected by each change operation δ in U ∆S . The synchronizer, shown in Algorithm 1, works by translating the primitive update operations on s into updates of the target SCA model t. Then, with the identified constructs correspondence it translates the operation δ (i.e., given in Table II) into a well-formed update U ∆T on the target w.r.t consistency relation C. Finally, rather than "executing the entire transformation afresh", the synchronizer computes inplace a new model t (i.e., (U ∆S (s), t ) ∈ C) as an alteration of t by applying the obtained U ∆T .

To illustrate the synchronization algorithm, consider two models {⊥ s } and {⊥ t } that are synchronized, and a transformation context D = {(⊥s, ⊥t)}. Then, given the update operation sequence U ∆S of Figure 4 that produces the BPMN model s of Figure 3, the operator translates it into the well-formed update operation U ∆T sequence for t in the same figure. For instance, the operation addN ode(5, SOSR, SendT ask, 3, init) on s is translated to the operation addN ode(4, SOSR, Ref erence, 2, init) on t, and D is updated with the couple [START_REF] Levi | A goal-driven approach to enterprise component identification and specification[END_REF][START_REF] Chen | From software architecture analysis to service engineering: An empirical study of methodology development for enterprise soa implementation[END_REF] in the line 1 of the Algorithm 1. However, when an operation adds a node with a type that does not hold in the consistency relation such as addN ode [START_REF] Dahman | Generation of Component Based Architecture from Business Processes: Model Driven Engineering for SOA[END_REF]E1,EndEvent,[START_REF] Wermelinger | A graph based architectural (Re)configuration language[END_REF][START_REF] Wermelinger | A graph based architectural (Re)configuration language[END_REF], D is updated with (7, ∅). It means that this object has no counterpart SCA construct. Second, consider the update sequence U ∆S of Figure 5 for s of Figure 1 in which the addition of the receive task ROSR is similarly translated onto an addition of a callback of the perviously generated reference SOSR in U ∆T . The transformation context translation is updated with the couple [START_REF]Yaoqiang bpmn editor[END_REF][START_REF] Giese | From model transformation to incremental bidirectional model synchronization[END_REF] of those object identifiers. Also, updating of the index of ROSR receive task in U ∆S with the operation is translated into a deletion (i.e., line 2 of the Algorithm 1) of the corresponding reference callback and the addition of the service ROSR to the component SU P in the sequence U ∆T . Finally, without disrupting the core SCA assembly model consistency and completely regenerating the model t of Figure 1, the system architects can rapidly assess the necessity to propagate the changes to the SCA implementations. addNode (11, ROSR, ReferenceCallback, 4, 3) addNode (12, SOSR, ServiceCallback, 7, 3) D = { (⊥ s ,⊥ t ), (1,1), (2,2), [START_REF] Wermelinger | A graph based architectural (Re)configuration language[END_REF][START_REF] Wermelinger | A graph based architectural (Re)configuration language[END_REF], (4,∅), [START_REF] Levi | A goal-driven approach to enterprise component identification and specification[END_REF][START_REF] Chen | From software architecture analysis to service engineering: An empirical study of methodology development for enterprise soa implementation[END_REF], (6,∅), (7,∅), (8,∅), [START_REF] Antkiewicz | Generative and transformational techniques in software engineering ii[END_REF][START_REF] Levi | A goal-driven approach to enterprise component identification and specification[END_REF], [START_REF] Biermann | Precise Semantics of EMF Model Transformations by Graph Transformation[END_REF][START_REF] Dumas | Service-enabled process management[END_REF], (11,∅), [START_REF] Mens | Transformational Software Evolution by Assertions[END_REF][START_REF] Dahman | Generation of Component Based Architecture from Business Processes: Model Driven Engineering for SOA[END_REF], (13,∅), (14,∅), (15,∅), [START_REF] Konemann | Model-independent differences[END_REF][START_REF] Lopes | Generating transformation definition from mapping specification: Application to web service platform[END_REF], [START_REF] Xiong | Towards automatic model synchronization from model transformations[END_REF][START_REF] Antkiewicz | Generative and transformational techniques in software engineering ii[END_REF], [START_REF] Léger | Reliable Dynamic Reconfigurations in a Reflective Component Model[END_REF][START_REF] Biermann | Precise Semantics of EMF Model Transformations by Graph Transformation[END_REF] This section described our update translation operator for managing and re-establishing the structural consistency. Moreover, adopting a MDE approach to build the service-enabled software solutions may require the usage of different technologies to implement the SOA. Also, the composite applications can contain both business services newly created for the application, and business function from existing system applications, reused as part of the composition. Due to lack of space, we intentionally put the specification of those structural constraints (e.g., the prevention of relevant component update, or the choice on the implantation technology) out of the scope of this paper.

D. Model Synchronization Implementation

For a proof-of-concept prototype, the synchronizer has been successfully implemented as an extension to the Yaoqiang BPMN Editor [START_REF]Yaoqiang bpmn editor[END_REF]. This editor is compliant with BPMN 2.0 specification [START_REF]Business Process Model and Notation (BPMN) 2.0, Beta 1[END_REF] and it is based on the JGraph [START_REF]Yaoqiang bpmn editor[END_REF] graph visualization library. We added a filter that logs the primitive graph editing operation which manipulate the BPMN construct types shown in Figure 2. We have also implemented a removing redundancy algorithm that transforms a sequence of graph structure operations into a normalized form as specified in [START_REF] Mens | Transformational Software Evolution by Assertions[END_REF]. With the synchronization algorithm, we obtain a graph editing operation sequence that manipulates SCA constructs types. This sequence again enforced with the JGraph library is applied to another graph structure representing the SCA assembly model. The development of an editor to visualize the resulting SCA model is a work in progress.

A fundamental transformation law is the determinism. In our case, the transformation is modeled as a mathematical function. It means that given the same pair of models, the update translation algorithm always returns the same proposed modification. The synchronizer given in Algorithm 1 propagates only the operations that synchronize the SCA model with the BPMN model. With these properties, we can conclude that the synchronizer is terminating and locally confluent. We refer the reader to [START_REF] Mens | Transformational Software Evolution by Assertions[END_REF], [START_REF] Giese | From model transformation to incremental bidirectional model synchronization[END_REF] for further discussions on the scalability measurements. The current implementation checks for the applicability conflicts of our primitive change operations. Evidently, that there are some limitations inherent to any operation-based approach in comparison with a statebased one. The introduced operations can be composed to give rise to model update types with enhanced semantics for the users (e.g., splitting a service, assigning a task to a component through their behavioral concerns). However, we restricted our presentation to the structural correctness. For example, the semantic that means that a business process update is a modification in the service interaction pattern is out of the scope of this paper.

IV. RELATED RESEARCH

The BPM [START_REF] Dumas | Service-enabled process management[END_REF] used within the MDE approaches [START_REF] Dahman | Generation of Component Based Architecture from Business Processes: Model Driven Engineering for SOA[END_REF], [START_REF] Lopes | Generating transformation definition from mapping specification: Application to web service platform[END_REF] often results in SOA models that are automatically transformed from the business process models. However, by the time a business process evolution must be implemented in the IT infrastructure on the opportunity to capitalize on the previous SOA implementations may be lost. Further, responding to the business process evolution is still a manual practice. In the SOA space, the MDA [START_REF] Gitzel | Model-driven Software Development Using a Metamodelbased Extension Mechanism for Uml[END_REF] enables business level functionalities to be modeled with the UML [START_REF] Ravichandar | Morpheus: Semantics-based incremental change propagation in soabased solutions[END_REF]. Certainly, the SOA models can be expressed using the UML [START_REF] Stahl | Model-Driven Software Development[END_REF]. However, as the UML is neither fully service-centered, nor process-oriented [START_REF] Ravichandar | Morpheus: Semantics-based incremental change propagation in soabased solutions[END_REF], it is necessary to provide alternative design methods. The standard BPMN [START_REF]Business Process Model and Notation (BPMN) 2.0, Beta 1[END_REF] offers the sufficient conceptual information needed to specify a service-enabled software solution in cross-organizational settings. In order to define the business process logic of each partner pertaining to a domain being modeled, the BPMN refers to a service orchestration [START_REF] Papazoglou | Serviceoriented computing: State of the art and research challenges[END_REF] as a participant's private process. However, it neither specifies the roles (e.g., service consumer or provider) that participants are expected to play in a business collaboration, nor foreshadow the architecture of the supporting SOA implementation. The SCA specifications [START_REF]SCA Assembly Model Specification 1.1, Open SOA[END_REF] provide a framework for creating software solutions in a multi-language and multi-platform environment that are organized in a SOA. Unlike the BPMN, the SCA describes the system configuration (or run-time architectures) and its deployment. It is supported by an integration middleware that provides the broker and the binding mechanisms which follow the SOA principles.

The need for synchronizing multiple heterogeneous software languages in multi-level SOA development. The multilevel incremental change propagation and the change impact analysis in the SOA development was studied in [START_REF] Zhang | Variationoriented analysis for soa solution design[END_REF], [START_REF] Ivkovic | Tracing evolution changes of software artifacts through model synchronization[END_REF]. Separately, other approaches have studied the reconfiguration on the component models [START_REF] Wermelinger | A graph based architectural (Re)configuration language[END_REF], [START_REF] Fiadeiro | A Model for Dynamic Reconfiguration in Service-Oriented Architectures[END_REF]. However, to the best of our knowledge only the general model synchronization frameworks [START_REF] Antkiewicz | Generative and transformational techniques in software engineering ii[END_REF] was used for the consistency management among those heterogenous models. Those frameworks can guarantee the consistency between software artifacts that are expressed in different languages. However, they require to manually write the synchronization code to deal with each update kind on each of the assorted models [START_REF] Xiong | Towards automatic model synchronization from model transformations[END_REF]. Compared to these approaches, our synchronizer automatically extracts the synchronization informations from the previous transformation context and does not require the users to write code to handle for model modifications.

The term "synchronization" sometimes refers to the approaches to differencing and merging models that conform to the same metamodel [START_REF] Konemann | Model-independent differences[END_REF]. These approaches can be used in the MDE to merge models with multiple concurrent updates. Unfortunately, they lack computations with reasonable decoupling from the model sizes [START_REF] Giese | From model transformation to incremental bidirectional model synchronization[END_REF]. Moreover, the languagespecific syntactic consistency of the assorted model types can be formally expressed in OCL-compliant notation in the transformation code [START_REF] Ivkovic | Tracing evolution changes of software artifacts through model synchronization[END_REF]. However, this makes the synchronization code much complex, particularly, when not all the source metamodel maps to the target one. In this case, the generality of the incremental model synchronization system cannot fit in here. The promising formal conditional graph rewriting approaches [START_REF] Wermelinger | A graph based architectural (Re)configuration language[END_REF], [START_REF] Giese | From model transformation to incremental bidirectional model synchronization[END_REF] has been intensively explored to express automatic software artifacts transformations in a uniform way. However, the change propagation across heterogeneous software models still remains as an open problem [START_REF] Xiong | Towards automatic model synchronization from model transformations[END_REF]. In [START_REF] Mens | Transformational Software Evolution by Assertions[END_REF], the composite graph productions were used to express the software evolutions. However, this technique is mainly focused on the homogeneous model transformation, i.e., where the source and target models conform to the same metamodel. Our work performs a more through investigation on the heterogeneous model synchronization while preserving the respective SCA and BPMN model consistency.

V. SUMMARY AND OUTLOOK

The automation of a (business process driven) system engineering that adheres to a SOA architectural style needs to go beyond of identifying the system configurations that have to be implemented by the developers. Since this is now performed through a MDE approach, what is required from the business analysts is that they design the process activities and their dependencies with the external business services as task centric flows. In the first development stages, the BPM often results in models that are conceptually different the SOA implementations. In order to bridge this gap, we introduce a BDD method in which we start with the business requirements contained in BPMN models and work our way towards a seamless transformation into software architectures that fulfill the business goals. In summary, our approach aims at maintaining the alignment between a (source) BPMN model and a (target) SCA model which is organized in a SOA. When a target model has been generated (and implemented) and that the business requirements evolve, our synchronizer enforces automated in-place translations of correct updates on the BPMN model into correct operations on the SCA. Then, without disrupting the system structural consistency and rather than executing the entire transformation afresh, the system architects can assess the necessity to propagate the design changes to the run-time implementation. Finally, the IT developers can synchronize the application code in order to maintain the Business/IT alignment. Furthermore, since separation occurs at the level of models rather than at the level of opaque code, this enables quick and localized evolutions of the SOA implementations in response to the business changes.

The experimental results are encouraging. A proof-ofconcept prototype that supports the synchronization algorithm have been successfully implemented. The approach seems very promising, but still needs to be validated in a real-scale case study and tool. The integration of our update translation operator in a previously developed ATLAS Transformation Language [START_REF] Lopes | Generating transformation definition from mapping specification: Application to web service platform[END_REF] chain for the Eclipse SOA Tools Platform [START_REF] Dahman | Generation of Component Based Architecture from Business Processes: Model Driven Engineering for SOA[END_REF] is in development. Furthermore, the full round-tripping between business processes and the software architectures is essential to rapidly realign the process to accommodate changing business conditions. Consequently, a technical challenge is the bidirectional transformation of their concurrent updates. Likewise, we have to consider update to both the business and IT architectures via pattern-based techniques. Striving for further alignment, and making SOA development more tractable to reconfigure architectures without disrupting the functional capabilities of the implementations remain as a future work. Of course, the BPMN expressiveness is higher than this of the SCA, because there is no mean of control-flows between the SCA components. The BPMN behavioral aspects (e.g., tasks, gateways, flows) have no direct counterparts in the SCA. Therefore, we can enlarge our approach by transforming BPMN control-flows and message interactions to non-standard SCA annotations.

Fig. 1 .

 1 Fig. 1. Examples of BPMN collaboration and SCA assembly diagrams.

Fig. 2 .

 2 Fig. 2. BPMN and SCA assembly graphical constructs and metamodels.

Fig. 3 .

 3 Fig. 3. Graphs for BPMN collaboration and SCA assembly models.

)

  Adds the node v of a type y in the parent node v with a label b and an index i insertEdge(e, v, v , b, y) Inserts the edge e of a type y with a label b between the nodes v and v dropN ode(v, v ) Drops an existing node v from the parent node v deleteEdge(e, v, v ) Deletes an existing edge e between the nodes v and v setLabel(v, b, b ) Sets the label of the node v from b to b setSource(e, v, v )Sets the source of the edge e from v to v setT arget(e, v, v )

Fig. 4 .

 4 Fig. 4. Primitive graph productions for the models of Figure 3.

Fig. 5 .

 5 Fig. 5. Composite graph productions for the models of Figure 1.

Target Canonical SCA Assembly Models Source Core BPMN Collaboration Models SUPlier CUStomer Order Status DNCOL CUS SUP

	P1	B1	B2	P2
	SF1		SF3
		CL1 CL2
	SF2	SF4
		E1	E2

Receive Order Status Request Send Order Status Request SF6 SF5 CL3 CL4 Receive Order Status Response Send Order Status Request SUPlier CUStomer DNCOL CUS SUP

	P1	B1	B2	P2
	SF1		SF3
		CL1 CL2
	SF2		SF4
		E1

Receive Order Status Request Send Order Status Request SF6 SF5 CL3 CL4 Receive Order Status Response Send Order Status Request Order Status REQuest Order Status RESponse

	s'	Dealing Network Collaboration	Dealing Network Collaboration	s''
									E2
	t'								t''
			SOSR		ROSR	ROSR		SOSR ROSR	SOSR
		P1	ROSR	OS	SOSR	P2	P1	OSERES OSEREQ	P2

TABLE I CONCEPTUAL

 I MAPPING RULES BETWEEN THE BPMN AND THE SCA.

	BPMN Meta-class	SCA Meta-classes
	Collaboration	Composite
	P articipant	Component
	SendT ask	Ref erence or ServiceCallback
	ReceiveT ask	Service or Ref erenceCallback
	P rocess	Implementation
	Conversation	W ire
	ConversationSource	W ireSource
	ConversationT arget	W ireT arget

TABLE II PRIMITIVE

 II GRAPH PRODUCTIONS.

	Primitive Change Operation	Description
	addN ode

TABLE III SIMPLIFIED

 III STRUCTURAL CORRECTNESS AND CONSISTENCY RELATIONS. Core BPMN collaboration structural correctness: Zs (Collab., ⊥), (P art., Collab.), (P roc., P art.), (SendT ask, P roc.), (Rec.T ask, P roc.), (Seq.F.Sour., Int.T ask), (Seq.F.T ar., Int.T ask), (Conv., Collab.), (Conv.T ar., Conv.), (Conv.Sour., Conv.), (Conv.Sour., Int.T ask), (Conv.T ar., Int.T ask), (⊥, ∅) Canonical SCA assembly structural correctness: Zt (Compos., ⊥), (Compon., Compos.), (Impl., Compon.), (Ref., Compon.), (Serv., Compon.), (Serv.Callb., Service), (Ref.Callb., Ref.), (W., Compos.), (W.T ar., W.), (W.Sour., W.), Rec.T ask, P roc., f in), (Ref.Callb., Ref.)), ((SendT ask, P roc., f in), (Serv.Callb., Serv.)), ((Conv.Sour., Conv., ∅), (W.Sour., W.)), ((Conv.T ar., Conv., ∅), (W.T ar., W.)), ((Conv.Sour., SendT ask, init), (W.Sour., Ref.)), ((Conv.T ar., Rec.T ask, init), (W.T ar., Serv.)), ((⊥, ∅, ∅), (⊥, ∅)) mapped to wires that are contained in a composite. Actually, the types in the respective BPMN or SCA models of the previous figures hold in the correctness relations: Z s and Z t . The consistency relation established between two models s= (..., Y s , I s , ...) and t= (..., Yt, It, ...) (i.e., assimilated to a graphs) is a relation C=

	(W.T ar., Serv.), (W.Sour., Ref.), (⊥, ∅)
	BPMN-to-SCA consistency relation: C
	((Collab., ⊥, ∅), (Compos., ⊥)), ((P art., Collab., ∅), (Compon.,
	Compos.)), ((P roc., P art., ∅), (Impl., Compon.)), ((Conv.,
	Collab., ∅), (W., Compos.)), ((SendT ask, P roc., init), (Ref.,
	Component)), ((Rec.T ask, P roc., init), (Ser., Component)),
	((Definition 6 (Consistency Relation):