Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Guards and Effects

Guards and Effects are used to control the flow of the simulation and to execute additional actions or effects during the course of a simulation.

Guards and Effects

Topic

Detail

See also

Guards

Guards are conditional statements that are evaluated anytime the simulator needs to decide which path to take next. Guards typically have the following characteristics:

•Defined on transitions and control flows to govern how simulation proceeds
•Written in Javascript
•May refer to variables defined during simulation

 

Dynamic Simulation with Javascript

Adding Guards

Guards are defined on the Transition or Control Flow in the Properties dialog for the selected connector. A Guard is typically a piece of Javascript that will evaluate to either true or false. For example, the following is a conditional statement that refers to a current variable (Balance) being greater than zero. Note the use of the prefix this to indicate that the variable is a member of the current Class context.

 

StateTxGuard

 

 

Evaluation Semantics

During execution the Simulator will examine all possible paths forward and evaluate any guard conditions. Based on this evaluation the following can occur:

•A single valid path forward evaluates to true; the simulator will follow that path
•Two valid paths are found; the simulator will block, waiting for some manual input via the console window to resolve the deadlock
•No valid path exists; the same response as when two paths are found - wait for the user to change the execution context using the console window
•No paths evaluate to true but a default (unguarded path) exists; the Simulator will take the unguarded path

 

 

Effects

Effects are defined behaviors that are executed at special times:

•On entry to a state
•On exit from a state
•When transitioning from one state to another (transition effect)

 

Effects can either be a section of Javascript code or a call to another Behavior element in the current simulation.

 

 

Javascript Effects

A Javascript effect might resemble the example below, in which the Balance variable is decremented:

TransitionEffect1

 

 

Call Behavior Effects

In the example below the effect is a call behavior effect. In this case it calls into a model Activity named Decrement Balance that is defined elsewhere. The simulation will then enter into that diagram/behavior and continue to execute until returning to the point at which the effect was invoked.

TransitionEffect2

 

 

 

Order of Execution of Effects

In complex simulations that might involve transitioning out of deeply nested states into other deeply nested states in a different parent context, it is important to consider the following rules concerning the order of execution:

•All exit actions (effects) encountered leaving a nested context are executed in order of most deeply nested to least deeply nested
•All actions (effects) defined on transitions are executed next
•Finally, all entry effects are executed from the least deeply nested context to the most deeply nested
 

So the basic rule is: all exit actions, followed by all transition actions, and finally all entry actions.

 

 

Note on Javascript Variables

Javascript variables to be accessed and referred to during Simulation execution must be prefixed with either:

•sim.  e.g. sim.pedestrianwaiting - typically used for global simulation variables, or
•this.  e.g. this.CustomerNumber - typically used to refer to owning Class attributes

 

This is important to let the Javascript engine know you are referring to a SImulation variable and not a simple local variable used during, for example, basic calculations.  You can create Simulation variables of arbitrary scope and depth - for example, this.customer.name is a legitimate qualified name.

 

 

Learn more