IEEE Computer, October 1989.

GRAPHICAL CONFIGURATION PROGRAMMING

"the structural description, construction and evolution of

software systems using graphics"

J. KRAMER, J. MAGEE, K.NG

Department of Computing, Imperial College of Science and Technology, 180 Queen's Gate, London SW7 2BZ,

Great Britain.

ABSTRACT

In systems engineering, considerable advantages accrue by constructing and managing thesystem in terms of its software configuration; that is the set of constituent software componentstogether with their control and communication interconnections. A specification of the systemconfiguration can be used both to describe the required system structure and for actual systemconstruction. Management of the operational system is achieved by monitoring the status ofcomponents and making extensions or changes to that system configuration by the addition ofsoftware components or the replacement of existing ones. The performance of these programmingtasks at the configuration level is termed configuration programming .

Configuration descriptions and changes are most easily described and viewed graphically,but have traditionally been provided to the system in textual form. This paper describes a graphicalworkstation which integrates the textual and graphical information required for configurationprogramming. It provides editing facilities for drawing and describing system configurations;monitoring facilities for viewing the current system configuration, component status andinterconnections; layout facilities for automatically generating the graphic representations from textand improving the configuration information layout, and control facilities to permit system changesto be initiated by graphical changes to the system configuration. In contrast to many systemconstruction tools, changes are applied dynamically to operational systems. The paper discusses theissues raised by graphical configuration programming, describes the workstation in more detail andpresents examples and experience using the approach in Conic, an environment for programmingand managing distributed and concurrent systems.

Keywords: system configuration, programming environment, system evolution, visualprogramming, distributed system, graphics, dynamic configuration.

1

1. INTRODUCTION

What is Configuration Programming?

Software systems can be succinctly described, constructed and managed in terms of theirsoftware configuration [1,2,3,4]. This configuration consists of the set of software componentswhich implement the functionality of the system together with their control and communicationinterconnections. Program modules are defined and constructed so as to provide well definedinterfaces, giving the information and calls provided to or required from other modules. Theprogram is then configured by creating and interconnecting instances of these software modules.The specification of the system configuration provides a conveniently abstract form in which todefine and comprehend programs, and can also be used to generate the actual executable program.Evolutionary changes to the program are reflected as changes to the program structure, either by theaddition of further modules, and/or the use of modified versions of selected modules."Configuration programming" , the term we use to describe programming at the configuration level,thus provides a clear and flexible means for program definition, construction, modification andcomprehension. Configuration programming is closely related to the ideas of programming-in-the-large and the use of a module interconnection language outlined in [1]. Configuration refers here tothe structure of a system and not to version control.

Configuration programming is particularly appropriate for distributed processing where thesoftware components may additionally reside on different machines. The specification of the systemconfiguration can be used both to describe the required system structure and to specify theallocation of components to machines. Management of the operational system is achieved bymonitoring the status of the system's components and making extensions or changes to that systemconfiguration. These changes may require modification of a function already provided by thesystem, or extension by the introduction of new functions. It may involve a change inimplementation due to a technology change, improved implementation techniques or to provideredundancy in the system. It is certainly advantageous if configuration management is capable ofsupporting such change to the operational system dynamically, without interrupting the processingof those parts of the system which are not directly affected.

The Conic environment [5], developed by the Distributed Systems Group at ImperialCollege, provides support for configuration programming for distributed and concurrent programs.The environment provides support for two languages, one for programming individual taskmodules (processes) with well defined interfaces, and one for the configuration of programs fromgroups of task modules. In addition the environment provides support for the reuse of modules indifferent contexts and support for dynamic configuration. This latter facility is achieved using on-line management tools which permit dynamic creation, control and modification of applicationprograms. The basic Conic environment has been in use for over 5 years, with dynamicconfiguration as a more recent facility. It has amply demonstrated the utility of configuration levelprogramming.

Although the configuration descriptions are most easily described and viewed graphically

2

