Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.stsci.edu/~rdouglas/publications/thesis/section2_9_2.html
Дата изменения: Tue May 13 19:35:11 1997 Дата индексирования: Sat Dec 22 19:14:13 2007 Кодировка: Поисковые слова: comet |
~ ~ 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 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].
~ ~ 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, 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.