This example models the behavior of Mobile Phone Networks (MPNs).

System Modeling


The MPN metamodel is shown in the following figure:

An MPN has cell phones and antennas. Antennas provide coverage to cell phones, depending on their relative distance. A cell phone is identified by its number, and can perform calls to other phones of its contact list. Dialed and received calls are registered. Phone’s attribute bps represents the battery consumption per time unit, while vx and vy their velocity vector (we suppose that cell phones are moving continuously).

We describe a graphical concrete syntax for this language by defining a gcs model. In a gcs model, we associate every class of the metamodel with a picture. This concrete syntax will be used in the definition of the behavioral rules.


We have designed the following set of rules and helpers to model the behavior of MPNs:

The InitialModel rule creates the initial configuration of the system. The NotExecutedBefore NAC pattern forbids the triggering of the rule if was already performed before (note the realized status label in the action execution’s header), independently of its participants. No other condition is required: the LHS pattern is empty, and therefore it is always fulfilled. This rule creates all the model objects specified in the figure:

When a phone is off and has enough battery, it is switched on (and its battery decreased) in five time units through the SwitchOn rule. The BatteryOff models the opposite behavior: whenever a phone is on and has no battery, it is switched off.

The Coverage periodic rule specifies the way in which antenna coverage changes. Coverage is updated every five time units. Each cell phone is covered by the closest antenna: as specified in its NAC pattern, the rule cannot be applied if there exists another antenna closer to the phone. To compute the distance between an antenna and a phone, we have defined the distance helper. A helper is defined as an OCL operation. This rule is shown in the following picture:


The BatteryConsumption ongoing rule models phone battery consumption (note the use of purple arrow to distinguish ongoing actions from atomic ones). According to this rule, the battery power is decreased bps 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.

Phones moving is also modeled by an ongoing rule, the Moving rule. In this case, the position of each phone will be updated accordingly to its velocity vector and time elapse. We suppose that phones can only move inside the limits of the MPN they belong to, and therefore positions and velocity vector are always corrected accordingly to these limits, which are given by xSize and ySize MPN’s attributes. The correctPos and correctV helpers, are defined for this purpose.

The following picture 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 (p1 or p2) is participating in another call. For this purpose, we make use of NAC patterns together with action executions. These action executions explicitly specify that phone p1 (and p2, respectively) is currently participating (notice the unfinished status label in the action execution’s header) in a Call action.

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 phone p2) including the duration of the call and its starting time. The duration of the current rule execution 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.

The BatteryOffCaller atomic rule models the behavior of a caller phone when it runs out of battery in the middle of a conversation. The rule is triggered whenever two phones p1 and p2 are participating in a Call action, 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 phone p1 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 p1 and p2 play in the Call action), which allow us to properly register the call: as a dialled call for the caller phone p1, and as a received call for the callee phone p2. Analogously to the BatteryOffCaller rule, the BatteryOffCallee atomic rule models the behavior of a callee phone when it runs out of battery in the middle of a conversation.


We can configure eMotions launcher to run the simulation as shown in the figure:

We do not need to specify an initial model since we have a rule that creates it. Of course, we can simulate the system with different initial configurations by modifying the InitialRule. In this case, as a result of the simulation we will obtain a MPNs model in which phones have switched on, antennas have supplied phones with coverage and phones have made calls between them:


The file contains the project with all files required to try this example: the metamodel definition, the graphical concrete syntax for the metamodel and its corresponding behavioral specifications. To import this project, right click on the navigation view Import...-> General -> Existing Projects into Workspace -> Select archive file and then select the file.