[3,4] they have traditionally been provided to the support environment in textual form. This textualform has advantages in conciseness and ease of parsing. The developers and users of Conic havealways drawn diagrams to describe and document their configurations, but interaction withcompilers, builders and managers has always been in textual form. Together with the availability ofgraphics based workstations, this prompted the development of graphical support for configurationprogramming. This graphical support is essentially a visual programming language forconfiguration. However, in contrast to the majority of work on visual programming [6] ourapproach emphasises system structure in-the-large rather than detailed data and control structure.The combination of graphics and text is proving to be a powerful facility. In particular, the graphicscomplements the text by reflection of the described or existing configuration, thereby aidingcomprehension and validation. The text is still essential for the detailed information, and for certaincomplex cases which are not amenable to display.

Overview of the Paper

The Conic environment is first described to provide an introduction to the use ofconfiguration programming and management. The paper then describes the graphical supportsystem which integrates the textual and graphical information required for configurationdescription, system monitoring and change management. It provides editing facilities for drawingand describing system configurations; monitoring facilities for viewing the current systemconfiguration, component status and interconnections; layout facilities for automatically generatingthe graphic representations from text and improving the configuration information layout, andcontrol facilities to permit system changes to be initiated by graphical changes to the operationalsystem configuration. A step-by-step example of the use of the graphical interface is then presented.Finally the paper discusses the issues raised by graphical configuration programming, theexperience gained using the approach in the Conic environment, and the directions for furtherwork.

2. CONFIGURATION PROGRAMMING IN CONIC

This section describes the configuration programming concepts embodied in the Conicdistributed programming environment. These concepts are illustrated by using a simple example: apatient monitoring system [7]. The intensive care ward in a hospital consists of a number of beds.Patients in each bed are continuously monitored for a number of factors, such as pulse, temperatureand blood pressure. For each patient the current readings can be displayed both at the bedside and atthe nurse unit. If any of the factor readings of a patient are outside of some preset limits, then analarm is sent to the central nurse station.

Module Types.

The system is constructed from the two module types defined both graphically and textuallybelow in Figures 2.1 and 2.2.

3

bed

alarmpatient

group module patient; use monmsg: bedtype, alarmstype; exitport alarm:alarmstype; entryport bed:signaltype reply bedtype; { - The module periodically reads sensors attached to a patient. Readings outside preset ranges cause alarm messages to be sent to the exitport alarm. A request message received on the entryport bed returns the current readings and ranges. }

end .

Figure 2.1 - The Patient Module

The interface to a module is defined by typed exit- and entryports. Messages are sent out of amodule via exitports and received into modules from entryports. Messages can be of any Pascaldatatype. The type definitions are imported from definition units by the use clause (types bedtype,alarmstype from monmsg in Figures 2.1 and 2.2).

bed5

bed4

bed3

bed2

bed1

alarm5

alarm4

alarm3

alarm2

alarm1

nurse

group module nurse (maxbed:integer=5); use monmsg: bedtype, alarmstype; entryport alarm[1..maxbed]:alarmstype; exitport bed[1..maxbed]:signaltype reply bedtype; { - the module displays alarms received from alarm[] and can request the display for a particular patient from its exitports bed[]. }

end . Figure 2.2 - The Nurse Module

System Configuration.

Given the hardware depicted in Figure 2.3, we can construct an initial patient monitoring

4

system consisting of one nurse unit and one patient unit by instantiating one instance of each of theabove module types and interconnecting their exit- and entryports. The links between exitports andentryports allow modules to communicate by message passing. The Conic environment permitsonly ports of the same type to be connected. The configuration program for this initial system isagain shown both textually and graphically in Figure 2.4.

Sun1

Targ1 Targ2

Ethernet

Figure 2.3 - Hardware Environment

The system is actually created by submitting the configuration description to a configurationmanager tool which downloads module code into target processors or instantiates processes underUnix as appropriate. The configuration management tool and its supporting environment isdescribed in [5]. The configuration description may be submitted directly as text to theconfiguration management tool or indirectly using the graphical editor described in more detail inthe next section. As can be seen from Figure 2.4, the graphical description contains lessinformation than the textual one. Additional information is elicited by the graphics tool through theuse of dialogue boxes. This extra information consists of physical module location (the at clause)and module parameters. For example the nurse module has a default parameter setting to the value 5(Figure 2.2). However this could have been changed when the module instance was specified, i.e.

