ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr4/proceedings/detex/miller.detex

Text File | 1992-04-05 | 14KB | 400 lines

 [12pt] article








  A Knowledge-Based Approach to
Encouraging Reuse of
Simulation and Modeling Programs

  Lawrence H. Miller
        The Aerospace Corporation
        Post Office BOX 92957
        Los Angeles, CA. 90009-2957

        Alex Quilici
        Department of Electrical Engineering
        University of Hawaii at Manoa
        2540 Dole St, Holmes Hall 483
        Honolulu, HI. 96822






This paper describes a knowledge-based approach
to encouraging the reuse of existing simulation
and modeling programs.
In our environment there are
two barriers to reuse of these programs: poor
interfaces and minimal documentation.
To get around these problems,
we are (1) treating each existing program as an operator
in a planning system,
(2) creating a knowledge base describing
the user goals each program achieves,
the pre- and post-conditions of running the program,
and its I/O behavior, and
(3) developing several tools that make use of
this knowledge to automate the development of new
interfaces to these programs and to assist the
creation of scripts that achieve high-level user goals.




  Introduction

The Aerospace Corporation has a large collection of
programs that perform simulation and modeling tasks
related to spacecraft design and evaluation.
As with most corporations, there exists a strong
desire to make as much use of existing code as possible,
and to write new code only as a last resort.

Unfortunately, these programs have several properties that
make this goal extremely difficult to achieve.
First, they were written in Fortran by engineers and
physicists untrained in software engineering methodologies.
The result is poor program design, which makes it
all but impossible to separate
these programs into reusable components.
Second, they often started out as one-shot solutions
to a particular program and only over time proved
more generally useful.
Because these programs were
originally intended to be used only by their designers,
they tend to have horrible interfaces and minimal
to non-existent documentation which discourages their
use by anyone other than the small community of users
that are currently intimately familiar with the program.

Our efforts have concentrated on ways to maximize
the use of these existing programs.
In particular,
we're concerned with developing techniques that encourage
the use of existing programs as components in the creation
of new software systems.
Thus, our focus is on increasing the reuse
of programs as a whole rather than on their components,
although that's clearly an important issue as well
 .

Our basic approach has been to create a knowledge base that
describes our existing simulation and modeling programs,
and to then use this knowledge base in two ways:


To help construct new interfaces that can be wrapped
around our existing programs.

To help construct scripts for achieving high-level
user goals that use our existing programs as components.

Currently, we're in the process of developing a pair
of tools that use this knowledge base.
The first takes a description of a simulation
program and automatically generates a new interface that can be wrapped around it.
The second allows developers to form scripts that achieve
high-level user goals by connecting up goal-oriented
descriptions of the function of various programs.

  The Knowledge Base For Simulation Programs

We view each of our simulation and modeling programs as an
operator in a planning system.
Thus, our
knowledge base describing these programs contains
information similar to that kept by most planning systems
 .
In particular, we describe the goals each program achieves, the situations in which it's applicable, and its input and
output behavior (which corresponds loosely to the preconditions and postconditions of the program).

As an example, one very useful program, IMPACT, simulates
a collision between two orbiting space-objects.
Our knowledge base contains
the following information for this program:



It achieves the goal ``simulate collision between
two space craft.''

It is applicable under various constraints on the
type of collision,
such as that the collision must be orbital
and hyper-velocity.

Its input is a file ``impact.in'' that contains the
initial collision parameters,
such as the initial velocity of the projectile in meters
per second and the altitude of the collision in kilometers.

Its output is a file ``impact.out'' that contains a
description of the initial orbits of the particles
that result from the collision,
presented as a set of particle positions and velocity,
grouped by size of particle.

The information describing the various input and output
values of these programs is quite detailed, including
the value's purpose, its expected units, its expected
range, and so on.
In addition, since some of these input
values can be computed automatically by running
alternate programs,
the knowledge base also associates input values with
the programs that can be run to compute them.

We construct this knowledge base in the obvious way:
first, by examining whatever program documentation
happens to be available, and second, by
consulting with current users of the program.
Thus, in addition to its role in assisting the process of
constructing new interfaces and forming scripts that
use these programs,
the knowledge base serves as additional
documentation for these programs.

  Providing Multi-Modal Interfaces

A key to making existing programs usable to a larger
community of users is to provide them with a friendly
user interface,
complete with dialog boxes and mouse selections for input,
and bar charts, plots, and tables for output.
Unfortunately, our current
fleet of aging simulation and modeling
programs have interfaces that are exactly the opposite.
Typically, these programs accept a stream of values for
input, in a particular order and in particular units,
and produce a stream of values as output.   It
takes a significant amount of time for users to come
up to speed on the input formats and to understand
the meaning of the program's output.

Because these programs are generally poorly written,
it's difficult to perform cosmetic surgery
on them.
They frequently read input or produce output
from multiple locations in the program,
or read and write input and output values
directly into specific locations in memory.
Their batch nature, however, makes it straightforward,
although time-consuming,
to wrap them in a richer interface.
The input side of the interface prompts for values or runs
other programs to provide the needed values, and then
creates the files necessary for a given program to run.
The output side of the interface takes the program's
output values and displays them in appropriate tabular
or graphic forms.

