Empirical Modelling Artefacts in Concurrent Systems Modelling
Lecture 6: Empirical Modelling Artefacts in Concurrent Systems Modelling
The term 'artefact' is used in EM to emphasise the idea that model making is first and foremost about creating something physical that can be experienced by the modeller. This experience can in principle come from any sensory source, but - because of the nature of the traditional computer interface - visualisation is usually the most significant ingredient. Harel, in his response to Brooks's No Silver Bullet, attaches much importance to the idea that visualisation is essential in aiding comprehension. His paper 'On Visual Formalisms' juxtaposes the concrete experience ("Visual") with abstract structure ("Formalism") in an unexpected way. It introduces the 'statechart' as a means to enable a modeller to appreciate complex structure more readily in a visual form. This lecture takes up Harel's general theme concerning visualisation and understanding of complex systems, but develops a different stance, in which 'modelling with statecharts' is one aspect of a broader concern for developing construals. This lecture is a slightly modified version of a lecture entitled "Visualisation and Concurrent Systems Modelling" from the MSc module "EM for Concurrent Systems". It relates to EM as it operates in the near vicinity of a system, where terms such as 'definitive programming' as opposed to 'modelling with definitive scripts' are not entirely out of place - though of course a 'program' is to be interpreted as a variety of construal in this context (cf. the status of the EM JUGS model as a "program").
1. Visualisation in Concurrent Systems Modelling
What has visualisation to do with concurrent systems modelling? We argue that to understand a complex system, we have to analyse the system into agents and model the interfaces between these agents in terms of observations. Visualisation is the means by which activity at the agent interfaces is "made visible" to the designer. This is the approach that an engineer takes when building a complex device.
To pursue the analogy with conventional engineering, the engineer generally deals with components that interact in ways that are not directly visible. For instance, an electrical current cannot be directly experienced by the engineer (at any rate in a safe and useful fashion!). When constructing or diagnosing the faults in a complex system, the engineer attaches equipment to the system to make the interactions between components visible. It is very important that these measurements should reflect the activities they are recording as accurately as possible. In particular, changes in electrical activity at the interface should be registered as far as possible synchronously and accurately. By accuracy we are here referring to a precise correlation, such as a functional relationship, between stimulus and response.
We shall use definitive scripts as an interface mechanism in precisely this role [BY89]. The visualisation aspects of the computer model of a complex system are directly analogous to the engineer's measuring instruments. (The term "interface mechanism" is apt because it expresses the resemblance to a mechanical linkage that reliably and instantaneously transmits state change from one place to another.) The engineer's design tools include devices to provoke state-changes that are complementary to measuring instruments. The engineer probes the system by initiating changes and studying the response. These changes generally correspond to activities that are ultimately carried out by other agents within the system. In this lecture, we shall describe and illustrate the techniques that we use to build "measuring instruments" to aid the designer of concurrent systems.
The analogy between a visualisation and a measuring instrument extends to other concerns. It is useful to be able to separate the model of the system from the visualisation in the same way that we can attach instruments to a system as and when we need to inspect its behaviour more closely. It is also useful to be able to carry out the visualisation in parallel with normal operation of the system. Definitive scripts can achieve this objective because they only rely on knowing appropriate references that can be used in the RHS of formulae.
It is also of interest in this context to consider the relationship between what an engineer conceives by way of interaction between components (as e.g. in the propagation of signals, or the application of forces) and what an engineer can actually observe directly, through visual or audible output. The designer of a complex system has a conceptual view of interactions within the system that involves notions that may have no direct visual significance. Developing visualisations for such concepts (or indeed developing any other form of output that can be experienced directly, e.g. as in sonification) is a process that has no clearly prescribed limits. Each definitive notation for graphics addresses some part of this task of "converting abstract concepts into something that can be represented visually". The relationship between what the designer in mind and what is observed on the screen differs from notation to notation. This is why we have already developed several different notations for interactive graphics.
The use of definitive notations for visualisation is primarily associated with a particular kind of programming activity: viz. single agent definitive programming in which the sole state changing agent is the system designer. Visualisation can be intended to help the designer grasp what is in fact invisible, or to model what a user does in practice see of the system. For instance, in the VCCS, the speedometer, the cruise controller interface and the brake and pedal represent the interface to the driver of the vehicle, whilst the animation of the forces acting on the vehicle, the diagrammatic position of the vehicle, the clock and the throttle are there to assist the designer in understanding how the controller performs.
In studying the use of definitive scripts for visualisation, we are concerned with the designer's perspective on the views of many different agents. This is an exercise in knowledge representation, in expressing what agents can respond to and what they can change. In the VCCS:
- the definitive programmer can make free with the script,
- the designer can modify it in any way that is plausibly consistent with the real-world semantics,
- the mouse user can interact through using the buttons that delimit the driver's view.
2. Some Illustrative Examples
2.1. The role of the SCOUT notation
For our purposes, the interaction between computer and the designer and the computer is via the screen, the keyboard and the mouse. In visualisation, we are concerned with output from the computer via state-changes to the screen. We have argued that different symbolic representations are required to communicate conceptually different kinds of observation that might be made of system state. The EM tools provide three basic ways to describe patterns on the screen: window layout, textual display and 2d-line-drawing. Some simple examples serve to illustrate the basic principles at work in using definitive scripts for visualisation; they also highlight the scope for generalisation and the significant difference in orientation between the experiential and formal perspectives.
The lines demonstration
This example illustrates the general principle of combining conceptually different types of visualisation. In the demonstration, there are two DoNaLD and two ARCA windows, combined within the SCOUT environment. Lines in ARCA and DoNaLD have a very different significance, ARCA diagrams being abstract combinatorial graphs in which the node references are identified by indices. This means that we can express what it means to trace a particular path of coloured directed edges in an ARCA diagram, as we might do, for instance, in studying transitions in a finite state machine.
The lines demonstration also illustrates the sublety of the visualisation process associated with the use of a definitive notation. The diagram that appears in the screen is an approximate representation of a family of lines that the script describes in an idealised manner. This underlines the unusual character of geometric variables in the definitive script: they represent Platonic points and lines, whereas the visualisation is only as accurate as the computer arithmetic allows. These and related issues are also relevant in connection with 'analogue variables' in the VCCS, as will be later discussed in connection with the ADM.
Putting rooms into windows
One function of Scout is to provide complementary information about where and how to display (say) a DoNaLD picture. This is illustrated in the roomviewer.s demo, in which the DoNaLD room is displayed in two windows using different display conventions. The essential principle is that of independently specifying the location and shape of the graphics window and the portion of a DoNaLD picture to be displayed within it. This independence can be used to adapt a window to the size of its contents (as in the roomviewer.s menu buttons) or to ensure that a picture always stays within a fixed frame (as in the DoNaLD poset) in lines.sdae.
Scout also makes it possible to relate textual annotations to picture content and other aspects of system state. This illustrates the manner in which dependencies reflect an agent's interpretation of state. Consider, for instance, monitoring the length of the cable and whether the table obstructs the door as in roomviewer.s, and displaying combinatorial invariants of the configurations of lines as in lines.sdae. The rubrics on the menu options in roomviewer.s are also dynamically determined in this way.
Experiments involving the extension and elaboration of scripts play a major role in the development of scripts such as roomviewer.s and lines.sdae. The designer performs these experiments through redefinition of variables in a manner that is quite unconstrained. The roomviewer.s demo demonstrates how we can also complement Scout by introducing mouse-sensitive regions to the display and using these to animate a restricted repertoire of redefinitions. As in the VCCS demo, these allow the designer to mimic the roles that will be played by agents with more restricted privileges to change the system state. In moving beyond visualisation of agent roles to animation of the system, the emphasis shifts from identifying privileges to enabling conditions for exercising them. We might impose constraints, for instance, so that redefinitions that violate some postcondition (e.g. cable is overextended in roomviewer.s) are not admitted.
3. Statecharts as a Visual Representation of Active Agency
A particularly subtle mode of state representation of interest in this context is Harel's statechart concept. The next section shows how the characteristics of statecharts can be seen to be related to the presence of LSD agents, and the roles that they play.
3.1. Case Study: The Digital Watch
Harel's statechart model for the digital watch
The statechart for the digital watch can be explained informally as follows.
statechart = state diagrams + depth + orthogonality
+ broadcast communication
For explanation of statecharts, see Harel: On Visual Formalisms p521-526.
In the digital watch statechart, have 3 of the 4 characteristic features
state diagrams:
illustrated in update etc
depth:
being in the state of displays meansbeing in update, or in date, or in stopwatch, or in alarm etc
Will say that being in displays encompasses being in update etc
orthogonality:
light, alarm-st and chime-st are orthogonal componentsbeing in alive state is equivalent to
being in power, and in main, and in displays,
and in light, and in alarm-st and in chime-st
[no use is made of broadcast communication.]
Other feature represented in the diagram is the default arrow, which identifies the default state entered when entering an encompassing state. For example, when watch is first alive:
power is OK, display shows time, light is off, and alarm & chime are disabled.
3.2. An LSD specification for the digital watch
An LSD specification for the digital watch can be developed by pursuing the general philosophy that the pattern of state transitions depicted in the statechart corresponds to the pattern of temporal coincidence between agents. This leads us to introduce agents to correspond to most of the states in the statechart and to model the rest as states within these agents. For instance, the LSD has watch(), displays() and alarm_st() agents, and there is a state variable alarm_st_s within the alarm_st() agent with values D(=1) and E(=2) according to whether the alarm is disabled or enabled. The two characteristics discussed by Harel, associated with depth and orthogonality, can then be interpreted as corresponding to two methods of describing an agent in terms of simpler agents.
The first way, corresponding to "depth", is associated with defining an agent in terms of the roles it can play: as in
a() = case a_s of {
1: a1();2: a2();
....
}
Here we think of one agent a() as acting through playing one of several roles a1(), a2(), ... . At any time a() is in at most one role, so that its state can be seen in Harel's terms as being "playing a1() XOR playing a2() XOR ....".
The second way, corresponding to orthogonality, is associated with defining an agent as a parallel composition of several agents: as in
a() = b() || c() || d() .....In this case, the agents a(), b(), c() and d() all have exactly the same period of existence. In Harel's terms, the current state of agent a() is defined as being the current state of b() AND the current state of c() AND the current state of d() ... .
As an example of the role construct, we can consider the displays() agent, which either plays the role of the display_current_time() agent or the display_current_chime_time() agent or the display_current_date() agent or the display_current_stopwatch_time() agent etc.
As an example of the parallel construct, we can consider the watch() agent itself, which is defined by the parallel composition of several agents:
main() || light() || alarm_st() || chime_st().
[The omission of the power() agent is deliberate, as explained below.]
In summary, what we have done is to interpret the statechart as a specification of the conditions for liveness of LSD agents. Where there is depth, we think of an agent playing more and more specific roles. Where there is orthogonality, we think of agents operating in parallel.
There are constraints on the agents that can be defined using the two constructs we have introduced. If a() is the parallel composition of b(), c(), d(), ... then the agents b(), c(0 and d() must have the same lifetime as a() itself. And if a1() is one of the roles played by a(), then lifetime a1() must be nested within the lifetime of a().
On the other hand, there are situations in which an agent spawns another agent that has an independent existence, and can have a different period of existence from its creator. The beep() agent associated with the statechart is best conceived as having a lifetime briefer than the watch. When the circumstances that lead to beeping arise, the main() agent, responsible for display functions, runs a beeping process in parallel, until such time as the beeper is disabled.
There are other examples of hidden agents. The function of the agents within displays() is to ensure that various information relating to time, and times associated with the functions of the watch such as the the alarm, are displayed. What is on the display is a function of the actual time, the internal state of the digital watch and the current status of displays() (determined by which of its roles it is currently playing). The agents that maintain the values to be displayed are not all represented in the statechart. To model the passage of time, we must introduce a clock() agent. There must also be a stopwatch component to the watch, complementary to the stopwatch display role, that takes the form of an independent resettable clock running in parallel with the main watch. The current time set for the alarm can conveniently be incorporated into the state of the alarm_st() agent, which is already independent of the alarm time display role in the statechart.
As another refinement, it seems appropriate to separate the power() agent from the watch() itself. Effectively, power is the agent that provides the energy to keep the watch alive, and with an appropriate function of time to represent the battery charge, the watch automatically ceases to function after a certain time has elapsed. The top-level specification then has form:
agent power() {
derivate power_s = battery_charge(time) // three-valued 3,2,1}
agent watch() {
derivate LIVE = (power_s >= 1)}oracle power_s
agent main() { // as specified below
.....
agent alarm_st() {
derivate LIVE=LIVEmain} // !d here means that button d has been pressedoracle LIVEmain, displays_s, alarm_s
state alarm_s = D, set_time = 00.00
handle alarm_s // 1:Disab, 2:Enab
protocol displays_s == A & alarm_st == D & !d -> alarm_st = E
displays_s == A & alarm_st == E & !d -> alarm_st = D
agent chime_st() { // and several other agents, such as light() etc
}
agent clock() {
}
agent stopwatch() {
}
agent main() {
derivate LIVE=LIVEwatchoracle LIVEwatch, main_s, alarm_s
state main_s = D // an integer - 1:Displays, 2:Beep || displays
handle main_s
protocol
(main_s==D) & (time==set_time) & alarm_s==E -> main_s=B
agent displays() {
derivate LIVE=LIVEmain}oracle LIVEmain
state displays_s = T // 1:Time, 2:Update, 3:Date, etc
handle displays_s, update_s, upalarm_s
protocol displays_s==T & !c -> update_s=1,
displays_s==T & !d -> displays_s=D,
displays_s==A & !c -> upalarm_s=1,
.....
displays_s!=S & displays_s!=T & 2-min -> displays_s=T
agent disp_date() {
derivate LIVE = LIVEdisplays& displays_s==D,}"watch_display = date as of clock()"
oracle LIVEdisplays, displays_s
agent disp_time() { ......
}
agent disp_upalarm() {
derivate LIVE = LIVEdisplays & upalarm_s>0,}displays_s = (upalarm_s==0%4)?A:UA
"watch_display = time as of alarm setting with right digit highlighted"
oracle LIVEdisplays, upalarm_s
state upalarm_s = M
// 1:Min, 2:TenMin, 3:Hr, 4=0(mod 4): Alarm
handle upalarm_s, set_time
protocol !b or 2-min -> upalarm_s=A,
!c -> upalarm++,
"event -> update set_time so as to increment highlighted digit in set_time"
..................agent beep() {
derivate LIVE=LIVEmain & main_s==Bstate main_s
protocol beep_stop -> main_s
}
} // end main()
References
[BY89] Definitive Interfaces as a Visualisation Mechanism
[BNRSYY89] Software Construction using Definitions CS RR#147
[Harel] David Harel On Visual Formalisms CACM 1988, 31(5), p514-530
[B&C] Beynon and Richard Cartwright, Empirical Modelling for Cognitive Artefacts IEE Colloquium Dec 1995