create nurse:nurse(3) at sun1.

5

bed5

bed4

bed3

bed2bed1

alarm5

alarm4

alarm3

alarm2

alarm1

bed

alarm

nurse

bed1

system ward; create

bed1:patient at targ1; nurse: nurse at sun1;

link bed1.alarm to nurse.alarm[1]; nurse.bed[1] to bed1.bed;

end .

Figure 2.4 - Initial Patient Monitoring System

Dynamic Configuration.

In addition to programming initial configurations, the Conic toolkit permits dynamicconfiguration: changes to running systems. For example, extending the above system to include anadditional patient unit can be performed by submitting the following configuration program to aconfiguration manager :

manage ward; create

bed2:patient at targ2; link

bed2.alarm to nurse.alarm[2]; nurse.bed[2] to bed2.bed;

end

System ward (figure 2.4) is dynamically evolved to the system depicted grapically in Figure 2.5:

bed5

bed4

bed3

bed2

bed1

alarm5

alarm4

alarm3

alarm2

alarm1

bed

alarm

bed

alarm

nurse

bed2

bed1

Figure 2.5 - Extended Patient Monitoring System

6

In practice, we have found it convenient to create initial systems from the more conciseconfiguration program. Once created, the graphics tool can be used to display the system as itexists. It gathers information directly from the executing system by communicating with aconfiguration manager. The graphics tool can be used to query textual information which is notdirectly displayed. Modification to the system can be performed either through graphicalcommands or from configuration program text. A change which has been performed graphicallycan be saved in its text form for later re-use. The configuration management system is itself adistributed system which means that more than one agent may cause the system configuration tochange. The graphics tool can be used in a monitoring mode to allow users an up-to-date view ofthe system configuration. In the above, the diagram of Figure 2.4 was created by using the graphicstool to monitor a system created from the configuration program of Figure 2.4. The system wasextended by editing the diagram directly to create Figure 2.5. These edits caused the tool to send theextension configuration text to a configuration manager to change the actual system accordingly.

Module Hierarchies

In the above, we have described the top-level configuration of modules to construct a patientmonitoring system. In fact, each of the two module types used are themselves configurations ofmodules. For example, the internal structure of the patient module is depicted in Figure 2.6.

alarm

bedmonitorscanner

patient

group module patient; use monmsg: bedtype, alarmstype; {import message types} exitport alarm:alarmstype; entryport bed:signaltype reply bedtype; use scanner; monitor; {import module types} create

scanner(100); {scan every 100ms} monitor;

link scanner.readings to monitor.readings; monitor.alarm to alarm; bed to monitor.data;

end .

Figure 2.6- Internal structure of Patient Module

The module types used to construct patient may themselves have an internal structure. Asystem in Conic is thus an hierarchic structure of modules. The modules at the bottom of thehierarchy are task modules which are implemented in a version of Pascal to which messagepassing constructs have been added. These task modules execute concurrently and arehierarchically structured using the configuration programming language into logical nodes.Logical nodes are simply group modules which include a run-time executive. Logical nodes are

7

the unit of both distribution and dynamic configuration. Currently, the structure of modules within alogical node is determined at compile time and does not change at system runtime. Consequently, itis not necessary for the graphics tool to have the ability to edit internal node structure. However, toaid system comprehension we intend to provide the facility to "explode" logical nodes to allowexamination of their internal structure. This together with the ability to examine the program text ofa module (whether a configuration program or a task program) will provide a powerful systembrowsing facility.

This section has very briefly outlined how configuration programming is provided in theConic system and given an overview of how graphics are used in this environment. The nextsection examines in more detail the facilities provided by the graphics tool and its interaction withthe distributed system environment.

3. CONICDRAW: THE GRAPHICAL WORKSTATION

