A Functional/Declarative Dichotomy for Characterizing
Simulation Models
P. A. Fishwick
Department of Computer and Information Sciences
University of Florida, Bldg CSE, Room 301
Gainesville, FL. 32611
Abstract
Traditional computer simulation terminology in
cludes taxonomic divisions with terms such as "dis
crete event," "continuous," and "process oriented."
Even though such terms have become familiar to sim
ulation researchers, the terminology is distinct from
other disciplines such as artificial intelligence and
software engineering which have similar goals to
our own relating specifically to modelling dynamic
systems. We present a perspective that serves to char
acterize simulation models in terms of their procedu
ral versus declarative orientations. In teaching sim
ulation students using this perspective, we have had
success in relating the field of modelling within com
puter simulation to other subdisciplines within com
puter science.
1 Introduction
Computer simulation is the creation and execu
tion of dynamical models employed for understand
ing system behavior. Even though the literature base
in simulation is quite large, many simulation text
books serving as archives for future researchers and
students cover simulation methodology using the
classic taxonomies including terms such as "contin
uous," "discrete event" and "eventoriented." This
type of taxonomy may seem comfortable and famil
iar; however, we will demonstrate that for the task
of modelling, we need to strengthen ties with artifi
cial intelligence (AI) and software engineering (SE) to
provide a more uniform view of system modelling that
is less focused on one particular simulation method
(such as discrete event simulation), and more attuned
to modelling continuous, discrete models and spatial
models using a unified framework. First, we stress
that "modelling" and "simulation" are two different
tasks and we will attempt not to use them inter
changeably; one model may be simulated using sev
eral different simulation algorithms. When reviewing
..i I.I 1. ' in discrete event simulation, we find it
tempting to confuse the method of modelling such as
process orientation (i.e., a functional modelling ap
proach) with the method of simulating or executing
a model such as event scheduling (i.e., an approach of
simulating parallelism of an abstract, lumped model
on a sequential computer).
Our emphasis is on modelling methodology [7, 6]
rather than analysis methodology. Methodology in
analysis has received a much more comprehensive
treatment in the general simulation literature [17, 2]
as compared with methodology in modelling. The
art and science of modelling, per se, is more akin to
the computer science discipline, and consequently, we
find several examples in computer science that serve
to bolster our argument for a more integrated mod
elling approach that encapsulates many of the mod
elling methods in AI and SE. There are key facets
of simulation modelling that are strongly related to
parts of AI and SE, and these facets appear to be
more fundamental to the nature of simulation mod
elling than are the current divisions along the lines
of "discrete event," "continuous" and "combined" or
"activity scanning," "event . I. .1.II,1, and .p .... 
interaction." For example, the data flow diagram in
SE and the block model in simulation represent the
same modelling technique; the DFD has elements in
cluding functional blocks, inputs, outputs, coupling
and hierarchy. The same is true of the functional
block model in SE. In the past, the two modelling
camps could be considered completely separate en
titites; however, with the onset of distributed com
puting and the encapsulation of code in physically
separated and, therefore, modeled objects, soft
ware engineers are every bit as interested in modelling
continuous and discrete data flows as are simulation
modellers. In SE, a data flow diagram represents a
modelling technique valuable for a great number of
models. In simulation, we should also use this func
tional category of modelling to represent queuing net
works, digital logic circuits and systems for control
TR92003 Computer and Information Sciences, University of Florida
MODEL CHARACTERISTICS
CONCEPT Nonexecutable
Model Z
Complexil DECLARATIVE FUNCTIONAL Homogeneous Nodes
in model graph
& Internode coupling
HETEROGENEOUS Heterogeneous Nodes
m model graph
& Internode coupling
MULTIMODEL Interlevel coupling
Figure 1: The proposed modelling paradigm.
engineering; there are some differences in the data
flow (discrete versus continuous), although this is a
minor difference and does not represent a fundamen
tal shift in modelling practice1
Our hypothesis is that, while the current tax
onomies for modelling in simulation haved served
their purpose, we need to consider another taxonomy
that fits more closely with related modelling efforts
in the AI and SE communities. The modelling of dy
namic systems has become a widespread phenomenon
and is no longer specific to the traditional simulation
discipline; we need to embrace these competing ar
eas to derive a common taxonomy or i..I1.1 l, 
with regard to system modelling. This alternative
taxonomy is based on a set of modelling approaches
depicted in figure 1. In fig. 1, the first type of model
is the concept model which corresponds to an object
model within SE or a system entity structure [31].
The concept model is nonexecutable, and serves as
a knowledge base for the system. From the concept
model, one can derive either one of two basic mod
elling forms: declarative and functional. Declarative
models emphasize state transitions, while functional
models emphasize operational or event oriented mod
elling. One may combine these forms to form hetero
geneous models where model graph nodes may be of
different types. Finally, the multimodel [13, 18, 15]
is the most comprehensive type of model that sup
ports multiple models tied together with homomor
phic mappings from one model to another. The pro
posed taxonomy is an extension to the object oriented
modelling paradigm. While we adhere to the object
model as a good basis for conceptual, nonexecutable
models, we depart from the norm when introducing
how additional modelling techniques such as produc
tion systems, trackbased animation and System Dy
namics fit within the overall framework. In the usual
object oriented modelling approach within SE [26, 4],
1In terms of closed form analysis, it is natural to form a
dichotomy between "discrete" and "continuous" since the solu
tion methods are different. With simulation and especially
with the differences are not that pronounced.
specific modelling methods such as FSA modelling
and DFDs are promoted. We treat these two types
of models as instances of a class rather than the class
itself. Our approach is to stress the utility of having
classes of models. In our declarative modelling class,
for instance, we list several types of models including
FSAs, production rules, and logic based models.
We are interested in overviewing the commonalities
in the modelling process as well as asking fundamen
tally interesting historical questions such as "What
are the causes or catalysts aiding in the relatively
recent convergence in AI, SE and simulation mod
elling?" and "How, precisely, will modellers and de
cision makers benefit in this convergence?" The in
tegrated style is being used by several simulation re
searchers; however, it has not yet penetrated the gen
eral textbook simulation literature as a more power
ful paradigm for modelling dynamical systems. Al
though the introduction of new dichotomies, tax
onomies and reorganizations is a philosophical issue,
we have had first hand experience in teaching the pro
posed simulation modelling methodology to college
seniors and first year graduate students with much
success. Students who take, for instance, courses in
AI and SE can take a class in simulation that builds
upon rather than replaces recently learned model
forms.
Two key aspects of the new view shown in fig. 1
are the declarative versus the functional perspec
tives. These two modelling views form a dichotomy in
that most modelling methods in simulation are ori
ented toward one view rather than the other. Sys
tem Dynamics models [25] and block models, for in
stance have functional orientations. The term "di
chotomy" is used somewhat loosely, though, since
there exist some kinds of modeling methods such
as Petri nets [23] that have equal shares of declara
tive (i.e., place) and functional (i.e., transition) sub
representations.
We first overview why we chose these two categories
in our attempt to synthesize system modelling tech
niques in AI, SE and simulation. Within the context
of a two jug problem in AI, we then discuss how the
jug system can be viewed from these two perspec
tives. We close with some conclusions and research
currently underway to extend these ideas.
2 Synthesis of Modelling Techniques
2.1 AI & Simulation Models
Within AI, one is concerned with how to model
human thought and decision making. Often, the de
cision making is heuristically based, and there is in
TR92003 Computer and Information Sciences, University of Florida
complete knowledge about the domain. This "incom
1.1. i ...  should be programmed into the dynamical
model where it is present. For the past decade, the
interface area between AI and simulation has grown,
and several texts have appeared [28, 14]. Simula
tion models have characteristically been composed of
simple entities and objects; however, the introduction
of autonomous agents (including robots and humans)
into a model has suggested that simulationists use AI
models in places where autonomy is present. While
a simple queuing network avoids the use of knowl
edge based simulation models, a more detailed model
would include beliefs, plans and intentions of the au
tonomous agents at some level of detail. Trajectories
of projectiles and three phase motors are compara
tively simple to model because these objects operate
in accordance with natural laws that are sometimes
shaped (or controlled) through engineering. Models
of intelligent agents are much more complicated due
to the sophisticated reasoning abilities of humans and
of robots that are endowed with humanlike reason
ing.
Autonomy has, therefore, spawned the creation of
knowledge based models that contain a variety of nat
ural, artificial and intelligent objects interacting and
reasoning in an environment. The fields of qualita
tive reasoning and qualitative physics [27, 3] are ev
idence of the AI interest in system modelling from
the perspective of mathematical reasoning. In addi
tion to autonomy playing a critical role, incomplete
knowledge is ever present within models and AI re
searchers have suggested new ways of representing
this type of knowledge. While simulationists have
used probability theory for representing abstracted
quantities, one can also use heuristic rules and con
straint based modelling techniques. These types of
techniques have been used for declarative and func
tional modelling [29]; however, they are most use
ful within conceptual models that serve to enhance
our ability to diagnose symptoms, plan future ac
tions and provide commonsense explanations of de
vice .. i, .. ['', 5].
2.2 SE & Simulation Models
Software engineers are pioneering new and novel
methods for computer assisted methods; tools such
as Foresight [1] provide the modeller with the ca
pability of modelling dynamic systems using finite
state automata and block modelling all under the
umbrella of object organization. It appears as if soft
ware engineers are developing a keen interest in sim
ulation; there is an apparent convergence between
these two areas [21, 20]. Some of our previous re
search [11, 10, 12, 15] has suggested the study of
model engineering as a direct analog to software engi
neering. The key to the convergence between the SE
and simulation fields lies in the area of distributed
and realtime computing. Technology has seen the
computer decrease in size and cost while increasing
in power. This combination of circumstances natu
rally leads to the use of computers in almost every
electromechanical device. Zeigler presents a theory
for modelling autonomous agents [32] while imple
menting a model engineering methodology. When
software engineers had to concern themselves with
modelling only mainframe or workstation software,
the modelling process dealt with functional decompo
sitional methods: creating hierarchical routines and
stubs while gradually expanding the size and com
plexity of the program. Now, however, with the ever
expanding migration of the microprocessor, the struc
tural components of software models are beginning to
act and appear like the physical objects in which the
processors live. Modelling distributed software, with
its emphasis on communication protocols, is similar
to modelling the physical objects for which the soft
ware is written.
Thus, the convergence of SE and simulation mod
els stems, largely, from distributed computing. There
are key differences, though, between the end results
one obtains. Software engineers want an executable
program, while simulationists want to model the per
formance and lumped behavior of the system. While
these two avenues appear to diverge, there is actu
ally a confluence. The confluence is best seen at a
higher level in the decision making process that over
sees the use of software engineers and simulationists.
That is, the decision maker who wants to create ef
ficient and correct distributed software for his inter
bank transaction project, for instance, is also highly
concerned with the efficiency of the entire architec
ture. Whereas, a decade ago, a project might have
involved simulation before or during actual construc
tion of hardware, communications pathways and dis
tributed software, now, a project can be created while
cleanly integrating the tasks of performance analysis
with software development. The ultimate simulation
is the actual creation of the software which is then
executed; lumped statistical behaviors can easily be
obtained when one has the lowest level performance
traces. The ultimate software development tool is
one that permits modelling the software at a variety
of abstraction levels the lowest level providing de
tailed behavior of the sort normally associated with
program input and output traces.
TR92003 Computer and Information Sciences, University of Florida
6
Jug A
3 gallons
Jug B
4 gallons
Figure 2: Two jug system.
3 The Two Jug System
Consider the water jug problem as described in
AI[16, 24]. In the water jug problem, there are two
water jugs (one with a four gallon capacity, and the
other with three gallons). Jug A is the three gallon
jug, and jug B is the four gallon jug (see figure 2).
There are two water spigots and there are no mark
ings on either jug. There are three basic operations
that can be performed in this system: emptying a
jug, filling a jug, or transferring water from one jug
to the other. In addition to operations, it is com
mon, in this problem, to specify a goal that we want
to obtain the sequence of operations that will yield
2 gallons in Jug A. We will study the system as a
whole without focusing on the discrete optimization
aspect of reaching a particular goal.
4 Declarative Models
In declarative modelling, we build models that fo
cus on state representations and statetostate tran
sitions. Given a state and a transition, the model
will provide the next state. This simple metaphor
provides for a whole class of models. The FSA and
Markov model in simulation are the most basic model
types.2 In SE, the state transition model is termed
the "dynamic" or I i.." model. The use of the word
"dynamic" is somewhat unusual from a simulation
ist's perspective since data flow diagrams are also
a valid form of dynamic model representing input,
transfer functions and outputs coupled within a block
network diagram. On the other hand, in SE, the ref
erence to "dynamic" reflects that state change is at
the heart of dynamics. Even though this is true for
the most part, memoryless functions also represent
dynamical systems. Moreover, if FSAs are embed
ded within another formalism (such as a data flow
diagram) then that formalism is also considered dy
namic. In AI, the declarative approach is quite ad
vanced since there are several AI declarative repre
sentations that can be useful in modelling. From AI,
2In systems theory, the the FSA is often termed a "local
transition function."
* The operator and description.
we can enrich the stateoriented declarative modelling
approach to include logic, rules, and production sys
tems. The declarative approach need not be limited
to simple state to state transitions. If a state matches
a certain structure then we delineate in our model
the transition to the next state. We can, in fact, use
pattern matching capabilities so that state 1. i'' 11'
str '. iiii. are used instead of state "instantiations"
with builtin constant values. The production sys
tem and logic approach utilize this form of calcula
tion to afford declarative methods the capability of
representing complex behaviors with a modicum of
mathematical notation.
Methods of production systems [5] and formal
logic [8] (either standard or temporal) may be used as
a basis for simulation modelling. We need to define
the concept of state, input and time with respect to
these models:
State is defined as the current set of facts
(truths) in a formal system. For predicate logic
this equivalences to a set of predicates. For ex
pert systems, the rule or I:.... I..I ." base is the
state of the system.
For production systems, inputs are known as
.1.. i Ii.. A sequence of parameterized calls
to the operators serve as the input stream that
controls the system. We will associate time dura
tions with input events by saying that whenever
an input event occurs (which causes a change in
state), the ensuing state will last for some spec
ified period of time.
Time can be assigned to each production or in
ference so that the process of forward chaining
produces a temporal flow. We could make state
variables vary continuously or discretely.
The state of the water jug model will be identified
by a set of predicates. Note that predicates and argu
ments are both in lower case. The state is defined as
(X, Y) where X is the amount of water (in gallons)
in the 3 gallon jug, and Y is the amount of water in
the 4 gallon jug. We define states to vary using dis
crete jumps so that filling an initially empty jug A,
for instance, would cause a jump from state (0, 0) to
(3, 0). We will assume an initial state of (0, 0) (i.e.
both jugs are empty). Time will be measured in min
utes, therefore rates are measured in terms of gallons
per minute. Filling is somewhat slow and proceeds at
a rate of 2 gallons per minute. All other operations
take 10 gallons per minute. There are 4 operators.
We will define them as follows:
TR92003 Computer and Information Sciences, University of Florida
* Conditions for the operator to be applied (i.e.
fire).
The time duration AT of the operator if it is ap
plied. The duration is associated with the cur
rent state.
1. OPERATOR 1: empty(J).
(a) Empty jug J {A, B}.
(b) For J = A, (X, YX > 0) 
AT = X/10.
(c) For J = B, (X,YY > 0)
AT= Y/10.
2. OPERATOR 2: fill(J).
(a) Fill jug J C {A, B}.
(b) For J = A, (X, YX < 3) 
AT= (3 X)/2.
(c) For J = B, (X,YIY < 4) 
AT = (4 Y)/2.
3. OPERATOR 3: xferall(J1, J2).
(a) Transfer all water from jug J1 t
(b) For J1 = A, (X, YIX+Y < 4AXs
4)  (0, X + Y), and AT = X/
(c) For J1 = B, (X, YX+Y < 3AY
3) (X + Y, 0), and AT = Y/1
4. OPERATOR 4: xfer_full(J1, J2).
(a) Transfer enough water from jug
J2.
(b) For J1 = A, (X, YIX+Y > 4AXs
4)  (X(4Y), 4), and AT =
(c) For J1 = B, (X, YIX+Y > 3AY
3) (3, Y(3X)), and AT =
The application of various operators will
current state to new state. For instance
initial system state as being (0, 0) we s
can apply only operator fill. Specifical
do either fill(A) or fill(B). Both oper;
a certain amount of time AT. The Al
ated with the current state. Let's look a
taken to fill jug A. We note that the
rule associated with this operation is: I
(X, YX < 3) (3,Y) and AT = (3 
go from state (0, 0) to (3, 0), for instance,
total time of T = (3 0)/2 or T = 1.5. TI
preted as: "if the system is in the state (0,
operator fill is input to the system then
will enter state (3, 0) in 1.5 minutes." In o
(0, Y) and
(X, 0) and
SJugB
0 0 0 *
0 0 0 0
0 1 2 3 J A
O O
(a) Jug A full
SJug B
0 0 0 0
C1 0 0 0
Jug A
0 1 2 3
(b) Jug B full
Figure 3: Full phase.
(3, Y) and the system remains in state (0, 0) for 1.5 minutes be
fore immediately transitioning to state (3, 0).
If we consider each operator as representing an ex
(X, 4) and
ternal, controlling input from outside the jug system,
then we can create a an FSA that represents the pro
duction system. Figure 6 displays this FSA where
the following acronyms are defined:
ojug J2.
> OAY 1. Ex: Emptyjug x.
10. 2. Fx: Fill jug x.
> OAX <
3. TAxy: Transfer all water from jug x to jug y.
No overflowing of water is permitted.
4. TFxy: Transfer all water from jug x to jug y.
g J1 to fill until jug y is full.
Even though the state space contains 20 states there
S> OAY < are only 14 possible states in the FSA. The two jug
(4Y)/10. system dynamics are quite complex; this attests, pri
> OAX < marily, to the power of production rules (with pattern
(4Y)/10. matching) over simple FSAs (without pattern match
ing). We can simplify the system by partitioning
change the state or event space. There is no automatic method
,given the for state space partitioning; however, we can use a
ee that we heuristic to help us: form new states using participle
ly, we can created from the object model. That is, the present
nations take participle form of "fill" is "filling." Figures 3 through
is associ 5 suggest a partitioning of state space that provides
it the time a lumped, more qualitative model. Since these seg
production ments overlap, and do not form a minimal partition,
..r J = A, we must combine substates reflecting levels in jugs
X)/2." To A and B to form 9 new states. The greatest "lump
will take a ing" effect is contained in the state (Jug A filling,
his is inter Jug B filling) where the term "filling" means neither
0) and the empty nor full. It is important not to underestimate
the system the lumping effect when considering other possible,
their words, but similar, systems. For instance, if the jugs could
TR92003 Computer and Information Sciences, University of Florida
Jug B
000
000
000
000
Jug'
0 1 2 3 Jug
(a) Jug A empty
Figure 4: Empty phase.
contain arbitrarily large amounts then the state space
for fig. 6 would also be large, but the state space for
the lumped model would remain the same (9 states).
It is possible to further reduce the number of states
by mapping and partitioning state or event space in
accordance with natural language terminology; state
space could easily be broken into ;. and "dry"
where dry corresponds to both jugs being empty, and
wet covering the remainder of state space. Models
at varying levels of abstraction [9] are created in re
sponse to the questions asked of them [15].
5 Functional Models
SJug B
0 0 0 0
) * 0
C * 0
0 1 2 3 JugA
o
012 3
(a) Jug A filling
JugB
2 0* *
1 e *
o 0 0 0 ,
0 1 2 3 JugA
(b) Jug B filling
Figure 5: Filling phase.
We will use a liberal interpretation of the word
"functional" to include modelling approaches that
stress procedural or 1......oriented" models. A
purely functional model is termed .... .... I. ." since
there is no state information; so we define a func
tional model as one that focuses on "function" rather
than state to state transition. Functional models,
therefore, will often contain FSAs embedded within
the definition of a functional block; the model is con
sidered "functional" if this view dominates any sub
sidiary declarative representations. A function will
be represented as a block with inputs and outputs.
Inputs and outputs can represent data flows or con
trol flows, and they are defined as such within SE [1].
From our perspective, these flows are all data flows
regardless of whether a function treats its input data
from a control perspective. The functional SE box
structuring techniques of Mills [19] bear remarkable
resemblance to those of systems and simulation the
ory [22, 30]. This further demonstrates a convergence
in model theory between SE and simulation.
Jug B
0
0
0
0
to
to
0 Jug A
0 1 2 3
Figure 6: FSA for the jug system.
(b) Jug B empty
TR92003 Computer and Information Sciences, University of Florida
and each subcomponent has its own dynamics. The
declarative approach of a rulebased production sys
tem while it accurately represents the jug system
dynamics partitions state space without an accom
panying separation of function. Despite these dif
ferences, there is not an inherent advantage of using
the functional approach over the declarative approach
since the production rule model separates behaviors
according to pattern matches in state space; it is sim
ply another way of viewing the system.
Figure 7: Functional model of two jug system.
Xfe(A,B)
Empty(A)
Empty(A)
Figure 8: FSA for jug A.
If we consider each tap and each jug to be
tion then we can create a functional block m
lustrated in figure 7. This dynamical model c
simulated as it is represented; that is, message
be input to blocks that would delay the corr
ing outputs to represent the passage of time. 1
delay, therefore, represents a simple way to cr
abstract model. If we want to increase model
the delay can be further decomposed into an F
the tap dynamics, we use a delay; however, for
dynamics, we choose an FSA. The dynamics
A are shown in figure 8. The entire function
shown in fig. 7 has four functional blocks with
the blocks (jugs A and B) having an internal
further refine state to state behavior. It is wor
to contrast this model with the declarative I
fig. 6. In the declarative model, each state rep
the state of the entire system whereas, for th
tional model, states are "local" to the specify
tion. In the object oriented sense, these stE
hidden or encapsulated within the block. The
of locality is what has made the functional aj
more acceptable to the systems community
tem is broken into functional blocks, each o
represents a physical subcomponent of the
6 Conclusions
Our purpose was primarily to demonstrate the
need for simulation modelling taxonomy to take a
form more compatible with system modeling efforts
in SE and AI. We have demonstrated how a declara
Xf(A,BJ. tive/functional dichotomy already exists within each
BA) discipline, and we gave definitions of the two views us
ing a simple example of dynamics the jug problem.
Several simulation researchers have pointed out the
need for further integration with SE and AI, but most
simulation texts fall behind in their discussions of
modelling and how it relates, for example, to system
models within the object oriented design approach.
Simulation has much to offer the fields of SE and AI;
however, we have slanted this discussion to talk of a
general integration of terminology and general taxo
nomic breakdown. All three fields have much to offer
a func each other; formal studies in precisely how system
lodel il models differ is a good beginning, and this has been
would be our motivation behind the presented work. We are
s would presently extending this study to delineate two other
espond key classes of model: the concept model and the mul
Use of a timodel.
eate an
I detail, References
SA. For
the jug
for jug
1 model
Stwo of
FSA to
thwhile
lodel in
)resents
te func
ic func
ites are
aspect
)proach
a sys
f which
system,
[1] Athena Systems.
February 1989.
Foresight User's Manual,
[2] Jerry Banks and John S. Carson. Discrete Event
System Simulation. Prentice Hall, 1984.
[3] Daniel G. Bobrow. Qualitative Reasoning about
Physical Systems. MIT Press, 1 .
[4] Grady Booch. Object Oriented Design. Ben
jamin Cummings, 1991.
[5] Ernest Davis. Representations of Commonsense
Knowledge. Morgan Kaufmann, 1990.
[6] Maurice S. Elzas, Tuncer I. Oren, and Bernard P.
Zeigler. Modelling and Simulation Methodology
I ll(A)
Jug A
X=0
Sill(A) Fhnm X=3
Xfer(BmApt
TR92003 Computer and Information Sciences, University of Florida
in the Artificial Intelligence Era. North Holland,
1986.
[7] Maurice S. Elzas, Tuncer I. Oren, and Bernard P.
Zeigler. Modelling and Simulation Methodology:
Knowledge Systems' Paradigms. North Holland,
1989.
[8] Herbert Enderton. A Mathematical Introduction
to Logic. Academic Press, 1972.
[9] Paul A. Fishwick. The Role of Process Abstrac
tion in Simulation. IEEE Transactions on Sys
tems, Man and Cybernetics, 18(1):18 39, Jan
uary/February 1988.
[10] Paul A. Fishwick. Qualitative Methodology in
Simulation Model Engineering. Simulation Jour
nal, 52(3):95 101, March 1989.
[11] Paul A. Fishwick. Studying how Models Evolve:
An Emphasis on Simulation Model Engineering.
In Advances in AI and Simulation, pages 74
79, Tampa, FL, 1989.
[12] Paul A. Fishwick. Toward an Integrated Ap
proach to Simulation Model Engineering. Inter
national Journal of General Systems, 17(1):1
19, May 1990.
[13] Paul A. Fishwick. Heterogeneous Decomposi
tion and Coupling for Combined Modeling. In
1991 Winter Simulation Conference, pages 1199
1208, Phoenix, AZ, December 1991.
[14] Paul A. Fishwick and Richard B. Modjeski, edi
tors. Knowledge Based Simulation: Methodology
and Application. Springer Verlag, 1991.
[15] Paul A. Fishwick and Bernard P. Zeigler. A Mul
timodel Methodology for Qualitative Model En
gineering. AC if Transactions on Modeling and
Computer Simulation, 1992. Submitted for re
view.
[16] Robert Kowalski. Logic for Problem Solving. El
sevier North Holland, 1979.
[17] Averill M. Law and David W. Kelton. Simula
tion Modeling & Analysis. McGraw Hill, 1991.
Second edition.
[18] Victor T. Miller and Paul A. Fishwick. Hetero
geneous Hierarchical Models. In Artificial Intel
ligence X: Knowledge Based Systems, Orlando,
FL, April 1992. SPIE.
[19] Harlan D. Mills. Stepwise refinement and veri
fication in boxstructured systems. IEEE Com
puter, 21(6):23 36, June 1988.
[20] Richard E. Nance. Modeling and Programming:
An Evolutionary Convergence, April 1988. Un
published overheads requested from author.
[21] C. Michael Overstreet and Richard E. Nance. A
Specification Language to Assist in Analysis of
Discrete Event Simulation Models. Communi
cations of the AC i1 28(2):190 201, February
1 I ",
[22] Louis Padulo and Michael A. Arbib. Systems
Theory: A Unified State Space Approach to Con
tinuous and Discrete Systems. W. B. Saunders,
Philadelphia, PA, 1974.
[23] James L. Peterson. Petri Net Theory and the
Modeling of Systems. PrenticeHall, Inc., Engle
wood Cliffs, N.J., 1981.
[24] Elaine Rich and Kevin Knight. Artificial Intel
ligence. McGrawHill, 1991.
[25] George P. Richardson and A. L. Pugh. Intro
duction to System Dynamics Modeling with DY
NAMO. MIT Press, Cambridge, MA, 1981.
[26] James Rumbaugh, Michael Blaha, William Pre
merlani, Eddy Frederick, and William Lorenson.
ObjectOriented Modeling and Design. Prentice
Hall, 1991.
[27] Daniel S. Weld and Johann DeKleer. Readings in
Qualitative Reasoning about Physical Systems.
Morgan Kaufmann, 1990.
[28] Lawrence E. Widman, Kenneth A. Loparo, and
Norman R. Nielsen. Artificial Intelligence, Sim
ulation and Modeling. John Wiley, 1989.
[29] Terry Winograd. Frame Representations and the
Declarative/Procedural Controversy. In Daniel
Bobrow and Allan Collins, editors, Representa
tion and Understanding. Academic Press, 1 I7.
[30] Bernard P. Zeigler. Theory of Modelling and
Simulation. John Wiley and Sons, 1976.
[31] Bernard P. Zeigler. DEVS Representation of Dy
namical Systems: EventBased Intelligent Con
trol. Proceedings of the IEEE, 77(1):72 80,
January 1989.
[32] Bernard P. Zeigler. Object Oriented Simulation
with Hierarchical, Modular Models: Intelligent
Agents and Endomorphic Systems. Academic
Press, 1990.
