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. The analysis and representation of agent perceptions and privileges is a first step towards modelling and animating a concurrent system.
The detailed design of Scout will be considered at a later stage. The examples which follow are designed to give some idea of the way in which Scout allows the designer to describe the whole screen layout by devising windows in which to display graphical ouput in DoNaLD and attaching textual annotations.
T4.2.2. 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 will be considered in greater depth in connection with analogue variables in the VCCS [Th2].
T4.2.3. 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.
T4.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.
T4.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
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.
T4.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()
4.3.3. Illustrating the Empirical Modelling Laboratory
The following notes, originally prepared in 1992, prior to subsequent development of the digital watch model by Richard Cartwright, contain some informal documentation of an early version devised by Beynon. They are included to illustrate the experimental character of the specification process, and the general untidiness in the overall script that distinguishes it from a good conventional program specification. The virtue of this is that it is true to James's characterisation of the world of pure experience (Quote C2); it admits all sorts of possible consciousnesses to be brought to bear on it, and is for this reason a most valuable resource for imaginative thinking about issues relating to digital watch modelling, simulation and design. The attached suggestions for further work, though possibly now somewhat out of date, are presented as a way of stimulating awareness of this aspect of Empirical Modelling activity.
A rough implementation of the digital watch and statechart animation is specified by the three files: digwatch.s, digwatch.e and watchmech.e. These three files address different aspects of the model:
The present implementation is currently in a reasonably advanced state of development, but shows signs of unstructured incremental design. There are comments in the program in places, but these can be quite misleading. For instance, the purpose of the function id_ix is to associate a unique integer index with each named state in the statechart. The EDEN function on p3 of digwatch.e (lines 156-163) achieves this by finding the index of an identifier in the symboltable, but is much slower in execution than the alternative function defined at l165. Some of the EDEN code is esoteric, and addresses somewhat tangential issues, such as generation of the SCOUT/DoNaLD script for the visualisation of the statechart; the brief commentary below is intended to help you to focus on the parts of the model that are of most interest. (Note that in its current state of development, the software is somewhere between a model and a program. It is in effect a script, together with a set of agents whose protocols for action have been partly animated via EDEN actions.)
The code is presented as a useful basis for further experiments that might address several different issues, both in respect of written and practical work. For instance:
How easily can you reverse engineer the model? For instance, can you supply LSD specifications for the missing components, like the stopwatch? Can you figure out the (crucial) role played by the filter action (digwatch.e p10) - is this role represented in the LSD specification outlined above? and, if not, how would you represent it?
Can you re-organise, document and simplify the program? For instance, can you produce a version of the digital watch simulation as well-organised and documented as that developed by Ian Bridge for the VCCS?
There is an action called markchart on p6 of digwatch.e. Is it possible to replace this by a piece of definitive script?
I have claimed that you can gain insight into definitive scripts by interacting with it in an experimental mode e.g. extracting pieces of the script and exercising them in isolation. Can you substantiate this claim?
The model is incomplete (like the statechart) in that the update functions (associated with the update and upalarm states in the statechart) are not specified. Can you add these to the model? What impact would it have on the LSD specification, and the EDEN code? How would it affect the statechart if these functions were introduced?
There are EDEN procedures set_time() and inc_time() to simulate the effect of running and setting the watch. The digital watch doesn't run in real-time in its present form, but could you link it to the computer system time so that (say) it runs at speed 5 times slower than real-time?
To what extent can you demonstrate the scope for specifying alternative models by slotting in different pieces of script into the existing model? For instance, can you model a watch with an analogue display?
There is a commercial package for manipulation of statecharts that I believe allows them to be constructed by direct manipulation - i.e. by drawing the statechart on the display. How easy would it be to simulate this type of activity on top of the present model?
Can you suggest ways in which EDEN could be enhanced to simplify the
specification task? In what respects could the development environment
for LSD to SCOUT-DoNaLD-EDEN be improved?
[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