As outlined in the preceding section, Conic provides facilities for configuration programmingand management. Although diagrams were always used in conjunction with the textual descriptionsand commands, their use was originally informal and the diagrams were generated manually.Integrated support facilities for both text and diagrams are obvious aids to comprehension,validation (by reflection of the specified configuration) and documentation. In addition, graphicsfacilities offered the opportunity to investigate the use of graphical configuration programming andmanagement by interacting with the running system. In this section we describe the facilitiescurrently provided by ConicDraw, the graphical workstation.

Changes

Status

Actual System

Graphic Interface(ConicDraw)

Management System

iman

gman

Text Interface

VT100

This is some text for

the VT100 Screen

This is some text for

the VT100 Screen dgdbc c

Figure 3.1 - Relationship Between ConicDraw and System . As depicted in Figure 3.1, the management system provides both an interactive textual and

graphic interface to the operational system. ConicDraw maintains a graphic representation ofexecuting Conic systems in terms of the module instances which exist in the system, theirinterconnections and their execution state. Changes to the system are reported to ConicDraw by

8

configuration management to enable it to maintain an up-to-date view of the system. ConicDraw canitself instigate changes to the system as a result of edits to the graphic representation. Since italways maintains a representation of the actual system, one or more workstations can be connectedto the distributed system to allow a number of users to co-operatively manage and monitor thesystem. ConicDraw contains a comprehensive set of tools for creating and editing Conicconfiguration diagrams. As such, it can also be used as a standalone diagram editor.

We have chosen an Apple Macintosh as the implementation vehicle because of itscomprehensive support for programming graphic interfaces and because of experience in its usebuilt up in a previous project. Currently, the Macintosh communicates via a serial RS232communication link with the distributed system (running on Sun Workstation, VAX and VME68000 machines connected by Ethernet). This serial link currently limits response times and may bereplaced by a direct Macintosh to Ethernet connection.

In the following sections, we describe the main facilities provided in ConicDraw and discuss the issues raised by its implementation.

System Monitoring In ConicDraw

To support the online monitoring of systems, ConicDraw needs to have access to theexecuting distributed system. This is achieved by running a special version of a configurationmanager (gman) in conjunction with ConicDraw (Fig 3.1). Gman is a Conic program running ona host machine and communicates with ConicDraw on the Macintosh via a serial link. In the sameway that an interactive manager (iman) is used to support the textual interface, gman acts as aserver to ConicDraw and can provide information on all Conic systems running on Unix machinesas well as standalone targets. Using a simple communication protocol, gman supplies ConicDraw,upon request from the latter, the names of currently active systems and the nodes, ports andinterconnections within each system. In addition, it can also provide detailed information of eachnode, such as the type of the node, which machine it is running on, how long it has been running,and so on.

At the beginning of a session, the user will typically want to find out what systems arerunning in the network. This is done by selecting Get systems from the Command menu, whichputs up a set of icons in the Systems window, as shown in Fig. 3.2. Each icon in this windowrepresents one Conic system, and acts as the interface through which the system can be accessed.To view a system, the user need only double-click on the appropriate system icon. This opens upthe system to reveal its internal nodes and their interconnections. The pictorial representation of thesystem is displayed in a graphical window (Fig. 3.3).

9

Figure 3.2 - Icons in the Systems Window

ConicDraw allows multiple systems to be opened at the same time. The number is limitedonly by the computer's memory. By default, an opened system will be continuously polled byConicDraw for changes to either its structure or its state. When a change is detected in a system, itsdiagram will be updated appropriately to ensure that the graphical information presented to the useris kept consistent with the true state of the system.

Figure 3.3 - An Example of a Graphical Window

When there is more than one system opened, the user has the choice of monitoring all ofthem or just the one that is front-most on the screen. Monitoring can also be turned off completely,in which case none of the system diagrams will be updated. In addition, depending on how rapidlya system is expected to change, the user can also modify the frequency of polling. All thesemonitoring options are set via a dialog box (Fig. 3.4).

10

Figure 3.4 - Options For System Monitoring

