## 5 Model Transformations
### Execution and Implementation of the Model Transformations  
We developed the Java program _EcTransformer_ to execute the transformations in the required order as shown in Figure 10. We have also experimented with ATL [25] to implement the model transformations before choosing QVTo. Even though ATL could meet our requirements, we preferred QVTo because it was standardized by Object Management Group (OMG), like UML and ALF. However, we had to develop an equivalent method in QVTo for a practical feature of ATL called the _refining mode_. In the refining mode, an ATL model transformation only changes specific elements in the input model, leaving everything else the same. The refining mode of ATL is distinct from the in-place model transformations of QVTo because it saves the output as a different model and does not modify the input model. It is suitable for our needs because we only transform the parts of the input model regarding the enhanced connectors. QVTo does not have the refining mode, but it supports in-place transformations. However, when we use this option, QVTo modifies the input model. We solve this problem by using the Java API of QVTo. We define the transformations as in-place transformations. Therefore, the model transformations modify the input models when we run them manually from inside Eclipse, using QVTo run configurations. However, when the Java program EcTransformer runs them, it takes the in-memory representations of the output models and saves them as different models. Using this method, we can obtain functionality in QVTo equivalent to the refining mode of ATL. ```
1 packageMultiDestRequester_E1{
2//Theinterfaceintheportcontract
3 publicabstractclassXIfc{
4 publicabstractxOp(inarg:Integer):Integer;
5}
6
7//Theconnectorclass
8 publicclassConnector1_ConnectorCls{
9 InPort:RequestPortCls[1..1]orderednonunique;
10 OutPort:XIfc[2..2]orderednonunique;
11 ReplyBuffer:Integer[2..2]orderednonunique;
12
13//Operationforroutingrequestsmergingrepliesfromproviders
14 publicxOp(inarg:Integer):Integer{
15 Integeri=1;
16 for(ifcinthis.OutPort){
17 this.ReplyBuffer[i]=ifc..xOp(arg);
18i++;
19}
20
21//Replymergestargety:
22i=1;
23 Integersum=0;
24 while(i<=2){
25 Integerintval=this.ReplyBuffer[i];
26
27 if(intval!=null){
28 sum=sum+intval;
29//Invalidvaluestoredinthesingleopybuffer
30 this.ReplyBuffer[i]=null;
31}
32i++;
33}
34 returnsum;
35}
36
37@CreatepublicConnector1_ConnectorCls(){
38 Integeri=1;
39 while(i<=2){
40 this.InPort[i]=
41 newRequestPortCls(this);
42i=i+1;
43}
44}
45//Theclassforreceivingandstoringtherequests
47 publicclassRequestPortCls{
48 publicownerConnector:Connector1_ConnectorCls[1..1];
49
50@Create
51 publicRequestPortCls(inc:Connector1_ConnectorCls){
52 this.ownerConnector=c;
53}
54
55 publicxOp(inarg:Integer):Integer{
56//Forwardtherequestoftheconnectorobject
57 returnthis.ownerConnector.xOp(arg);
58}
59}
60}
61}//endpackage

## 6 Example Connector Behaviors

In this section, we present example connectors developed using the proposed method. Besides clarifying the application of the method in different cases, the examples also demonstrate the expressive power of the connector behavior specification method. ### The Round-Robin Requester

The round-robin requester connector coordinates a single requester and multiple providers. It sends each request made by the requester to the providers in a round-robin order and sends the received reply to the requester. Figure 8a shows the composite structure diagram for the E1 model. Listing 3 shows the connector behavior specification. ```
1 Integerresult=this.OutPort[this.Index].xOp(arg);
2 this.Index=this.Index+1;
3 this.Index=this.Index%PRV_CNT;
4 returnresult;
```

Listing 3: Connector behavior specification for the round-robin requester. The behavior uses the integer _Index_ property of the OpaqueBehavior that represents the connector behavior in the E1 model. We initialize the _Index_ property in the E1 model by providing a default value of _IntegerLiteral 1_.