Action Statements

In in-place model transformation approaches, LHS, RHS, and NAC patterns are defined in terms of system states. This is a strong limitation in those situations in which we need to refer to actions currently under execution, or to those that have been executed in the past. For example, we can be interested in knowing whether an object is currently performing a given action to take some decision, e.g., to interrupt the action (e.g., in case an exception occurs), or not to allow the object to perform another action. We can also be interested in reasoning about the performed actions so far (e.g., to be able to search for undesirable action occurrences or invalid sequences of action executions). Note that a given system state may usually be reached by performing different sequences of actions, and checking only system states will not always give us information about the performed actions. In general, the inability of modeling and dealing with action occurrences hinders the specification of some useful action properties, unless some unnatural changes are introduced in the system model—such as extending the system state (i.e., the metamodel of the DSML) with information about the actions currently happening.

In order to be able to model both state-based and action-based properties, we propose ex-tending model patterns with action executions to specify action occurrences. These action executions will contain information on the type of the action (given by the name of the atomic rule that represents the action); its status, i.e., if the action is unfinished, realized, interrupted or aborted (see below); and its identifier. They may also specify its starting and ending time—the latter one can only be specified for non-unfinished actions—, its execution time, and the set of participants involved in it. These participants are specified by object mappings, which are sets of pairs (o→ r). Each pair identifies the object that participates in the action (o) and one of the roles it plays in the rule (r). For instance, the Call rule in Figure 7.13 defines five roles: two phones (p1andp2), the clock instance (cl), and two call records (c1andc2), which correspond to the identifiers of the elements placed in LHS and RHS patterns. When using action execu-tion in patterns, we can also leave unspecified the type of the rule and the role of an object to represent whatever rule instantiation or object role, respectively.

Action executions whose status is unfinishedrefer to actions that are currently happening, i.e., actions which have been triggered but its duration time has not been consumed yet. Action executions whose status isrealizedrefer to actions that were already performed (i.e., the effects specified in their RHS were already applied). Action executions whose status isinterrupted re-fer to actions that were triggered but not realized because their corresponding action executions

were deleted by a rule explicitly modeled by the user for that purpose (see below). And finally, action executions whose status is abortedrefer to actions that were triggered but not realized because any of its participants were removed from the system before the duration time of the action was consumed, i.e., actions that were automatically discarded because they could not be completed.

7.2.3.1 Concurrency

Atomic rules have a duration, and they can be applied whenever an occurrence of the LHS pattern and none of the NAC patterns are found in the model. Therefore, elements can be engaged in several actions at the same time. This is very useful for modeling realistic situations in a natural way, e.g., a phone can be involved in a talk while its coverage is being updated, its battery decreased, and it is receiving a message. As we previously mentioned, the triggering of an atomic rule is only forbidden if another occurrence of the same rule is already executing with the same participants. However, there are some situations on which we want to forbid (or enforce) the execution of a rule if one of its participants is already performing the same action with different participants, or simply one of its participants is performing any other action.

Figure 7.13:The Call atomic rule.

As an example, Figure 7.13 shows the Call atomic rule, which models the behavior of a call from a cell phone to one of its contacts. To make a call, both phones must be on and have coverage. Furthermore, we do not allow call waiting: we want to forbid the execution of the rule whenever one of the phones (p1orp2) is participating in another call. For this purpose, we make use of action executions in NAC patterns. These action executions explicitly specify

that phonep1andp2are currently participating (notice theunfinishedstatus label in the action execution’s header) in a Call action. Note that there is no role specified forp1 nor forp2 in the action execution, and therefore it refers to any instantiation of theCallrule wherep1orp2 is participating, no matter if the phone is the caller or the callee. For the same reason, since no other participant is specified in the action execution, it refers to any instantiation of theCall rule independently of the remaining participants, i.e., no matter ifp1(orp2, respectively) is in aCallwithp2(orp1, respectively) or with any other phone.

At the end of the talk, the call is registered in both phones (as a dialed call in phone p1 and as a received call in phonep2³) including the duration of the call (T) and its starting time (initTime). Note that T refers to the duration of the current rule execution, which will vary between 20 and 30 time units. The starting time of the call is computed by using the clock instance together with a variable. Variables are computed when the rule in which they are defined is triggered, and they can be used in all the patterns (LHS, RHS and NACs) defined for the rule. In this case, we use theinitTimevariable to store the value of the clock at the moment of the triggering of the rule, and then assign it to thestartingTimeattribute of the call records at the moment of the finalization of the rule.

7.2.3.2 Separation of Concerns

Ongoing rules usually model system properties that must be continuously updated. However, the updating of these properties can also depend on the realization of other actions of the system. Think for instance on battery consumption, which could be greater while we are engaged in a call; or the position of the phones: some people stop moving when they are in a talk; etc. As a first attempt, the user can try to include the adjustment of these system properties in every atomic rule that interferes with them. However, the properties will not be properly updated until the actions are completely performed, and therefore it can lead to some inconsistent states in the meantime. Thus, the best way to do this is by using ongoing rules together with action executions to model separately the continuous updating of this kind of properties.

As an example, let us revisit the modeling of the battery consumption, and let us replace the rule in Figure 7.10 with the following rules. Figure 7.14 shows theTalkingBatteryConsumption

3Although the e-Motions tool does not show in its diagrams the type of the links, every link is associated with a specific reference (EReference) defined in the metamodel of the DSML for which we are specifying its behavior. In this example, the links between thep1andp2phones and their corresponding call recordsc1and c2refer to thedialedCallsandreceivedCallsreferences of the MPN metamodel, respectively.

Figure 7.14: The TalkingBatteryConsumption and StandbyBatteryConsumption ongoing rules.

andStandbyBatteryConsumptionongoing rules, which models the battery consumption while phonepis involved in aCallaction and when it is not, respectively. Since a phone consumes more battery when it is participating in a call, we will duplicate (two timesbps battery units per time unit) its battery consumption. Note that ongoing actions are always updated before the triggering of any atomic rule, and therefore these two rules will never be executing at the same time for the same phone.

7.2.3.3 Past Actions

There are some situations in which the triggering of an action may depend on the previous realization (or not) of another action. For instance, there are actions that must be realized just once; some others can only be triggered after the realization of another action (e.g., a sequence of action must be somehow enforced); etc. Reasoning about past actions usually allows us to take better decisions about future actions. Thus, action execution can also refer to past actions.

Figure 7.15 shows theInitialModelrule, which creates the initial configuration of the system.

In particular, it creates all the model objects specified in Figure 7.4. TheNotExecutedBefore NAC pattern forbids the triggering of the rule if it was already performed before (note the realized status label in the action execution’s header), independently of its participants. No

Figure 7.15:The InitialModel instantaneous rule.

other condition is required: the LHS pattern is empty, and therefore it is always fulfilled.

Note that this mechanism allows us to create models conforming to our DSML’s meta-model, which is specially relevant when our DSML is not supported by a more sophisticated graphical concrete syntax.

7.2.3.4 Exceptions in Actions

Atomic rules are realized at a non-deterministic moment of time between t and t^′ time units after its triggering, where t and t^′ represent its duration interval of time. The only condition for their final application is that the elements involved are still there; otherwise the action will be aborted. Nothing is assumed about what happens while the action is being executed: if we want to make sure that something happens or does not happen, we can make use of action execution elements to model the corresponding exceptional behavior. In particular, we can add new rules that model action interruptions by deleting their corresponding action executions, i.e., by including them in a rule’s LHS pattern but not in its RHS pattern. Their effects will be then defined in the rule’s RHS pattern.

Figure 7.16:The BatteryOffCaller instantaneous rule.

Consider, for instance, the BatteryOffCaller atomic rule in Figure 7.16, which models the behavior of a caller phone when it runs out of battery in the middle of a conversation. The instantaneous rule is triggered whenever two phonesp1andp2are participating in aCallaction, and the caller phone p1 has no battery. In this case, the Call action is interrupted, the call registered in both phones, an the caller phonep1 is switched off. Note the use of object roles in the action execution element to identify the caller and the callee phones (i.e., the roles that p1andp2play in theCallaction), which allow us to properly register the call: as a dialled call for the caller phonep1, and as a received call for the callee phonep2.

Figure 7.17:The BatteryOffCallee instantaneous rule.

Analogously, theBatteryOffCalleeatomic rule shown in Figure 7.16 models the behavior of a callee phone when it runs out of battery in the middle of a conversation.

Figure 7.18:The BatteryOff instantaneous rule (revisited).

Note that the BatteryOffCaller and BatteryOffCallee rules consider that a phone runs out of battery in the middle of a talk to switch off the phone and record the call. However, as currently modeled, the BatteryOff rule could be applied instead, and the call would not be registered. Therefore, we modify the BatteryOff rule to forbid its application whenever the phonepis participating in aCallaction. The resultingBatteryOffrule is shown in Figure 7.18.

Finally, note that it only makes sense to interrupt actions that are currently happening. We do not allow to “delete” (include in the LHS pattern and not in the RHS one) action executions whose status is other than unfinished. Note also that action executions placed in a rule’s LHS (or RHS) pattern become also participants in the rule when it is executed. Therefore, in the same way in which atomic rules are aborted when any of its participant objects is removed from the system before their duration time is consumed, they will be aborted when any of its participant action executions is removed (by explicit deletion or because the action is realized) as well. This means that if an action execution in a LHS pattern refers to an unfinished ac-tion, the referred action must be still unfinished at the moment of the finalization of the rule, otherwise the rule application will be aborted.⁴ This has to be taken into account only for action executions that refer to unfinished actions, since the status of finished actions (whether realized, interrupted or aborted) will never change, and they cannot be interrupted.

The deletion of action executions is included in our proposal to model the interruption of actions in an intuitive way. However, action executions are not defined to handle them as common model objects. For instance, we cannot force the triggering of an action by creating an action execution (by including it in a RHS pattern and not in its corresponding LHS pattern).

4Action interruptions should be modeled as instantaneous rules to avoid this situation.

We only allow rules to be triggered when a match of its LHS pattern (and none of its NAC patterns) is found in the model. In the same way, we do not allow users to explicitly modify any of the action execution properties by modeling the corresponding behavior in a rule. Action execution elements are included in our approach only for (a) reasoning about the existence of (past or present) action occurrences, and (b) interrupting actions in the way we have described in this section.