Implementational Control

~ ~ This section discusses the implemented control flow between the various tools that were used to develop SNEAKERS. The three main tools were Motif, which controls the pieces of the user-interface; C, in which all the system control functions, design output, and math functions were written; CLIPS, in which the expert systems were written; and COOL, the object system part of CLIPS, in which the tower database was created. Motif, CLIPS, and COOL were described in detail in Chapter .

The relationship of these three tools to the user is shown in Figure . The user interacts through Motif widgets to produce design changes, which are handled by C code. These changes are then asserted as facts to CLIPS, which runs the rules and outputs decisions by working back up the control chain to the interface. The C code can also act directly on the objects in the design by communicating with COOL. COOL can also be controlled from within CLIPS. The individual responsibilities of the major tools used are detailed in the subsections below.

Figures and show the logical version of the control and data flow shown in Figure . In the implementation, the blocks entitled Design Choices, Messages, and Graphics are all implemented in C. Motif shares the block entitled User with the actual user of the system. The Blackboard System block is implemented by CLIPS entirely. The Design Database in Figure is implemented in COOL.

Motif

~ ~ Motif was introduced in Section . Motif is responsible for controlling the behavior of the widgets which comprise the screen. It is responsible for making a pushbutton look and act like the button to which a user of Motif software is accustomed and for allowing the user to select items from lists. It is responsible for all the widgets which are able to offer the user a wide variety of allowable actions and to control how the user's actions affect the rest of the code.

Motif controls the execution of the program by running a loop which waits for events to occur. These events can be button presses, or screen refreshes, or anything that the user can do. A callback is assigned to the events for each widget. These callbacks are written in C code and the call back is executed in full before returning control to the main loop to wait for the next event to be processed.

Each of the individual areas of the screen had to be implemented as an individual widget which would provide the functions that the area was required to support according to the system design. The widgets which were used to implement the screen are shown in Figures and . These screendumps of the widget hierarchy outline are from VUIT's Widget Tree Browser, used to help modify individual pieces of the interface. Several of the buttons are referred to as Gadgets. These perform the same functions as widgets, but are faster during run time.

The whole screen is contained in a main window widget. The Menu Bar is a menu bar containing three cascade buttons which each contain a pull-down menu with several pushbuttons. The Drawing Area is a drawing area widget, which can show the results of calls to X primitives which allow line drawing, and a scale bar used to rotate the view.

The Agent Display Area is rather complicated. It is a form widget containing thirteen pushbuttons, representing the aspects and the agents, and a return pushbutton. There is also a pop-up dialog which displays the agents output in a scrollable list of messages.

The Palette of Objects is a form widget containing a combination of pushbuttons and scales which appear at the required times. The Message Area is a scrollable list of messages, just like that used in the Agent Display Area's pop-up dialog.

The Requirements Display Area and Other Information Area are simple text widgets which display the string they are given. The Requirements Pop-up Dialog is a form dialog widget containing several scales and toggle buttons.

This is a general view of the implementation of the interface in Motif. The outline shown in Figures and are more detailed. For more information about the actual widgets and their functionality, see [Berlage 1991].

General C Code

~ ~ When a callback is executed, it runs the C code written to interpret the user's action, to control the design choices, and to inform, change and control CLIPS and COOL. The functions of the C code include determining the viewing angles for the graphics routines to convert three dimensional points onto a two dimensional screen. Another function is to keep track of the current level of the design. It also keeps track of various lists to determine where new pieces can be added to the current design.

The greatest responsibility of the C code is as a link between Motif and CLIPS. It must convert the user's action into facts that can be asserted in CLIPS, or into changes made to object instances in COOL. These changes can affect the view of the tower. CLIPS developed agents are able to output advice to the user via Motif, using the C functions.

The C code represents a large piece of the entire objects coding, but lacks the ``glamorous'' duties that would make it more interesting to study.

CLIPS and COOL

~ ~ CLIPS, as was mentioned in Section , was used to build the expert systems which represent the various types of agents and the various aspects of the design. COOL, CLIPS Object Oriented Language, was used to act as an object-oriented design database. Some knowledge about the domain of and the towers that can be built using them is encoded there.

All of the rules written in CLIPS operate by attempting to match facts in the condition part of each rule to those in the fact-list, and then implementing an action when those facts are matched. The control view of CLIPS is that the agents are all read into the SNEAKERS environment when it is started and that CLIPS maintains a single fact-list, which is used by all the agents. The C code described above and the CLIPS code described here, both assert facts in the form:

(designfact (time ?value) (level ?value) (aspect ?value)
                 (agent ?value) (information ?value))

All facts used in the expert systems are in this form, whether they are in the condition part of a rule or the asserted facts that constitute deductions made by an agent.

Each of the fields contained in parentheses describes something about the design decision just made. The time field is the number of user actions made since the beginning of the design. The level field is the level of abstraction at which the design decision was made, eg. ABSTRACT. The aspect field is the name of the aspect to which the agent who posted the fact belongs, eg. DESIGN. The agent field is the agent type who posted the fact, eg. ADVISOR. The information field is the most relevant field, because it is the information the agent wishes to communicate, eg. New design started.

The agents are written so that the right combination of designfacts will cause them to either post another designfact or inform the user of some information. All agents have a chance to react to every designfact that is posted.

The COOL database contains all of the objects that can exist in a tower design. These objects are shown in Appendix . Each object has a number of attributes, which can be values or other objects. These objects in the database act as classes, i.e. they represent sets. When a design is performed, instances of these classes are created which have specific values for their attributes, and which can then be reasoned about. By referencing the instances of these objects, the agents can get a detailed view of the current state of the tower's design. The instances are also referenced by the general C code to display the graphical view of the tower. Attributes of the instances are used to progress through the design. For example, the system knows, from the class information, that a tower is composed of supports, so it will continue through the design until all the supports needed have been specified as attributes of the tower.