Dynamic System Adaptation by Constraint Orchestration
For Paradigm models, evolution is just-in-time specified coordination conducted by a special reusable component McPal. Evolution can be treated consistently and on-the-fly through Paradigm's constraint orchestration, also for originally unforeseen ev…
Authors: L.P.J. Groenewegen, E.P. de Vink
Dynamic System Adaptation b y Constrain t Orc hestratio n L.P .J. Gro enewegen 1 , ⋆ and E.P . de Vink 2 1 F aST Gro up, LIA CS, Leiden Universit y 2 F ormal Metho ds Group, Eindhov en Universit y of T ec hnology Abstract. F or Paradigm mo dels, evo lution is just-in- time sp ecified co- ordination conducted by a special reusable comp onen t McP al. Evolu- tion can be treated consistently and on-t h e-fly through Para digm’s con- strain t orc hestration, also for originally unforeseen evolution. UML-like diagrams visually supplement such migration, as is illustrated for the case of a critical section solution ev olving into a pip eline architecture. 1 Problem Situation Soft ware systems are large and complex. How ever, more strikingly , softw are sy s- tems hav e a strong tendency to grow over time, bo th in size and complexity . In order to deal with size a nd complexity , so ft ware a rchit ectures are used. A s oft- ware a rchit ecture pr ovides a globa l des cription of an a ctually far mo re detailed softw are system by giving a n ov erview in terms o f c omp onents and links . Co m- po nen ts ar e the main relev a n t parts, links are the r elev ant c onnections betw een them. A C B pC pC pB1 pB2 pB1 pB2 pA pA A−B−C Fig. 1. Two comp osite structure diagrams. Figure 1 presents t wo ar c hitectural visua lizations in UML-style [1 4]. The more usual, fully str uctural style is at the left. The larg er, iconize d r ectangles are c omp onents . The sma ller rectangles, p o sitioned acro ss a comp onents b order , are p orts , each one re pr esent ing an in terface offere d by that co mponent. A por t serves as the scene of action for a r ole that the comp onent is resp onsible for in the architectural constella tion. Lines connecting p orts a r e links , v ia which comp onent s communicate by executing their roles. A t the r igh t of Figure 1 , a ⋆ Corresponding author, e-mail luuk@liacs.n l . less common, more dynamica lly or ien ted presentation is given. It vis ualizes a c ol lab or ation : a grouping o f ro les constituting a co op erative unit, a pro toco l. The roles a re repres e n ted via their r espec tiv e po rts; comp onents r emain hidden. An architecture serves as a basis for the glo bal understa nding of the sy stem in terms of coherence be tween its cons tituen ts: compo nen ts, po rts/roles , links and collab orations / proto cols. The coher e nce cov ers the struc tur al fitting o f thes e four constituent categorie s , and, more imp ortantly , also their dyna mic consis tency . In particula r, each categ ory o f constituents has its own type of dyna mics: A) F or a co mponent it is lo cal, internal comp onent b e ha viour, usually hidden. B) F or a p ort it is lo ca l, external v isible role behaviour. C) F or a link it consists of sending a nd receiving in either direction, role int erac tio n. D) F or a colla bor ation it is the co or dination of the role b ehaviours and their interactions into an ov erall proto col. W e refer to these four t yp es of dynamics a s type A, B , C and D, resp ectively . In view o f the mutual dynamic fitting of b eha vioura l sp ecifications, c o herence betw een such sp ecifications is o f utmost r e le v ance. In Figur e 2, three situatio ns are b eing indicated, T1 –T3, w her e coherence of dynamics has to b e ass ured. In line with [21], we call such a situatio n a dy na mic consistency problem type. T1 T2 T3 dynamic consistency type−1 dynamic consistency type−2 dynamic consistency type−3 hidden (in component) role (at port) 2 roles (at link) protocol (collaboration) A B C D Fig. 2. Dyn amic consistency problem typ es T1 to T3 in a stable UML collaboration. In addition to the dynamics and c o nsistency relev an t for the fo reseen situa- tion of regular, stable collab oratio n, ther e may b e evolution fro m the orig inal, foreseen s ituation tow ards the initia lly unforeseen situa tio n of a renewed co llab- oration. During migration in particular, i.e . when tak ing an evolutionary step, behavioura l spec ific a tions, of any type A–D, ca n change. Figure 3 visualiz e s four additional dynamic consistency pr oblem types, T4–T7, r esulting from mig ra- tion. Genera lly , to main tain consis tency , the c hange of dynamics should o ccur smo othly: consistent with what prec e ded as well as consistent with wha t is to come next. So, b ehavioural executio n of all dyna mics should b e deflected suffi- ciently g radually . A primar y question then is, how can the dynamics of comp o- nent s, p orts, links and co llabo rations be repre s en ted, to supp ort the claim that the sys tem b ehaviour r emains coher e n t during the complete migratio n. Indeed, such c oherent e x ecution, solving dyna mics consistency pr oblem t yp es T1–T3 , should not only last during the original, stable situation, but also during the migration, a s w ell as during the new situation, uninterruptedly tha t is, b e it 2 changing gradua lly . Here, as is typically the case for large s oft ware s ystems, e x e- cutions are as sumed to contin ue, w itho ut any halting or o ther form of quiescence. T2 T3 T1 T2 T3 T1 T2 T3 T1 T5 T7 T4 T6 T5 T7 T4 T6 A B C D A A B C D D B C original situation original situation migration Fig. 3. Dyn amic consistency p roblem t yp es T4 to T7 in case of migration. As a solution to the a bove co nsistency pro blems, we pr opo se the co ordina tion mo deling lang uage Paradigm, s ee [15 , 17], tog e ther with the sp ecial comp onent called McPal (short for Ma na ging changing Pro cesse s ad libitum). 3 A Paradigm mo del without McPal s pecifies co o r dination of sta ble , fores een collab ora tions by dynamically res tricting and re-e na bling par ts of comp onent b ehaviour: con- straint orchestration. I n this ma nner, a Paradigm mo del provides coherence o f t yp e T1 –T3 b et ween dyna mics of t ype A, B, C and D. In view of future, un- foreseen migra tion of a Paradigm mo del as-is, McPal is to b e inco rpo rated into it. Component McP al, on the basis of the P aradig m notio ns of interaction, is designed as follows. Fir st, McPal allows for extending the constra in ts and their dynamic comp ositions while keeping the exec utio n of the sys tem go ing as- is. Second, McPal co or dinates mig r ation fr o m the as-is execution to the to-b e exe- cution aimed a t on the basis o f the new co nstraints a nd their new orchestration recently added. Third and last, once the execution situatio n aimed a t has been established, McPal remov es b ehaviour, co nstraints a nd o rch estra tio ns no longer needed. Note, executions are assumed to co ntin ue, without a n y ha lting or qui- escence. In the field of so ftw are migration and evolution, the present work fits in the setting o f una nticipated dyna mic s oft ware ev olution, fo cusing o n pro cesses and their dyna mics. An exa mple thereof is dyna mic co-evolution, where changing business rules a nd evolving so ft w are need to b e aligned. A num ber of g eneral techn iques are pro pos e d in [2 3, 24]: McPal’s migra tion co n trol rea liz es their g en- eration technique; complementarily , P ara digm, via its phases, traps and co ns is- ten t dynamic character, covers their other techniques: decomp osition (unco m- 3 F or a restricted version of McPal of a fixed form, see [16]. 3 monly dynamic via pro cesses and their phas es), reification, r eflection (b oth via consistency) and pr o bes (via tra ps). In the se tting of component-based soft ware engineering, pro cess languages and mobile calculi are exploited to for ma lly analyze runtim e mo dificatio n of adaptors, for example via cont ext-dep endent dynamic mapping s. Cf. [6 , 9, 8, 20]. Also, for the non- dynamic as well as the dyna mic case, algorithmic pro cedures to derive concr ete adaptor s fro m high-level sp ecification a re pr opo sed [5, 2 , 26]. Reconfiguratio n, mainly at the structural lev el, is treated by gr a ph g r ammars and graph transfo rmation, e.g ., in [13, 1 9, 3, 22, 4 ]. A recent development based on hierarchical r ewriting can b e found in [7]. T ranslation o f UML mo dels via O b ject-Z into CSP , has b een proven so und for so-called basic co nsistency [2 7], wher e as verification o f UML sequence diagr a ms are discussed in [28]. The pap e r [10 ] studies b ehaviour preser ving mo del trans- formations co mpos e d from subtrans formations pe r view a nd pr o vide a pro oftech- nique to achiev e global corre ctness. The views are similar to our collab oratio ns. How ev er, in our appr oach Paradigm guar an tees global cor rectness of evolution by construction. Ar c hitectural adaptation by gr aph transfor mations, as an implicit McPal in our terms, has been studied by v ar ious authors, [25] b eing r eminiscen t to our appro ach. Consistency in the context of evolution and s elf-management is also address ed, e.g., in [12, 11 , 29]. The rema inder of the pap er is structured as follows: In Section 2, Paradigm’s wa y of mo deling is illustrated for a critical section example with known dyna mics. In Section 3 it is discus s ed how McPal dea ls with unfor eseen b eha viour , with the example migrating to a pro ducer-co nsumer pipeline; additional UML diagra ms prov e us eful to o. Section 4 gives some conc luding r e marks. The app endix pr esent s an ov erview of P ara digm notions . 2 Constrain t Orc hestration for F oreseen Co ordination This s e ction briefly intro duces the co or dination mode ling langua ge Paradigm in terms of t wo kinds of b ehavioural constraints, pha se and tr ap , and tw o w ays of dynamically c o mpos ing these constraints, seq uen tially as glo b al pr o c ess and synchronized as c onsistency rule . A more detailed description o f Paradigm’s core definitions can b e found in the app endix. A Paradigm pr oce s s is given by a state transitio n diagram (STD), its transi- tions lab eled by actions . Usually a pro cess is visualized by a simple statemachine diagram. In its detailed for m, a pro cess captures t yp e A dynamics, as discussed in Section 1. See the middle pa rt of Figure 4 for tw o example pro cesses (to b e explained later): a worker and a scheduler. A pha se is a restricted v ersion of an underlying pro cess, obtained by co n- straining to a part of the pro cess be haviours. A t r ap is a further co nstraint on it: a tra p is a s ubset o f the phase states , which cannot b e left by mea ns of the transitions av ailable during the phase. A tra p is co mmitted to a utonomously , just by entering it; a phase is impos ed, from else whe r e. The lower-left part of 4 Figure 4 depicts three phases of the worker, OutCS , Insp ec and InCS , and four traps, triv , noty et , started and done . Given some phases and traps of a pro cess, the induced glo bal pr oces s has the phases as its s tates. The glo bal pro cess has a transition from one phase to another, if there is a trap of the first phase that is contained in the sec ond phase. So, a state in the trap is a state of the first phase as well as a state of the second phase. The trap is referred to as a connecting trap and is used as the lab el of the transitio n of the global pr oce ss. The low er-r igh t part of Fig ure 4 shows an example of a global pro cess, induced by the phases and traps from the low er-left figure part. In a sense, a global pro cess is a seq uen tial comp osition of phases. It sp ecifies a role, a t a p ort, of the comp onent whose hidden dynamics is the underly ing pro cess. It sp ecifies Section 1’s type B b ehaviour. Moreov er, a global pro cess brings forward type C dynamics: Information ab out a trap committed to is sent fr om the r ole’s p ort via the link. Information ab out a phase imp osed, renewed constraint for the pro cess b ehaviour r e garding the role, is r e c eive d at the same role’s p ort where the t yp e B be haviour is o ccurring. A mir rored version of the role is o c curring at the link’s other end, mo dulo po s sible delays b etw een sending from one end a nd receiving at the other; time-ordered sends/receives constitute t yp e C b ehaviour. Given mir rored ro les, a c onsistency rule synchronizes their steps. It couples each synchronized step to a step of a detailed pro cess, a so-ca lle d manager pro- cess. The p ossible sequences o f the synchronized steps constitute a proto col, Section 1’s type D dynamics. Thus, roles can b e seen as pr oto col ro le s . The pro- to col co nstitutes the co ordina tion of the collabo ration by pro perly comp osing the r e lev ant cons traint s. W e ca ll this c onstr aint or chestr ation . O n the basis of Paradigm’s notions, the dynamic consistency problem types of the sta ble, fore- seen co ordination situation a re made explicit. A UML-like visualization of this co ordination stresses the coherence. Figure 4 pr esen ts a small example of a so- called critical section management problem (CSM), with its str uc tur e diagrams and with v ar ious fra gmen ts of the Paradigm mo del, inc luding detailed pro cess es, phases, traps and glo ba l pro c e sses. Figure 4 ’s upp er lay er gives the collab orating participants o f the CSM ar- chit ecture: W orker comp onents co mpeting for p ermissio n to enter their critical section. A scheduler comp onent, for three work ers, giving the pe r mission to a work er asking for it, exclusively; the p ermission is w ithdr a wn o nly after the work er indicates it do e s not need it a n y longer. The middle lay er o f Figure 4 gives the pro cesses for workers and scheduler. A worker needs the p ermission for being in its state Crit where it do es its critical a ctivit y . In Post it does some wrapping up, in F ree is do es nothing in particula r, in NCrit it do es non-critica l work a nd in Pr e it prepares its critical activity . As long a s it do es not hav e the per mission to go to Crit , it waits there . In UML-s tyle, the black dot with outg o - ing edge indicates the star ting state F ree . Likewise, pro ces s Scheduler sta rts in Check 1 . In a state Chec k i , the scheduler checks whether W orker i wan ts to have the p ermission. If s o , it go e s to Asg i where it assig ns the permiss ion to W orker i ; 5 Asg3 Check3 Check2 Check1 Asg1 Crit Post Free NCrit Pre NCrit NCrit Free NCrit Pre Post Pre started Worker2 Worker3 InCS OutCS Inspec done started notyet triv CSM constraints on Worker: phases and their traps continue allow disallow Asg2 allow disallow continue continue disallow allow Scheduler finish start prepare enter Worker leave OutCS Free Post notyet Inspec Free Post Crit Pre InCS Worker1 triv done global process Worker(CSM) CSM CSM CSM CSMCoord CSM CSM CSM CSM architecture CSMCoord Scheduler Fig. 4. CSM collab oration. if not so, it g o es to the next state Check i +1 in round r obin fashion. In Asg i it waits until W ork er i has finished its critical activity . Figure 4’s low est lay er visualizes cons traint s, viz. thr ee pha ses OutCS , Insp ec and InCS , each as par tial STD of a worker, and four traps, triv of OutCS , noty et and star ted both of Ins pec and do ne of InCS , each dra wn as p olyg on around the states it consists o f. Being a co mmit within the phase, a trap o nce ent ered cannot b e left as long as the phase constraint holds. The phases and traps reflect the following intuition. Phase OutCS covers the b ehavioural phase where a worker do es not hav e the p ermission to enter its cr itical s e ction. OutCS reflects, it is as if state Crit do es not exists. Contrarily , InCS covers having that per mission. InCS reflects, state Crit can be entered, but once only , as state Pr e is unreachable during this b ehavioural phase. Phase Insp ec is an int errupted form of OutCS , as ent ering state Pre is no longer p ossible during it: either trap started has b een ent ered or trap notyet . B eing in started is taken as a CSM- per mission reques t, b eing in noty et is taken as no CSM-p ermissio n request yet. The trivia l tr ap triv of O utCS reflects, OutCS can b e int errupted – to wards phas e Insp ec – unconditionally; trap done o f InCS reflects , the CSM-p ermission can b e withdrawn: state Crit has b een left. At the right of Figure 4’s low est level, the global pro cess or ro le W orker i ( CSM ) is given. 6 Asg2 triv OutCS triv OutCS OutCS OutCS InCS OutCS OutCS OutCS OutCS Inspec Inspec Inspec Worker1(CSM) Worker2(CSM) Worker3(CSM) Scheduler ... ... done notyet continue disallow allow Check3 Check1 Check2 started Fig. 5. CSM protocol: phase constraints enforced, trap constraints chec ked. Synchronized r ealizations of the globa l b ehaviours of thre e workers constitute a proto col r ealization or scena rio. Figure 5 gives suc h a s c enario in the form of a UML- like ac tiv ity diagra m: thr ee swimlanes fo r the three global pro cesses coupled to one swimlane for the scheduler. In pa rticular, our visua lization reveals the b ehavioural c o nsequences of the v ar io us phase constraints for the detailed behaviours after each pr otoc ol step. One sees, how, when and why exactly the CSM-p ermission is g iven exclusively to one worker at a time, indeed in round robin o r der, the phase Insp ec s hifting from W orker 1 , to W orker 2 , to W ork er 3 . The proto col steps as visua lized in Figure 5, are sp ecified by consistency rules, synchronizing g lo bal pro cess steps and co upling them to o ne deta iled mana ger step, as follows. Scheduler : Chec k i allow → Asg i ∗ W orker i ( CSM ): Insp ec started → InCS (1) Scheduler : Asg i disallo w → Chec k i +1 ∗ W orker i ( CSM ): InCS done → OutCS , W orker i +1 ( CSM ): OutCS triv → Insp ec (2) Scheduler : Chec k i con tinu e → Chec k i +1 ∗ W orker i ( CSM ): Insp ec notY et → OutCS , W orker i +1 ( CSM ): OutCS triv → Insp ec (3) In fact, Figure 5’s first step illustrates rule (3): a sc heduler transition from a Check state to a next Check state is co upled to tw o global pro cess tra ns i- tions: o ne for g lobal pro cess W orker i ( C S M ), r eturning from b eing interrupted in Inspec to not having the p ermission in OutCS as trap noty et was entered; the other fo r the next global pro cess W orker i +1 ( C S M ), changing fro m not having the p ermission in O utCS to b eing interrupted in Insp ec a s trap triv was entered 7 trivially . Similarly , Figur e 5 ’s s econd step illustra tes r ule (1 ) and Figure 5 ’s third step illustrates r ule (2). In order for a rule to be applied, Paradigm’s definitions in addition r equire: the one detailed transition mentioned in the r ule, o ccurs in every cur rent ly v alid phase constraint as sp ecified by the v arious cur ren t states o f the relev an t glo bal pro cesses. Based on this, Paradigm mo dels fo r foresee n co or dination succe e d in guaranteeing dynamic c onsistency of t yp e T1 to type T3. In the critica l s e ction management exa mple ab ov e, the scheduler is a lso re- ferred to as the manager o f the colla bor ations, the workers as its employe es . As such, the s cheduler is o ccurr ing at the left-hand side of a cons istency r ule, the work ers on the right-hand s ide. In the colla bor ation CSM , the lo cal STD behaviour of the manager, i.e . the Sc heduler pro cess is t ype A dynamics, the role b eha viour of the g lobal pro cesses W orker i ( CSM ), the employ ees, is type B dynamics. The trap infor ma tion from the w orkers as employ ees to the scheduler as manager and, v ic e versa, the newly prescr ibed phases flowing from manag e r to employ ees, constitute t yp e C dynamics. The total of a ll consistency rules to- gether for m the proto col, t yp e D dynamics , comprising the co ordination of the comp onent s in the co llabo r ation. 3 Ev olution b y Constrain t Orchestration In view of unforese en change w ithin an architecture, the sp ecial comp onent McPal is to be added to it: for co ordinating unanticipated migration tow ards a new wa y o f working. During a stable co llabo ration phase, McPal is stand- b y only , not influencing the other comp onen ts at all. B ut by b eing there, McPal provides a pattern for dynamic evolution management in the architectural con- stellation of the Paradigm mo del. T o that aim, p orts and link s a re in place, realizing rudimentary interfacing for the moment. As soon as, via McPal but in strict se pa ration of the mo del’s stable working, a new wa y of working to- gether w ith a mig ration tow ards it, has b een mo deled, typically just-in-time (JIT), McPal star ts co ordinating the migra tion. Its own migr ation b egins, the migration of the o thers is sta r ted thereafter. Finishing the mig ration is do ne in reversed order . The others are ex plicitly left to their new stable co llabo rative work b efore McPal ceas es to influence the others. It is stressed, that the migra- tion is on-the- fly . McPal activities and migration to the new e volution pha se can be mixed with older b ehaviour. Figure 6 v isualizes McPal ’s hidden, detailed dynamics (t ype A) as follo ws. In its starting state Observing , McPal is doing no thing in par ticular, but it can observe, that something should change. State JITting is where just-in-time fore- seeing and mo deling of such a c o ncrete change o ccurs. The extended mo del then is av aila ble in s tate NewRuleSet . So, up on le aving that sta te for state Sta rtMigr , McPal is supp osed to change its own phase StatP hase into an o riginally unknown next phase MigrPha se , which by then is known indeed. See Figure 6 for these tw o phases with their relev ant traps a nd for the induced g lobal pr oces s Mc P al ( Evol ). 8 ready McPal, "complete" when migrating: more type A dynamics type B dynamics McPal(Evol) MigrPhase StatPhase ready migrDone Content NewRuleSet Observing phase StatPhase . . . . . . subprocess MigrPhase migrDone McPal type A dynamics StartMigr giveOut knowChange JITting phaseAuto wantChange Fig. 6. McP al - during a stable collaboration situation ‘mainly’. Figure 7 gives an overview of all comp onen ts co op erating in collab ora tion Evol . McPal has the EvolCo ord role, which here means, it is mana g er of five employ ees having an Evol p ort e a c h: three work ers, a sc heduler a nd itself . New constra ints are imp osed on the employees according to the migr a tion details. McPal Worker1 Worker2 Worker3 Scheduler Evol Evol Evol Evol Evol Evol EvolCoord Fig. 7. The other comp onents. Figure 8 depicts a very small part of the type D dynamics of c ollab oration Evol , viz. the constraint orchestration fragment most ess e n tial for the Evol r ole of McPal . Similar as b efore, it is built by synchronizing all five Ev ol roles of the re s pective comp onents coupled to the detailed steps of manager McPal . The Paradigm model for McPal has initia lly the following tw o c o nsistency r ules sp ecifying the semantics for McPal ’s first tw o steps. McP al : Ob serving wan tChange → JITting McP al : JITting knowChange → NewRuleSet ∗ McP al [ Crs : = Crs + Crs migr + Crs toBe ] The first step from state Obser ving to JITting has no coupling, so Figur e 8 do es not show a co rresp onding role step. The second step from J ITting to NewRuleSet 9 Observing Observing StartMigr wantChange JITting knowChange NewRuleSet giveOut Content phaseAuto wantChange ... McPal W1,2,3(Evol), Sch(Evol) ... ... various migration steps Phase1 each migrDone StatPhase ready StatPhase MigrPhase McPal(Evol) ... Phase2 each now all different Fig. 8. Migration coordination as constrain t orchestration. has no coupling either, but here, via a so-c a lled change clause, the set of co nsis- tency r ule s Crs for the sta ble or iginal situa tion is extended with the rules Crs migr for the migration only and with the r ule s Crs toBe for the new, stable s itua tion to migrate to. This mea ns in pa r ticular, a part from all other migr ation co or dination details, McPal fr o m then on has at least tw o more consis tency r ules: McP al : NewRuleSet giveOu t → StartMi gr ∗ McP al ( Evol ): StatPhase ready → MigrPhase McP al : Conten t phaseAuto → Observing ∗ McP al ( Evol ): MigrPhase migrDone → StatPhase , McPal [ Crs : = Crs toBe ] The first new rule says, on the basis of having entered tra p rea dy , the phase change fro m StatPhas e to MigrPha se can b e made, coupled to McPal ’s transition from state NewRuleSet to Sta rtMigr . Figure 8 expresses this where the upp er ‘lightning’ step draws the r eader’s attention. O ne clearly sees, the three workers and scheduler remain the s ame, a s there is no constra int change for them yet. F rom then on, the migration is a matter of no rmal co ordinatio n only , exactly according the planning as mo deled while in state JITting . E ventually , Scheduler and each W orker i are restric ted to new phases (that remain unex pla ined here). Moreov er, their new co ordination has by then been ada pted as planned. So, consistency is ac c o un ted for by no r mal Paradigm execution. At the last migratio n step, after having phas e d out the dynamics tha t is no lo ng er needed for the other comp onent s, i.e. after having entered trap migrDone of its phas e Migr Phase , McPal returns from Migr Phase to StatP hase by mak ing the (coupled) step from 10 state Conten t to O bserving . Then also the rule set Crs is reduced to Crs toBe , by means of a suitable change clause. This can be seen in Figure 8 (low er ‘lightning’) and is expr e ssed by the cor resp onding new rule for McPal . Once returned in sta te Observing , McPal is stand-by aga in, ready for a next migration. In order to illustrate the general usability of McPal for mig ration co ordination, we present the following example. Assume, McPal during its so journ in state Observing want s to c hange the hierarchical architecture of the scheduler and its three work er pro cess es in to a pip eline of four pro cess es, rather different in b e- haviour each. Assume in a ddition, in its state JITting pr oce ss McPal establishes a Paradigm mo del fo r this pa rticular situation to-b e, as w ell as for a sufficiently smo oth migration from the old, still cur rent situation to the situation to-b e. <> Unit2(Prod) Unit4(ConsCoord) <> ProdCons2 <> Unit4(Cons) <> Unit3(ProdCoord) ProdCons3 Unit2(ConsCoord) <> <> Unit3(ConsCoord) <> Unit1(Prod) ProdCons1 Unit2 Unit3 Unit1 Unit4 Prod ConsCoord ConsCoord ProdCoord Prod Cons ConsCoord Fig. 9. New arc hitecture an d new collab orations. Figure 9 prese n ts our example to-b e ar c hitecture of the pipeline: s ome item handling is rep eatedly star ted by Unit 1 , it is contin ued by either Unit 2 or Unit 3 , and in bo th cases it is finished b y Unit 4 . Instead o f the one collab oration CSM in the o riginal ar c hitecture, now there a re thr e e colla bor ations of a pr oducer - consumer c harac ter each: in Pr odCo ns 1 , employ ee pr oce ss Unit 1 pro duces for its tw o consuming manager pro cesses Unit 2 and Unit 3 ; in Pro dCons 2 , employ ee pro cess Unit 2 pro duces for the consuming manager pro cess Unit 4 ; in P ro dCons 3 , manager pro cess Unit 3 pro duces for the consuming employ ee pro cess Unit 4 . Note, the three pro cesses Unit 1 , Unit 2 and Unit 4 , constituting the upper part of the pipeline, hav e one employ ee ro le each, so they hav e ea ch o ne globa l pro cess; pro cess Unit 3 has no employ ee role whatso ever, so it do es not hav e a g lobal pro cess. T o illustrate the migration from the original CSM a rchitecture to the new pipeline architecture, it is a lr eady very clarifying to gues s how the origina l CSM collab oration is shrink ing gradua lly (to nothing), while the other three new col- lab orations P ro dCons are gr owing gr a dually (fro m nothing). One goal thereby is, for the sake of the example, that the orig inal s c heduler pro cess has to bec o me the new Unit 3 pro cess – be ing the only pro cess without employee r oles, i.e. hav- ing no globa l pro cess, bo th in the origina l situation a nd in the to -be s ituation. 11 PC1 U1(P) e U2(CCr) m e U2(P) m S(CCr) e W3(C) CSM PC2 e U2(P) m U4(CCr) U1(P) e U2(CCr) m m U3(CCr) PC1 e U4(C) m U3(PCr) PC3 PC2 e U2(P) m U4(CCr) PC2 U1(P) e U2(CCr) m PC1 m S(CCr) CSM e PC3 U4(C) e U1(P) PC1 m S(CCr) e W1(C) e W3(C) e W1(C) m S(CCr) CSM CSM e e W2(C) W3(C) W2 as U1 W1 as U2 W3 as U4 S as U3 Fig. 10. A n ex ample scenario for migrating collaborations in snapsh ots. F urthermore, each work er pro ces s may b ecome any of the pro cesses Unit 1 , Unit 2 and Unit 4 . Figure 10 presents an ex a mple collabo ration migration tra jectory in three int ermediate snapshots. Note how first the pipe line’s upper part is b eing built from left to r igh t. So, a fir st worker ( W 2 ), up on b ecoming av ailable, is to change int o Unit 1 , a second w orker ( W 1 ), up on becoming av ailable, is to become Unit 2 and the rema ining work er ( W 3 ) is to be come Unit 4 , but no t b efore this o ne has bec ome av a ilable too . As long a s a worker is not av ailable yet, pro cess Scheduler might b e needed for regula ting the cr itical sectio n a ccess. So, Scheduler is the last pro cess that is to change int o the las t Unit pr o ces s , Unit 3 . Note, six differen t migration tra jectories exist for this migr a tion: 3 × 2 × 1, as there a re three po ssibilities for b eing the first av ailable W orker, tw o p oss ibilities fo r b eing the second av ailable W orker and no choice for the last av aila ble W orker. JITting NewRuleSet StartMigr giveOut ready Conf123 Content Observing Observing Content Conf132 Conf213 Conf231 Conf312 Conf321 knowChange wantChange StationaryPhase WhoFirst seeWorker2 seeWorker3 phaseOut phaseOut phaseOut phaseOut freezePipeline freezePipeline freezePipeline freezePipeline seeWorker1 seeWorker2 seeWorker3 kickOff NewRuleSet StartMigr giveOut seeWorker1 phaseOut phaseOut freezePipeline freezePipeline seeWorker3 seeWorker2 seeWorker1 Migr1−2 phaseAuto migrDone phaseAuto W1asU1 W2asU1 W3asU1 2:W1asU2 2:W3asU2 3:W1asU2 3:W2asU2 1:W3asU2 1:W2asU2 Fig. 11. McP al as migration coordinator. 12 The ab ov e example tra jectory in snapshots pr esen ts a guideline for the mi- gration co ordina tion to b e conducted by McPal . Fig ure 11 prese n ts such co ordi- nation as McPal ’s be haviour b elonging to its phase Migr 1 − 2 . Note, six different behaviours are p ossible, representing all different migr a tion tra jectories. In state WhoFirst pro cess Mc P al waits until a first work er bec omes av ailable. In state W i as U 1 pro cess McPal ha s found W orker i av ailable first. In a state i : W j as U 2 it has found W orker j av ailable next. The remaining W or ker is W orker k . In state Conf i,j,k , it has found W orker k av ailable and Scheduler has sta rted the last turn it ca n give. So, after that turn Sc heduler ca n bec o me Unit 3 . In state Conten t it has found, the scheduler a nd a ll w orkers have started to b e have as the right unit. Finally , in s tate Observing it has s w app ed back fro m phase Migr 1 − 2 to StatPhase . So, then this mig ration is history . Without pr e sen ting the details o f the global pro cesses at the E v ol p orts, we nevertheless sketc hily visualize the subsequently v alid b ehaviour constraints of the v ario us worker pro cesse s during their migration by means of constraint orchestration. W e do this for the a bove migratio n scenario only . Thus, Figure 12 presents main mig ration co ordination details, in terms of the Evol pa rtitions for the one scenar io . The fig ur e has b een annotated with seven notes: A, . . . , G . Ea c h note indi- cates a relev ant horizontal pictorial level: Mc P al per forms a migrative step by progre s sively co ordinating the simultaneous b ehavioural freedo m of the original work er pro cesses. Thus, at note A , McPal star ts its own migr ativ e phase only , like alrea dy spec ified in Figur e 8 . At note B , McPal simultaneously restric ts the worker pro cesses, by giving them a last orders p ossibility fo r their cr itical activity by means of phase W orkerT oBeUnit . A t note C , McPal , on the basis of its first obser v ation of a tr ap r eady of W ork erT oBeUnit having b een entered (by W orker 2 ), app oints W orker 2 as the future Unit 1 . At no te D , McPal , on the bas is of its second o bserv a tion of a trap ready of W ork erT oBeUnit having b een en- tered (by W orker 1 ), app oints W orker 1 as the future Unit 2 and moreover app oints W orker 3 as the future Unit 4 . Note, the la tter app ointmen t is done on the basis of trap triv having b e e n en tered (instead o f trap ready ). At note E , on the basis of trap o nItsW a y of phase T ow ardsUnit 4 having b een entered by W orker 3 as well a s trap triv of phase O rigAsSched by Scheduler , McPal changes phase OrigAsSched of Scheduler into T ow ardsUnit 3 . At note F , McPal , se e ing the scheduler and each work er in their res p ective traps ready of the four phases T o wardsUnit .. , simul- taneously changes these phases in to T oBe AsUnit .. . At note G , McPal finishes its own migr ative phase, like alr eady sp ecified in Figure 8. In exact confor mit y to the ab ov e constr ain t o rchestration o f the one scenar io, the consis tency rules b elow sp ecify a ll six scenario s. Note how change clauses a re used for par a meterizing the actual scenario follow ed. W e actually present s e v en rules, o ne for each note A to G and in the s ame order . W e thereby rep eat the rules for note A and G , already presented as new rule s in the context of Figure 8. As the seven rules sp ecify migrative steps only , they all b elong to the se t Cr s migr . So, the last rule actually re moves these seven r ules, at the end of the migratio n indeed, together with the original rules no longer needed. 13 StartMigr Content Observing A B C D E F G triv triv triv ready triv onItsWay Observing JITting NewRuleSet WhoFirst knowChange seeWorker2 seeWorker1 giveOut McPal(Evol) McPal Scheduler(Evol) wantChange kickOff phaseOut Migr1−2 Migr1−2 Migr1−2 Migr1−2 Stationary Phase freezePipeline phaseAuto wantChange ready Stationary Phase OrigAsWorker OrigAsWorker OrigAsSched OrigAsWorker OrigAsWorker OrigAsWorker OrigAsWorker OrigAsSched WorkerToBeUnit WorkerToBeUnit WorkerToBeUnit Migr1−2 OrigAsSched WorkerToBeUnit WorkerToBeUnit TowardsUnit1 ready triv TowardsUnit2 TowardsUnit4 OrigAsSched TowardsUnit1 TowardsUnit2 TowardsUnit4 TowardsUnit3 TowardsUnit1 ready ready ready ready ToBeAsUnit2 ToBeAsUnit3 Migr1−2 ToBeAsUnit4 ToBeAsUnit1 migrDone ToBeAsUnit3 ToBeAsUnit4 ToBeAsUnit1 ToBeAsUnit2 Worker1(Evol) Worker2(Evol) Worker3(Evol) W2asU1 2:W1asU2 Config213 OrigAsSched Fig. 12. Orchestrating a migration co ordination scenario – m ain lines. McP al : NewRu leSet giveOu t → S tartMigr ∗ McP al ( Evol ): StatPhase ready → M igr 1 − 2 McP al : St artMigr kic kOff → WhoFi rst ∗ W orker 1 ( Evol ): OrigAsW orker 1 triv → W orkerT o BeUnit , W orker 2 ( Evol ): OrigAsW orker 1 triv → W orkerT o BeUnit , W orker 3 ( Evol ): OrigAsW orker 1 triv → W orkerT o BeUnit McP al : WhoFirst seeW orke r i → W i as U 1 ∗ W orker i ( Evol ): W orkerT oBeUnit ready → T o wa rdsUnit 1 McP al : W i as U 1 seeW orke r j → i : W j as U 2 ∗ W orker j ( Evol ): W ork erT oBeUnit ready → T o wa rdsUnit 2 , W orker k ( Evol ): W orkerT oBeUnit triv → T o wa rdsUnit 4 14 McP al : i : W j as U 2 freezePipeline → Conf i,j,k ∗ W orker k ( Evol ): T ow ardsU nit 4 onItsW ay → T o wa rdsUnit 4 , Scheduler ( Evol ): OrigAsSc hed triv → T o wa rdsUnit 3 McP al : Conf i,j,k phaseOut → Conten t ∗ W orker i ( Evol ): T o w ardsUnit 1 ready → T oBeAsUnit 1 , W orker j ( Evol ): T o w ardsUnit 2 ready → T oBeAsUnit 2 , Scheduler ( Evol ): T o w ardsUnit 3 ready → T oBeAsUnit 3 , W orker k ( Evol ): T ow ardsUnit 4 ready → T oBeAsUnit 4 McP al : Conten t phaseAuto → Observing ∗ McP al ( Evol ): Mig r 1 − 2 migrDone → StatPhase , McPal [ Crs := Crs toBe ] As w e hav e exp erienced, a cons traint orchestration as presented is very help- ful for understanding co rresp onding consistency rules. F urthermor e, the collab- oration s na pshots illuminate McPal dynamics a s well a s understa nding how to mo del, just-in-time, the phases a nd traps in the v arious Evol partitions and how to mo del, JIT to o, the global pro cesses a t their levels. So, the v arious UML diagrams used: c o llabo ration, state machine (s imple and sp ecial, b ecause of Paradigm) and a ctivit y diagra m (sp ecial as constr ain t orchestration), do sup- po rt the understanding of the dynamically consis tent co ordination of the origi- nally unforeseen migration of a first architecture tow ards a se c ond, J I T mo deled architecture. As such migration is a sp ecial form of co ordination, there is no tempo rary quiescence needed of wha tev er comp onent: the migration is really on-the-fly . Moreover, a fter Mc P al has returned to its stand-by behaviours in its phase StatPhase , it is r e ady for starting yet another completely differen t and unforeseen migra tio n in a dynamica lly consistent wa y . 4 Conclusion T o ca ter for future, unforese e n on-the-fly migration, McPal can be incorp ora ted int o any Paradigm mo del. McPal comprises the co ordination needed for conduct- ing the migratio n collab ora tion o f all compo nen ts towards a new wa y of working. Mo deled just-in-time, mig ration co ordination is s uch that no form of temp orary quiescence is needed to o ccur for whatever comp onent dur ing its migra tio n. Any such compo nen t remains in ex ecution, b e it in a smo othly changing manner , gradually a dapting to new circumstances a rising along the migration tra jectory . McPal ’s co ordination, a s s pecified in Paradigm, maintains consistency o f the mo del b oth during and after migr a tion, thereb y dealing with the v arious dy- namic c o nsistency problem types. It is noted, UML v isualizations subs tan tially supplement the understanding o f the evolution. In this ma nner , McPal is capa- ble to co or dinate its own migration tra jectory dynamica lly consis ten t with the other comp onents. McPal as in tro duced here, gene r alizes the McPal from [16], as now it allows all kinds of complex b ehaviour in the JIT mo deled phase Mig rPhase , as lo ng 15 as it remains a co rrect Paradigm co or dination. T he McPal c o mponent prop osed in [16] was restricted to a fixed migratio n co ordinatio n pattern. As a next and substantial generalizatio n we are going to incorp orate semantics for creating as well as deleting dynamics, in particular o f t yp e A and of type B, consisten tly . This will e nable, e.g., creation of a stand-by McPal when the orig ina l Mc P al is busy with a first migr ation: the stand-by can then initiate a different migration, even b efore the first has finished. As Paradigm’s pro cesses can mo del b oth ICT activities and busines s activities, the McPal pattern is particula rly promising for addres s ing all kinds of alignment situations b etw een business and ICT and moreov er for addres sing g eneral evolution of ICT and business in tandem, cf. [23 ]. By means of ParADE, a modeling and animation environment for Paradigm mo dels, PhD work by Andries Stam, first migra tion exa mples ha ve b een imple- men ted and tested. A preliminar y , but promising result [1] has b e en obtained in translating Paradigm into the pro cess algebra ACP . With its coupling to the mCRL2 to olkit [18 ], s tate-of-the-art mo delchec king of Paradig m mo dels, in particular of migra tion tra jector ies, co mes in to reach. References 1. S . A n do v a, L.P .J. Gro enew egen, and E.P . de Vink. D ynamic consistency in pro cess algebra: F rom Paradigm to ACP. I n P . Poizat C. Canal and M. Sirjani, editors, Pr o c. FOCLASA’08 , 2008. 19pp. T o app ear in the ENTCS. 2. M.A. Barbosa an d L .S . Barbosa. A n orc hestrator for dyn amic interconnection of soft w are comp onents. El e ctr onic Notes i n The or etic al Computer Scienc e , 181:49– 61, 2007. 3. L. Baresi, R. Heck el, S. Th¨ one, and D. V arr´ o. S tyle-based mo deling and refinement of service-oriented architectures. Softwar e and System Mo deling , 5:187–207 , 2006. 4. D . Bisztray , R. Heck el, and H. Ehrig. V erification of architectural refactorings by rule extraction. In J.L. Fiadeiro and P . Inv erardi, editors, Pr o c. F ASE , pages 347–361 . LNCS 4961, 2008. 5. A . Bracciali, A. Brogi, and C. Canal. A formal ap p roac h to comp onent adaptation. Journal of Systems and Softwar e , 74:45–54, 2005. 6. A . Brogi, J. C´ amera, C. Canal, J. Cub o, and E. Pimentel. Dyn amic con textual adaptation. Ele ctr onic Notes in The or etic al Computer Scienc e , 175:81–9 5, 2007. 7. R . Bruni, A. L lu ch Lafuente, U. Montanari, and E. T uosto. Style-based A rchitec- tural Reconfi gurations. Bul letin of the EA TCS , 94:181–180, 2008. 8. J. C´ amara, G. Salua ¨ un, and C. Canal. R un-time comp osition and adaptation of mismatc hing behavioural transactions. In Pr o c. SEFM, 10–14 Sept emb er 2007, L ondon , pages 381–390. IEEE Computer So ciet y , 2007. 9. J. Cub o, G. Sala ¨ un, J. C´ amara, C.Canal, and E. Pimentel. Context-based adap- tation of component b eha vioural interfaces. In A .L. Mu rphy and J. Vitek, editors, Pr o c. CO ORDINA TION 2007 , pages 305–32 3. LNCS 4467, 2007. 10. J. Derrick and H. W ehrh eim. Model transformations incorporating multiple views. In M. Johnson and V. V ene, editors, Pr o c. AMAST 2006 , pages 111–126. LNCS 4019, 2006. 11. L. Desmet, N . Janssens, S. Michiels, F. Piessens, W. Joosen, and P . V erbaeten. T o wa rds p reserving correctness in self-managed soft ware systems. In D. Garlan, J. Kramer, and A.L. W olf, editors, Pr o c. WOSS’04 , pages 34–38. ACM, 2004. 16 12. G. Engels, J.M. K ¨ uster, R. Heck el, and L. Groen ew egen. A metho dology for sp ec- ifying and analyzing consistency of ob ject-orien ted behavioral mod els. In Pr o c. FSE’01 , pages 186–1 95. ACM, 2001. 13. Gregor Engels and R eiko Heck el. Graph Transformation as a Conceptual and Formal Framew ork for System Mo deling and Model Evolution. In U. Mon tanari, J.D.P . R olim, and E. W elzl, editors, Pr o c. ICALP 2000 , pages 127–150. LN CS 1853, 2000. 14. M. F o wler. UML Distil le d (3r d e d.) . Addison-W esley , 2004. 15. L. Gro eneweg en, N. v an Kamp enhout, and E. d e Vink. Delegation modeling with paradigm. In J.-M. Jacquet and G.P . Picco, editors, Pr o c e e dings Co or di nation 2005 , pages 94–108 . LNCS 3454, 2005. 16. L. Groenewegen and E. de Vink. Evol ution-on-t he-fly with Par adigm. In P . Ciancarini and H. Wiklicky , editors, Pr o c. Co or dination 2006 , pages 97–112. LNCS 4038, 2006. 17. L.P .J. Gro eneweg en, A.W. Stam, P .J. T oussaint, and E.P . de Vink . P aradigm as organization-orien ted co ordination language. In L. v an de T orre and G. Bo ella, editors, Pr o c. CoOr g 2005 , pages 93–113. ENTCS 150(3), 2005. 18. J.F. Groote et al. T he formal sp ecification language mCRL2. In E. Brinksma et al., editor, Metho ds for Mo del ling So ftwar e Syst ems . IBFI, Schlo ss Dagstuhl, 2007. 34 pages. 19. D. Hirsh. Gr aph tr ansformation mo dels for softwar e ar chite ctur e styles . PhD t hesis, Universidad d e Buenos Aires, 2003. 20. C. K¨ ohler, F. Arbab, and E.P . de Vink. Reconfiguring distributed reo connectors (extended abstract), 2008. 15pp. Submitted. 21. J. K ¨ uster. Consistency Management of Obje ct-Oriente d Behavior al Mo dels . PhD thesis, Universit y of P aderb orn, 2004. 22. T. Mens, G. T aentzer, and O . Runge. Analysing refactoring dep endencies using graph transformation. Softwar e and System Mo deling , 6:269–28 5, 2007. 23. R . Morrison et al. An active architecture approach to dy namic systems co- evol ution. In F. Oq uendo, editor, Pr o c. ECSA’07 , pages 2–10. LNCS 4758, 2007. 24. R . Morrison et al. A framew ork for supp orting dynamic systems co-evol ution. Aut omate d Softwar e Engine ering , 14:261–292, 2007. 25. J. Padb erg. Basic ideas for transformations of sp ecification arc hitectures. In R. Heckel , T. Mens, and M. W ermelinger, editors, Pr o c. ICGT’02 , pages 46–58. ENTCS 72, 2003. 26. P . Poiza t and G. S ala¨ un. Ad aptation of op en comp onen t-based systems. In M.M. Bonsangue and E.B. Johnsen, ed itors, Pr o c. FMOODS 2007 , pages 141–156. LNCS 4468, 2007. 27. H . Rasch and H . W ehrh eim. Checking consistency in UML disagrams : classes an d state machines. I n E. Na jm, U. Nestmann, and P . S tev ens, editors, Pr o c. FM OODS 2003 , pages 229–24 3. LN CS 2884, 2003. 28. H . R asc h and H . W ehrheim. Chec king the v alidit y of scenarios in U ML mo d els. I n M. S teffen and G. Zav attaro, editors, Pr o c. FMOOD S 2005 , pages 67–82. LNCS 3535, 2005. 29. J. Zhang and B.H.C. Chen g. Mo del-based d ev elopment of dynamically adaptive soft w are. In L.J. Osterweil , H .D. Rombac h, and M.L. S offa, editors, Pr o c. ICSE’ 06 , pages 371–380. ACM , 2006. 17 5 App endix The appendix lists the definitions of P aradig m’s main synt actical ingredients, viz. pro ces s, phase, (co nnec ting ) tra p, partition and global pr oc e ss, and very briefly indicates their mea ning s. It ends with pr esent ing Paradig m’s consistency rules on which P ara digm’s op erational semantics is ba s ed. Definition 1. A pro cess or state-transition diagra m or STD Z is a triple h ST , AC , TS i . Her e, ST is the non- empty set of states , AC is t he s et of actions or transition la b els and TS ⊆ ST × AC × ST is the set of tra nsitions . A tra nsition ( x, a, x ′ ) ∈ TS is said to b e from x to x ′ and is denote d as x a → x ′ . A phase or subpro cess S of an STD Z = h S T , AC , TS i is itself an STD S = h st , ac , ts i with s t ⊆ S T , ac ⊆ AC , ts ⊆ { ( x, a , x ′ ) ∈ TS | x, x ′ ∈ st , a ∈ ac } . A tr ap t of a phase S = h st , ac , ts i is a n onempty set of states t ⊆ st such that x ∈ t and x a → x ′ ∈ ts imply that x ′ ∈ t . If t = st , the tr ap is c al le d trivia l , denote d as triv or tr iv ( S ) . F or two phases S = h st , ac , ts i and S ′ = h st ′ , ac ′ , ts ′ i b e of t he same STD, a tr ap t of S is c al le d connecting from S to S ′ if t ⊆ st ′ . The triple ( S, t, S ′ ) is then c al le d a phase change , notation S t → S ′ . A par tition { ( S i , T i ) | i ∈ I } of an STD Z = h ST , A C , TS i is a nonempty set of phases S i = h st i , ac i , ts i i of Z , e ach with a set T i of its tr aps with triv ( S i ) ∈ T i . If S T = S i ∈ I st i and TS = S i ∈ I ts i , t he p artition is said to b e covering pr o c ess Z or cov ering for short. A g lobal pro cess at the level of a p artition π = { ( S i , T i ) | i ∈ I } of another STD Z = h ST , AC , TS i is an STD Z ( π ) = h GST , GAC , GT S i with phases GST ⊆ { S i | i ∈ I } as its states, t r aps GAC ⊆ S i ∈ I T i as its actions, and phase changes GTS ⊆ { S i t → S j | i, j ∈ I , t ∈ GAC } as i ts tr ansitions. The STD Z is c al le d underlying the glob al STD Z ( π ) or more deta ile d than Z ( π ) or jus t detailed . A pro cess presents a ll (sequential) dynamics a cer tain unit (compo nen t, thread, ob ject, pers on, team, etc.) can have o r can undergo as far as r elev ant in a certain situation. A phase of a pro ces s is a temp orary c o nstraint imp osed on the pro cess , restricting the pro cess to the part expr essed as phase. A trap of a phase is a tempo rary co nstraint committed to b y that phase, delib eratively taken up by entering the set of states s pecified as tr ap. A g lobal pro ces s is a pro- cess s pecifying the (sequen tial) constraint dynamics of the underlying detailed pro cess a s fa r as rele v ant to a certain (collab ora tive) situation. As such, a global pro cess ha s as states a set of phases and has a s actions connecting traps from one phase (as glo bal state) to another phase (as next globa l state). One under- lying, detailed pro cess can hav e many global pro cesses, each defined in terms of separated sets of phases a nd their traps. Such a separ ate set is determined by a partition. In ‘normal’, foreseen co ordination situatio n, an y par tition is covering; oth- erwise, what were not covered b y it, would forever b e exc luded fro m o ccur ring 18 or being reached. But, in (originally) unforeseen coor dination situations, aris- ing when lazily mo delled migra tion is to b e co ordinated, it s hould b e p ossible to e xtend pa rtitions later. So their b eing cov ering is no longer needed, rather counterproductive, as later mo deled co nstraint dynamics can allow as yet what befo re w as excluded fr om occur ring o r from being reached. Definition 2. L et { P i | i ∈ I } b e a set of detaile d pr o c esses. F or e ach i ∈ I , let J i b e another index set with 0 ∈ J i and let { π i,j | j ∈ J i , j 6 = 0 } b e a set of p artitions of pr o c ess P i . The pr o duct sp ac e of the s tate sp ac es of t hese pr o c esses is c al le d the Cartesian fra me of these pr o c esses, denote d as CF . A co nsistency r ule cr for CF has, in its c omplete form, the fol lowing format P m : s a → s ′ ∗ P e ( π e,p ): S e,p θ e,p → S ′ e,p , . . . , P f ( π f ,q ): S f ,q θ f,q → S ′ f ,q , P m [ x : = α ] wher e x is a se quenc e of variables lo c al to the detaile d pr o c ess P m and α is a c orr esp onding se qu enc e of (expr essions of ) values. The part before the ∗ is called the detaile d step of the consistency rule c r ; it contains either zero o r one detailed pr o ces s trans itio n. The part right of the ∗ of the pr oc e sses P e to P f is called the pr oto c ol s tep ; it contains zero or more phase changes, each fro m a different glo bal pro cess in frame CF . The r ight -most part, re cognizable from its square brackets inv olving pr oce ss P m , is called the change clause ; it contains one (or more) assignments to v ar iables of the lefthand pro cess P m . Optionally , the part left of ∗ , pro ces s name and tra nsition, can b e omitted. In that ca se, the part with a change claus e is absent to o. A consistency r ule cr , v ia the co upling in its format, spe cifies a (p ossible) synchronization o f single steps taken simultaneously in different co ordinates of the Cartesian fr ame CF . If the proto col step is non-empty , detailed pr oce ss P m is called m anager o f its employe es b eing the different detailed pr oce sses P e , . . . , P f . Such synchonized s tep in the frame CF can b e taken only , if not only the deta ile d step is contained in each curr en t phase o f deta ile d pr oces s P m but also, within each cur rent phase S e,p , . . . , S f ,q , the connecting tra ps θ e,p , . . . , θ f ,q hav e b een ent ered, res p ectively . A co nsistency rule s p ecifies which phase changes can o ccur simult aneous ly , strictly synchronized and at most one p er partition / glo ba l pro cess. Such syn- chronized ense m ble of g lobal steps ca n b e additionally synchronized with at most one detaile d step and if so, the larger synchronized ensemble can be even further synchonized with upda tes of one or mor e v ariables local to the s ame detaile d pro cess. Please note, constr a in ts imposed as w ell as constraints committed to really r e strict the ta king of the deta iled step a s well as the taking o f the proto col step of consistency rule cr . 19
Original Paper
Loading high-quality paper...
Comments & Academic Discussion
Loading comments...
Leave a Comment