There are several ways in which nodes in a diagram can be displayed. The default is to viewnodes by their names, that is only the instance name is displayed within its box. Other options areviewing by type, location or full information, in which case the information displayedincludes the name, type, location and state of the node, as well as its environment (whether it isrunning on a unix machine or a stand-alone target). It is also possible to find out how long a nodehas been running, by choosing the ‘Get info’ menu command. This will open a dialogue box whichdisplays the full information of the node, plus its uptime (Fig. 3.5).

Figure 3.5 - Detailed information of a node instance

Because no layout information is contained in messages received from gman, it is theresponsibility of ConicDraw to decide on the placements of system components within a diagram.At present we adopt a simple layout strategy rather than a complex algorithm to minimise the delaybetween the request for the system from the user and the display of its diagram on screen.Additionally, it is important to reflect changes to the system as they are happening. Initially, nodesare placed into arrays of grid cells and the ports are ‘scattered’ randomly along the 4 faces of theirparent nodes. Links are then drawn as single-segment straight lines connecting the appropriatemessage ports. As one would expect, the resultant diagram produced using this scheme is almostinvariably messy and often unreadable. We have thus introduced a tidy-up facility based on somesimple heuristics which is invoked at the end of each system request (and change) to clean up adiagram. This is described in more detail later in the paper.

11

Dynamic Configuration In ConicDraw

Once a system diagram is displayed, it is subject to modifications by the user. These caneither be cosmetic modifications to the layout of the diagram or structural changes involving thecreation or deletion of system components or changes to their status. Both types of changes areachieved by direct manipulation of the graphical objects on the screen. Structural changes are treatedas commands by ConicDraw. They are relayed to gman which makes the equivalent changes to therunning system. These include node creation and deletion, exit to entryport linking and unlinkingand change in node status.

To add a node to a system, the user would select the node tool from the tool palette and drawa rectangle in the system's window. This brings up a dialogue box which prompts the user for thename, type and location of the new node instance, as well as any extra parameters that are neededfor its creation (Figure 3.6). This information is then packaged and sent to gman in the form of a‘create’ command.

Figure 3.6 - Creation of a new node instance

To create a connection between an exit and entry port, the user simply draws a link betweenthe two ports. This can be a single straight line or a multi-segment polyline connecting the 2 ports.It results in a ‘link’ command being sent to gman with the appropriate arguments. To delete a nodeor a link, the user first needs to select the item with the selection tool, and then choose the ‘Clear’item from the Edit menu.

For various reasons, it is possible that the creation or deletion of a node or a link may fail. Inthese situations, the system configuration displayed to the user will actually be inconsistent with thetrue state of the system. To overcome this problem we introduce the notion of the ‘zombie’ state : anintermediate state acquired by an object which is in the process of being created or deleted. Azombie object will remain in this state until its creation or deletion is confirmed by gman. InConicDraw a zombie node is represented by a rectangle filled with an irregular pattern while azombie link is drawn using dashed-lines.

12

Changing the status of a node is done via the Start nodes and Stop nodes menu commands.To start a node, the user first selects it with the selection tool and then chooses Start nodes from theCommand menu. Since this command works on any selected nodes, multiple nodes can be startedat the same time. The Stop nodes command works in a similar way. The status of a node relates toits configuration management state as determined by a change management protocol [8].

An example of the use of the graphics to perform and control dynamic configuration of thesystem is presented in section 4, in the form of a scenario.

Diagram Layout Support

ConicDraw provides all the standard editing facilities one would expect from a diagrameditor. It allows nodes to be moved and resized, ports to be dragged to any face of a node and linksto be reshaped by adding or deleting individual segments within the link. In addition, it knows thesyntax of Conic configuration diagrams and is therefore able to prevent syntactically ill-formeddiagrams to be constructed. For example, it ensures that all the ports and links of a node stayconnected when the node is moved, and that a port cannot be detached from its parent node.Because information on port types is also maintained by ConicDraw, it further ensures that onlyentry and exitports of compatible types can be connected.

