Real-Time Behavioral Semantics of DSMLs
7.3 Real-time Behavioral Semantic Mappings
7.3.2 Encoding of Atomic Rules
An atomic rule can be triggered whenever an occurrence (or match) of its LHS, and none of its NAC patterns, is found in the model. Then, the action specified by such rule is scheduled to be realized at a non-deterministic moment of time betweent and t′time units after. Such behavior can be naturally encoded in Maude with two rewrite rules, one modeling the triggering of the atomic action, and one modeling its actual realization.
7.3.2.1 The Triggering Rule
When the precondition of an atomic rule is satisfied, i.e., when an occurrence of the LHS that does not fulfill any of the NAC patterns is found in the model, an object of the AtomicAction-Execclass (which inherits from theActionExecclass) is created. TheAtomicActionExec object will represent the execution of the atomic rule, acting as a countdown to the finalization of the action (mintimerand maxtimer attributes). This object gathers all the information needed for its instantiation, such as the name of the rule (actionattribute), the identifiers of the elements involved in the action (participantsattribute), the status of the action (status attribute), the starting time (startingTime attribute), the ending time (endingTime at-tribute), and the execution time (executionTimeattribute). Initially, the status of the action is set tounfinished; themintimerand maxtimerattributes are set to the given minimal and maximal duration of the rule, respectively; the execution time is set to zero; the starting time is set to the value of theClockinstance; and the ending time is left undefined.
For instance, the following Maude rule corresponds to the encoding of the Call action’s triggering rule (see Figure 7.13):
v a r s initTime : OCL−Type .
c r l [ Call@Triggering ] : MM@ { --- LHS elements
< p1 : PHONE@p1@CLASS | contacts : CONTACTS@p1@ATT # on : ON@p1@ATT # p1@SFS >
< p2 : PHONE@p2@CLASS | on : ON@p2@ATT # p2@SFS >
< cl : Clock | time : TIME@CLK@ >
--- Further elements
< ’ids@ : Counter | value : VALUE@ids@ >
< ’rdm@ : Counter | value : VALUE@rdm@ >
OBJSET }
=>
MM@ { --- LHS elements
< p1 : PHONE@p1@CLASS | contacts : CONTACTS@p1@ATT # on : ON@p1@ATT # p1@SFS >
< p2 : PHONE@p2@CLASS | on : ON@p2@ATT # p2@SFS >
< cl : Clock | time : TIME@CLK@ >
--- Action execution
< ACTEXC@ : AtomicActionExec | action : "Call" # participants : Set{OR1@ ; OR2@} # minTimer : MINDURATION@ # maxTimer : MAXDURATION@ # status : unfinished # startingTime : TIME@CLK@ # endingTime : null # executionTime : 0 # variables : Set{VAR1@} >
< OR1@ : ObjectRole | actualObject : p1 # role : "p1">
< OR2@ : ObjectRole | actualObject : p2 # role : "p2">
< VAR1@ : Variable | name : "initTime" # value : initTime >
--- Further elements
< ’ids@ : Counter | value : ( VALUE@ids@ + 4) >
< ’rdm@ : Counter | value : VALUE@rdm@ >
OBJSET@ }
i f MODEL@ : = MM@ { < p1 : PHONE@p1@CLASS | contacts : CONTACTS@p1@ATT # on : ON@p1@ATT # p1@SFS >
< p2 : PHONE@p2@CLASS | on : ON@p2@ATT # p2@SFS >
< cl : Clock | time : TIME@CLK@ >
< ’ids@ : Counter | value : VALUE@ids@ >
< ’rdm@ : Counter | value : VALUE@rdm@ >
OBJSET }
/\ not p1isNotInACall@Call ( Set{p1 ; p2} , < VAR1@ : Variable | name : "initTime" # value : initTime >, MODEL@ )
/\ not p2isNotInACall@Call ( Set{p1 ; p2} , < VAR1@ : Variable | name : "initTime" # value : initTime >, MODEL@ ) .
Note the use of theMODEL@ variable matched in the condition of the rule to avoid repeating the configuration in the remaining conjuncts of the condition. In the rules below, we will write dots to abbreviate their presentations.
Objects of transformation rules’ LHS patterns are encoded as Maude objects placed in the left-hand side of the Maude rule; they are also included in the right-hand side so that they remain as such. LHS conditions and slots are encoded as rule conditions, which are computed by the eval operation. The eval operation evaluates the OCL expression given as its first argument in the context specified by its second and third arguments. The second argument represents a set of variable-value bindings of the form env(var1 ← val1, ...,varN ← valN), while the third argument represents the model on which we want the expression to be evaluated.
LHS links are encoded as rule conditions too by means of invocations to theinoperation. This operation checks whether an object identifier is included in a given collection of references.
ThetoRatoperation converts a possible float number into a rational number. This operation is applied to every value of the e-Motions language that represents a time value so that they can be handled by our (discrete or dense) model of time. The participants of the rule are specified by means of ObjectRole elements. An ObjectRole object represents a pair object-role:
the object that is involved in an action (actualObjectattribute) and the role that it plays on it (role attribute). Variables are computed in rule conditions and their values are stored in Variableobjects so that they can be accessed from the realization rule (see below).
The Clock instance is included in the Maude rule (no matter if is explicitly specified in the in-place rule or not) to set the starting time of theAtomicActionExecelementACTEXC@
that represents the rule execution. TwoCounterobjects are included too. Theids@counter is used to compute the identifiers of the new created objects by using the newId operation, which creates an object identifier from a given natural number. The rdm@ counter is used when the predefined e-Motions helper random is invoked to perform successive calls to the Mersenne twister random number generator that Maude provides [44].5 Additionally, the currentExec@Call operation is included to forbid the triggering of the rule whenever an-other occurrence of the same rule is already being executed with the same set of participants.
This operation checks the existence of anAtomicActionExec object that refers to the rule (Call) with the same set of participants (Set{p1 ; p2}) and with an undefinedendingTime in the model (@MODEL).
va r L@TIMER@ : MSet{OCL−Exp} .
5Theids@andrdm@counters are always included in the rule, no matter if they are used or not.
op currentExec@Call : Set @Model −> Bool . eq currentExec@Call( Set{p1 ; p2} ,
MM@ { < ACTEXEC@ : AtomicActionExec | action : "Call" # endingTime : null # participants : Set{OR1@ ; OR2@ ; L@TIMER@} # ACTEXEC@SFS >
< OR1@ : ObjectRole | actualObject : p1 # role : "p1">
< OR2@ : ObjectRole | actualObject : p2 # role : "p2">
OBJSET@ })
= true .
eq currentExec@Call( OIDSET@ , MODEL@ ) = false [ owise ] .
NAC patterns are encoded as predicates which are invoked from rule conditions (see the p1isNotInACall@Callandp2isNotInACall@Callpredicates). These predicates check whether occurrences of the specified patterns are found in the model. Their first and second parameters indicate the set of objects that are involved in the LHS pattern and the set of vari-ables defined in the rule, respectively, so that they can be referred from the NAC pattern. For instance, the following excerpt of code specifies thep1isNotInACall@Callpredicate:
va r initTime : OCL−Type . va r L@a : MSet{OCL−Exp} . v a r s OR1@a : Oid .
v a r s OR1@a@SFS : Set{@StructuralFeatureInstance} .
op p1isNotInACall@Call : Set Set{@Object} @Model −> Bool . eq p1isNotInACall@Call( Set{p1 ; p2} ,
< VAR1@ : Variable | name : "initTime" # value : initTime >, MM@ { --- NAC elements
< a : AtomicActionExec | action : "Call" # status : unfinished # participants : Set{OR1@a ; L@a} # a@SFS >
< OR1@a : ObjectRole | actualObject : p1 # OR1@a@SFS >
--- Further elements OBJSET@ })
= true .
eq p1isNotInACall@Call( OIDSET@ , OBJSET@ , MODEL@ ) = false [ owise ] .
In this case, the NAC pattern is only composed of an action execution element. Action execu-tion elements are encoded asAtomicActionExecobjects, while object mappings are encoded asObjectRole objects. Note that theObjectRole does not restrict the role that object p1 plays in the rule, since it was left undefined in the specification of the atomic rule (see Fig-ure 7.13).
DPO and SPO formalizations. The encoding of the atomic action’s triggering rule presented above follows the SPO formalization. However, our tool also supports the DPO formalization.
When the DPO formalization is chosen, an invocation of the dpo predicate is added to the conditions of the triggering rule. This predicate has three arguments: 1) the set of elements to
be deleted specified by the rule; 2) the list of links (of sortMyLinkList) to be deleted specified by the rule; and 3) the model on which the condition required by the DPO formalization will be checked. Thedpooperation firstly deletes from the model all the links and objects (including their contained objects) specified by the rule to be deleted (lines 4 to 6), and then checks whether no references to these deleted elements are left in the model (lines 8to 17). If any dangling reference is found, the DPO condition is not satisfied and the rule will not be applied.
1 v a r s L L’ : MSet{OCL−Exp} .
2 v a r s LO LO’ : List{OCL−Exp} .
3
4 op dpo : Set MyLinkList @Model−> Bool .
5 eq dpo( SET , MLL , MODEL ) = dpo ( union ( SET , getAllContainedOids ( SET , MODEL ) ) ,
6 deleteEls( SET , deleteLinks ( MLL , MODEL ) ) ) .
7
8 op dpo : Set @Model−> Bool .
9 eq dpo( Set{mt} , MODEL ) = true .
10 --- Possible references to deleted elements
11 eq dpo( Set{O ; L} , MM {< O ’ : C | ( REF : Sequence{LO # O # LO’} # SFS ) > OBJSET}) = false .
ThegetAllContainedOidsoperation obtains from a set of objects (SET) the set of iden-tifiers of the objects recursively contained by them. ThedeleteEls anddeleteLinks op-erations remove a set of objects (including their contained objects) and a list of links from a model, respectively.
7.3.2.2 The Realization Rule
Once an atomic action’s minimum timer is consumed (i.e., there is an AtomicActionExec object whoseminTimerattribute’s value is0) the corresponding action can be performed if its participants are still there. Then, the matching of the LHS is substituted by the corresponding instantiation of the RHS and the attribute computations are realized. To keep track of the performed actions, the AtomicActionExec objects are not deleted, but their ending times are set, and their corresponding status and participants are updated instead. For instance, the following Maude rule corresponds to the encoding of theCallaction’s realization rule:
va r initTime : OCL−Type . c r l [ Call@Realization ] :
MM@ { --- LHS elements
< p1 : PHONE@p1@CLASS | contacts : CONTACTS@p1@ATT # dialedCalls : DIALEDCALLS@p1@ATT # p1@SFS >
< p2 : PHONE@p2@CLASS | receivedCalls : RECEIVEDCALLS@p2@ATT # p2@SFS >
< cl : Clock | time : TIME@CLK@ >
--- Action execution with minimum timer consumed
< ACTEXEC@ : AtomicActionExec | action : "Call" # participants : Set{OR1@ ; OR2@} # minTimer : 0 # status : unfinished # endingTime : null # executionTime : T # variables : Set{VAR1@} # ACTEXC@@SFS >
< OR1@ : ObjectRole | actualObject : p1 # role : "p1">
< OR2@ : ObjectRole | actualObject : p2 # role : "p2">
< VAR1 : Variable | name : "initTime" # value : initTime >
--- Further elements
< ’ids@ : Counter | value : VALUE@ids@ >
< ’rdm@ : Counter | value : VALUE@rdm@ >
OBJSET@ }
=> readjust ( ACTEXEC@ , Set{mt} , MM@ { --- RHS elements
< p1 : PHONE@p1@CLASS |
contacts : update ( contacts , CONTACTS@p1@ATT , nil , link ( p2 , null ) ) #
dialedCalls : update ( dialedCalls , DIALEDCALLS@p1@ATT , nil , link ( c1 , null ) ) # p1@SFS>
< p2 : PHONE@p2@CLASS | receivedCalls : update ( receivedCalls , RECEIVEDCALLS@p2@ATT, nil , link ( c2 , null ) ) # p2@SFS >
< ACTEXEC@ : AtomicActionExec | action : "Call" #
participants : Set{OR1@ ; OR2@ ; OR3@ ; OR4@} # minTimer : 0 # status : realized # endingTime : TIME@CLK@ # executionTime : T # variables : Set{VAR1@} # ACTEXEC@SFS >
< OR1@ : ObjectRole | actualObject : p1 # role : "p1">
< OR2@ : ObjectRole | actualObject : p2 # role : "p2">
< OR3@ : ObjectRole | actualObject : c1 # role : "c1">
< OR4@ : ObjectRole | actualObject : c2 # role : "c2">
< VAR1 : Variable | name : "initTime" # value : initTime >
--- Further elements
< ’ids@ : Counter | value : ( VALUE@ids@ + 4) >
< ’rdm@ : Counter | value : VALUE@rdm@ >
OBJSET@ }
Objects that are specified by the rule to be created are added to the right-hand side of the Maude rule and included as new participants of the action execution. The complete operation adds to a new object all the structural feature-value pairs (with their default value) that are not explicitly specified within the object’s slots in the rule. RHS slots are encoded as computations in the right-hand side of the rule. The final duration of the rule T is obtained from theAtomicActionExecobject’sexecutionTimeattribute. Links that are specified by the rule to be created or deleted are so by means of theupdateoperation. The first parameter of this operation is the reference that the link represents; the second parameter represents the previous value of the reference; the third parameter represents the list of links to be deleted;
and the fourth parameter represents the list of links to be added. For this operation, we specify links as pairs (o, p), where o represents the target object identifier and p its possible position in the source collection of references (nullif not specified).
Thereadjustoperation performs the deletion of objects (second parameter) that are spec-ified in the in-place rule to be deleted (an empty set in this case). These deletions are handled with an equation (instead of simply not including the objects in the right-hand side pattern of the rewrite rule) because further processing is usually needed. In particular, once an object is deleted, all its contained objects and the set of all possible dangling references that its deletion may cause should be deleted as well.6 Thereadjustoperation is also responsible for abort-ing all the current action executions on which any of the elements that are specified by the rule to be deleted are involved in. Similarly, it aborts all unfinished actions in which the current finished action executionACTEXEC@specified by this rule participates (see Section 7.2.3.4).