Estado del arte: fortalezas y debilidades

In this subsection we show how time-related attributes can be added to rules to represent fea-tures like duration, periodicity, etc. We identify two types of rules to specify time-dependent behavior, namely atomic and ongoing rules, and we include a special kind of object, Clock, that represents the current global time elapse.

7.2.2.1 Atomic Rules

One natural way to model time-dependent behavior quantitatively consists in decorating the rules with the time they consume, i.e., by assigning to each action the time it takes. Thus, we define atomic rules as in-place transformation rules of the forml : [NAC]^∗ × LHS ^[t,t→ RHS,^′] where [t, t^′] expresses the duration interval of the action modeled by the rule, i.e., the minimum and the maximum amount of time needed to perform the action.

As normal in-place transformation rules, an atomic rule can be triggered whenever an oc-currence (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 between t and t^′ time units later. At that time, the rule is applied by substituting the match by its RHS and performing the attribute computations.

Since actions have now a duration, elements can be engaged in several actions at the same time. The triggering of an atomic rule is only forbidden if another occurrence of the same rule is already being executed with the same participants,¹ to avoid non-terminating executions.

Note that the states of the elements that participate in a timed action may vary during the action’s time elapse, since the states of the elements may be modified by other actions. The only condition for the final application of an atomic rule is that the elements involved are still there; otherwise the action will be aborted. If we want to make sure that something happens (or does not happen) during the execution of an action, we can make use of action execution elements to model the corresponding exceptional behavior (see below).

As an example, Figure 7.5 shows theSwitchOnatomic rule. When a phone is off and has enough battery, it is switched on in five time units. More precisely, if a phone pwhich is off

1We call participants of a rule to those objects andActionExec elements that instantiate the rule’s LHS pattern.

Figure 7.5:The SwitchOn atomic rule.

and has more than five timesbpsbattery units is found in the model, after five units of time it is switched on and its battery decreased five timesbps battery units, wheneverpstill remains in the model; otherwise, the action is simply aborted. Note that, in this case, the minimal and maximal duration of the rule coincide, so the rule duration is deterministic. The attribute computationp.battery - 5 * p.bpsis performed at the moment of the finalization of the rule, and therefore property values (p.bateryandp.bps) are accessed at this moment of time (but previous to any computation performed by the RHS pattern). If the value of the properties at the moment of the triggering of the rule were needed, variables could be used (see Section 7.2.3).

Instantaneous rules. Atomic rules extend in-place transformation rules with the time they consume. Therefore, standard in-place rules can be modeled as atomic rules with no duration.

We named this kind of rules instantaneous rules, and they are modeled with atomic rules which take zero time units. No other action may occur during the execution of this kind of actions.

Figure 7.6:The BatteryOff instantaneous rule.

The BatteryOffrule, which is depicted in Figure 7.6, is an example of instantaneous rule:

whenever a phonepthat is on and has no battery, it is switched off.

Rule execution modes. We distinguish normal rules, which are triggered as soon as possi-ble, from soft rules, which are not necessarily triggered immediately, but in a non-deterministic moment in time in the near future (e.g., next time the clock is stopped because some event hap-pens). Contrary to normal rules, soft rules are not forced to be applied whenever its LHS pattern (and none of the NACs) occurs in the model.

The SwitchOn action in Figure 7.5 is modeled by a soft rule (notice the soft label in the rule’s header): we allow phones to be switched on at a non-deterministic moment in time.

However, theBatteryOff action in Figure 7.6 is modeled by a normal (non-soft) rule: mobile phones must go off as soon as they run out of battery.

The e-Motions language also supports the definition of scheduled actions, which are ac-tions that are tried to be triggered at a specific moment in time (and only at that moment in time). This kind of actions will be actually triggered if their preconditions hold at that moment of time, i.e., if an occurrence of their LHS, and none of their NAC patterns, is found in the model. They are modeled by normal (non-soft) atomic rules whose lower and upper bounds (lowerBoundandupperBoundattributes, see Figure 7.1) coincide with the moment in time at which the rules are scheduled.

Figure 7.7: The RemoveOffPhones scheduled rule.

The RemoveOffPhonesrule, which is depicted in Figure 7.7, is an example of scheduled rule: we plan to remove from the system all the phones that are off at the moment of time150 (notice this value specified as the rule’s lower and upper bounds between the square brackets in the right-hand side of the header of the rule).

These rule execution modes are also applicable to ongoing rules.

Periodicity. Another essential aspect for modeling time-dependent behavior is periodicity.

Atomic rules admit a parameter that specifies the period of an action. We distinguish between normal periodic rules and soft periodic rules: both kinds of rules are triggered as soon as possible, but normal periodic rules can only be triggered at the beginning of the period—if they cannot be triggered at that moment of time they will not be enable until the next period—, while soft periodic rules can be triggered at any time within the period—if they cannot be triggered at the beginning of the period they will be tried to be triggered at any other time within the period (but only once per period).

Figure 7.8:The Coverage periodic rule.

Figure 7.8 shows the Coverage atomic periodic rule, which specifies the way in which antenna coverage changes. Coverage is updated every five time units (notice the loop icon in the header of theCoveragerule). Each cell phone is covered by its closest antenna: as specified in its NAC pattern, the rule cannot be applied if there exists another antenna closer to the phone.

Figure 7.9:The distance helper.

To compute the distance between an antenna and a phone, we have defined the distance helper(see Figure 7.9). A helper is defined as an OCL operation. Helper invocations in LHS and NAC patterns are computed at the triggering of actions, while helper invocations in RHS patterns are computed at their realization. Thus, note that the distance between the antenna and the phone may vary on these two different moments of time. If the same value were needed, a variable could be used (see below).

The e-Motions tool is designed to provide useful predefined helpers. For instance, it cur-rently supports, by means of the emotions.random(b : Int) : Int helper, the generation of a

pseudo-random number between zero and the given boundb.

7.2.2.2 Ongoing Rules

In addition to atomic rules, e-Motions also provides rules to model actions that are continuously progressing and require to be continuously updated. Think for instance of an action that mod-els the consumption of a phone battery, whose level decreases continuously with time. This property must be always updated, since most rules (such asSwitchOnandBatteryOff) depend on its value.

Ongoing rules model this kind of behavior. They are used to model actions that a) do not have a priori duration time—they progress with time while the rule preconditions (LHS and NACs) hold, or until the time limit (maxDuration) of the action is reached—and b) are required to be continuously updated— their effects are always computed before the triggering of any atomic rule.

Figure 7.10:The BatteryConsumptionRule ongoing rule.

For example, Figure 7.10 shows the BatteryConsumption ongoing rule, which models phone battery consumption (note the use of the purple background for the arrow in the rule to distinguish ongoing actions from atomic ones, on the blue background). According to this rule, the battery power is decreasedbps battery units per time unit. To explicitly identify the state in which a phone runs out of battery, and not to decrease the battery power below zero, we limit the duration of the rule (see the expression on the right-hand side of symbol≤). Since the effects of ongoing actions are always realized before the triggering of atomic rules, phone batteries will always be updated whenever an atomic rule is tried to be triggered.

Phones moving can also be modeled by an ongoing rule, which is shown in Figure 7.11.

In this case, the position of each phone will be updated according to its velocity vector and time elapse. We suppose that phones can only move inside the limits of the MPN they belong

Figure 7.11: The Moving ongoing rule.

to, and therefore positions and velocity vector are always corrected according to these limits, which are given by xSize and ySize MPN’s attributes. Notice that the Moving rule has no maximum duration, that means that phones will keep moving for ever. The correctPos and correctVhelpers, shown in Figure 7.12, are defined for this purpose.

Figure 7.12:The correctPos, correctV and power helpers.

Note that, by using ongoing rules, we have modeled battery consumption and phone move-ment separately from the other behavior rules, avoiding concern tangling. Even if the battery consumption or phones moving would depend on the execution of other actions, we could define their behavior in a separate way by using action executions, as we shall see below.

Atomic rules versus ongoing rules. Our approach provides two different kind of rules: on-going and atomic. These two types of rules are provided to model different kind of actions.

Of course, we could try to model ongoing actions using periodic atomic actions, by somehow

“discretizing” them and using the minimum time elapse as the period (e.g., one time unit).

However, this solution becomes quite inefficient in a simulation (or analysis) scope: the rule would be applied at every time unit. Furthermore, if the rule is used to model a property that must be updated at every time moment, we should explicitly force the rule to be executed at

every time unit before the triggering of any other rule, complicating the design of the rule by in-troducing some control mechanisms. As we shall see in Section 7.3, ongoing rules are updated according to time elapse as needed, and previously to the triggering of any atomic rule.

Moreover, ongoing rules can hardly model some atomic actions. In the best case, we could modify the DSML’s metamodel to include some kind of timer that represent a countdown to the finalization of the atomic action, together with some links to gather the information about the rule instantiation. The idea would be then to use three ongoing rules per each atomic ac-tion: an initial rule that set two different timerst1andt2to the minimal and maximal duration of the action, respectively; another rule that decreases the timers; and a third rule that checks whethert1has been consumed andt2has not been so, and if so substitutes the corresponding match by its RHS. However, this approach has several drawbacks: a) it does not have exactly the same semantics as a single atomic rule (if the same semantics were required, more con-trol mechanisms need to be included); b) it cannot model instantaneous rules (ongoing rules progress with time, and they require time to elapse to be executed); and c) this mechanism would imply breaking our principle of separation of concerns, since we have to modify the DSML’s metamodel to include action properties.

Therefore, we strongly recommend the use of both kinds of rules (atomic and ongoing) were needed, avoiding the artificial (and probably incorrect) design of actions by using only one kind of rule.

7.2.2.3 Global Time Elapse

We provide a special kind of object, namedClock, that represents the current global time elapse.

A unique and read-only Clock instance is provided by the system (i.e., it does not need to be created by the user) to model time elapse through the underlying platform. This allows designers to use theClockin their timed rules to get the current time (using its attributetime) to model, e.g., time stamps (as we shall see later on with theCallrule). Provided that the clock behavior cannot be modified, users cannot drive the system to time-inconsistent sequences of states (even unwillingly).²

2Of course, users can define their own clocks to model other aspects of distributed systems (such as distributed clocks) and specify how they individually evolve. In this case, the user is responsible for the correct modeling and use of these clocks.