Event

Defined in this section are the domains and functions related to the messages passed to and fro the processes. The messages are called henceforth events.

Domains

The Event Queue which is a part of all processes state is realised by a list of Event Queue Elements. The elements consists of pairs of Event, Originator Ids.

The events have three parts:

the type

identifies what class of event it is and what type of process it comes from;

the name

identifies exactly what event it is;

data

which dynamic is data supplied with the event and may contain anything.

The Event Template is just an event without the data part.

EventQueue ≡ List(EventQueueElement) EventQueueElement ≡ Event × OriginatorId

Event ≡ EventType × EventName × Data

EventTemplate ≡ EventType × EventName

The type of the event consists of the Originator and the Type Name. The Origi-nator is the type of process that has sent the event and the Type Name is one of three:

notification

which is an event notifying that something has occurred, to this event no reply is required;

request

which is an event that request that the receiving process take some action, and responds with a response event;

3.3 Shared Definitions 37

response

which is an event responding to a request event.

EventType ≡ Originator × EventTypeName Originator ≡ {phone, bcsm, si, ssf, scf, sdf, srf}

EventTypeName ≡ {notification, request, response}

The Event Name is defined by the different process types.

EventName ≡ ssf: SSFEventName ∪ bcsm: BCSMEventName ∪ scf: SCFEventName ∪ si: SIEventName∪

sdf: SDFEventName ∪ srf: SRFEventName The Originator Id is the identity of a sending process.

OriginatorId ≡ Id(phone) ∪ Id(bcsm) ∪ Id(si) ∪ {ssf, scf, sdf, srf}

Functions

The functions type, name, data and sender all selects that part of an Event Queue Element.

type: EventQueueElement → EventT ype type(hhtype, , i, i) ^def= type name: EventQueueElement → EventN ame name(hh , name, i, i) ^def= name data: EventQueueElement → Data data(hh , , datai, i) ^def= data

sender: EventQueueElement → OriginatorId sender(hh , , i, originatori) ^def= originator

The template function constructs an Event Template out of an Event Queue Ele-ment by removing the sender information and data.

template: EventQueueElement → EventT emplate template(elt) ^def= htype(elt), name(elt)i

The notification, request and response functions tests whether an Event Queue Element is a notification, request or response respectively. Further they check

that the type of process sending the event was orig and that the Event Name was name.

The event test function is a utility function used by the notification, request and response functions. The function tests whether the Event Template supplied is the same as that of the Event Queue Element.

∗: Originator × EventN ame × EventQueueElement_⊥→B

notification(orig, name, elt) ^def= event test(hhorig, notificationi, namei, elt) request(orig, name, elt) ^def= event test(hhorig, requesti, namei, elt) response(orig, name, elt) ^def= event test(hhorig, responsei, namei, elt) event test: EventT emplate × EventQueueElement_⊥→B

event test(template, elt) ^def=







false if elt = ⊥

true if template(elt) = template false otherwise

Chapter 4

Tool

We implemented a simulator and service creation tool in Erlang using the library connection to Tk handle the graphics.

The service creation tool is so far only a prototype in which one can graphically design the services as was described in the design example in section Section1.5.1, with the exception that connections for the dynamic has to be given textually.

4.1 SIMULATOR

We started writing the simulator when we had already decided on formalism and had made the first draft of the model. Initially we simply implemented the func-tional entities in Erlang, making a prototype to see whether Erlang suitable as language.

The choice of language was suitable, however direct implementation made changes difficult when the model evolved. To make the handling of changes in the model easier we decided to state the model as an Erlang term and interpret the term. We then realised that to get a truly flexible system we would break down the abstract data types and other structures, such as conditionals, that are used to construct the model into modules.

Luckily the Erlang runtime system has a good support for modules, with the application functions that accept both the module and function as argument.

We now had a system composed of the core engine performing a very simple top-loop, as shown simplified in Figure 4.1, calling on the module of the functional entity it is simulating to get the actual details.

schedule := process type:schedule() rules := process type:rules()

loop(schedule, rules, state)

rule := schedule(schedule, rules, state);

state := evaluate(rule, state);

end loop

Figure 4.1: The engine core of the simulator

The terms describing the functional entities are built up using constructors de-fined in the different modules. Say for example that we want to build a list composed of the one element, which is the head of the variable format. Then we would write: list:mklist([list:head(env:var(format))]) where the nota-tion list:mklist signifies that mklist is a funcnota-tions in module list.

The constructed term contains the information that is a list constructed out of the subterm which is a function call, but also contain information as to what module constructed the term. When the term is interpreted the responsibility of this term falls on the module that constructed the term.

In this way we have gained great flexibility, since in most cases when we intro-duce a new construct of abstract data type we do not have to change any of the existing ones. Should we on the other hand find that an existing module should be incorrect or inadequate we can just change or augment it without changes the other modules.

When adding an analysis tool one could in the same manner break down the problem, for example for calculating the weakest precondition.