Originally, we created these improved interfaces by hand.
In particular, we built an improved interface to an aging
Fortran program that computes reliability of satellite
components, and included it as part of a new, multi-modal
environment for evaluating satellite performance.
Given this knowledge base, however, it becomes possible
to automate much of this process.
We've created a straightforward interpreter that's given
existing programs to run,
and uses the knowledge base to
automatically query users or run other programs
to determine the necessary input values.
It then creates the necessary input file and runs
the program.
Once the program runs, the interpreter uses the
knowledge base to run through its output
file and display those output values appropriately.

By providing these programs with improved interfaces,
we have greatly extended the community
of users for these programs.
In addition, our knowledge-based approach is much simpler
than trying to construct new interfaces by hand,
or trying to modify the existing simulation programs
themselves.


  Synthesizing Simulation and Modeling Scripts

Another key to encouraging reuse is to make it easy for users and developers to combine existing programs to form
solutions to their problems.
In our environment,
one important set of programs simulates orbiting space
objects.
Along with IMPACT,
these include programs
to determine the probability of collisions with other
space objects, how long particles will orbit, and where
particles are likely to land when they return to earth.
Experienced users of these programs have figured out
how to combine them into scripts that achieve
their high-level goals,
such as planning satellite breakups meeting
certain constraints, or determining whether an existing
breakup will cause damage to a particular satellite.
Most of these scripts haven't yet been
implemented as programs, and exist solely in the
heads of users.

Our feeling is that there are three ways to
increase the reuse of our existing simulation programs.
First, by capturing existing uses of programs as
concrete scripts that solve particular user goals.
Second, by assisting users in automatically creating
new scripts.
And third, by presenting these scripts in
a way that they can understand better what the
component programs do.

Our assumption is that the scripts
these experienced users
formulate can be represented as a hierarchical goal
decomposition, consisting of an initial goal decomposed
into subgoals, with programs that achieve various
subgoals attached to leaves of the tree.
As an example, consider the goal of
planning a breakup collision that satisfies the constraint that there's a low
probability of debris colliding with an existing satellite.
It breaks down into the following steps:


Decide upon an initial collision velocity and
collision angle.

Simulate the collision

Determine the probability of hitting an
existing satellite.

Reposition existing satellites that are in
danger.

Determine a new collision velocity and angle.

Go to step 2.

Some of these subgoals correspond directly to running
programs, such as step 2, is achieved
by running the IMPACT program.
Others, however,
correspond to another sequence of subgoals,
such as step 3, which consists of a subgoal
of determining which satellites are in the general
orbit of the particles resulting from the breakup,
and then determining the probabilities of
each of these satellites being in danger.
Finally, some subgoals correspond to manual tasks,
such as steps 4 and 5, which involve
manually trying to find new locations for satellites
in danger and trying
to guess more appropriate collision angles.

Our approach is to provide a graphically-oriented tool
that allows users to specify the complete
goal hierarchies for solving their problems,
along with the connections between various
subgoals and existing programs.
This allows them to easily form a library of scripts
that capture how the programs are actually being used
to solve problems.
We then provide an interpreter that automatically
executes these scripts,
automatically obtaining needed input values and displaying output values appropriately.
In addition, while executing these scripts,
the interpreter highlights active subgoals,
allowing users to learn the uses of
existing programs.

Our knowledge base supports this process by containing
the knowledge necessary to map programs to
the goals they achieve,
as well as knowledge about their inputs and outputs,
so that users constructing scripts are freed from
worrying about those values.

  Future Work and Conclusions

Currently, there are several limitations to our approach.
First, our programs are primarily batch and have
limited options.
We haven't yet tried to create a knowledge
base for an interactive program or for a program that
does different things in different situations.
And second, our approach is only at the prototype stage.
We have implemented knowledge bases describing a set of
approximately a dozen programs and scripts of their use,
as well as first pass implementations of the tools that
use this knowledge base to provide new interfaces, and to
assist users in entering and executing the scripts for
their high-level goals.
We are beginning to consider many of the issues that will
arise when we scale up to larger collections of programs,
such as users being able to find the appropriate script
that achieves their goal  .

Besides beginning to deal with scaling issues,
we're also starting to explore several new directions.
The first is to use the knowledge base to automatically
form scripts from initial descriptions of user goals.
In particular, we've been considering how to combine our
approach with    Weaving , a large grained data flow
environment designed to support the combination of programs
 .
Another problem we've begun looking at is
to tryito automatically extract some of
the information now placed into our knowledge base by hand.
In particular, we're focusing on how we can
extract knowledge about a program's input and output behavior.

In summary, we are trying to encourage the use of these
batch programs by making them appear to be interactive
and by including them as components of more
sophisticated interactive, software systems.
We're doing so by
(1) providing them with better interfaces and by (2)
combining them into high-level scripts that reflect
how they're used.  The key is we're
using a knowledge base describing these programs to help
us create tools that
automatically perform these tasks.

   Bigg 90


Allen, J., Hendler, J. and Tate, A. (Editors),    Readings
in Planning , Morgan Kaufman, Palo Alto, CA, 1990.


Biggerstaff, T. (Editor),    Software Reuse ,
Addison Wesley, Reading, MA, 1990.


Fischer, G., Henninger, S., and Redmiles, D.,
``Cognitive Tools for Locating and Comprehending Software
Objects for Reuse.''
In    Proceedings of the 13th International Conference
on Software Engineering , IEEE Computer Society Press,
1991.


Gorlick, M. and Razouk, R.,
``Using Weaves For
Software Construction and Analysis.''
In    Proceedings of the 13th International Conference
on Software Engineering , IEEE Computer Society Press,
1991.