monitoring facilities for viewing the current system configuration, component status and ..... displays the full information of the node, plus its uptime (Fig. 3.5).
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 the system in terms of its software configuration; that is the set of constituent software components together with their control and communication interconnections. A specification of the system configuration can be used both to describe the required system structure and for actual system construction. Management of the operational system is achieved by monitoring the status of components and making extensions or changes to that system configuration by the addition of software components or the replacement of existing ones. The performance of these programming tasks 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 graphical workstation which integrates the textual and graphical information required for configuration programming. It provides editing facilities for drawing and describing system configurations; monitoring facilities for viewing the current system configuration, component status and interconnections; layout facilities for automatically generating the graphic representations from text and improving the configuration information layout, and control facilities to permit system changes to be initiated by graphical changes to the system configuration. In contrast to many system construction tools, changes are applied dynamically to operational systems. The paper discusses the issues raised by graphical configuration programming, describes the workstation in more detail and presents examples and experience using the approach in Conic, an environment for programming and managing distributed and concurrent systems. Keywords: system configuration, programming environment, system evolution, visual programming, distributed system, graphics, dynamic configuration.
1
1. INTRODUCTION What is Configuration Programming? Software systems can be succinctly described, constructed and managed in terms of their software configuration [1,2,3,4]. This configuration consists of the set of software components which implement the functionality of the system together with their control and communication interconnections. Program modules are defined and constructed so as to provide well defined interfaces, giving the information and calls provided to or required from other modules. The program 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 to define 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 the addition 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 and comprehension. Configuration programming is closely related to the ideas of programming-in-thelarge and the use of a module interconnection language outlined in [1]. Configuration refers here to the structure of a system and not to version control. Configuration programming is particularly appropriate for distributed processing where the software components may additionally reside on different machines. The specification of the system configuration can be used both to describe the required system structure and to specify the allocation of components to machines. Management of the operational system is achieved by monitoring the status of the system's components and making extensions or changes to that system configuration. These changes may require modification of a function already provided by the system, or extension by the introduction of new functions. It may involve a change in implementation due to a technology change, improved implementation techniques or to provide redundancy in the system. It is certainly advantageous if configuration management is capable of supporting such change to the operational system dynamically, without interrupting the processing of those parts of the system which are not directly affected. The Conic environment [5], developed by the Distributed Systems Group at Imperial College, provides support for configuration programming for distributed and concurrent programs. The environment provides support for two languages, one for programming individual task modules (processes) with well defined interfaces, and one for the configuration of programs from groups of task modules. In addition the environment provides support for the reuse of modules in different contexts and support for dynamic configuration. This latter facility is achieved using online management tools which permit dynamic creation, control and modification of application programs. The basic Conic environment has been in use for over 5 years, with dynamic configuration as a more recent facility. It has amply demonstrated the utility of configuration level programming. 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 textual form has advantages in conciseness and ease of parsing. The developers and users of Conic have always drawn diagrams to describe and document their configurations, but interaction with compilers, builders and managers has always been in textual form. Together with the availability of graphics based workstations, this prompted the development of graphical support for configuration programming. This graphical support is essentially a visual programming language for configuration. However, in contrast to the majority of work on visual programming [6] our approach 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 graphics complements the text by reflection of the described or existing configuration, thereby aiding comprehension and validation. The text is still essential for the detailed information, and for certain complex cases which are not amenable to display. Overview of the Paper The Conic environment is first described to provide an introduction to the use of configuration programming and management. The paper then describes the graphical support system which integrates the textual and graphical information required for configuration description, system monitoring and change management. It provides editing facilities for drawing and describing system configurations; monitoring facilities for viewing the current system configuration, component status and interconnections; layout facilities for automatically generating the graphic representations from text and improving the configuration information layout, and control facilities to permit system changes to be initiated by graphical changes to the operational system 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, the experience gained using the approach in the Conic environment, and the directions for further work.
2. CONFIGURATION PROGRAMMING IN CONIC This section describes the configuration programming concepts embodied in the Conic distributed programming environment. These concepts are illustrated by using a simple example: a patient 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, temperature and blood pressure. For each patient the current readings can be displayed both at the bedside and at the nurse unit. If any of the factor readings of a patient are outside of some preset limits, then an alarm is sent to the central nurse station. Module Types. The system is constructed from the two module types defined both graphically and textually below in Figures 2.1 and 2.2.
3
patient
alarm bed
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 a module via exitports and received into modules from entryports. Messages can be of any Pascal datatype. The type definitions are imported from definition units by the use clause (types bedtype, alarmstype from monmsg in Figures 2.1 and 2.2).
alarm1 alarm2
bed1
nurse
bed2
alarm3
bed3
alarm4
bed4
alarm5
bed5
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 the above module types and interconnecting their exit- and entryports. The links between exitports and entryports allow modules to communicate by message passing. The Conic environment permits only ports of the same type to be connected. The configuration program for this initial system is again shown both textually and graphically in Figure 2.4.
Sun1
Ethernet
Targ1
Targ2
Figure 2.3 - Hardware Environment The system is actually created by submitting the configuration description to a configuration manager tool which downloads module code into target processors or instantiates processes under Unix as appropriate. The configuration management tool and its supporting environment is described in [5]. The configuration description may be submitted directly as text to the configuration management tool or indirectly using the graphical editor described in more detail in the next section. As can be seen from Figure 2.4, the graphical description contains less information than the textual one. Additional information is elicited by the graphics tool through the use 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
alarm
bed1
alarm1
bed
bed2
bed1
nurse
alarm2
bed3
alarm3
bed4
alarm4 bed5
alarm5
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 dynamic configuration: changes to running systems. For example, extending the above system to include an additional patient unit can be performed by submitting the following configuration program to a configuration 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:
bed1
alarm bed
alarm1 bed1
bed3
nurse
bed4 bed5 alarm3
bed2
alarm bed
alarm2 bed2
alarm4 alarm5
Figure 2.5 - Extended Patient Monitoring System 6
In practice, we have found it convenient to create initial systems from the more concise configuration program. Once created, the graphics tool can be used to display the system as it exists. It gathers information directly from the executing system by communicating with a configuration manager. The graphics tool can be used to query textual information which is not directly displayed. Modification to the system can be performed either through graphical commands or from configuration program text. A change which has been performed graphically can be saved in its text form for later re-use. The configuration management system is itself a distributed system which means that more than one agent may cause the system configuration to change. The graphics tool can be used in a monitoring mode to allow users an up-to-date view of the system configuration. In the above, the diagram of Figure 2.4 was created by using the graphics tool to monitor a system created from the configuration program of Figure 2.4. The system was extended by editing the diagram directly to create Figure 2.5. These edits caused the tool to send the extension 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 patient monitoring system. In fact, each of the two module types used are themselves configurations of modules. For example, the internal structure of the patient module is depicted in Figure 2.6.
scanner
monitor
bed alarm
patient group module patient; use monmsg: bedtype, alarmstype; exitport alarm:alarmstype; entryport bed:signaltype reply bedtype; use scanner; monitor; create scanner(100); {scan every 100ms} monitor; link scanner.readings to monitor.readings; monitor.alarm to alarm; bed to monitor.data; end.
{import message types}
{import module types}
Figure 2.6- Internal structure of Patient Module The module types used to construct patient may themselves have an internal structure. A system in Conic is thus an hierarchic structure of modules. The modules at the bottom of the hierarchy are task modules which are implemented in a version of Pascal to which message passing constructs have been added. These task modules execute concurrently and are hierarchically 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 a logical node is determined at compile time and does not change at system runtime. Consequently, it is not necessary for the graphics tool to have the ability to edit internal node structure. However, to aid system comprehension we intend to provide the facility to "explode" logical nodes to allow examination of their internal structure. This together with the ability to examine the program text of a module (whether a configuration program or a task program) will provide a powerful system browsing facility.
This section has very briefly outlined how configuration programming is provided in the Conic system and given an overview of how graphics are used in this environment. The next section examines in more detail the facilities provided by the graphics tool and its interaction with the distributed system environment.
3. CONICDRAW: THE GRAPHICAL WORKSTATION As outlined in the preceding section, Conic provides facilities for configuration programming and management. Although diagrams were always used in conjunction with the textual descriptions and 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, graphics facilities offered the opportunity to investigate the use of graphical configuration programming and management by interacting with the running system. In this section we describe the facilities currently provided by ConicDraw, the graphical workstation. Management System
Actual System
Text Interface This is some text for the VT100 Screen This is some text for the VT100 Screen dgdbc c
VT100
iman
Graphic Interface (ConicDraw)
Changes
Status gman
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 of executing Conic systems in terms of the module instances which exist in the system, their interconnections 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 can itself instigate changes to the system as a result of edits to the graphic representation. Since it always maintains a representation of the actual system, one or more workstations can be connected to the distributed system to allow a number of users to co-operatively manage and monitor the system. ConicDraw contains a comprehensive set of tools for creating and editing Conic configuration 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 its comprehensive support for programming graphic interfaces and because of experience in its use built up in a previous project. Currently, the Macintosh communicates via a serial RS232 communication link with the distributed system (running on Sun Workstation, VAX and VME 68000 machines connected by Ethernet). This serial link currently limits response times and may be replaced 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 the executing distributed system. This is achieved by running a special version of a configuration manager (gman) in conjunction with ConicDraw (Fig 3.1). Gman is a Conic program running on a host machine and communicates with ConicDraw on the Macintosh via a serial link. In the same way that an interactive manager (iman) is used to support the textual interface, gman acts as a server to ConicDraw and can provide information on all Conic systems running on Unix machines as 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 and interconnections within each system. In addition, it can also provide detailed information of each node, 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 are running in the network. This is done by selecting Get systems from the Command menu, which puts up a set of icons in the Systems window, as shown in Fig. 3.2. Each icon in this window represents 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 up the system to reveal its internal nodes and their interconnections. The pictorial representation of the system 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 limited only by the computer's memory. By default, an opened system will be continuously polled by ConicDraw for changes to either its structure or its state. When a change is detected in a system, its diagram will be updated appropriately to ensure that the graphical information presented to the user is 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 of them 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 rapidly a system is expected to change, the user can also modify the frequency of polling. All these monitoring 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 view nodes by their names, that is only the instance name is displayed within its box. Other options are viewing by type, location or full information, in which case the information displayed includes the name, type, location and state of the node, as well as its environment (whether it is running on a unix machine or a stand-alone target). It is also possible to find out how long a node has been running, by choosing the ‘Get info’ menu command. This will open a dialogue box which displays 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 the responsibility 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 delay between 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, nodes are placed into arrays of grid cells and the ports are ‘scattered’ randomly along the 4 faces of their parent nodes. Links are then drawn as single-segment straight lines connecting the appropriate message ports. As one would expect, the resultant diagram produced using this scheme is almost invariably messy and often unreadable. We have thus introduced a tidy-up facility based on some simple heuristics which is invoked at the end of each system request (and change) to clean up a diagram. 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 can either be cosmetic modifications to the layout of the diagram or structural changes involving the creation or deletion of system components or changes to their status. Both types of changes are achieved by direct manipulation of the graphical objects on the screen. Structural changes are treated as commands by ConicDraw. They are relayed to gman which makes the equivalent changes to the running system. These include node creation and deletion, exit to entryport linking and unlinking and change in node status. To add a node to a system, the user would select the node tool from the tool palette and draw a rectangle in the system's window. This brings up a dialogue box which prompts the user for the name, type and location of the new node instance, as well as any extra parameters that are needed for 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 between the 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 node or 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. In these situations, the system configuration displayed to the user will actually be inconsistent with the true state of the system. To overcome this problem we introduce the notion of the ‘zombie’ state : an intermediate state acquired by an object which is in the process of being created or deleted. A zombie object will remain in this state until its creation or deletion is confirmed by gman. In ConicDraw a zombie node is represented by a rectangle filled with an irregular pattern while a zombie 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 the Command menu. Since this command works on any selected nodes, multiple nodes can be started at the same time. The Stop nodes command works in a similar way. The status of a node relates to its 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 the system 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 diagram editor. It allows nodes to be moved and resized, ports to be dragged to any face of a node and links to be reshaped by adding or deleting individual segments within the link. In addition, it knows the syntax of Conic configuration diagrams and is therefore able to prevent syntactically ill-formed diagrams to be constructed. For example, it ensures that all the ports and links of a node stay connected 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 only entry 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 the layout of his diagram. It is equally important, however, that the tool should provide aid to the user to simplify the task of editing and maintaining the diagram. This is especially true in the case of ConicDraw, where the diagram of a system configuration is generated automatically by the tool from information determined directly from the operational system and often requires a fair amount of editing before it resembles the structure the user has in mind. We have provided various facilities which automate some of the frequently performed editing tasks, as well as tools to help the user in managing complex diagrams. However, rather than forcing these tools on the user, we have, for more flexibility, provided them as options. These facilities are described below. Automatic Diagram Tidy-up : This facility is invoked automatically after a system diagram is generated and is also available manually via the ‘Tidy diagram’ item in the Layout menu. The algorithm 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 on opposite faces of their nodes. Whether they end up on the North-South or East-West faces depends on 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 A
Node B
Before Tidy-up
Node A
Node B
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 links do not cross. In addition, the ports within each face are spread evenly along the face so that a regular appearence is obtained. Figure 3.8 below shows an example of the effects of performing this step.
Node B Node A
Node B Node A
Node C
Before Tidy-up
Figure 3.8 -
Node C
After Tidy-up
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 fairly clean diagram which can be used as a starting point for further layout enhancement through manual editing. It has produced particularly good results if the user places the nodes in roughly the right locations 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 layout and VLSI design, but the programs tend to be big and are often slow in execution, making them unsuitable for an interactive tool such as ConicDraw. Furthermore, the aesthetics of diagrams is a very subjective matter so even the results produced by the best of algorithms may not be acceptable to 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 layout of 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. These blocks of text and picture act as place holders for the contents of the page, and are independent of their contents. This independence between the template and its contents has the added benefit that the 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 diagram has associated with it a template which can contain multiple node holders. To create a holder the user first has to switch to the template view of the diagram by choosing the Switch view menu command. This gives him a new set of tools for creating the different types of holders. There are 3 types of general node holders provided, namely the ring, row and column holders. The association between a holder and a node is achieved by giving each holder a holder type. Any node of that type then belongs to that holder. The diagrams below shows the patient monitoring system with all the patient 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 nodes can be changed by dragging the nodes with the selection tool. The user does not have to be very precise in doing so as the nodes will by default snap back to their holder and redistribute automatically. Similarly, when a holder is moved or resized, all its nodes will be relocated appropriately. Combined with the tidy-up facility, the use of templates has proved to be an effective layout aid. It is particularly useful for diagrams which have regular layouts, such as those depicting clientserver models. On the other hand, we recognise that the template facilities currently provided are still fairly restrictive and inflexible. Possible future extensions include the ability to include nodes of more 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 invisible alignment grid which contrains the placements of nodes in a diagram. When a node is created or subsequently moved, its top-left corner automatically snaps to the nearest point in the grid. This feature 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 one segment, each segment is automatically checked and, if necessary, modified so that it lies in either a horizontal or vertical direction. This means that if the user wants only horizontal and vertical links in his diagram, he need only draw lines which approximate their desired shape and leave it to the tool do the necessary modification. Hiding Port Names: Screen cluttering is a common problem when displaying complex diagrams, especially with the small size of the standard Macintosh screen. We therefore give the user the option of not displaying the names of the entry and exit ports. We find that this usually improves the readability of diagrams, and is especially useful when one is interested more in the structure of a diagram. Diagram Scaling: ConicDraw allows a diagram to be viewed and edited at any level of magnification.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 for controlling 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 scaling factor via a dialogue box.
This section has outlined the facilities currently provided by ConicDraw. A step-by-step example 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 both conventional software development, as in the use of interface specifications in the Inscape Environment [9], and in distributed systems such as Conic and, more recently, Durra [10]. Graphical support is particularly appropriate for the structural information used in configuration specifications. STILE[11] also applies graphics to configuration, the focus being design and development rather than system construction and management. This paper has reported on the current state of our work in providing graphical facilities for editing, monitoring and controlling configuration programs. Based on experience with using ConicDraw, we plan to expand its capabilities in the following areas. System Browsing As described in Section 2, the nodes displayed graphically by ConicDraw have themselves an internal structure. We plan to include the facility to "explode" nodes such that their internal structure can also be viewed graphically. A user will thus be able to trace down through the hierarchy of modules which constitute a system till at the bottom level he can view task module program text. Based on our experience of using the tool at the dynamic configuration level of Conic, we believe that this will provide a powerful aid to understanding complex systems. The approach we have adopted has more in common with design and specification tools [12] than to more conventional browsers such as those used in the Smalltalk-80 environment. At each level, the user will be able to view both the configuration program text and its graphical representation (as is currently provided at the top-level). We believe strongly in the importance of retaining a textual representation of the configuration since in some instances it conveys a clearer understanding of the semantics of a module. The examples presented in section 2 used a subset of the facilities of the configuration language and consequently, the graphical representation was adequate. The following example forms part of a parallel implementation of the Fast Fourier Transform. It uses imported functions to control the internal connection pattern. Inputs are connected to the output which has a bit reversed value 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 n the 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. Similar problems 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 can occur in the system. Usually, these "fast" changes are as a result of pre-programmed reconfigurations being executed by configuration managers in response to failures or user action. Configuration programs are essentially declarative. The configuration management system uses a non-trivial algorithm to order the execution of individual configuration actions. Viewing these changes in real-time ( or as fast as ConicDraw can display the changes) conveys little to the user of the sequence of actions which have occurred to effect the change. Consequently, we plan to provide the facility to record sequences of changes and the ability to replay the changes graphically at a speed which is comprehensible to the user. This facility can be thought of as animating the execution of changes. In addition, such animation can be used to test configuration change programs 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 to understanding and constructing configuration programs. However, we do not think of the graphic form of configuration programs as a replacement for the textual form but as existing in a symbiotic relationship. Textual programs have the advantage of conciseness and clarity in expressing complex structures. Graphics offer a more accessible human interface. The ability to translate between the two forms offers the best of both worlds.
Acknowledgements We would like to acknowledge the advice and expertise of Naranker Dulay and Kevin Twidle for their support in the implementation and interaction with the configuration managers. Together with Morris Sloman, they have also contributed to useful discussions on graphical configuration programming. The referees have made a substantial contribution to the clarification and presentation of this paper. Acknowledgement is made to SERC ACME Directorate for partial support of this work under grant GE/E 62394.
22
REFERENCES [1] F.DeRemer, H.H.Kron. Programming-in-the-large Versus Programming-in-the-small, IEEE Trans. Software Engineering, Vol. SE-2, 2, June 1976. [2] J.A.Goguen. Reusing and Interconnecting Software Components. IEEE Computer (Designing for 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 on Software Engineering, SE-11 (4), April 1985, pp. 424-436. [5] J.Magee, J.Kramer, M.Sloman, "Constructing Distributed Systems in Conic", to appear in IEEE Trans. in Software Engineering, June 1989. [6] S.K. Chang. Visual Languages: ATutorial and Survey. Visualization in Programming, Lecture Notes 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 the Future Trends of Distributed Computing Systems in the 1990s, Hong Kong, Sept. 88, pp.286295. [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 -MemorySwitch 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. 8th Int. 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