It is essential that a graphical system such as ConicDraw give full control to the user over thelayout of his diagram. It is equally important, however, that the tool should provide aid to the userto simplify the task of editing and maintaining the diagram. This is especially true in the case ofConicDraw, where the diagram of a system configuration is generated automatically by the toolfrom information determined directly from the operational system and often requires a fair amountof editing before it resembles the structure the user has in mind. We have provided various facilitieswhich automate some of the frequently performed editing tasks, as well as tools to help the user inmanaging complex diagrams. However, rather than forcing these tools on the user, we have, formore flexibility, provided them as options. These facilities are described below.

Automatic Diagram Tidy-up : This facility is invoked automatically after a system diagram isgenerated and is also available manually via the ‘Tidy diagram’ item in the Layout menu. Thealgorithm uses the following 2 criteria in its attempt to improve the layout of a diagram :

(i) Minimization of the lengths of links. (ii) Minimization of crossovers between links.

These are achieved by performing the following steps :

Determine on which face of a node a port should be placed. This involves going through all the links in the diagram and ‘pulling together’ the ports at

either ends, as illustrated in figure 3.7. The result is that the ports at the ends of a link will be onopposite faces of their nodes. Whether they end up on the North-South or East-West faces dependson which pair produces the shorter link. At the end of this step, all the ports in the diagram will

13

have been positioned on the adjacent faces.

Node BNode A Node BNode A

Before Tidy-up After Tidy-up

Figure 3.7 - Minimizing the Length of a Link

Determine the relative positions of ports within a face. This involves finding out, for each node, the relative positions of other nodes which have

links connected to it. This information is then used to ‘sort’ the ports of the node so that their linksdo not cross. In addition, the ports within each face are spread evenly along the face so that aregular appearence is obtained. Figure 3.8 below shows an example of the effects of performingthis step.

Node C

Node B

Node A

Node C

Node B

Node A

Before Tidy-up After Tidy-up

Figure 3.8 - Avoiding Cross-overs Between Links

In practice, we have found that while the above algorithm may not be sophisticated enough to produce an aesthetically optimum layout, it is a very fast and effective way of generating a fairlyclean diagram which can be used as a starting point for further layout enhancement through manualediting. It has produced particularly good results if the user places the nodes in roughly the rightlocations before invoking the command, as in Fig. 3.9 below.

14

Figure 3.9 - A Dining Philosophers System Before and After Tidy-up

Templates : The automatic tidy-up facility described above works well in cleaning up the links,but makes no attempt to reposition the nodes. Various placement algorithms exist for diagram layoutand VLSI design, but the programs tend to be big and are often slow in execution, making themunsuitable for an interactive tool such as ConicDraw. Furthermore, the aesthetics of diagrams is avery subjective matter so even the results produced by the best of algorithms may not be acceptableto everyone.

We believe that an effective way of overcoming this problem is to enlist the help of the user,through the use of templates. This is an idea borrowed from desktop publishing, where the layoutof a page is often described in terms of blocks or columns of text and pictures by the page designer.Together they form what is termed a template which determines the appearance of the page. Theseblocks of text and picture act as place holders for the contents of the page, and are independent oftheir contents. This independence between the template and its contents has the added benefit thatthe layout information of the page can be stored separately and reused.

In ConicDraw, a template is used to determine the placements of the nodes. Each diagramhas associated with it a template which can contain multiple node holders. To create a holder theuser first has to switch to the template view of the diagram by choosing the Switch view menucommand. This gives him a new set of tools for creating the different types of holders. There are 3types of general node holders provided, namely the ring, row and column holders. The associationbetween a holder and a node is achieved by giving each holder a holder type. Any node of that typethen belongs to that holder. The diagrams below shows the patient monitoring system with all thepatient nodes placed in a column holder and a ring holder (Fig. 3.10 and 3.11).

Figure 3.10 - Patient Nodes Arranged in a Column Holder

15

Figure 3.11 - Patient Nodes Arranged in a Ring Holder

ConicDraw distributes nodes evenly within each holder. The relative positions of the nodescan be changed by dragging the nodes with the selection tool. The user does not have to be veryprecise in doing so as the nodes will by default snap back to their holder and redistributeautomatically. Similarly, when a holder is moved or resized, all its nodes will be relocatedappropriately.

