## 4 Connector Behavior Specification
### Using ALF to Specify Connector Behavior  
In UML, _Behavior_ is an abstract classifier, and its specializations are _StateMachine_, _Interaction_, _Activity_, and _OpaqueBehavior_. Therefore, these are the types of behaviors that can be associated with the connectors using the _contract_ role. We propose using activities specified in ALF for connector behavior specification. ALF is a surface notation for fUML. It can be used to declare a model's structural and behavioral parts using textual notation. fUML is a subset of UML, which only includes a specific set of UML concepts to allow executable models. Because ALF is a surface notation for fUML, complete models specified using ALF are also limited to the subset of UML covered by fUML. However, there are other intended uses for ALF. While ALF maps to the fUML subset to provide its execution semantics, in case the execution semantics is not required, ALF is also usable in the context of models not restricted to the fUML subset [4; 26]. By using ALF only to specify the coordination behaviors of the enhanced connectors, we allow other parts of the model to use the UML concepts outside of the fUML context. ALF provides significant advantages for the specification of activities. When we use graphical notation, the specification of even simple behaviors can become quite complex, hard to understand, and maintain. We can denote the same behaviors using ALF in a more readable and maintainable format. Figure 7, an example included in the ALF specification [4], shows the distinction between the two formats. The figure shows the implementation of the same quick sort algorithm using both ALF notation and activity diagram notation. In our previous study [7], we proposed using _Interactions_ specified by sequence diagrams for connector behavior specification. Since using imperative logic for the merge behaviors was not feasible with sequence diagrams, we have proposed using the target programming language to specify the behaviors for merging requests and replies. In this study, we address this problem by using ALF. The connector behaviors specified using ALF also include the behaviors for merging replies and requests, along with behaviors for routing requests. To define the connector behaviors, we use an _OpaqueBehavior_ element for which we provide the specification using ALF in combination with specific _Properties_ to denote the reply and the request buffers. The OpaqueBehavior allows the connector activity to have additional Properties, making room for stateful connector behaviors. Figure 8 shows an example UML model where we define an enhanced UML connector. Listing 1 shows the body of the OpaqueBehavior developed using ALF for the connector behavior specification. The connector behavior sends incoming requests to all connected providers and then stores the replies from the providers in the single-copy reply buffers (line 3). _OutPort_ denotes the array of providers (e.g., objects \(b\) and \(c\) in the figure). The term _arg_ used in the _ifc.xOp(arg)_ operation call represents the argument of the request. After sending requests to all providers, we execute a reply merge strategy (lines 7-19), in which we merge replies from each provider using integer addition. The _PRV_CNT_ term used in line 10 is a placeholder evaluated as the actual number of providers by the model transformations explained in the upcoming sections. activityQuicksort(inlist:Integer[0.,*]sequence): Integer[0.,*]sequence: { x = list[1]; if(x == null) { return null; else { list1 = list->excluded(1); returnOutksort(list1->selectecta(x<x))-> including(x)-> union(Quicksort(list1->selectb(b>=x))) } } } ```
Figure 8: UML diagram and the UML model for the enhanced connector that sends requests to each provider: (**a**) Composite structure diagram showing the requester, providers, and the enhanced connector. (**b**) UML model showing the connector behavior. Figure 7: The Quicksort algorithm using ALF and graphical notation.