Towards reduction of Paradigm coordination models
Citation for published version (APA):
Andova, S., Groenewegen, L. P. J., & Vink, de, E. P. (2011). Towards reduction of Paradigm coordination models. In L. Aceto, & M. R. Mousavi (Eds.), Proceedings of the First International Workshop on Process Algebra and Coordination (PACO 2011, Reykjavik, Iceland, June 9, 2011) (pp. 1-18). (Electronic Proceedings in Theoretical Computer Science; Vol. 60). EPTCS. https://doi.org/10.4204/EPTCS.60.1
DOI:
10.4204/EPTCS.60.1
Document status and date: Published: 01/01/2011
Document Version:
Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)
Please check the document version of this publication:
• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.
• The final author version and the galley proof are versions of the publication after peer review.
• The final published version features the final layout of the paper including the volume, issue and page numbers.
Link to publication
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
• You may freely distribute the URL identifying the publication in the public portal.
If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:
www.tue.nl/taverne
Take down policy
If you believe that this document breaches copyright please contact us at: openaccess@tue.nl
providing details and we will investigate your claim.
L. Aceto and M.R. Mousavi (Eds.): PACO 2011 EPTCS 60, 2011, pp. 1–18, doi:10.4204/EPTCS.60.1
c
S. Andova, L.P.J. Groenewegen and E.P. de Vink
This work is licensed under the Creative Commons Attribution License.
Suzana Andova∗
Department of Mathematics and Computer Science TU/e, Eindhoven, the Netherlands
Luuk Groenewegen
FaST Group, Leiden Institute of Advanced Computer Science Leiden University, The Netherlands
Erik de Vink
Department of Mathematics and Computer Science TU/e, Eindhoven, the Netherlands
Abstract The coordination modelling language Paradigm addresses collaboration between
compo-nents in terms of dynamic constraints. Within a Paradigm model, component dynamics are con-sistently specified at a detailed and a global level of abstraction. To enable automated verification of Paradigm models, a translation of Paradigm into process algebra has been defined in previous work. In this paper we investigate, guided by a client-server example, reduction of Paradigm mod-els based on a notion of global inertness. Representation of Paradigm modmod-els as process algebraic specifications helps to establish a property-preserving equivalence relation between the original and the reduced Paradigm model. Experiments indicate that in this way larger Paradigm models can be analyzed.
Keywords coordination, process algebra, Paradigm, vertical dynamic consistency, levels of
abstrac-tion, branching bisimulaabstrac-tion, globally inert, model reduction
1
Introduction
Within the current software architecture practice, architectures are mostly used for describing static as-pects of software systems. Techniques that allow system architects to describe coordination among components within an architecture and to reason about the dynamics of the system in its entirety, are not commonly used. The coordination description language Paradigm helps the designer to merge different dynamic aspects of a system. At the same time the language allows for the description of both detailed and global behaviour of an individual component i.e. its own specific behaviour and separately its inter-action with other components, and the language is particularly helpful in enforcing consistency in the behaviour of large sets of interrelated components.
The coordination modeling language Paradigm [9, 10] specifies roles and interactions within col-laborations between components. Interactions are in terms of temporary constraints on the dynamics of components. To underpin Paradigm models with formal verification and automated analysis, the Paradigm language has been linked with themCRL2 toolset [11] via its translation to the process algebra ACP [6, 3] and with the probabilistic modelchecker Prism [15, 4] via a direct encoding scheme. Process algebras (PA for short), such as CCS, CSP, LOTOS and ACP, provide a powerful framework for formal modeling and reasoning about concurrent systems, which turns out to be very suitable for our needs in the setting of coordination. The key concepts of compositionality and synchronization in process algebra are mostly exploited in our translation. As detailed and global aspects of component behaviour are specified by separate PA specifications, the vertical constraints are encoded through synchronizations expressing consistency of detailed and global component behaviour. Horizontal constraints at the protocol level are naturally captured by parallel composition, synchronization and encapsulation.
While the translation to ACP andmCRL2 allows for formal verification of Paradigm models [3, 2, 4], the omnipresent problem of state space explosion when analyzing large models occurs here as well. In the present paper, we address the question of reducing Paradigm models of coordination. The reduction method applies to a component’s behaviour, reducing the representation of the vertical constraints of that component by abstracting away any information on the component behaviour irrelevant for these constraints. To this end, the benefit of the translation of Paradigm language into ACP is twofold. On the one hand, we borrow the abstraction concept from PA and apply it directly in Paradigm on detailed behaviour. On the other hand, the translation provides us with a formal proof methodology to reason and guarantee that the reduced Paradigm model has the same properties as the original model. As a matter of fact, it has gradually become evident that separating detailed from global behaviour as supported by the Paradigm language, allows us to reason about reduction by abstraction in a rather natural way. We shall clarify this point after the Paradigm overview, at the end of Section 2.
Our work on dynamic consistency in a horizontal and vertical dimension has been influenced by the work of K ¨uster [7, 14]. Related work includes the Wright language [1] based on CSP provides FDR support to check both types of consistency properties. Other bridges from software architecture to auto-mated verification include the pipeline from UML via Rebeca and Promela to the SPIN model-checker and from UML via Object-Z and CSP to the FDR model-checker [19, 16]. Process algebra driven proto-typing as coordination from CCS is proposed in [18]. The skeletons generated from CCS-specifications overlap with Paradigm collaborations. In the TITAN framework [17], CCS is playing a unifying role in a heterogeneous environment for aspect-oriented software engineering. Recently the coordination lan-guage Reo has been equipped with a process algebraic interpretation [5, 12]. The encoding of Reo into mCRL2 and subsequent analysis has been integrated in the ECT toolset for Reo [13].
We present our idea by means of an example. The system we consider consists of n clients who try to get service from one server exclusively, a critical section problem, where the server is supposed to choose the next client in a non-deterministic manner. While the translation of the Paradigm model into PA for the example is done manually, the toolsetmCRL2 is exploited to generate the complete state spaces, on which further analysis can be done. Initial results show a substantial reduction in the size of the state space. In Section 2 Paradigm is summarized on the basis of the above example. Section 3 briefly introduces our process algebra translation for the example model. In Section 4 we present our reduction techniques. Section 5 concludes the paper.
2
Paradigm and a critical section model
This section briefly describes the central notions of Paradigm: STD, phase, (connecting) trap, role and consistency rule.
• An STD Z (state-transition diagram) is a triple Z = hST, AC, TRi with ST the set of states, AC the set of actions andTR⊆ ST × AC × ST the set of transitions of Z, notation x→ xa ′.
• A phase S of an STD Z = hST, AC, TRi is an STD S = hst, ac, tri such that st ⊆ ST, ac ⊆ AC and tr⊆ { (x, a, x′) ∈ TR | x, x′∈ st, a ∈ ac }.
• A trap t of phase S = hst, ac, tri of STD Z is a non-empty set of states t ⊆ st such that x ∈ t and x→ xa ′ ∈ tr imply x′∈ t. A trap t of phase S of STD Z connects phase S to a phase S′= hst′, ac′, tr′i of Z if t ⊆ st′. Such trap-based connectivity between two phases of Z is called a
• A partitionπ= { (Si, Ti) | i ∈ I } of an STD Z = hST, AC, TRi, I a non-empty index set, is a set of
pairs(Si, Ti) consisting of a phase Si= hsti, aci, trii of Z and of a set Tiof traps of Si.
• A role at the level of a partition π = { (Si, Ti) | i ∈ I } of an STD Z = hST, AC, TRi is an STD
Z(π) = hcST, cAC, cTRi with cST⊆ { Si| i ∈ I }, cAC⊆Si∈ITiandTRc⊆ { Si→ St j| i, j ∈ I,t ∈ cAC} a set
of phase transfers. Z is called the detailed STD underlying global STD Z(π), being role Z(π). • A consistency rule or protocol step for an ensemble of STDs Z, Z1, . . . , Zkand roles Z1(π1), . . . , Zk(πk)
is a nonempty set of phase transfers preceded by one extra transition. • Let Z : x→ xa ′∗ Z1(π1) : S′1
t
→ S′′1, . . . , Zk(πk) : S′k t
→ S′′k be a consistency rule for a given ensemble;
Zi, . . . , Zkare participants of it, Z is conductor.
• A Paradigm model is an ensemble of STDs, roles thereof and consistency rules.
The above notions constitute Paradigm models. The semantics thereof are roughly as follows: a consis-tency rule has synchronization of its phase transfers and its conductor transition, only if all connecting traps mentioned have been entered. Detailed transitions are allowed in the current state of an STD, only if the current phase (state) of each role of the STD contains the transition. In this way, phases are constraints on underlying STD dynamics imposed by protocols (sets of protocol steps). In a mirrored way, traps impose constraints on the behaviour at the protocol level, as traps are involved in the firing of consistency rules. Waiting Without leave AtDoor Out enter Waiting AtDoor Interrupt leave Out notYet request Waiting Busy AtDoor With explain thank done Without Interrrupt With Waiting Busy triv (a) (b) (c) done triv notYet request Out AtDoor leave thank explain enter
Figure 1: (a) detailed STD of Client, (b) partition of three phases, (c) global STD Client(CS). An STD is a step-wise description of the dynamics belonging to a component. It is visualized as a directed graph: its nodes are states, its action-labeled edges are transitions. Initial states are graphically indicated by a black dot-and-arrow. Figure 1a gives the so-called detailed STD of a Client in and around a shop: starting in state Out the client cycles through states Waiting, Busy, AtDoor and Out again, subsequently. The entire system we consider, contains n such clients, dynamically the same, plus one different component, the server. For the complete system the overall requirement is that only one client at a time, out of all n clients, is allowed to be in its state Busy. So, being in state Busy is a Critical Section problem (abbreviated CS). To solve it, ongoing Clienti dynamics is constrained by the phase
prescribed currently. Figure 1b visualizes phases Without, Interrupt and With. Phase Without excludes being in state Busy by prohibiting to take the actions explain and thank. Contrarily, phase With allows
both, going to and leaving state Busy. Finally, the intermediate phase Interrupt is an interrupted form of Without, as action enter cannot be taken, but being in state Waiting is allowed, though.
In view of a transfer from the current phase into a next phase to occur, enough progress within the current phase must have been made: a connecting trap has to be entered first. Figure 1b pictures relevant connecting traps for the above three phases, drawn as rectangles around the states the trap consists of. In particular, we need trap triv to be connecting from Without to Interrupt, trap notYet to be connecting from Interrupt back to Without, trap request to be connecting from Interrupt forward to With and finally, trap done to be connecting from With back to Without. In this manner, Figure 1b gives all ingredients needed for the dynamics of a ClientiSTD at the level of partition CS: see role Clienti(CS) in Figure 1c
and repeated in Figure 2a.
Interrupt[request] Interrupt[notYet] Interrupt[triv] Without[triv] With[done] With[triv] triv−use done−use done−register request−use request−register notYet−use notYet−register With Without Interrrupt done request notYet triv (b) (a)
Figure 2: (a) global process Client(CS) and (b) its refinement in view of translation.
Figure 2b presents a slightly refined diagram of the proper role STD in part (a). State names here, additionally keep track of the trap most recently entered within a phase, as if it could be taken as a smaller phase committed to within the larger one imposed. Action names still refer to a trap that is entered, but they additionally discriminate between, first, registering the trap has been entered and, second, thereafter
using this for a phase transfer. This more refined view represents the starting point for the ACP encoding
of the global process, as discussed in the next section.
So far, we have discussed ‘sequential composition’ of constraints: imposed phases alternated with traps committed to. Semantically, any current phase constrains the enabled transitions to those belonging to the phase. So, at any moment a current detailed state belongs to the current phase too. From this it follows, that the dynamics of the detailed STD and of the global STD are consistent, the current global phase reflects the current local state. Paradigm’s consistency rules are to the essence of ‘parallel composition’: they express coupling of role steps of arbitrarily many participants and a detailed step of one conductor. Any consistency rule specifies the simultaneous execution of the steps mentioned in the rule, a transition of the conductor and phase transfers for the participants.
To continue the example of n clients getting service, one at a time, we present a non-deterministic coordination solution for the n clients via a server. The non-deterministic server checks the clients in arbitrary order. If a client, when checked, wants help, it gets help by being permitted to enter the critical section. If not, permission to enter is refused to it. Only after a client’s leaving the critical section, the server stops helping it by returning to the idle position, from which it arbitrarily selects a next client for checking. In the example, the server provides a unique conductor step for each consistency rule. The STD Server of the server is drawn in Figure 3. As conductor, detailed steps of Server need to be coupled to phase transfers of each Clienti, 1≤ i ≤ n.
continue refuse permit continue continue refuse refuse permit permit
. . .
check2 NDHelping2 NDChecking2 Idle check1 checkn NDHelping1 NDHelpingn NDChecking1 NDCheckingn ServerFigure 3: STD non-deterministic server Server.
Server : Idle checki
−−−−→ NDCheckingi ∗ Clienti(CS) : Without−−→ Interrupttriv (1)
Server : NDCheckingi
refuse
−−−−→ Idle ∗ Clienti(CS) : Interrupt−−−−→ WithoutnotYet (2)
Server : NDCheckingi
permit
−−−−→ NDHelpingi ∗ Clienti(CS) : Interrupt
request
−−−−→ With (3)
Server : NDHelpingi
continue
−−−−−→ Idle ∗ Clienti(CS) : With−−−→ Withoutdone (4)
Note that for this protocol, each conductor step of the server corresponds to a phase change of exactly one client. E.g., the server moves from the stateIdletoNDCheckingiiff the global client processClienti(CS)
changes from the phase Withoutto the phase Interrupt. The server then makes a checki transition. In general, there is a precondition, however. Within the phaseWithoutsufficient progress should have been made, such that the particular trap has been reached. In this case, it is the trivial trap triv rendering the requirement superfluous, as the trivial trap, containing all states of the phase Without, is trivially reached. For the actual checking, the next two consistency rules, dependent on the trapnotYetandrequest, respectively, decide the target of the conductor transition and the next participant phase, viz. state Idle and phaseWithoutor stateNDHelpingiand phaseWith, respectively. The last consistency rule couples the
conductor’s returning from stateNDHelpingitoIdlewith trapdoneof phaseWithhaving been entered.
The consistency rules specifyhorizontal dynamic consistency, i.e. across components, here between server and clients. Such specification is about coordination, i.e. what Paradigm actually models, step-wise computation of next behavioural constraints. The constraining property imposed by a phase implies, an underlying Clienti transition is allowed only if it belongs to the phase that corresponds to the current
state of the role ofClientiin theCScollaboration, i.e. the current state of the global STDClienti(CS). The
constraining propertyClienti commits to by entering a trap, allows for a phase transfer, i.e. a transition
of Clienti(CS), once the (connecting) trap is entered. These two constraining properties syntactically
guaranteeverticaldynamic consistency, i.e. within a component between its underlying STD and its role. As mentioned in Section 1, is has become evident to us that separating detailed from global be-haviour as supported by the Paradigm language, allows one to reason about reduction by abstraction in a rather natural way. The intuitive explanation for this is as follows: Global behaviour, actually defin-ing phases a system needs to go through durdefin-ing a particular coordination solution, is built on top of the detailed behaviour: each global phase represents a sub-behaviour of the underlying detailed behaviour. Nevertheless, not every action at the detailed level affects the current global phase. Only some actions may enable a next phase transfer and hence may affect the protocol execution. Thus, it is natural to try to detect the detailed actions that do not matter for, i.e. that cannot be observed at, the protocol level. By hiding them, a reduced detailed behaviour is obtained, just containing all relevant information and actions needed for proper execution of the component role within the protocol. As we shall show for
our running example, this information can be extracted from the hierarchical structure per component in the Paradigm model, see Subsection 4.1. Note that all interaction between components (horizontal) and all hierarchical structure within components (vertical), as specified in the Paradigm model in an explicit manner, are flattened in the PA translation and hence their character being either horizontal or vertical, gets lost. Thus, after the PA translation only a single communication pattern remains, from which it is no longer straightforward to extract information needed for proper reduction of detailed behaviour.
Yet another aspect of the Paradigm model that can be justified and confirmed by the approach taken here is discussed shortly in the paper, see Subsection 4.2. From the definition of Paradigm, although provided with a formal operational semantics, it is not straightforward to see to what extent a compo-nent’s detailed behaviour is not affected by some constraints or coordination rule. In particular, consis-tency rules for some complex model may have an unforeseen effect on detailed component behaviour, in particular a deadlock at the detailed level. The translation from Paradigm to ACP combined with the abstraction techniques discussed in the next section supports formal verification of separate protocols and of overall coordination.
3
Paradigm model as a process algebraic specification
In this section we show by means of the example introduced in Section 2, how a Paradigm model can be translated into ACP. The general translation has been defined in [3] to which we refer for more detail. Roughly, each STD will be represented by a recursive specification. Vertical consistency in Paradigm has to be expressed explicitly. In particular, to represent the interaction of a detailed STD and the global STD, we use actionsok!(.)andok?(.)that take the labels ofdetailed stepsas their argument. The complementary actions synchronize if the step of the detailed STD is allowed by the current phase of the global STD as constraint. Thus, synchronization of actions ok!(·)and ok?(·)between global STD and detailed STD reflect the current permission for the detailed step to be taken.
In addition, we use the complementary actionsat!(.)and at?(.)that take detailed statesas their argu-ments. The complementary actions synchronize if the step to be taken by the global STD is allowed by the current trap of the detailed STD as constraint. Upon synchronization ofat!(·)and at?(·)the global process will update its trap information, if applicable. For the communication within the protocol, here between the server and its clients, actionscrule!(.)on the side of a conductor are meant to complement crule?(.)actions on the side of the employees. Synchronization leads to execution of the corresponding consistency rule: a detailed transition of the conductor, phase changes for the employees involved.
For the concrete example the above amounts to the following. We adorn thenprocessesClientiwith
the actionsat!, conveying state information, and actionsok?, regarding transition eligibility. \
Clienti = Outi
Outi = at!(Outi) · Outi+ ok?(enteri) · Waitingi
Waitingi = at!(Waitingi) · Waitingi+ ok?(explaini) · Busyi
Busyi = ok?(thanki) · AtDoori
AtDoori = at!(AtDoori) · AtDoori+ ok?(leavei) · Outi
The LTS of Client\i ofClienti is given in Figure 4a (with the subscript i suppressed). The definition of
processClient\i assures, the process really starts in close correspondence to starting stateOut from
Fig-ure 1a. The definition of processOutiexpresses: (1) upon being asked, it can exchange state information
Figure 1a, in view of continuing with processWaitingithereafter. Note, in the definition of processBusyi the possibility for exchange of state information is not specified, as asking for it does never occur. Note, in Figure 1b, stateBusydoes not belong to trapdone.
With[done] ok!(leave) Waiting Busy Inter[triv] With[triv] Inter[notYet] at?(Out) at?(AtDoor) ok!(enter) ok!(leave) at?(AtDoor) ok!(leave) ok!(thank) ok!(explain) at?(Waiting) Without[triv] Inter[request] Out AtDoor ok?(leave) at!(Out) at!(AtDoor) ok?(thank) ok?(explain) at!(Waiting) ok?(enter) (a) (b) crule?(notYet) crule?(triv) crule?(request) crule?(done)
Figure 4: Processes (a) \Client and (b) \Client(CS).
In a similar manner, the nprocesses Clienti(CS)are augmented with the actions at?and ok!. Now,
at the global level, the relevant information is the pair of the current phase and the current trap. For example, the recursion variableWithouti[triv]represents that Clienti is constrained to phase Withoutand
hasn’t reached a specific trap, whereas Interrupti[notYet]reflects that Clienticommitted to phase Interrupt
resides in trapnotYet. As these global processes play a participant role in the protocol, thecrule?actions for engaging in a consistency rule have been put in place as well.
\
Clienti(CS) = Withouti[triv]
Withouti[triv] = ok!(leavei) · Withouti[triv] + ok!(enteri) · Withouti[triv] +
crule?(trivi) · Interrupti[triv]
Interrupti[triv] = at?(AtDoori) · Interrupti[notYet] + at?(Outi) · Interrupti[notYet] + at?(Waitingi) · Interrupti[request] + ok!(leavei) · Interrupti[triv]
Interrupti[notYet] = ok!(leavei) · Interrupti[notYet] + crule?(notYeti) · Withouti[triv]
Interrupti[request] = crule?(requesti) · Withi[triv]
Withi[triv] = at?(AtDoori) · Withi[done] + ok!(explaini) · Withi[triv] +
ok!(thanki) · Withi[triv]
Withi[done] = crule?(donei) · Withouti[triv]
The corresponding LTS of the specificationClient\i(CS)ofClienti(CS)is given in Figure 4b.
As above, process Client\i(CS)is defined in close correspondence toWithouti[triv]being starting state
in Figure 2b. Theok!(.)-actions provide the permission answers to requests from Client\i to take a
de-tailed step. The at?(.)-actions ask for state information relevant for deciding a next, smaller trap has been entered. Thecrule?(.)-actions correspond to a phase change, so they synchronize with a particular conductor step.
The final component of the Paradigm model that needs to be translated into ACP is the non-determinis-tic serverServer. In fact, the STD of the server as given in Figure 3 exactly corresponds to its recursive specification; we only rename each transition labelℓfrom Figure 3 intocrule!(ℓ)to stay consistent with the general translation as defined in [3], for instance permiti is renamed into crule!(permiti) in the PA
specification. There is neither anyok(.)action nor anyat(.)action added here. This component plays the conductor role in the protocol and as such it is represented only by its detailed behaviour (detailed STD). Therefore, no vertical constraints are imposed on its detailed behaviour.
\
Server = Idle
Idle = crule!(check1) · NDChecking1+ · · · + crule!(checkn) · NDCheckingn
NDCheckingi = crule!(permiti) · NDHelpingi+ crule!(refusei) · Idle
NDHelpingi = crule!(continuei) · Idle
For the communication function ‘|’ we put at!(s) | at?(s) =τ for ‘states’ s= Outi,Waitingi,AtDoori, and
ok?(a) | ok!(a) = ok(a), for actions a= enteri,explaini,thanki,leavei. Note, ACP allows to keep the result of
the synchronization ofok?(a)andok!(a)observable, here as the actionok(a), for suitablea. We exploit this feature below to express system properties, since the synchronization actionsok(a)describe detailed steps taken by clients. E.g., observingok(enteri)indicates a service request made byClienti. On the contrary,
synchronization ofat!()andat?()is only used to update the information of the current detailed state. The resulting actions are internal to the component and not needed in any further analysis. Therefore, we safely useτfor the synchronization ofat?()andat!().
Finally, we need to encode the coordination captured by the consistency rules. For example, consis-tency rule (1) couples a detailedcheckistep of theServer, being the conductor of theCSprotocol, to the
globaltrivstep ofClienti, being a participant in theCSprotocol. The net result is a state transfer, i.e. a
tran-sitionIdle−−−−→ NDCheckingchecki
ifor the server, and a phase transfer, i.e. a transitionWithout
triv
−−→ Interruptin the global STD for thei-th client. Similar correspondences apply to the other consistency rules. Therefore, we put
crule!(checki) | crule?(trivi) = checki
crule!(permiti) | crule?(requesti) = permiti
crule!(refusei) | crule?(notYeti) = refusei
crule!(continuei) | crule?(donei) = continuei
As usual, unmatched synchronization actions will be blocked to enforce communication. We collect those in the setA= { crule!, crule?, at?, at!, ok?, ok! }. Finally, the process for the collaboration of the server and thenclients is given by
∂A( \Client1k \Client1(CS) k . . . k \Clientnk \Clientn(CS) k \Server) (5)
The next section is concerned with the intertwining of detailed and the global behavior, and possible ways to reduce the component specification by abstracting away from specific detailed activities. The process algebraic specification of our running client-server example will be used below to establish relations be-tween Paradigm models before and after reduction. Therefore, it comes in handy to represent the overall behaviour of theClientcomponent as the parallel composition of its detailed and global behaviour. To this end, we denote the set of states of the detailed processClient\byStatesD= { Out, Waiting, Busy, AtDoor },
the set of labels of its transitions by of detailedLabelsD= { enter, explain, thank, leave }and we put
AT= { at!(s), at?(s) | s ∈ StatesD} OK= { ok!(a), ok?(a) | a ∈ LabelsD}
and defineH= AT ∪ OK. Then the process combining detailed behaviour ofClient\and global behaviour of \
Client(CS)can be expressed asClient(DG)\ , withDGreferring to ‘detailed’ and ‘global’, given by \
crule?(request) Inter[triv] Waiting Busy With[triv] Inter[triv] AtDoor Out With[triv] Waiting Waiting Waiting With[done] With[triv] AtDoor AtDoor AtDoor Without[triv] Inter[notYet] AtDoor Out ok(enter) ok(explain) ok(leave) ok(leave) ok(thank) ok(leave) Inter[notYet] Inter[triv]Out Without[triv] Without[triv] Inter[request]
crule?(done) crule?(notYet) crule?(triv) crule?(notYet) crule?(triv) crule?(triv) τ τ τ τ
Figure 5: Process \Client(DG)
Figure 5 shows the behavior ofClient(DG)\ graphically. The process describes the way the detailed and global behaviors occur and constrain each other.
On the one hand, steps taken at the detailed level influence the current phase at the global level, and therefore allows and forbids certain phase transitions at the global level. The global process and its transitions, are ‘navigated’ by the activities executed at the detailed level. For instance, the effect of the detailed transitionok(enter)is described with the appearance of twotrivtransitions. One of them captures the scenario in which the client has not yet required any service, which means thatenter has not been taken yet at the detailed level, although the server (conductor) may offer service. It can be observed that this transition is followed by the phase transitionnotYetwhich brings the process back to the initial state. We can also observe that as soon as the detailed transitionenteris taken, the enabledtrivtransition differs from the previous one.
On the other hand, fromClient(DG)\ we can observe how each phase, i.e. a global state, constrains the steps that can be taken locally. Moreover, it is specified exactly how a trap that is reached blocks any detailed transitions, just as expected. For instance, we see that the action ok(leave) on top of Figure 5 cannot be executed before the phase is changed, i.e. a step fromWith[done]toWithout[triv]via the global transition crule?(done). Note that such details, which are explicit and easily observable from the ACP specification of the compositionClient(DG)\ , cannot be directly detected in the Paradigm model.
Once systems are modeled algebraically, their behaviours can be compared. Comparison is typically done by means of equivalence relations, chosen appropriately to preserve certain properties. Since we aim at the mCRL2 toolset for tool support, we choose for branching bisimulation [8] as the equivalence relation we apply. Indeed, branching bisimulation is the strongest in the spectrum of behavioural equiva-lence relations, but yet weak enough to identify sufficiently many systems. Below we adapt the definition from [8] (originally defined on labelled transition systems) to STDs with uniquely indicated initial states. In fact, labelled transition systems (LTS), as a (visual) representation of process algebraic specifications, can be seen also as STDs. Therefore, in the sequel we do not make explicit distinction between LTSs and STDs.
Definition 1. For two STDs Z= hST, AC, TSi, Z′= hST′, AC′, TS′i a symmetric relation R ⊆ ST × ST′is called a branching bisimulation relation if for all s∈ ST and t ∈ ST′such that R(s,t), the following condition is met: if s−→ sa ′in Z, for some a∈ AC ∪ {τ}, then either a =τand R(s′,t), or for some n ≥ 0, there exist t1, . . . ,tnand t′in ST′such that t−→ tτ 1−→ . . .τ −→ tτ n
a
− → t′
For two STDsZandZ′, two statess∈ Zandt∈ Z′are called branching bisimilar, notations↔bt, if there
exists a branching bisimulation relationRforZ andZ′such thatR(s,t). The STDsZandZ′are branching bisimilar, notationZ ↔bZ′if their initial states are branching bisimilar.
4
Reduction of the client processes
In Section 3 we explained how ACP specifications are obtained from the detailed and global client STDs, and how ACP’s communication function captures synchronization of detailed and global steps, guaranteeing consistent dynamics at both levels. Based on the complete client component we are able to make several observations regarding the Paradigm approach to separate the detailed from the global behaviour.
4.1 First-reduce then-compose
The global STD of a component is an abstract representation of its detailed STD. It represents the part of the behaviour of the component that is essential for the interaction within a given collaboration. In general, for the global behaviour not all local transitions are relevant, most are not influencing the overall coordination at all. Although not always easy to isolate, in actual full-fledged systems only a restricted part of the whole system provides a specific functionality. In such a situation, from a modeling perspec-tive it is clarifying to abstract away the irrelevant part and to concentrate on a reduced detailed behaviour containing the relevant interaction. As a consequence, dealing with models that are purposely made concise becomes simpler, more feasible and less error-prone.
In the previous sections, we have made a Paradigm model out of the components: detailed client STDs, their global STDs and the server STD. Moreover, we have presented their translations into process algebraic specifications. The overall behaviour of the client-server system is obtained by putting the components involved in parallel and make them interact. In this section we show that we can achieve the same total behaviour of the client-server system byfirst reducingthe client components andthen composing the reduced versions afterwards with other components of the system. Reduction is directly applied on the original Paradigm client model, by abstracting away irrelevant states and local transitions.
It is intuitively clear that the global behaviour alone is not branching bisimilar to the overall client behaviour Client(DG)\ . This is because some local steps change the further global behaviour. As a con-sequence, such local transitions can be detected at the global level. Extending terminology going back to [8], we call these transitionsglobally non-inert. Similarly, a local transition is referred to asglobally inert if it cannot be observed, explicitly or implicitly, at the global level. More specifically, it can be detected whether local action enter has been taken or not by observing whether the global transition notYet or global transitionrequest follows after global steptriv. Putting it differently, the transition labeledenter makes the difference for phaseInterruptof residing in trapnotYetor in traprequest, as can be seen in Fig-ure 1. Thus, the local transitionenteris not globally inert. In a similar manner, the local actionthankis not globally inert as it enables –and so it can be detected– the execution of the global actiondone. In terms of the partition, in phaseWiththe action thankenters the trapdone. On the other hand, again referring to the phases ofClient(CS)in Figure 1b, we see that the actionleaveis in each phase either within a trap (phasesWithoutandInterrupt) or not possible at all (phaseWithis missing the target stateOut). Likewise, the actionexplainis not possible (phases WithoutandInterruptare missing state Busy) or doesn’t change the trap information (in phaseWiththe transition doesn’t enter the trapdone).
Definition 2. Let a Paradigm model be given. A detailed transition x→ xa ′of a participant of a protocol is called globally inert with respect to its partitionπ= { (Si, Ti) | i ∈ I } if for all traps t in Tiit holds that x∈ t ⇐⇒ x′∈ t whenever both x, x′∈ Si,
i∈ I. An action a is called globally inert for a participant of a protocol with respect to a partition, if all a-labeled transitions
are.
Using the notion of detailed transitions being globally inert or non-inert, we can reduce the detailed STD of the client. After renaming all globally inert transitions intoτ, we can identify branching bisimilar states. The resulting quotient STD for the client carries the behaviour that is necessary and sufficient for the global STD to interact with the other components, including the conductor of the collaboration. The composition of the process algebraic specifications of the quotient STD and the globalClient(CS)\ behaves exactly (up to branching bisimulation) as the behaviour of the composition of the original detailed and global STDs together as represented byClient(DG)\ . By congruence, composition of either of these systems with the other clients and the server leads, modulo branching bisimulation equivalence, to the same behaviour. This is summarized by the next result, whereτI, for a set of labelsI, represents the hiding of
the actions inIfromPby renaming them intoτ, and∂J(P), for a set of labelsJ, is the encapsulation of the
actions ofJfromPby blocking and transition forPwith label inJ.
Lemma 3. Let G⊆ LabelsDbe a subset of globally inert actions. Then it holds for the induced quotient QClient of Client that
(i) QClient↔bτG(Client), and
(ii) ∂H( \QClientk \Client(CS) ) ↔bτOK(G)( \Client(DG) ), where OK(G) = { ok(a) | a ∈ G }.
Q P Q P Waiting Busy Out AtDoor thank enter at!(Q) at!(P) ok?(thank) ok?(enter) thank enter (b) (c) (a) P τ τ Q
Figure 6: (a) processτG(Client) and related states, (b) quotient STD QClient and (c) \QClient.
Proof. We consider the case of the maximal set of local actions that are globally inert, i.e. for G= { explain, leave }. Split the
set of states StatesDof the detailed STD into P= { Out, AtDoor } and Q = { Waiting, Busy }. Let QClient be the induced
quotient STD, the STD obtained from Client by identifying the states Out and AtDoor as well as the states Waiting and Busy. The processes QClient andτG(Client) are shown in Figure 6ab. A branching bisimulation between QClient andτG(Client)
can be immediately established, which proves the first part of the lemma.
In order to prove the second part of the lemma, we first translate QClient into the process algebraic specification \QClient
whose STD is shown in Figure 6c. In order to compute the composition of \QClient and \Client(CS) the communication function
has to be adapted to \QClient. For the \QClient process Out and AtDoor are identified into the P. Similar for Waiting, Busy, now
represented by Q. Thus, a detailed \QClient communication intention conveying ‘at P’ or ‘at Q’ updates the global process about
the current local state. Hence, we extend the communication function with at!(P) | at?(Out) =τ, at!(P) | at?(AtDoor) = τ, at!(Q) | at?(Waiting) =τ and at!(Q) | at?(Busy) =τ. Now we consider the process∂H( \QClientk \Client(CS) ) with
H= AT ∪ OK as defined in Section 3, with AT extended accordingly. The composition is shown in Figure 7a, the process τOK(G)( \Client(DG) ) is depicted in Figure 7b. It is straightforward to establish a branching bisimulation between these two processes.
State names ofτOK(G)( \Client(DG) )have been suppressed in Figure 7b for readability. Note that the number of states in τG( \Client(DG) ) is 13, while the first-reduce then-compose approach with QClient\ and Client(CS)\
ok(thank) (a) ok(enter) ok(enter) ok(thank) (b) crule?(notYet) crule?(triv) crule?(triv) crule?(request) crule?(done) crule?(triv) crule?(triv) crule?(notYet) crule?(done) crule?(notYet) crule?(triv) crule?(request) τ τ τ τ τ τ τ τ τ τ τ
Figure 7: Branching bisimilar processes: (a)∂H( \QClientk \Client(CS)) (b) processτOK(G)(\Client(DG)).
P’ Q’ ok(explain) ok(leave) (a) (b) crule?(notYet) crule?(triv) crule?(done) explain leave crule?(request) τ τ τ
Figure 8: (a) adapted quotient process QClient, (b) composition of new \QClient and \Client(CS).
It is obvious that not every choice of actions at the detailed level has the property of Lemma 3. For exam-ple, selecting the set of actionsG′= { enter, thank }, yields a split-up into{ Out, Waiting }and{ Busy, AtDoor } and another reduction, depicted in Figure 8a. However, this reduction is not a proper one as the induced composition of the reduced detailed and the global behaviour in Figure 8 is not branching bisimilar with the original compositionτOK(G′)(\Client(DG)).
It is instructive to consider a slightly different client. Now we assume that the client may decide to draw back the service request and return back to the initial stateOut. The detailed STD and the global STD shown in Figure 9 differ from the model in Figure 1 only in thereturntransition. If we apply the same reasoning of Lemma 3 to this model of a client, we observe that the return transition does not change the situation regarding the reduction of the local behaviour. Again, the enter transition is not globally inert, for the same reasons as in the previous model. Similarly,returnis also not globally inert. Still, the original quotient from Lemma 3 based on the inert actions explain and leave yields a proper reduction. See Figure 10.
The last example we consider as a further variation, namedClient′′, is presented in Figure 11. The only change is now in the global STDClient′′(CS). The client is provided service unconditionally, i.e. without interruption, even without needing it. But, if it doesn’t need it the client is handled as if it does not need service any longer. The simplified global behaviour, with less phases and less traps, imposes less constraints on the detailed behaviour. Thus, the relation between the detailed and the global behaviour
Waiting Busy Waiting Waiting AtDoor Waiting Busy AtDoor triv (b) (a) Out AtDoor leave explain thank enter return Without leave AtDoor Out Interrupt leave Out notYet request With explain thank done enter return
Figure 9: Modified client: (a) STD of Client′, (b) phase and trap constraints.
ok(thank) (a) ok(enter) ok(thank) (b) ok(return) ok(enter) ok(return) crule?(done) crule?(triv) crule?(request)
crule?(triv) crule?(notYet) crule?(done) crule?(notYet)crule?(triv)crule?(triv) crule?(notYet)
crule?(request) crule?(triv) τ τ τ τ τ τ τ τ τ τ τ
Figure 10: Branching bisimilar processes: (a)∂H(QClient′k \Client′(CS)), (b)τOK(G)(\Client′(DG)).
is rather loose. In Figure 12 the behaviour of processClient\′′(CS)and the parallel compositionClient\′′(DG) are graphically represented. In order to show this formally, we again apply thefirst-reduce then-compose approach along the lines of Lemma 3 by taking the trivial split-up ofStatesDalong all detailed actions
inLabelsD. Thus, we identify all local actions inG′′= LabelsD as globally inert. The resulting quotient
STD ofQClient′′and its process algebraic translation are shown in Figure 13bc. The composition of the reduced detailed behaviour ofClient′′with its global behaviour has now 3 states as shown in Figure 13d. A branching bisimulation between this process and the corresponding processτG′′( \Client′′(DG) )can be
established easily.
In order to investigate the effect of the reduction on a larger scale, we have analyzed the client-server system using themCRL2toolset [11] and compared the implementation of the system using either the orig-inalClient\ components or their reduced versionsQClient\ . The translation of ACP-based specifications of thenclientsClient\i, the globalClient\i(CS)and the serverServerinto the input language of themCRL2toolset,
enter Waiting AtDoor Busy Waiting Without leave AtDoor Out enter triv Waiting Busy (b) leave Out explain thank With done (a) Out AtDoor leave explain thank
Figure 11: The Paradigm model of Client′′.
With[done] Out With[done] Out Waiting Busy ok(enter) ok(explain) ok(leave) ok(leave) ok(thank) ok(leave) With[triv] Waiting AtDoor With[triv] AtDoor With[triv] AtDoor AtDoor Out With[done] Without[triv] With[triv] With[triv] Without[triv] Without[triv] ok!(enter) ok!(leave) emp(triv) Without[triv] With[triv] ok!(thank) ok!(explain) at?(Out) emp(done) at?(AtDoor) ok!(leave) (a) crule?(triv) (b) crule?(done) crule?(triv) crule?(done) crule?(triv) τ τ
Figure 12: Processes \Client′′(CS) and \Client′′(DG).
thefirst-reduce then-composeprinciple yields a significant decrease in the size of the state space in a number of cases. The results are collected in Table 1.
4.2 Extracting detailed behaviour
Intuitively it is clear that in the case of the client-server example the global behaviour does not change or influence the local behaviour. In fact, if in the total client behaviour Client(DG)\ we hide the actions crule?(·)from the setE performed by the global process (E for external), we obtain a process which is branching bisimilar to the detailed behaviourClient. This is expressed by the following lemma.
Lemma 4. Client↔bτE( \Client(DG) ).
Proof. We start from the process \Client(DG) as shown in Figure 5. After hiding the actions in E, i.e. renaming them intoτ, the processτE( \Client(DG) ) is obtained, shown in Figure 14. A branching bisimulation equivalence between this process and
P P Busy Out AtDoor (d) crule?(done) crule?(triv) (a) (b) (c) Waiting τ τ τ τ τ τ τ τ at!(Sd)
n with \Client with \QClient states transitions states transitions
2 69 142 32 54 3 297 819 92 204 4 1161 3996 240 656 5 4293 17685 592 1920 6 15309 73386 1408 5280 10 – – 36863 212480
(no result for \Client with n=10 within 24 hours) Table 1: Effect of the first-reduce then-compose approach.
Client process can be defined without difficulty. In Figure 15 related states are connected by differently dotted lines. Note, we
have mirrored the Client orientation with respect to the North-East South-West diagonal.
Inter[triv] Waiting Busy With[triv] Inter[triv] AtDoor Out With[triv] Waiting Waiting Waiting With[done] With[triv] AtDoor AtDoor AtDoor Inter[notYet] AtDoor ok(leave) Out ok(enter) ok(explain) ok(leave) ok(thank) Without[triv] Without[triv] Inter[request] Inter[notYet] Out Without[triv] Inter[triv] ok(leave) τ τ τ τ τ τ τ τ τ τ τ
Figure 14: ProcessτE(\Client(DG)).
In the general situation, the statement of the lemma provides a check on the constraints imposed by the global STD on the detailed one. In case the statement of the lemma holds, the complete behaviour of the component is preserved in the consistent composition, assuming the coordinating protocol provides all phase transfers in some order. In case the statement of the lemma does not hold, part of the original detailed behaviour has been eliminated because of the participation with the protocol. This may be deliberate and allows for further reduction of the detailed STD. This may be accidental, requiring the overall coordination to be revised.
5
Concluding remarks
In a Paradigm model several STDs may belong to the same component, describing the component’s dynamics either at various levels of abstraction (detailed vs. global STDs) or describing different roles
Inter[triv] AtDoor Out AtDoor Busy Out Inter[request] With[triv] Waiting Waiting Waiting With[done] With[triv] AtDoor AtDoor AtDoor ok(enter) ok(explain) ok(leave) ok(thank) ok(leave) ok(leave) Busy With[triv] Out Inter[triv] Waiting Without[triv] AtDoor Inter[notYet] Inter[notYet] Inter[triv] Out Without[triv] Without[triv] Waiting explain leave thank enter (a) (b) τ τ τ τ τ τ τ τ τ τ τ
Figure 15: Branching bisimulation between (a)τE(\Client(DG)) and (b) Client.
of the component in various collaborations. Collaboration between components is described in terms of dynamic constraints. Vertical consistency is maintained by keeping phases vs. detailed transitions and traps vs. transfers aligned. Starting point of our investigation here is the translation of Paradigm models into the process algebra ACP and its coupling with themCRL2toolset for subsequent automated analysis. In the translated model, every STD from the Paradigm model is represented by a recursive specification; the total behaviour of a single component is obtained as a composition of the recursive specifications of the detailed and the global component’s STDs; the overall system is specified as a parallel composition of all components.
In this paper we have described a method to reduce the Paradigm representation of the detailed STDs of the components, yielding reduction of the overall Paradigm models, but preserving the overall be-haviour. The reduction boils down to inferring globally inert detailed steps. By abstracting them away a smaller representation of the detailed component is obtained. This representation contains all informa-tion about the constraints the detailed behaviour imposes on the global behaviour(s) of the component. The formal validation that the reduction, indeed, does not change the overall model behaviour is achieved via the process algebraic representation of the model: we show for our client-server example that the re-duced model is branching bisimilar to the original one, having the same properties. Furthermore, by means of a proper abstraction, in this case applied at the global level, we can observe directly from the model, by a direct comparison, in which way the global behaviour, and thus the collaboration, affects the components’ detailed behaviour. In case no influence is to be expected, it is sufficient to show that the component model is equivalent, up to branching bisimulation, to the detailed behaviour after all global steps are abstracted away.
As to the contribution of this paper, we have established a further connection of process algebra and its supporting apparatus to the domain of coordination. In particular, abstraction and equivalences, typical for process algebra, become techniques that can be applied to coordination models, via the estab-lished link of the Paradigm language and ACP, in our case. Thus, coordination can be initially modeled in the Paradigm language which offers compositional and hierarchical modeling flexibility. Then, model reduction can be applied, if appropriate. Finally, via its process representation the model can be formally analyzed.
reduction, in particular in a situation with overlapping or orthogonal coordination. More specifically, it is interesting to study the notion of globally inert detailed steps for a component that participates in multiple collaborations. We plan to investigate whether other techniques from process algebraic analysis, e.g. iterated abstraction, and pattern-based simplifications can be beneficial for the modeling with Paradigm.
References
[1] R.J. Allen (1997): A Formal Approach to Software Architectures. Ph.D. thesis, Carnegie Mellon University. [2] S. Andova, L.P.J. Groenewegen, J.H.S. Verschuren & E.P. de Vink (2009): Architecting Security with
Paradigm. In: Architecting Dependable Systems VI, LNCS 5835, pp. 255–283. doi:10.1007/
978-3-642-10248-6_11.
[3] S. Andova, L.P.J. Groenewegen & E.P. de Vink (2010): Dynamic Consistency in Process Algebra: From
Paradigm to ACP.Science of Computer Programming. doi:10.1016/j.scico.2010.04.011, 45pp.
[4] S. Andova, L.P.J. Groenewegen & E.P. de Vink (2010): Towards Dynamic Adaptation of Probabilistic
Sys-tems. In T. Margaria & B. Steffen, editors: Proc. ISOLA 2010, LNCS 6416, pp. 143–159. doi:10.1007/
978-3-642-16561-0_19.
[5] F. Arbab (2004): Reo: A Channel-based Coordination Model for Component Composition. Mathematical
Structures in Computer Science14, pp. 329–366. doi:10.1017/S0960129504004153.
[6] J.C.M. Baeten, T. Basten & M.A. Reniers (2010): Process Algebra: Equational Theories of Communicating
Processes.Cambridge Tracts in Theoretical Computer Science50, CUP.
[7] G. Engels, R. Heckel, J.M. K¨uster & L. Groenewegen (2002): Consistency-Preserving Model Evolution
through Transformations. In J.-M. J´ez´equel, H. Hußmann & S. Cook, editors:Proc. UML 2002, LNCS 2460, pp. 212–226. doi:10.1007/3-540-45800-X_18.
[8] R.J. van Glabbeek & P. Weijland (1996): Branching time and abstraction in bisimulation semantics.Journal
of the ACM43, pp. 555–600. doi:10.1145/233551.233556.
[9] L. Groenewegen & E. de Vink (2002): Operational Semantics for Coordination in Paradigm. In F. Arbab & C. Talcott, editors:Proc. Coordination 2002, LNCS 2315, pp. 191–206. doi:10.1007/3-540-46000-4_20. [10] L. Groenewegen & E. de Vink (2006): Evolution-On-The-Fly with Paradigm. In P. Ciancarini & H. Wiklicky,
editors:Proc. Coordination 2006, LNCS 4038, pp. 97–112. doi:10.1007/11767954_7.
[11] J.F. Groote et al. (2007): The Formal Specification Language mCRL2. In E. Brinksma et al., editor:Methods for Modelling Software Systems, IBFI, Schloss Dagstuhl. 34 pages.
[12] N. Kokash, C. Koehler & E.P. de Vink (2010): Time and Data-Aware Analysis of Graphical Service Models
in Reo. In J.L. Fiadeiro A. Maggiolo-Schettini & S. Gnesi, editors:Proc. SEFM 2010, IEEE, pp. 125–134. doi:10.1109/SEFM.2010.26.
[13] C. Krause (2011): Reconfigurable Component Connectors. Ph.D. thesis, Leiden University. To appear. [14] J.M. K¨uster (2004): Consistency Management of Object-Oriented Behavioral Models. Ph.D. thesis,
Univer-sity of Paderborn.
[15] M.Z. Kwiatkowska, G. Norman & D. Parker (2009): PRISM: probabilistic model checking for performance
and reliability analysis. SIGMETRICS Performance Evaluation Review36, pp. 40–45. doi:10.1145/
1530873.1530882.
[16] M. M¨oller, E.-R. Olderog, H. Rasch & H. Wehrheim (2008): Integrating a formal method into a
soft-ware engineering process with UML and Java. Formal Aspects of Computing, pp. 161–204. doi:10.1007/
s00165-007-0042-7.
[17] M.A. P´erez-Toledano, A. Navasa, J.M. Murillo & C. Canal (2007): TITAN: a Framework for Aspect-Oriented
[18] N.F. Rodrigues & L.S. Barbosa (2005): Architectural Prototyping: From CCS to .Net. In A. Mota & A.V. Moura, editors:Proc. SBMF 2004, ENTCS 130, pp. 151–167. doi:10.1016/j.entcs.2005.03.009. [19] M. Sirjani, A. Movaghar, A. Shali & F.S. de Boer (2004): Modeling and Verification of Reactive Systems