Combined with the tidy-up facility, the use of templates has proved to be an effective layoutaid. It is particularly useful for diagrams which have regular layouts, such as those depicting client-server models. On the other hand, we recognise that the template facilities currently provided arestill fairly restrictive and inflexible. Possible future extensions include the ability to include nodes ofmore than one type in a holder, the distribution of nodes of the same type in more than one holder,the groupings of holders, and the facility for the user to specify new types of holders.

16

Alignment Grid: To help the user line up nodes precisely, ConicDraw provides an invisiblealignment grid which contrains the placements of nodes in a diagram. When a node is created orsubsequently moved, its top-left corner automatically snaps to the nearest point in the grid. Thisfeature can however be turned off by the user to permit finer control over the layout of the diagram.

Automatic Line-straightening: When a user draws or moves a link which has more than onesegment, each segment is automatically checked and, if necessary, modified so that it lies in either ahorizontal or vertical direction. This means that if the user wants only horizontal and vertical linksin his diagram, he need only draw lines which approximate their desired shape and leave it to thetool do the necessary modification.

Hiding Port Names: Screen cluttering is a common problem when displaying complexdiagrams, especially with the small size of the standard Macintosh screen. We therefore give theuser the option of not displaying the names of the entry and exit ports. We find that this usuallyimproves the readability of diagrams, and is especially useful when one is interested more in thestructure of a diagram.

Diagram Scaling: ConicDraw allows a diagram to be viewed and edited at any level ofmagnification.The user may thus zoom in on a particular portion of a diagram for detailed editing,or zoom out to get the complete view of a complex diagram. The Layout menu provides 5 items forcontrolling the scaling of diagrams. The first four enable fast switching to the four preset scales,i.e. ‘size to fit’, 50%, 75% and normal size, while the fifth allows the user to specify the scalingfactor via a dialogue box.

This section has outlined the facilities currently provided by ConicDraw. A step-by-stepexample of the use of the tool is presented in the next section.

17

4. A DEMONSTRATION OF DYNAMIC CONFIGURATION

18

19

20

5. CONCLUSIONS

Configuration programming provides a clear and flexible means for program definition,construction and management. The advantages of its use have been recognised for bothconventional software development, as in the use of interface specifications in the InscapeEnvironment [9], and in distributed systems such as Conic and, more recently, Durra [10].Graphical support is particularly appropriate for the structural information used in configurationspecifications. STILE[11] also applies graphics to configuration, the focus being design anddevelopment rather than system construction and management. This paper has reported on thecurrent state of our work in providing graphical facilities for editing, monitoring and controllingconfiguration programs. Based on experience with using ConicDraw, we plan to expand itscapabilities in the following areas.

System Browsing

As described in Section 2, the nodes displayed graphically by ConicDraw have themselvesan internal structure. We plan to include the facility to "explode" nodes such that their internalstructure can also be viewed graphically. A user will thus be able to trace down through thehierarchy of modules which constitute a system till at the bottom level he can view task moduleprogram text. Based on our experience of using the tool at the dynamic configuration level ofConic, we believe that this will provide a powerful aid to understanding complex systems. Theapproach we have adopted has more in common with design and specification tools [12] than tomore conventional browsers such as those used in the Smalltalk-80 environment. At each level, theuser will be able to view both the configuration program text and its graphical representation (as iscurrently provided at the top-level).

We believe strongly in the importance of retaining a textual representation of theconfiguration since in some instances it conveys a clearer understanding of the semantics of amodule. The examples presented in section 2 used a subset of the facilities of the configurationlanguage and consequently, the graphical representation was adequate. The following exampleforms part of a parallel implementation of the Fast Fourier Transform. It uses imported functions tocontrol the internal connection pattern. Inputs are connected to the output which has a bit reversedvalue of their input index.

group module interleave(n:integer); use

funcs:backwards,log2; compv:complex;

entryport input[0..n-1]:complex;

exitport output[0..n-1]:complex;

link family k:[0..n -1] input[k] to output[backwards(k,log2(n))];

end .

For large values of nthe graphic representation of this module appears as if inputs are

21

connected to outputs at random. The text conveys more clearly the purpose of the structure. Similarproblems occur when recursion is used in the configuration program.

