Formal Semantics

Details of the formal semantics of POOSL can be found in:

  • L.J. van Bokhoven, Constructive tool design for formal languages: from semantics to executing models, PhD thesis, Eindhoven University of Technology, Eindhoven, The Netherlands, 2002. DOI

The semantics of the data layer is defined as a probabilistic denotational semantics. It generally follow the behaviour of traditional object-oriented languages like Java. Its probabilistic nature is derived from an explicit modeling of probabilistic behaviour introduced by RandomGenerator objects.

The semantics of the process and architecture layers is defined as a probabilistic, timed, structural operational semantics similar to process calculi such as CCS or CSP. The probabilistic behaviour of processes originates from the probabilistic behaviour of data objects. The semantics of POOSL follows a two-phase execution model. The state of a model can either change by asynchronously performing actions or by synchronous passing of time. Time only advances if there are no actions that can be performed immediately (action urgency). The semantics ultimately defines a timed probabilistic labelled transition system of the form

It includes a set of configurations, each reflecting a possible state of the model during its execution. The initial configuration represents the initial state of the model at the start of its execution. A configuration includes the specification of behaviour that is to be executed in the context of information . Behaviour indicates the statements describing the (future) behaviour of an executing model, while information captures the data objects that are assigned to global and local variables. The timed probabilistic labelled transition system furthermore includes a set of actions, a time domain and two sets of labelled transition relations. For , three kinds of elements are distinguished:

  • the internal action and fix action , representing computations that are unobservable by the environment of an executing model;
  • communication actions of the following two forms. A send action denotes sending message with parameters to port , whereas the receive action indicates receiving message with parameters from port

The elements of the two sets of labelled transition relations are defined based on the semantical rules and axioms for the statements in table 2. The set denotes the action transitions for a model, where is the set of distribution functions over ;

In configuration , relation holds if action can be performed, after which the model transits to configuration with probability , for each . In case several (different) actions can be performed, the choice of which action is executed is made non-deterministically. Then, a probabilistic choice determines the resulting configuration. In a simulation tool, such as Rotalumis, the non-deterministic choices may be resolved randomly, or by means of user interaction.

The set denotes the time transitions for a model. In configuration , relation holds if the time can pass for units of time, where . A model only has time transitions for the maximal amount of time that it is willing to wait before continuing with performing action transitions, where it is implicitly understood that it is also willing to wait for a shorter time. As a result, there is at most one and for each such that holds. Hence, time transitions are deterministic (taken with probability 1).

Transition system can be visualised as a graph. The nodes of this graph represent the configurations of . The initial configuration is identified with a symbol > directed towards the node. For any action transition relation with , a directed double (multi) arrow is drawn from node to all nodes to which the system can transit with positive probability . The first part of the double (multi) arrow is a directed arrow labelled with action and the second part is a fan-out of directed arrows labelled with the probabilities . For any time transition relation , a directed arrow is drawn from node to node , which is labelled with . Since time transitions denote the maximal amount of time that the model is willing to wait before continuing performing action transitions, is either a (positive) number or . The following example illustrates visualisation of the transition system corresponding to the behaviour specified by one process method.


Generating bursts of (fixed-size) packets can be specified with the process method GenerateTraffic in figure 2. In line 1, a local variable p of type Packet is declared. The actual behaviour specification of GenerateTraffic starts in line 2 with the creation of a new instance of data class Packet. After creating the new packet, its identifier is set to PacketNumber. In line 3, PacketNumber is incremented to ensure that the identifier of the generated packet is unique. The braces in lines 2 and 3 specify that the enclosed expressions are to be executed as one indivisible action. The send statement in line 4 specifies sending p through port Out. The duration of sending p, which equals the size PacketSize of a packet divided by the (fixed) rate Bandwidth with which packets are sent, is modelled with the delay statement in line 5. Line 6 models the probability of inserting a period without traffic after sending p. To this end, a sample is drawn from the Bernoulli distribution InsertIdleTime. If sending another packet must be postponed, the delay statement in line 7 is executed. The exact time to wait depends on a sample drawn from the discrete uniform distribution IdleTimeDistribution. Infinite repetition of sending a packet and inserting an idle period is modelled with tail-recursion in line 9.

  GenerateTraffic()() |p: Packet|
    {p := new(Packet) withNumber(PacketNumber);
    PacketNumber := PacketNumber + 1};
    delay(PacketSize / Bandwidth);
    if InsertIdleTime yieldsSucces then
        delay(IdleTimeDistribution sample)

Figure 2. Generating bursts of packets.

When abstracting from the actual values of p and PacketNumber, the timed probabilistic labelled transition system defined by method GenerateTraffic can be visualised as shown in figure 3. The initial configuration C1 reflects the behaviour specified by the expressions of lines 2 and 3. The internal action transition from C1 to C2 originates from creating a new packet and incrementing PacketNumber in lines 2 and 3 together (because of the braces) and is performed with probability 1. The send statement in line 4 specifies the send action transition from configuration C2 to C3. Remark that send action Out!Packet denotes a synchronisation with the environment. If the environment is not prepared to participate in performing a matching receive action, execution of Out!Packet is postponed until the environment is ready to receive the packet. Hence, the send statement also specifies the time transition from C2 to C2 labelled with , which denotes the willingness to wait for an arbitrary amount of time before performing send action Out!Packet.

Visualisation of a timed probabilistic labelled transition system

Figure 3. Visualisation of a timed probabilistic labelled transition system.

The time transition from configuration C3 to C4 originates from the delay statement in line 5 of figure 2. The label 7/2 is obtained by assuming that PacketSize equals 140 data units and the rate Bandwidth of sending packets is 40 data units per time unit. The if statement in line 6 results in an internal action with branches to configurations C5 and C6. Assuming that the Bernoulli distribution InsertIdleTime yields success with probability 1/8, the system transits to C5 if no idle period has to be inserted and to C6 otherwise. From configuration C5, the fix action transition to C1 reflects the tail-recursive call of method GenerateTraffic. On the other hand, the part of the transition system in figure 3 regarding configurations C6 to C18 is the result of the delay statement in line 7. This delay statement illustrates how probabilistic timing behaviour can be specified in POOSL. Its execution first involves evaluating the amount of time to wait. Suppose that IdleTimeDistribution is a discrete uniform distribution assuming the values 4, 5, 6, 7, 8 and 9. Then, the resulting fix action has branches to 6 different configurations, which are all entered with the same probability. From these configurations, the time can pass for an amount equal to the involved sample of IdleTimeDistribution and after that the system resides in the corresponding configuration C13 to C18. Finally, the fix actions from these configurations to C1 reflect the tail-recursive call of method GenerateTraffic.