2.2.8 Actions and Guards

There is no strict definition of actions in the semantics of DCharts 1.0. As a loose definition, an action is a statement in an action language, which modifies the variables of the model, outputs events, or interacts with other parts of the system that are not modeled with DCharts. An implementation of DCharts may support an action language that is specific to it. For example, because SVM is implemented in Python and Python is an interpreted language, Python is chosen as the action language for SVM. Other DCharts implementations may use different action languages.

An action language must satisfy the following rules:

• An action must not modify the state hierarchy of the model. Nor can it reflect upon the current state of the model.

• Actions are executed sequentially. They must not contain any control flow structure, such as branches and loops.

• An implementation of DCharts usually provides primitive actions to model designers. With those primitive actions, the models are able to interact with the simulation or execution environment, or broadcast events. Examples of models' interaction with the simulation or execution environment include but are not limited to snapshot requests. (The complete state of the model is taken by a snapshot, which may be used later to roll back the model.) Snapshot is discussed later.

• A primitive action must be provided to access the elapsed time since the simulation or execution was started. The increment of this time must be synchronized with the wall-clock. I.e., the time obtained by this primitive action is increased by 1 after 1 second is elapsed in reality. (The accuracy depends on the operating system.)

The case of constraint language is similar. A constraint language is used to express guards of transitions. A guard is a side-effect-free statement that can be evaluated to either $true$ or $false$ at the time when the simulator or executor decides whether a transition is enabled. (In particular, for a timed transition with a guard, the guard is evaluated after the scheduled amount of time instead of at the time when the transition is scheduled.)

A constraint language must satisfy the following rules:

• A guard written in the constraint language must be side-effect-free. The language must not allow any change on the states or variables. Nor should it allow guards to control other parts of the system, which are not modeled.

• A guard is allowed to access the current state of the model. This makes it possible for an orthogonal component to dynamically decide whether a transition should be fired based on the current states of other orthogonal components.

• A guard should never affect the simulation or execution process (for example, by causing the model to sleep for a certain amount of time or by snapshotting or rolling back the model).

• Guards must be deterministic. Provided that all the states or variables (including those in the parts that are not modeled) that a guard depends on are not changed, the guard must always yield the same $true$ or $false$ result.

The above are the minimal requirements for DCharts actions and guards. Later versions of DCharts may explicitly define an action language and a constraint language, or specify more requirements for them.