Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: A Functional/declarative dichotomy for characterizing simulation models
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095105/00001
 Material Information
Title: A Functional/declarative dichotomy for characterizing simulation models
Alternate Title: Department of Computer and Information Science and Engineering Technical Report
Physical Description: Book
Language: English
Creator: Fishwick, Paul A.
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 1991
 Record Information
Bibliographic ID: UF00095105
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.

Downloads

This item has the following downloads:

199132 ( PDF )


Full Text









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 sub-disciplines 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 "event-oriented." 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







TR92-003 Computer and Information Sciences, University of Florida


MODEL CHARACTERISTICS
CONCEPT Non-executable

Model Z
Complexil DECLARATIVE FUNCTIONAL Homogeneous Nodes
in model graph
& Inter-node coupling

HETEROGENEOUS Heterogeneous Nodes
m model graph
& Inter-node coupling
MULTI-MODEL Inter-level 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 non-executable, 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, non-executable
models, we depart from the norm when introducing
how additional modelling techniques such as produc-
tion systems, track-based 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-







TR92-003 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 human-like 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 common-sense 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 real-time 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
electro-mechanical 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.







TR92-003 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 state-to-state 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 state-oriented 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 built-in 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:







TR92-003 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,Y|Y > 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, Y|X+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-(4-Y), 4), and AT =
(c) For J1 = B, (X, YIX+Y > 3AY
3) (3, Y-(3-X)), 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
(4-Y)/10. system dynamics are quite complex; this attests, pri-
> OAX < marily, to the power of production rules (with pattern
(4-Y)/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








TR92-003 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







TR92-003 Computer and Information Sciences, University of Florida


and each subcomponent has its own dynamics. The
declarative approach of a rule-based 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







TR92-003 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 box-structured 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. Prentice-Hall, Inc., Engle-
wood Cliffs, N.J., 1981.
[24] Elaine Rich and Kevin Knight. Artificial Intel-
ligence. McGraw-Hill, 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.
Object-Oriented 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: Event-Based 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.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs