## 5 Model Transformations
### Execution and Implementation of the Model Transformations
(**b**) Updated design: Using an enhanced connector to send requests in round-robin order. In the asynchronous case shown in Figure 24b, we design the connector as an active object which acts asynchronously. In the figure, filled arrows indicate synchronous messages, and unfilled arrows indicate asynchronous messages. Upon receiving an asynchronous message, the connector does not block the requester. When the connector decides on the routing of the message, it also forwards the request to the provider asynchronously. Thus, the connector is not blocked while waiting for a reply from the provider. As a result of describing the order of messaging in both synchronous and asynchronous cases, we showed that using a passive object as a connector in the synchronous case and using an active object as a connector in the asynchronous case allows preserving the semantics of coordination in both cases. ## 9 Relation with Protocol State Machines

UML defines the concept of _ProtocolStateMachines_, similar to the _protocol_ concept in UML-RT [34] and ROOM [12]. ProtocolStateMachines allow the definition of protocols that should be followed when interaction occurs using ports. In this section, we show how enhanced connectors can be used in the presence of ProtocolStateMachines. Figure 25 shows an example ProtocolStateMachine. This ProtocolStateMachine defines the order of operation calls and state changes for reading a file from the disk. The protocol enforces calling the _initialize_ operation first, then calling a series of _read_ operations, and then ending the communication with a _finalize_ operation. When the operations _initialize_, _read_, and _finalize_ are declared in an interface that defines the contract of a port, this ProtocolStateMachine can enforce sending the requests in the specified order. Figure 23: Synchronous and asynchronous handling of requests without using enhanced connectors: (**a**) Synchronous handling of requests. (**b**) Asynchronous handling of requests. Figure 15:0 Synchronous and asynchronous handling of requests using enhanced connectors: (**a**) Synchronous handling of requests using enhanced connectors. (**b**) Asynchronous handling of requests using enhanced connectors. Let us assume that the ProtocolStateMachine shown in Figure 25 is used for reading data from a single disk. Let us also assume that we have three disks in the system, and we want to read the same data simultaneously to increase reliability. We can use an enhanced connector between the requester and three disk managers. The enhanced connector can replicate the read requests to three disks and then compare the data, eventually returning with success to the original requester only if all three read requests return the same data. This example shows how enhanced connectors and ProtocolStateMachines can be used together and indicates that the two concepts are orthogonal concepts that complement each other. However, enhanced connectors and ProtocolStateMachines are not totally independent concepts. In the same scenario using three disks, if the requests are routed in a round-robin style by the enhanced connector, this may cause inconsistencies. We should send the _initialize_ request to all disks before we can route the subsequent _read_ requests to the three disks in round-robin order. Otherwise, we will send _read_ requests to some disks that are not initialized. Likewise, we should replicate the _finalize_ request to all three disks. The above observation indicates that when enhanced connectors are used in the presence of ProtocolStateMachines, the connector behavior specification should satisfy the constraints of the ProtocolStateMachine that bounds the coordination among the connected ports. In this example, we can design the connector to execute different behaviors for the _initialize_, _read_, and _finalize_ requests. Specifically, the connector can use _the multiple destination sender_ behavior for the _initialize_ and _finalize_ requests and _the round-robin requester_ behavior for the _read_ requests.