Input-output Conformance Testing for Channel-based Service Connectors

L. Aceto and M.R. Mousavi (Eds.): P A CO 2011 EPTCS 60, 2011, pp. 19– 35 , doi: 10.4204/EPTCS.60.2 c  N. K okash et al. This work is licensed under the Creativ e Commons Attribution License. Input-output Conf ormance T esting f or Channel-based Service Connectors Natallia K okash Farhad Arbab Behnaz Changizi CWI, P .O. Box 94079, 1090 GB Amsterdam, The Netherlands firstName.lastName@cwi.nl Leonid Makhnist Brest State T echnical University , Department of Higher Mathematics, Moskovskaya 267, 224017 Brest, Republic of Belarus Service-based systems are software systems composed of autonomous components or services pro- vided by dif ferent vendors, deplo yed on remote machines and accessible through the web . One of the challenges of modern software engineering is to ensure that such a system behaves as intended by its designer . The Reo coordination language is an e xtensible notation for formal modeling and ex ecu- tion of service compositions. Services that ha ve no prior knowledge about each other communicate through advanced channel connectors which guarantee that each participant, service or client, re- ceiv es the right data at the right time. Each channel is a binary relation that imposes synchronization and data constraints on input and output messages. Furthermore, channels are composed together to realize arbitrarily complex behavioral protocols. During this process, a designer may introduce errors into the connector model or the code for their e xecution, and thus affect the behavior of a composed service. In this paper, we present an approach for model-based testing of coordination protocols designed in Reo. Our approach is based on the input-output conformance (ioco) testing theory and exploits the mapping of automata-based semantic models for Reo to equi valent process algebra specifications. 1 Intr oduction Business process modeling is part of software development lifecycle which is primarily concerned with capturing the behavior of organizational business processes in a form that simplifies their analysis, fos- tering communication with various process stakeholders and helping to identify the requirements for the dev elopment of supporting software. T ypically models are written using some (preferably standard) language or notation such as BPMN or UML diagrams. Once a process model has been constructed, it can be analyzed to uncover logical flaws in a process or optimize its functional or non-functional characteristics [ 26 , 25 ]. While popular high-le v el modeling notations like BPMN or UML are suitable for f ast prototyping and capturing system requirements, they are rather ambiguous and imprecise to be used for rigorous process analysis. Modeling languages should operate on the level of abstraction that allo ws designers to focus on the essence of the problem without being lost in technical details and at the same time provide suf ficient precision and expressi v eness to av oid ambiguities in the model or failure to describe certain important concepts. Multiple ef forts on creating such modeling languages resulted into formalisms such as Petri nets and v arious process algebra-based languages often empo wered with graphical syntax to sim- plify the process of unambiguous system description. These models are more difficult to use compared to high-lev el notations. Howe ver , their handicap of usability is compensated by automated validation and v erification tools that provide po werful support for process analysis and quality assurance. More- 20 Input-output Conformance T esting for Channel-based Service Connectors ov er , various model-based transformation tools have been de veloped for major notations to assist process designers with con verting high-le v el process models into more rigorous ones. Reo [ 3 ] is an e xtensible model for coordination of software components or services wherein comple x connectors are constructed out of simple primitives called channels. A channel is a binary relation that defines synchronization and data constraints on its input and output parameters. By composing basic channels, arbitrarily complex interaction protocols can be realized. Previous w ork shows that most of the behavioral patterns expressible in BPMN or UML notations can be modeled with Reo [ 6 ]. W e hav e also de veloped a set of tools for automated con version of such models to Reo 1 . Each Reo channel has a graphical representation and associated semantics. The most basic semantic model that currently exists for Reo relies on constraint automata [ 9 ]. Action constraint automata [ 22 ] constitute a model that generalizes constraint automata by allowing more detailed observ ations on connector ports. When channels with timed, context-sensiti ve and probabilistic beha vior are used to design a connector , more expressi ve models to represent the semantics of the connector are required [ 4 , 7 , 10 ]. When using just a minimal set of channel types, it may happen that a substantial number of channels are required to construct a circuit with certain behavior . In general, it is not a trivial task to create a connector that implements a certain behavioral protocol. As any laborious process, connector imple- mentation is error-prone and requires v alidation of the connector’ s beha vior . There are se veral tools that can help to detect possible errors in Reo connectors. One of them is the animation engine [ 5 ]. This tool sho ws flash animated simulation of designed connectors and enables quick v alidation of connector designs. Ho we ver , for comple x connectors the number of possible traces is large and they are hard to analyze manually . Moreover , the current implementation of the animation engine is based on coloring semantics and cannot be used for reliable validation of data-dependent connectors. A more efficient analysis of Reo models can be performed with the help of simulation and model-checking tools, both specifically dev eloped for Reo [ 8 , 11 , 20 ] and external [ 24 , 21 ]. For example, simulation tools lpsxsim and ocis from mCRL2 [ 2 ] and CADP [ 19 ] toolsets can be used to visualize ex ecution traces of data-aware Reo networks follo wed by a user . Model checking tools pbes2bool and evaluator can be used to check the v alidity of connector properties expressed in the modal µ -calculus formulae. Both kinds of tools require substantial effort from the designer to analyze simulation traces or cor- rectly e xpress comple x properties using the intricate µ -calculus syntax. Y et another limitation of the aforementioned tools is their inability to analyze actual coordination code or protocol implementations. For example, in the context of the EU FP7 COMP AS project 2 we used Reo to design b usiness pro- cess fragments and v erify their conformance to various requirements e xtracted from compliance docu- ments [ 28 ]. These fragments are further implemented in BPEL and stored in a repository to enable their on-demand retriev al and reuse in service-based systems. While we can v erify the correctness of Reo models in this scenario, we cannot judge the correctness of fragment implementations. In this paper , we e xtend our pre vious work on verification of Reo with model-based testing facilities to automatically deri ve tests from connector specifications and ex ecute them to test service coordination code or protocol implementations. W e enable testing of connector designs gi ven specifications of their expected behavior in the form of constraint automata extended with inputs and outputs. T est generation is based on the ioco -testing theory which uses labelled transition systems (L TS) to represent system spec- ifications, implementations and tests and defines a formal implementation relation called ioco to sho w conformance between implementations and specifications. The encoding of automata-based behavioral semantics for Reo in process algebra mCRL2 is exploited to obtain L TS models suitable for testing Reo. 1 http://reo.project.cwi.nl/cgi- bin/trac.cgi/reo/wiki/Converters 2 http://www.compas- ict.eu/ N. K okash et al. 21 A B A B A B A B A B Sync LossySync FIF O SyncDrain AsyncDrain A B A B C A B A B C Filter T ransfo rm Merger Replicato r Figure 1: Graphical representation of basic Reo channels and nodes T ogether with previously de veloped tools for con verting specifications in high-lev el process modeling notations such as BPMN and UML to Reo, graphical Reo networks can be used as a formal specification of business process models. In this case, Reo connectors are seen as formal specifications of processes and used to automatically deri ve tests to check the quality of process implementations. Since the ioco - testing theory can be used to generate tests gi ven specifications in any language with the L TS-based formal semantics, we can apply it to deri ve tests for any systems specified in Reo. The remainder of this paper is org anized as follows. In Section 2 , we explain the basics of Reo. In Section 3 , we briefly summarize the basics of input-output conformance ( ioco ) testing theory . In Section 4 , we explain how this theory can be used to test Reo. In Section 5 , we illustrate the use of model-based testing tools to analyze Reo connectors. Finally , in Section 6 , we conclude the paper and outline our future work. 2 The Reo Coordination Language Reo is a coordination language in which components and services are coordinated exogenously by channel-based connectors [ 3 ]. Connectors are essentially graphs where the edges are user-defined com- munication channels and the nodes implement a fixed routing policy . Channels in Reo are entities that hav e e xactly tw o ends, also referred to as ports, which can be either source or sink ends. Source ends accept data into, and sink ends dispense data out of their respectiv e channels. Although channels can be defined by users, a set of basic Reo channels (see Figure 1 ) with predefined behavior suffices to imple- ment rather complex coordination protocols. Among these channels are (i) the Sync channel, which is a directed channel that accepts a data item through its source end if it can instantly dispense it through its sink end; (ii) the LossySync channel, which alw ays accepts a data item through its source end and tries to instantly dispense it through its sink end. If this is not possible, the data item is lost; (iii) the SyncDrain channel, which is a channel with tw o source ends through which it accepts data simultane- ously and loses them subsequently; (i v) the AsyncDrain channel, which accepts data items through only one of its tw o source channel ends at a time and loses them; and (v) the FIF O channel, which is an asyn- chronous channel with a buf fer of capacity one. Additionally , there are channels for data manipulation. For instance, the Filter channel alw ays accepts a data item at its source end and synchronously passes or loses it depending on whether or not the data item matches a certain predefined pattern or data constraint. Finally , the T ransfo rm channel applies a user-defined function to the data item receiv ed at its source end and synchronously yields the result at its sink end. Channels can be joined together using nodes. A node can be a sour ce , a sink or a mixed node, depending on whether all of its coinciding channel ends are source ends, sink ends or a combination of both. Source and sink nodes together form the boundary nodes of a connector , allo wing interaction 22 Input-output Conformance T esting for Channel-based Service Connectors { A , B } d A = d B { A , B } d A = d B { A } start { A } d A = 0 { B } d B = 0 { A } d A = 1 { B } d B = 1 { A , B } Sync LossySync FIFO SyncDrain { A } { B } { A , B } e xpr ( d A ) ∧ d A = d B { A } ¬ expr ( d A ) { A , B } d B = f ( d A ) AsyncDrain Filter T ransform { A , C } d A = d C { B , C } d B = d C { A , B , C } d A = d B = d C Merger Replicator Figure 2: Constraint automata for basic Reo channels and nodes with its en vironment. Source nodes act as synchronous replicators, and sink nodes as non-deterministic mergers. A mixed node combines these tw o beha viors by atomically consuming a data item from one of its sink ends at the time and replicating it to all of its source ends. 2.1 A utomata-based Semantics for Reo The most basic model expressing formally the semantics of Reo is constraint automata [ 9 ]. Transitions in a constraint automaton are labeled with sets of ports that fire synchronously , as well as with data constraints on these ports. The constraint automata-based semantics for Reo is compositional, meaning that the behavior of a complex Reo circuit can be obtained from the semantics of its constituent parts using the product operator . Furthermore, the hiding operator can be used to abstract from unnecessary details such as dataflo w on the internal ports of a connector . Definition 2.1 (Constraint automaton (CA)) A constraint automaton A = ( S , N , → , s 0 ) consists of a set of states S, a set of port names N , a transition r elation → ⊆ S × 2 N × D C × S, wher e D C is the set of data constraints o ver a finite data domain Data, and an initial state s 0 ∈ S . W e write q N , g − → p instead of ( q , N , g , p ) ∈ → . Figure 2 sho ws the constraint automata for the basic Reo channels. Note that we use the set Data = { 0 , 1 } as data domain for the FIF O channel. The behavior of any Reo circuit composed from these channels can be obtained by computing the product of the corresponding automata. Constraint automata in their basic form do not express all the information about Reo node commu- nication and fail to represent the behavior of e.g. context-dependent channels. An elemental e xample of such channels is a LossySync channel that loses a data item only if the en vironment or subsequent channels are not ready to consume it, i.e., it needs the information about the states of other channels or services to decide locally what to do with its data input. T o address this problem, sev eral other semantic models for Reo were introduced. In intentional automata [ 16 ] we distinguish two sets of ports in their transition labels, a request set and a firing set. The request set models the conte xt, i.e., the readiness of the channel ports to accept/dispense data, while the firing set models the actual flow of data through the circuit ports. Accounting for the requests that ha ve arriv ed but have not been fired yet introduces additional states in the model. Due to this fact, intentional automata rapidly become lar ge and difficult to manipulate. Connector coloring [ 14 ] describes the beha vior of Reo in a compositional fashion by coloring the parts of the circuit using different colors that match on connected ports. The basic idea in this model N. K okash et al. 23 flow no-flow-give-r eason no-flow-r equir e-r eason (1) (2) (3) (4) (1) (2) (3) (4) (1) (2) (3) (4) Sync LossySync Merger Figure 3: Examples of coloring semantics for Reo channels and nodes is to associate flow and no-flow colors to channel ends. When three colors are used, the model captures context-dependent behavior by propagating negati ve information about the exclusion of dataflow through the connector . This model is used currently as a theoretical basis for Reo circuit animation and simulation tools. Figure 3 sho ws examples of coloring semantics for basic Reo channels and connectors. In action constraint automata (A CA) [ 22 ], we distinguish several kinds of actions triggered on chan- nel ports to signal the state changes of the channel. F ormally , A CA can be defined as follows: Definition 2.2 (Action constraint automaton (A CA)) An action constraint automaton A = ( S , N , → , s 0 ) consists of a set of states S , a set of action names N derived fr om a set of port names M and a set of admissible action types T , a transition relation → ⊆ S × 2 N × DC × S, where DC is the set of data constraints o ver a finite data domain Data, and an initial state s 0 ∈ S . W e introduce an injectiv e function act : M × T → N to define action names for each pair of a port name and an action type observed on the port. F or example, the function act ( m , α ) = α · m , for m ∈ M , α ∈ T , where ‘ · ’ is a standard concatenation operator , can be used to obtain a set of unique action names given sets of distincti ve Reo port names and types of observable actions. This model can be used, e.g., to represent a sequential data flo w within a synchronous region and account for time delays in synchronous channels by distinguishing port blocking and unblocking ev ents as well as the start and the end of data transfer through a port. Coloring semantics can also be represented in a form of A CA using three actions to con ve y the possibility of data flow as well as r equiring and giving r easons for no-flow . 2.2 Process algebra-based Semantics f or Reo In our recent work [ 24 ], we represented the aforementioned semantic models for Reo using the process algebra mCRL2 . This allowed us to apply a set of verification tools de veloped for this specification language to analyze Reo connectors. The basic notion in mCRL2 is the action. Actions represent atomic events and can be parameterized with data. Actions in mCRL2 can be synchronized. In this case, we speak of multiactions which are constructed from other actions or multiactions using the so-called synchronization operator | , such as the multiaction a | b | c of simultaneously performing the actions a , b and c . The synchronization operator is commutati ve, i.e., multiactions a | b and b | a are equiv alent. The special action τ (tau) is used to refer to an internal, unobservable action. Processes are defined by process expressions, which are compositions of actions and multiactions using a number of operators. Among the basic operators are the follo wing: (i) deadlock or inaction δ , which does not display any behavior; (ii) alternative composition , written as p + q , which represents a non-deterministic choice between the processes p and q ; (iii) sequential composition , written p · q , which means that q is executed after p , assuming that p terminates; (i v) the conditional operator or the if-then-else construct, written as c → p  q , where c is a data expression that ev aluates to true or false; (v) summation Σ d : D p where p is a process e xpression in which the data 24 Input-output Conformance T esting for Channel-based Service Connectors T able 1: mCRL2 encoding for channels and nodes: CA semantics Sync = Σ d : Data A ( d ) | B ( d ) · Sync LossySync = Σ d : Data ( A ( d ) | B ( d ) + A ( d )) · LossySync SyncDrain = Σ d 1 , d 2 : Data A ( d 1 ) | B ( d 2 ) · SyncDrain AsyncDrain = Σ d : Da t a ( A ( d ) + B ( d )) · AsyncDrain FIF O ( f : DataFIFO ) = Σ d : Da t a ( isEmpty ( f ) → A ( d ) · FIFO ( full ( d ))  B ( e ( f )) · FIFO ( empty )) Filter = Σ d : Da t a ( expr ( d ) → A ( d ) | B ( d )  A ( d )) · Filter T ransfo rm = Σ d : Da t a A ( d ) | B ( f ( d )) · T ransform Merger = Σ d : Da t a ( A ( d ) | C ( d ) + B ( d ) | C ( d )) · Merger Replicato r = Σ d : Da t a A ( d ) | B ( d ) | C ( d ) · Replicato r Router = Σ d : Da t a ( A ( d ) | B ( d ) + A ( d ) | C ( d )) · Router v ariable d may occur , used to quantify over a data domain D ; (vi) parallel composition or merg e p k q , which interleav es and synchronizes the multiactions of p with those of q , where synchronization is gov erned by a communication function (see belo w); (vii) allow ∇ V ( p ) , where only actions in p from the set V are allowed to occur; (viii) the encapsulation ∂ H ( p ) , where H is a set of action names that are not allo wed to occur; (ix) the r enaming operator ρ R ( p ) , where R is a set of renamings of the form a → b , meaning that every occurrence of the action a in p is replaced by the action b ; (x) the communication operator Γ C ( p ) , where C is a set of communications of the form a 0 | ... | a n 7→ c , which means that e very group of actions a 0 | ... | a n within a multiaction is replaced by the action c ; (xi) hiding τ I ( p ) , which renames all actions in I of p into τ . It is possible to define recursiv e processes in mCRL2 . Ho we ver , allo w , encapsulation, hiding and communication operators can not be used within recursi v e processes. Structured operational semantics for the aforementioned mCRL2 operators can be found in [ 2 ]. The mCRL2 language provides a number of built-in datatypes (e.g., boolean, natural, integer) with a set of usual arithmetic operations. Moreo ver , an arbitrary structured type in mCRL2 can be declared by a construct of the form sort S = struct c 1 ( p 1 1 : S 1 1 , . . . , p k 1 1 : S k 1 1 ) ? r 1 | . . . | c n ( p 1 n : S 1 n , . . . , p kn n : S kn n ) ? r n ; This construct defines the type S together with constructors c i : S 1 i × . . . × S ki i → S , projections p j i : S → S j i , and type recognition functions r i : S → Bool . The mCRL2 toolset allows users to verify software models specified in the mCRL2 language. It includes a tool for con verting mCRL2 specifications into linear form (a compact symbolic representation of the corresponding L TS), a tool for generating explicit L TSs from linear process specifications (LPS), tools for optimizing and visualizing these L TSs, and many other useful facilities. A detailed ov erview of the av ailable software can be found at the mCRL2 web site 3 . The presence of multiactions in mCRL2 makes it possible to compositionally map Reo to process specifications and compose a connector by synchronizing actions on joint ports. Thus, mCRL2 models for Reo circuits are generated in the follo wing w ay: observable ev ents, i.e., data flow on the channel ends, are represented as atomic actions, while data items observed at these ports are modeled as param- eters of these actions. Analogously , we introduce a process for ev ery node and actions for all channel ends meeting at the node. The encodings for the basic Reo channels and nodes are listed in T able 1 . 3 http://www.mcrl2.org/ N. K okash et al. 25 Gi ven process definitions for all channels and nodes, a composite process that models a complete Reo connector is b uilt by forming a parallel composition of these processes and synchronizing actions for coinciding node/channel ends. Node/channel end synchronization is enforced using the mCRL2 operators communication and encapsulation. For example, an mCRL2 process for the replicator circuit in Figure 1 can be formed from three synchronous channels Sync 1 = A | X 1 . Sync 1 , Sync 2 = Y 1 | B . Sync 2 , Sync 3 = Z 1 | C . Sync 3 and a replicator node Replicato rNo de = X 2 | Y 2 | Z 2 . Replicato rNo de applying the communication and blocking operators to their parallel composition: Replicato rCircuit = ∂ { X 1 , Y 1 , Z 1 , X 2 , Y 2 , Z 2 }  Γ { X 1 | X 2 → τ , Y 1 | Y 2 → τ , Z 1 | Z 2 → τ } ( Sync 1 k Sync 2 k Sync 3 k Replicato rNo de )  ; Here we assume that the sink end X 1 of the channel Sync 1 is connected to the source end X 2 of the node Replicato rNo de , while sink ends Y 2 and Z 2 of the node are connected to source ends Y 1 and Z 1 of channels Sync 2 and Sync 3. Optionally , the mCRL2 hiding operator can be employed for abstracting the flo w in selected nodes. For simplicity , we omitted the encoding of data parameters in this example. For the treatment of data we assume, in the context of a gi ven connector , a global datatype giv en as the custom sort Data . Giv en such a datatype, we can use the mCRL2 summation operator to define data dependencies imposed by channels. F or the FIF O channel we additionally define the datatype sort DataFIFO = struct empty ? isEmpty | full ( e : Data ) ? isFull which allows us to specify whether the buf fer of the FIFO channel is empty or full, and if it is full, what v alue is stored in it. Additionally , we introduce a special kind of node, Join , which synchronizes all ends of incoming channels, forms a tuple of data items recei ved and replicates it to the source ends of all outgoing channels. More details on data handling in Reo and mCRL2 can be found in [ 24 ]. T able 2 shows the mCRL2 encodings for the basic Reo channels and nodes according to the A CA model with four actions: block and unblock actions are used to establish port communication within a single transaction and release channel ports in v olved in such a transaction, respectiv ely . The start and finish actions are used to represent the start and the end of dataflo w through a blocked channel port. In our encoding, we use prefix letters b , u , s and f in front of Reo port names to denote block, unblock, start and finish actions observed on these ports. Since data support in the ne w translation is analogous to the case of the CA-based translation, we omit its discussion here and for simplicity show only the data-agnostic mapping. As in the CA approach, we construct nodes compositionally . Gi ven process definitions for all channels and nodes, a composite process that models the complete Reo connector is built by forming a parallel composition of these processes and synchronizing communicating actions for the coinciding node/channel ends. T o incorporate the colorings in our encoding in mCRL2 , we represent colors as data parameters of actions [ 24 ]. Ho wev er , since the summation ov er a finite domain in mCRL2 is just an alternati ve choice of the same action with various parameters, we can represent ev ery parameterized action as an alternati ve choice of sev eral non-parameterized actions. This allo ws us to represent coloring semantics as shown in T able 3 . For e very port X , we consider three actions, wX , r X and gX which are abbre viations for actions flow , no-flow-r equir e-r eason , and no-flow-give-r eason observations on channel ports. The advantage of this approach ov er the use of parameterized actions is the possibility to hide no-flow labels. Thus, the process algebra mCRL2 provides a common ground for expressing most important semantic models for Reo preserving their compositionality . 26 Input-output Conformance T esting for Channel-based Service Connectors T able 2: mCRL2 encoding for channels and nodes: ACA semantics Sync = bA | bB · sA | sB · f A | f B · uA | uB · Sync LossySync = ( bA | bB · sA | sB · f A | f B · uA | uB + bA · sA · f A · uA ) · LossySync SyncDrain = bA | bB · ( sA · ( sB · ( f A · f B + f B · f A + f A | f B ) + f A · sB · f B + sB | f A · f B )+ sB · ( sA · ( f A · f B + f B · f A + f A | f B ) + f B · sA · f A + sA | f B · f A )+ sA | sB · ( f A · f B + f B · f A + f A | f B )) · uA | uB · SyncDrain AsyncDrain = ( bA · sA · f A · uA + bB · sB · f B · uB ) · AsyncDrain FIF O ( f : DataFIFO ) = isEmpty ( f ) → bA · sA · f A · uA · FIFO ( full )  bB · sB · f B · uB · FIFO ( empty ) Merger = ( bA | b C · sA | s C | f A | f C . uA | u C + bB | b C · sB | s C | f B | f C · uB | u C ) · Merger Replicato r = bA | bB | b C · sA | sB | s C · f A | f B | f C · uA | uB | u C · Replicato r T able 3: mCRL2 encoding for channels and nodes: coloring semantics Sync = ( wA | wB + rA | gB + gA | r B + gA | gB ) · Sync LossySync = ( wA | wB + wA | gB + gA | rB + gA | gB ) · LossySync SyncDrain = ( wA | wB + rA | gB + gA | r B + gA | gB ) · SyncDrain AsyncDrain = ( wA | gB + gA | wB + rA | wB + r B | wA + gA | gB ) · AsyncDrain FIF O ( f : DataFIFO ) = isEmpty ( f ) → (( wA | r B + wA | gB ) · FIFO ( full ) + ( gA | rB + gA | gB ) · FIFO ( empty ))  (( rA | wB + gA | wB ) · FIFO ( empty ) + ( rA | gB + gA | gB ) · FIFO ( full )) Merger = wA | gB | w C + gA | wB | w C + r A | rB | g C + gA | gB | rC ) · Merger Replicato r = ( wA | wB | w C + r A | rB | g C + r A | gB | r C + gA | gB | g C ) · Replicator 3 Input-output Conf ormance T esting In this section, we briefly introduce a model-based test generation theory for testing input-output confor- mance ( ioco ) of an implementation and a giv en specification [ 30 ]. Transition labels in (action) constraint automata represent sets of simultaneously observ able actions on Reo ports with enabling guards while in the original definitions on L TS each transition refers to a single observ able action. As follows from our mapping of constraint-automata-based semantics of Reo to L TS, each set of transition labels { A , B , C } in a CA corresponds to a transition with a unique action label A | B | C in the corresponding L TS, which further can be renamed to an action AB C . Assuming that the semantics of Reo is gi ven in a form of such L TS, we can apply the ioco testing theory to test Reo. In the following we redefine all necessary concepts of the ioco testing theory using CA, the original definitions on L TS can be found in [ 30 ]. Let L ∗ be the set of all finite sequences o ver a set L and ε denote the empty sequence. Given finite sequences σ 1 and σ 2 , we denote their concatenation σ 1 · σ 2 . If for some automaton there exists a trace q N 1 · τ · τ · N 2 · τ · N 3 · τ − − − − − − − → p , where N 1 , N 2 , N 3 ∈ L are sets of actions representing constraint automata labels and τ is a special action that refers to any set of unobserv able constraint automata ports, we write p N 1 · N 2 · N 3 = ⇒ q for the τ − abstracted sequence of observ able actions and say that p is able to perform the trace N 1 · N 2 · N 3 ∈ L ∗ . As we demonstrated in [ 23 ], every state s of a CA can be identified with a behaviorally equiv alent N. K okash et al. 27 mCRL2 process p . W e exploit this correspondence in the rest of the paper and do not distinguish between CA states and processes associated with these states. The follo wing definitions are needed to formally define the ioco testing relation for a gi ven specification and a system implementation. Definition 3.1 Let p be a pr ocess associated with the initial state s 0 of a constraint automaton A = ( S , N , → , s 0 ) and σ ∈ L ∗ wher e L = 2 N × D C is a set of the constraint automaton labels. 1. init ( p ) = { ρ ∈ L ∪ τ | p ρ − →} . 2. t races ( p ) = { σ ∈ L ∗ | p σ = ⇒} 3. p after σ = { p 0 | p σ = ⇒ p 0 } 4. P after σ = S p after σ | p ∈ P , wher e P ⊆ S is a set of states. 5. P refuses A = ∃ p ∈ P , ∀ ρ ∈ A ∪ τ : p ρ 9 , wher e P ⊆ S and A ⊆ L. 6. d er ( p ) = { p 0 | ∃ σ ∈ L ∗ : p σ = ⇒ p 0 } 7. p has finite beha vior if ther e is a natur al number n suc h that all traces in t races ( p ) have length smaller than n. 8. p is a finite state if the number of r eachable states d er ( p ) is finite . 9. p is deterministic if, for all σ ∈ L ∗ , p after σ has at most one element. 10. p is image finite if, for all σ ∈ L ∗ , p after σ is finite. 11. p is strongly con ver gent if ther e is no state of p that can perform an infinite sequence of internal transitions. 12. C A ( L ) is the class of ima ge finite and str ongly con verg ent constraint automata with labels in L. Definition 3.2 (Constraint automaton with Inputs and Outputs) A constraint automaton with inputs and outputs is a constraint automaton A = ( S , N , → , s 0 ) ∈ C A ( L I ∪ L U ) , where L I and L U , L I ∩ L U = / 0 ar e countable sets of disjoint input and output labels. L TS with inputs and outputs are used as formal specifications for ioco testing theory . Being a v ariant of L TS, constraint automata with inputs and outputs are used in our work to represent system-under-test specifications. This does not mean that these specifications ha ve to be written explicitly in a form of automata: it suffices that a specification language, e.g., Reo, had semantics e xpressed in the form of constraint automata with inputs and outputs. Definition 3.3 (Input-Output Constraint A utomaton) An input/output constraint automaton (IOCA) is a constraint automaton with inputs and outputs A = ( S , N , → , s 0 ) wher e all inputs ar e enabled in any r eachable state , i.e., ∀ s ∈ d er ( s 0 ) , ∀ N ⊆ L I : s N = ⇒ . Let C A ( L I , L U ) denote the class of all constraint automata with inputs in L I and outputs in L U . The class of input-output constraint automata with inputs in L I and outputs in L U is denoted by I O C A ( L I , L U ) ⊆ C A ( L I , L U ) . A constraint automaton with inputs and outputs can be con v erted to an input-output con- straint automaton by adding a self-loop transition with labels from L I to e very reachable state. This operation is called angelic completion [ 30 ]. Input-output constraint automata are used to model systems in which inputs are initiated by the en vironment and ne ver refused by the system and outputs are initiated by the system and ne ver refused by the environment. The input enabledness of system implementations 28 Input-output Conformance T esting for Channel-based Service Connectors is required in ioco testing theory to define the relation between the inputs generated by the tester and the observ able outputs. Since input-output constraint automata are just a particular type of constraint automata, all definitions for the latter apply , including the definitions of product and hiding operations. A state q of a process p without output actions, i.e., ∀ ρ ∈ L U | q ρ 9 , is called suspended or quiescent and is denoted δ ( q ) . The external observer of a system in a quiescent state does not see any outputs. Such a situation with no observ ations can be considered as a special action, denoted as δ . In our test cases, we allow system transitions p δ − → meaning that p cannot perform any output actions. It is also possible to extend traces with δ , e.g., p N 1 · δ · N 2 · N 3 = ⇒ , where N 1 , N 2 ∈ L I , N 3 ∈ L U , expresses the fact that after the input N 1 was observed, the system remained quiescent, while after the input N 2 , the system produced output N 3 . The quiescent traces of p are those that may lead to quiescent states, i.e., Q t races ( p ) = { σ ∈ L ∗ |∃ p 0 ∈ ( p after σ ) : δ ( p 0 ) } . T races that may contain the quiescence action are called suspension traces . More formally , the suspen- sion traces are St races ( p ) = { σ ∈ L ∗ δ | p δ σ − →} , where L δ = L ∪ δ and p δ is a process defined by a constraint automaton A = ( S , N , → , s 0 ) with inputs L I , outputs L U ∪ δ and a transition relation → ∪ → δ , such that → δ = { s δ − → s | s ∈ S , δ ( s ) } . T o test a system using the ioco testing theory , we assume that a tester is an en vironment which is able to pro vide inputs and observe system outputs including quiescence. This en vironment must be able to accept any output produced by the system. Thus, the beha vior of a tester can be modeled as IOCA with inputs and outputs exchanged. The occurrence of a special symbol θ / ∈ L I ∪ L U ∪ τ ∪ δ in tests indicates the detection of quiescence. Practically this means that the tester has to wait for a certain time-out to conclude that the system did not produce an output. Since test case execution must alw ays lead to a verdict, we include two special states reachable from an y other state of a testing IOCA: fail , pass ∈ S . Thus, a test case is defined as follo ws in ioco : Definition 3.4 (T est case) A test case t for an implementation with inputs in L I and outputs in L U is an IOCA A = ( S , N , → , s 0 ) ∈ I O C A ( L I , L U ∪ θ ) suc h that • t is finite and deterministic; • S contains two special states pass and fail , pass 6 = fail ; • t has no cycles e xcept those in states pass and fail ; • ∀ s ∈ S it holds that init ( s ) = a ∪ L U | a ∈ L I or ini t ( s ) = L U ∪ θ . The class of test cases for implementations with inputs in L I and outputs in L U is denoted T T S ( L U , L I ) . A run of a test case t ∈ T T S ( L U , L I ) with an implementation under test i ∈ I O C A ( L I , L U ) corre- sponds to the parallel synchronization of behavior expressed by the tester and the system. Howe ver , the usual parallel synchronization needs to be extended to account for special labels δ and θ . Such an extension, denoted by t e| i , is defined by the follo wing inference rules: i τ − → i 0 t e| i τ − → t e| i 0 t a − → t 0 , i a − → i 0 t e| i a − → t e| i 0 t θ − → t 0 , i δ − → t e| i θ − → t e| i 0 . Here a ∈ L I ∪ L U . The resulting system runs without deadlocks. This property follo ws immediately from the definition of test cases: since ∀ s ∈ S it holds that ini t ( s ) = a ∪ L U | a ∈ L I or init ( s ) = L U ∪ θ , we N. K okash et al. 29 A B C { A , C } { B } Reo model Constraint automaton (a) Specification A B C { A , B } { C } Reo model Constraint automaton (b) Implementation Figure 4: Specifications of a Reo connector and its wrong implementation (Example 1) can conclude that either an action a can always be performed on the implementation or i produces some output x ∈ L U ∪ θ . Definition 3.5 ( Ioco relation) Given a set of inputs L I and a set of outputs L U , the r elation ioco ⊆ I O C A ( L I , L U ) × C A ( L I , L U ) is defined as follows: i ioco s = ∀ σ ∈ St races ( s ) : out ( i after σ ) ⊆ ou t ( s after σ ) wher e for any state s of a CA ou t ( s ) = { x ∈ L U | s x − →} ∪ δ | δ ( s ) and for a set of states S out ( S ) = ∪{ ou t ( s ) | s ∈ S } For more details about ioco testing theory , i.e., test generation algorithm and the analysis of its cov erage, refer to [ 30 ]. The extension of ioco to test component-based systems is presented in [ 17 ]. Aichernig and W eiglhofer propose a unification of ioco relation by lifting the definition from L TS to reacti ve processes. In the rest of this paper , we discuss the application of the presented testing theory to detect errors in implementations of Reo coordination protocols. Giv en a Reo circuit specification, we use the ioco -based test generation algorithm to produce sets of inputs and judge the correctness of the implementations by observing its outputs. Inputs in our approach essentially represent sets of boundary ports of the circuit ready to accept data items while outputs are actual observations of dataflow on these ports. 4 T esting Channel-based Ser vice Connectors T o enable testing of Reo connectors, we extend constraint automata with actions that represent in- put/output events. Figure 4 shows a Reo connector specification and an erroneous implementation where Sync and FIFO channels are swapped. Figure 5 sho ws another sample specification and a wrong im- plementation where the SyncDrain channel is erroneously added to the circuit. The goal of testing is to detect such errors automatically by providing inputs and observing outputs obtained from a wrong imple- mentation which do not occur in the specification. Note that we use Reo to model both a specification and an erroneous implementation for illustration purposes only . In practice these errors may correspond to wrong implementation code such as e.g., wrong type of communication (synchronous vs. asynchronous) in the first example or wrongly enforced synchronization on tw o ports in the second example. T o obtain connector specifications suitable for testing, we combine the idea of e xplicit representation of pending requests introduced in intentional automata with constraint automata semantics for Reo. Thus, for e very boundary Reo port A we introduce two actions ? A and ! A that represent an external request for this port to accept or dispense a data item and the actual observation of data flow on the circuit node A , respecti vely . Thus, our representation of boundary nodes in mCRL2 will be as follo ws: 30 Input-output Conformance T esting for Channel-based Service Connectors A B C { A } { B , C } { B } { C } { C } { B } Reo model Constraint automaton (a) Specification A B C { A } { B , C } Reo model Constraint automaton (b) Implementation Figure 5: Specifications of a Reo connector and its wrong implementation (Example 2) Merger = ? C · ( A | ! C + B | ! C ) · Merger ; Replicato r = ? A · ! A | B | C · Replicator ; Router = ? A · ( ! A | B + ! A | C ) · Router ; Here we assume that the mer ger node has two internal input ports A and B and a boundary output port C while the replicator and the router nodes have one input boundary port A and two internal output ports B and C . It is not allowed in Reo to ha ve a boundary node which serv es both as input and output port. T aking into account that we label input and output ev ents on the same port using dif ferent action names (decorated with ? and !, respectiv ely), we can conclude that for a Reo circuit with all disjoint port names the requirement L I ∩ L U = / 0 holds. Figure 6 shows constraint automata with inputs and outputs for the specification and implementation of Reo connectors in Example 1. Aichernig et al. [ 1 ] de veloped a tool for testing Reo based on the representation of connectors as designs and specifying them in Maude. The authors claim that testing theories based on finite-state machines are not suitable for testing Reo since in Reo not all input e vents are follo wed by output ev ents. While this is true assuming that Reo circuit specifications are provided in the form of basic constraint automata, observ e that with our mapping schema we can distinguish a situation when some input item is rejected by a circuit from the case when this item is accepted by the circuit but does not appear on any of the output ports, e.g., destroyed by a SyncDrain or LossySync channels. In fact, any data item supplied by an en vironment that enters a circuit through an input boundary port A generates an output e vent ! A . Similarly , any output e vent ! B observed on the boundary output port B can only follow the preceding input ev ent ? B triggered by the environment. Furthermore, in contrast to earlier approaches based on input/output finite state machines [ 12 , 27 ], the ioco testing theory allows us to “observ e” outputs with no data flo w on Reo ports (quiescence). W e now illustrate why such an e xtended semantic model is needed to test Reo. In Example 2, the behavior of the circuit in the specification is more general than the behavior of the implemented circuit: for any data input through the input boundary port A in the specification, data flo w on the port B , port C or both of them simultaneously will be e ventually observed. In contrast, in the implementation data flow on ports B and C will be always observed simultaneously . If we generate test cases based on constraint automata, we always observe outputs that are a subset of the admissible outputs in the specification. Ho we ver , if we e xplicitly take into account requests from the environment to supply/consume data, we can detect the dif ference in the circuit implementation. Thus, after observing the input e vents ? A and ? B and the output ev ent ! A , the specification will expect the observation of the action ! B while the presented wrong implementation will be quiescent. Many existing semantic models for Reo operate at the le v el of observable data flo w on Reo ports and do not specify what happens with possibly multiple requests arriving at the boundary nodes. There are se veral strategies to handle these requests: for every port A with a pending request ? A on the arriv al of another request ? A we can (a) ignore the second request, (b) substitute the initial request with the ne w N. K okash et al. 31 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 { ?B,?A } { ?C,?A } { ?C,?B,?A } { ?B } { ?C } { ?C,?B } { ?A } { ?C } { !C,!A } { !C,!A,?B } { ?B } { !C,!A } { ?C,?A } { ?C } { ?A } { ?B,?A } { ?B } { ?A } { ?A } { ?B } { ?C } { ?C,?B } { ?B,?A } { ?C,?A } { ?C,?B,?A } { ?B } { ?C } { ?C,?B } { ?A } { ?C,?A } { ?C } { ?A } { !B,?A } { !B,?C,?A } { !B } { !B,?C } { ?C } { !B } { !B,?C } { ?B } { !B } { ?B,?A } { ?B } { ?A } { ?A } { !B,?A } { !B } { ?B } { ?C } { ?C,?B } (a) Specification 0 2 6 3 7 4 1 5 12 9 11 14 8 15 10 13 { ?B,!A } { ?C,?A } { ?C,?B,?A } { ?B } { ?C } { ?C,?B } { ?A } { !B,!A } { !B,!A,?C } { ?C } { ?B } { !B,!A } { ?C,?A } { ?C } { ?A } { ?B,?A } { ?B } { ?A } { ?A } { ?B } { ?C } { ?C,?B } { ?B,?A } { ?C,?A } { ?C,?B,?A } { ?B } { ?C } { ?C,?B } { ?A } { !C,?A } { !C,?B,?A } { !C } { !C,?B } { ?B,?A } { ?B } { ?A } { ?C } { !C } { !C,?B } { ?B } { !C } { ?C,?A } { ?C } { ?A } { !C,?A } { !C } { ?A } { ?B } { ?C } { ?C,?B } (b) Implementation Figure 6: Example 1: Constraint automaton with inputs and outputs for the specification of a Reo con- nector and its wrong implementation { ? A } { ? A } { ! A } (a) Ignore ... { ? A } { ? A } { ! A } { ! A } { ! A } (b) Overwrite ... { ? A } { ? A } { ? A } { ! A } { ! A } (c) Add Figure 7: Input request handling 32 Input-output Conformance T esting for Channel-based Service Connectors request, (c) add the second request to the waiting line to be processed by the circuit, e.g., on the FIFO basis. Figure 7 shows constraint automata with inputs and outputs-based specifications for the aforemen- tioned strategies. Note that it makes sense to distinguish between the first and the second strategies only for data-aware requests. For data-agnostic circuits it matters only ho w many requests the circuit needs to process. In the third case, we have to assume that the queue for pending requests is bounded in order to keep the model finite, and after its limit is reached, the further requests are either ignored or overwrite pre vious ones. What is important is that in all three cases we can see that Reo connector specifications can be represented by constraint automata with inputs and outputs that are input enabled. Based on this observ ation, we can apply angelic completion for constraint automata with inputs and outputs generated from Reo circuits as discussed above to obtain an input-output constraint automaton without affecting the actual behaviour of the circuit: for any input request ? A a subsequent request can influence the beha vior of the circuit only after the first request is processed, i.e., action ! A is observed, and, thus, adding loops with labels from L I to each state does not change the semantics of the circuit. An interesting result follo ws from the precongruence property for input enabled specifications [ 30 ] (see Proposition 3) and the fact that our generated constraint automata-based specifications are input enabled. Proposition 4.1 F or any two pairs of connector implementations and specifications, i k ∈ I O C A ( L I k , L U k ) and s k ∈ I O C A ( L I k , L U k ) , k = 1 , 2 with disjoint sets of input/output labels, i.e., L I 1 ∩ L I 2 = L U 1 ∩ L U 2 = / 0 , it holds that i 1 ioco s 1 and i 2 ioco s 2 implies ∂ H ( Γ H →{ τ } ( i 1 || i 2 )) ioco ∂ H ( Γ H →{ τ } ( s 1 || s 2 )) , wher e H = ( L I 1 ∩ L I 2 ) ∪ ( L U 1 ∩ L U 2 ) denotes the set of observed actions on their connected ports while ∂ H ( · ) and Γ C ( · ) ar e the mCRL2 encapsulation and communication operators intr oduced in Section 2.2 . Practically this means that the product operator on input-output constraint automata preserves the ioco relation and testing of Reo connectors can be performed compositionally . 5 T ool Support T o automate testing of Reo, we inte grated the JT orX tool into the ECT en vironment. JT orX is a Jav a- based tool to test whether the ioco relation holds between a given specification and a giv en implemen- tation. JT orX e xpects the specification to be giv en in a form of an L TS represented, e.g., in Aldebaran (.aut) or GraphML format. Thus, we employ our Reo to mCRL2 con version frame work to generate L TSs that are behaviorally equiv alent to constraint automata with inputs and outputs introduced in Section 3 . A detailed description of Reo to mCRL2 mapping plug-in is av ailable in [ 24 ]. T o include input/output actions into an mCRL2 specification generated from the graphical Reo circuit, select the I/O actions check box on the mapping parameters panel. This option can be chosen in combination with coloring and A CA-based mappings. The corresponding mCRL2 code will appear in the integrated te xt editor . An L TS with input and output ev ents can be obtained from the generated mCRL2 code by pressing the Show LTS button and sa ved in the .aut format afterwards. The JT orX tool does not recognize synchronized input and output actions in the form of mCRL2 multiactions. Therefore, we additionally dev eloped a simple script that con v erts labels of the form iA | iB and oA | oB into { ? A , ? B } and { ! A , ! B } , respectiv ely . Similarly to mCRL2 , all actions represented by a set of labels on a single transition in the L TS operated on by JT orX must happen simultaneously , and thus our transformation does not affect the outcome of testing. N. K okash et al. 33 Figure 8: T esting Reo with JT orX: generated test cases for Example 2 The implementation is either given in a form of L TS or it is a real program. In the latter case, JT orX needs to be able to interact with it, e.g., via the TCP protocol or via an adapter . For testing connector implementations against constraint automata specifications, we can supply both the specification and the implementation in the form of L TS representing their input/output constraint automata semantics. Similarly , for testing implementations of b usiness protocols modeled with Reo, we can obtain L TSs by con verting e xecution code, i.e., BPEL, to Reo [ 29 ], and then to mCRL2 , and, finally , to L TS as described abov e. Ho wev er , as this approach requires each translation step to preserve the semantics of the original code, which is not alw ays feasible, a more natural approach would be to de velop adapters that ex ecute tests generated by JT orX and observe outputs produced by the real system under test. There is an ongoing work on de veloping such an adapter for JT orX to communicate with the distributed implementation of Reo in Jav a [ 15 ]. Figure 8 shows a screenshot of the JT orX tool with tests generated for Example 2. The highlighted line sho ws a test case discussed in Section 4 on which the wrong implementation fails to yield the expected outputs and remains quiescent. Using JT orX, one can simulate test case execution to show traces corresponding to the violated test cases on both specification and implementation L TSs. In our future work, we will de velop a plug-in to simulate such test violation traces using Reo animation engine [ 5 ]. 34 Input-output Conformance T esting for Channel-based Service Connectors 6 Conclusions In this paper , we presented an approach to testing models in the Reo coordination language using the ioco testing theory . The approach is based on mapping of automata-based semantic models for Reo to the process algebra mCRL2 and reuse of existing state-space generation and model-based testing tools. W e extended the semantic model for Reo with input/output events and sho wed that the generated specifica- tions are suitable for testing. In contrast to the pre vious work on testing Reo [ 1 ], where basic connectors are specified equationally and their composition is encoded by means of rewrite rules, no additional ef- fort is required to obtain testable specifications and implementations in our framew ork. W e also expect compositionality of testing Reo with ioco to be a useful property that will allow us to assure quality of large process models. In our future work, we will in vestigate the applicability of several extensions of ioco relation, namely , symbolic ioco ( sioco ) [ 18 ] and timed-ioco ( tioco ) [ 13 ], to test time and data-aw are Reo circuits. Refer ences [1] B. K. Aichernig, F . Arbab, L. Astefanoaei, F . S. de Boer, M. Sun & J. Rutten (2009): F ault-Based T est Case Generation for Component Connectors . In: Proc. T ASE 2009 , pp. 147–154, doi: 10.1109/T ASE.2009.14 . [2] J.F . Groote et al. (2007): The F ormal Specification Language mCRL2 . In E. Brinksma et al., editor: Methods for Modelling Software Systems , IBFI, Schloss Dagstuhl, pp. 1–34. [3] F . Arbab (2004): Reo: A Channel-based Coordination Model for Component Composition . Mathematical Structures in Computer Science 14, pp. 329–366, doi: 10.1017/S0960129504004153 . [4] F . Arbab, C. Baier , F . de Boer & J. Rutten (2007): Models and T emporal Logical Specifications for T imed Component Connectors . Software and Systems Modeling 6, pp. 59–82, doi: 10.1007/s10270-006-0009-9 . [5] F . Arbab, C. K oehler , Z. Maraikar , Y .J. Moon & J. Proenca (2008): Modeling, T esting and Executing Reo Connectors with the Eclipse Coor dination Tools . T ool demo session at F A CS 2008. [6] F . Arbab, N. K okash & M. Sun (2008): T owards Using Reo for Compliance-awar e Business Pr ocess Modelling . In T . Margaria & B. Steffen, editors: Proc. ISoLA 2008 , LNCS 17, Springer , pp. 108–123, doi: 10.1007/978-3-540-88479-8 9 . [7] C. Baier (2005): Pr obabilistic Models for Reo Connector Circuits . Journal of Univ ersal Computer Science 11(10), pp. 1718–1748, doi: 10.3217/jucs-011-10-1718 . [8] C. Baier, T . Blechmann, J. Klein & S. Kl ¨ uppelholz (2009): A Uniform F ramework for Modeling and V erifying Components and Connectors . In J. Field & V .T . V asconcelos, editors: Proc. COORDIN A TION 2009 , LNCS 5521, Springer , pp. 268–287, doi: 10.1007/978-3-642-02053-7 13 . [9] C. Baier, M. Sirjani, F . Arbab & J. Rutten (2006): Modeling Component Connector s in Reo by Constraint Automata . Science of Computer Programming 61, pp. 75–113, doi: 10.1016/j.scico.2005.10.008 . [10] M. Bonsangue, D. Clarke & A. Silva (2009): Automata for Conte xt-dependent Connector s . In J. Field & V .T . V asconcelos, editors: Proc. COORDINA TION 2009 , LNCS 5521, Springer , pp. 184–203, doi: 10.1007/978- 3-642-02053-7 10 . [11] M. Bonsangue & M. Izadi (2010): Automata Based Model Checking for Reo Connectors . In: Proc. FSEN 2009 , LNCS 5961, Springer , pp. 260–275, doi: 10.1007/978-3-642-11623-0 15 . [12] L. du Bousquet & N. Zuanon (1999): An Overview of Lutess: A Specification-based T ool for T esting Synchr onous Softwar e . In: Proc. ASE’99 , IEEE Computer Society , pp. 208–215, doi: 10.1109/ASE.1999.802255 . N. K okash et al. 35 [13] L. Brandan Briones & E. Brinksma (2005): A T est Generation F r amework for Quiescent Real-T ime Sys- tems . In J. Grabowski & B. Nielsen, editors: Proc. F A TES 2004 , LNCS 3395, Springer, pp. 64–78, doi: 10.1007/b106767 . [14] D. Clarke, D. Costa & F . Arbab (2007): Connector Coloring I: Sync hr onization and Context Dependency . Science of Computer Programming 66, pp. 205–225, doi: 10.1016/j.scico.2007.01.009 . [15] D. Clarke, J. Proenca, A. Lazovik & F . Arbab (2011): Channel-based Coor dination via Constraint Satisfac- tion . Science of Computer Programming 76(8), pp. 681–710, doi: 10.1016/j.scico.2010.05.004 . [16] D. Costa (2010): F ormal Models for Context Dependent Connectors for Distributed Softwar e Components and Services . PhD thesis, Vrije Univ ersiteit Amsterdam. [17] A. Fai vre, C. Gaston & P . Le Gall (2007): Symbolic Model based T esting for Component-oriented Systems . In A. Petrenk o et al., editor: Proc. T estCom/F A TES 2007 , LNCS 4581, Springer, pp. 90–106, doi: 10.1007/978- 3-540-73066-8 7 . [18] L. Frantzen, J. T retmans & T .A.C. W illemse (2005): T est Generation Based on Symbolic Specifications . In J. Grabo wski & B. Nielsen, editors: Proc. F A TES 2004 , LNCS 3395, Springer , pp. 1–15, doi: 10.1007/978-3- 540-31848-4 1 . [19] H. Gara vel, R. Mateescu, F . Lang & W . Serwe (2007): CADP 2006: A T oolbox for the Construction and Analysis of Distributed Pr ocesses . In W . Damm & H. Hermanns, editors: Proc. CA V 2007 , LNCS 4590, Springer , pp. 158–163, doi: 10.1007/978-3-540-73368-3 18 . [20] S. Kemper (2011): SA T-based V erification for T imed Component Connectors . Science of Computer Program- ming doi: 10.1016/j.scico.2011.02.003 . [21] R. Khosravi, M. Sirjani, N. Asoudeh, S. Sahebi & H. Irav anchi (2008): Modeling and Analysis of Reo Connectors Using Alloy . In D. Lea & G. Zav attaro, editors: Proc. COORDINA TION 2008 , LNCS 5052, pp. 169–183, doi: 10.1007/978-3-540-68265-3 11 . [22] N. K okash, B. Changizi & F . Arbab (2010): A Semantic Model for Service Composition with Coordination T ime Delays . In Jin Song Dong & Huibiao Zhu, editors: Proc. ICFEM 2010 , LNCS 6447, pp. 106–121, doi: 10.1007/978-3-642-16901-4 9 . [23] N. Kokash, C. Krause & E.P . de V ink (2010): V erification of Context-Dependent Channel-Based Service Models . In F . de Boer et al., editor: Proc. FMCO 2009 , LNCS 6286, pp. 21–40, doi: 10.1007/978-3-642- 17071-3 2 . [24] N. Kokash, C. Krause & E.P . de V ink (2011): Reo + mCRL2 : A F r amework for Model-checking Dataflow in Service Compositions . Formal Aspects of Computing doi: 10.1007/s00165-011-0191-6 . [25] N. Lohmann, E. V erbeek & R. Dijkman (2009): P etri Net T ransformations for Business Pr ocesses - A Surve y . In K. Jensen & W . v an der Aalst, editors: Transactions on Petri Nets and Other Models of Concurrency (T oPNoC) II , LNCS 5460, Springer , pp. 46–63, doi: 10.1007/978-3-642-00899-3 3 . [26] S. Morimoto (2008): A Survey of F ormal V erification for Business Pr ocess Modeling . In M. Bubak et al., editor: Proc. ICCS 2008 , LNCS 5102, Springer , pp. 514–522, doi: 10.1007/978-3-540-69387-1 58 . [27] A. Petrenko (2000): F ault Model-Driven T est Derivation fr om F inite State Models: Annotated Bibliography . In F . Cassez et al., editor: Modeling and V erification of Parallel Processes , LNCS 2067, Springer , pp. 196– 205, doi: 10.1007/3-540-45510-8 10 . [28] D. Schumm, O. T uretken, F . Le ymann N. K okash, A. Elgammal & W .-J. Heuvel (2010): Business Pr ocess Compliance thr ough Reusable Units of Compliant Pr ocesses . In: Current T rends in W eb Engineering , LNCS 6385, Springer , pp. 325–337, doi: 10.1007/978-3-642-16985-4 29 . [29] S. T asharofi, M. V akilian, R. Z. Moghaddam & M. Sirjani (2008): Modeling W eb Service Interactions Using the Coor dination Language Reo . In: Proc. WS-FM 2008 , LNCS 4937, Springer , pp. 108–123, doi: 10.1007/978-3-540-79230-7 8 . [30] J. T retmans (2008): Model Based T esting with Labelled T ransition Systems . In: Formal Methods and T esting , LNCS 4949, Springer , pp. 1–38, doi: 10.1007/978-3-540-78917-8 1 .