Animation

One of the problems that has arisen in using ConicDraw is the speed at which changes canoccur in the system. Usually, these "fast" changes are as a result of pre-programmed re-configurations being executed by configuration managers in response to failures or user action.Configuration programs are essentially declarative. The configuration management system uses anon-trivial algorithm to order the execution of individual configuration actions. Viewing thesechanges in real-time ( or as fast as ConicDraw can display the changes) conveys little to the user ofthe sequence of actions which have occurred to effect the change. Consequently, we plan to providethe facility to record sequences of changes and the ability to replay the changes graphically at aspeed which is comprehensible to the user. This facility can be thought of as animating theexecution of changes. In addition, such animation can be used to test configuration changeprograms before use on the actual running system. Earlier work in the area of requirements analysis[13] has demonstrated the value of animation.

________________________________________

In conclusion, our experience using ConicDraw is that it provides a powerful aid tounderstanding and constructing configuration programs. However, we do not think of the graphicform of configuration programs as a replacement for the textual form but as existing in a symbioticrelationship. Textual programs have the advantage of conciseness and clarity in expressing complexstructures. Graphics offer a more accessible human interface. The ability to translate between thetwo forms offers the best of both worlds.

Acknowledgements

We would like to acknowledge the advice and expertise of Naranker Dulay and Kevin Twidle fortheir support in the implementation and interaction with the configuration managers. Together withMorris Sloman, they have also contributed to useful discussions on graphical configurationprogramming. The referees have made a substantial contribution to the clarification and presentationof this paper. Acknowledgement is made to SERC ACME Directorate for partial support of thiswork under grant GE/E 62394.

22

REFERENCES

[1] F.DeRemer, H.H.Kron. Programming-in-the-large Versus Programming-in-the-small, IEEETrans. Software Engineering, Vol. SE-2, 2, June 1976.

[2] J.A.Goguen. Reusing and Interconnecting Software Components. IEEE Computer (Designingfor Adaptability), Vol. 9, 2, February 1986.

[3] T.J.LeBlanc and S.A.Friedberg. HPC: A model of structure and change in distributed systems.IEEE Trans. on Computers, Vol. C-34, 12, December 1985.

[4] J.Kramer, J.Magee, "Dynamic Configuration for Distributed Systems", IEEE Transactions onSoftware Engineering, SE-11 (4), April 1985, pp. 424-436.

[5] J.Magee, J.Kramer, M.Sloman, "Constructing Distributed Systems in Conic", to appear inIEEE Trans. in Software Engineering, June 1989.

[6] S.K. Chang. Visual Languages: ATutorial and Survey. Visualization in Programming, LectureNotes in Computer Science 282, Springer-Verlag, pp. 1-23.

[7] W.P. Myers, G.F. Myers and L.C. Constantine. "Structured design", IBM Syst. J., vol. 13,no. 2, pp. 115-139, 1974.

[8] J.Kramer and J. Magee. "A Model for Change Management", IEEE Proc. Workshop on theFuture Trends of Distributed Computing Systems in the 1990s, Hong Kong, Sept. 88, pp.286-295.

[9] D.E.Perry, "The constructive use of module interface specifications", Proc. of 9th IEEE Int.Conf. on Software Engineering, April 1987.

[10] M.R.Barbacci, C.B.Weinstock, and J.M.Wing, "Programming at the Processor -Memory-Switch Level", Proc. of 10th IEEE Int. Conf. on Software Engineering, Singapore, April 1988.

[11] M.P. Stovsky and B.W. Weide. STILE: A Graphical Design and Development Environment,Digest of Papers COMPCON Spring '87, IEEE, San Francisco, Feb. 1987, pp.247-250

[12] M. Stephens, K. Whitehead. "The Analyst - a workstation for analysis and design", Proc. 8thInt. Conf. Software Engineering, IEEE Comp. Soc. Press 1985, pp. 364-369.

[13] J.Kramer, K. Ng. "Animation of requirements specifications", Software Practice &Experience, Vol. 18(8), Aug. 1988, pp. 749-774.

23