Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Integrating continuous and discrete models with object oriented physical modeling
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095397/00001
 Material Information
Title: Integrating continuous and discrete models with object oriented physical modeling
Series Title: Department of Computer and Information Science and Engineering Technical Reports
Physical Description: Book
Language: English
Creator: Fishwick, Paul A.
Affiliation: University of Florida
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 1996
 Record Information
Bibliographic ID: UF00095397
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:

1996235 ( PDF )


Full Text








INTEGRATING CONTINUOUS AND DISCRETE MODELS WITH OBJECT ORIENTED
PHYSICAL MODELING


Paul A. 1 ,-!r- 1, !:
Dept. of Computer & Information Science and Engineering
University of Florida
Bldg. ('Si. Room 301
Gainesville, FL 32611


ABSTRACT

When we build simulation models and construct dy-
namical models for ,1!. -i 1 -1 in- we often do not
do so using a clear overall framework that organizes
our geometry, dynamics and models. How do geome-
try and dynamics intertwine to effect -- -I, i i change
over multiple abstraction levels? We present a method-
S1, _-, called object-oriented .,..,' r- modeling (OOPM),
which builds on the currently accepted computer sci-
ence approach in object-oriented program design. This
I |,. of modeling i11 i I a way of incorporating ge-
ometry and dynamics into general object-oriented de-
sign. Moreover, we present an approach to dynamical
modeling that mirrors !i i.r categories of computer
programming languages, thereby achieving a defini-
tion of -- -I. i, modeling that reinforces the relation
of model to program.

1 INTRODUCTION

Simulation is divided into three areas: 1) model de-
sign, 2) model execution, and 3) execution .r..... '
Modeling is the process of abstracting real world be-
havior into a more economical form for purposes of
experimentation and learning. Our chief interest is
in. I t !i 11i capturing and organizing the knowledge
necessary to simulate 1i1- -i, ,1 -I. in- both artifi-
cial and natural. Simulation requires that we have
a way of designing and executing models. Models
can represent geometric shapes of real objects or the
dynamics of those objects. The shape of an object
is captured by its geometry, which is used by com-
puter graphics to li-il the object. The dynamics
of an object allows us to view a computer anima-
tion of the object undergoing time-dependent change.
Our purpose is to specify a method for modeling a
1i- -i, ,1 -- -1. ii while claiming that our method pro-
vides benefits such as model and model component re-
use. We provide a way of organizing 1i1!. -i1 1 knowl-
edge and a iii. !L. .1..-_- for those wanting to model


- i-1 at i i !ii levels of detail. Our techniques
build on top of object-oriented design principles es-
poused in both computer science as well as computer
simulation. The method surfaces the importance of
an integrated object-process method where both ob-
jects and processes are made visible in model design.
We present a uniform method that extends previous
work by I* if ir,- how shape and dynamics are inte-
grated in the same framework, and by defining meth-
ods for modeling that permit an integration of exist-
ing modeling methods without recommending an all-
encompassing new modeling technique. In this sense,
the contribution is one where we devise a specific
model integration approach. Further work in a more
complete OOPM 1in !, 1.l .1..-- can be found in (1 i-
wick 1996a)'.

2 MOTIVATION AND BACKGROUND

The word model is a somewhat overloaded term and
can have 11ii i! meanings depending on context. We
proceed to define what we mean by the word model.
Models are devices used by scientists and engineers to
communicate with one another using a concise often
visual-representation of a i~'1 -i, 1 -- 1. i! Models
are visual high-level constructs that we use to com-
municate -- -1. 1, dynamics without the need for fre-
quent communication of low-level formalism, seman-
tics and computer code. In our ii. i!. l .1.. _- (1 i-! -
wick 1I',I ), a model is defined as one of the follow-
ing: 1) a graph consisting of nodes, arcs and labels,
2) a set of rules, or 3) a set of equations. Com-
puter code and programs are not considered to be
models since code semantics are specified at too low
a level. Likewise, formal methods (Padulo and Ar-
bib 1974; Zeigler 1989) associate the formal seman-
tics with models but do not focus on representing the
kind of high-level form needed for modeling. One of
our thrusts in this paper is to discourage readers from
thinking that to simulate, they need to choose a pro-
lhttp://www.cise.ufl.edu/~fishwick/tr/tr96-026.html









gramming language and then proceed directly to the
coding phase. Even the phrase "-.1, I-oriented" is
often defined as being ii. o iii. .L- with certain pro-
gramming languages such as C++, and so one ii' ,
be lead to begin I'l' '- I'!!i! using polymorphism,
virtual base classes and other artifacts, before the de-
sign is specified. \\ i !.,l I the proper scaffolding for
our models, in the form of a conceptual model, we
will produce disorganized pieces of code without a
good understanding and organization of the 1i1! -., 1,
process we wish to study. The act of coding in an
object-oriented language is not a substitute for doing
good design. As an example, C++ provides iii, i- ob-
ject oriented capabilities, but does not enforce object
oriented design. Norman (1988) points out the need
for good visual, conceptual models in general design
for improved user-interfaces to ,1!i -i' 1 instruments
and devices. The importance of design extends to all
scientific endeavors with a focus on models. Models
need to provide a map between the 1'1! -i. ,1 world and
what we wish to design and subsequently implement
either as a program or a 1,'1 -i. 1 construction.
Programs and formal specifications (Zeigler 1972;
Zeigler 1989; Praehofer 1991) are a vital ingredient
in the simulation process since, without these meth-
ods, modeling approaches lack precision and cohe-
sion. However, formal specifications should not take
the place of models since they serve two l!!. i. Ii pur-
poses. Specifications are needed to disambiguate the
semantics, at the lowest level, of what one is model-
ing. Models exist to allow humans to communicate
about the dynamics and geometry of real world ob-
jects. Our definition of modeling is described at a
level where models are translated into executable pro-
grams and formal specifications. I i-I!;- !. 1 and Zei-
gler (1992) demonstrated this translation using the
DEVS (Zeigler 1989) formalism for one partic. il I l- I "
of visual multimodel (finite state machine model con-
trolling a set of constraint models). For other I- i" -
of multimodels, one can devise additional formalisms
(Praehofer 1991). Object-oriented ii. !1...L.1..-- in
simulation has a long history, as with the introduction
of the Simula language (Birtwistle 1979), which can
be considered one of the pioneering ways in which
simulation applied itself to "...1-. I-oriented think-
ing." Simula provided i ii ,- of the basic primitives
for class construction and object oriented principles
but was not accompanied by a visually-oriented en-
gineering approach to model building that is found
in more recent texts (Rumbaugh et al. 1991; Booch
1991; Graham 1991). As we shall see in model de-
sign, the visual orientation is critical since it rep-
resents the way most scientists and engineers rea-
son about 1,!- -1. i1 problems and, therefore, must be
made explicit in modeling. Other more recent simula-


tion thrusts in the object-oriented arena include SCS
conferences (Roberts, Beaumariage, Herring, and Wal-
lace !' 'I .) as well as numerous \\ !!!. i Simulation
Conference sessions over the past ten years. Also,
various simulation groups have adopted the general
object-oriented perspective (Rothenberg 1989; Zei-
gler 1990; Balci and Nance 1987).
We specify two contributions: 1) a comprehensive
!in. !,,l 1., .,_ for constructing 1!- -i1 ,1 objects that
encapsulate both geometric and dynamical models,
and 2) a new I ,'...!i..! for dynamic models. The
motivation for the first contribution is that there cur-
rently exists no method that uses object-oriented de-
sign and specifies an enhancement of this design to
accommodate static and dynamic models. We have
taken the existing visual object-oriented design appr-
oaches reflected in texts such as Rumbaugh (1991)
and Booch (Booch 1990) and extended these appr-
oaches.

3 SCENARIO

A general scenario should be defined so we can de-
velop the concepts of 1I 1! -i, 11- -1. -. 1 object-oriented
design. We will create a simple example and then pro-
vide a table that illustrates how this example can be
seen for a wide i, -- of disciplines. The reason for
this choice of scenario is that it captures the essence of
1.1- -i- 11 modeling: the application of dynamics and
geometry using particles and fields. Even in the do-
main of sub-atomic particles, the object orientation
is relevant since particles and fields integrate to form
objects via Schroedinger's wave equation. The robot
serves the role of a particle and the space (or land-
scape) serves the role of space. Together, they pro-
vide for a comprehensive model. Consider a 2D space
s that is partitioned using either a quadtree or i ,
A set of mobile robots move around s, undergoing
change, as well as changing attributes of s. Fig. 1
illustrates s and a sample robot r. In the remain-
der of the paper, we will refer to Fig. 1 using classes,
objects, attributes and methods. A robot or set of
robots move around space s, some -1 i 1 within the
confines of a particular partition of s, such as si,j for
i,j E {1,...,8}. Moreover, certain attributes of s
i i, change. For example, there !!i be water in s
or a particular ,I. i!!-i of matter assigned to s. Our
robots will be unusual in that they are capable of
changing shape over time if the dynamics demand this
of them. Before we embark on a discussion of object-
oriented 1.1! -i. 1 design for robots within spaces, we
present Table 1 to illustrate how, through mappings
from one discipline to another, different areas fit into
this general scenario scheme.











Table 1: A sample set of applications using a particle-field metaphor.

Application Particle I1 I1.
Cybernetics robot space
(intelligent agents) (room,factory floor,
terrain)
Military plane, squadron air space
(Air Force)
F,.'.._1 individuals, species landscape
Materials particles,molecules fluid
(air, liquid)
Computer chip, module N/A
Engineering
Quantum wave function wave function
Mechanics
SI I.. ..1.. hurricane, tornado atmosphere
(finite volumes)


1 8 end effector sensor
1 _ _ _ power arm
S point

upper arm

foundation

8 # sI
front back
wheels wheels
S r

1 ,i, 1: Scenario for generic object behavior.


4 CONCEPTII'AL MODELING

The first phase is constructing a conceptual model
of the I'1! -i. 1 scenario. To build such a model, we
must construct a class graph with relations among the
classes. Furthermore, we must identify attributes and
methods in those classes. A class is a I" Our treat-
ment of a class is as if it served as a i .... !:.- cutter."
A cookie cutter (class) operates over a sheet of dough
to create cookies ( .1,i. I -' We might create several
1- i" of robots: W ,!!.,_ I- n,'i ,i,'ll. 1 .. .-VI. Each
of these are classes and they are sub-classes of robot
since all of them are I of robots. This particu-
lar relation is called generalization. Another kind of
useful relation is called .,,,,,,i' ..,. since it involves
a relation among classes where there is a -"p I of"
relationship. For example, a particular robot i!! be
composed of (or -. ,1. ,I I from) wheels, an arm and
a camera. The base, arm and camera are part of the


Cl C2 C3 Cl C2 C3


Generahzahon
Hierarchy


Aggregation
Hierarchy


Dual Relatonship
Hierarchy


Note
C1= cardinalty constraint such as "-4" or "<2"

Ii ,t. 2: i i 1 It .- of a class with three relations.


robot: the robot is an aggregate of the base, arm and
camera. Fig. 2 shows how we illustrate both of these
relations: generalization with a circle and ;, i- _. i
with a square. We also permit an ;,,! 1- -1 to specify
;, !i given relation as both ;, i 11,i i. 1 and generaliza-
tion. This is delineated with a circle inside a square.
The C specified in Fig. 2 can specify cardinality for
a class. In general, without such a specification, it is
assumed that a class can be composed of; 1, number
of objects of the sub-class. However, let's that we
create a class Room which will always have four walls,
then we can specify = 4 on the ;i i.,! relation
arc to illustrate this constraint. \\ iil! tii this explicit
constraint, a Room can be composed of i,' number
of walls. This approach is consistent with several ex-
isting 00 approaches (Rumbaugh et al. 1991; Hill
1996) to ; i__- 11 i, specification.
While we are on the -,ii.. Il of classes, we define
an object to be an instance of a class. A particular
wheel is an instance of the class called Wheel. A
class is a set of objects, which are related through
the class definition. A class is composed of its name,
a set of attributes and a set of methods. A _ i- i.11,
among classes requires some clarification. If The set









of Wheels for a robot is. i _- -. .11 I from the classes
FrontW and BackW, there 11i be ; ,i number of
front wheels and ; ii number of back wheels. The
S 1 ;, just shows the class;-_ _ 11r. and not
the object i ,. 11 i, The specific number of wheels
is something that is changed as we create instances of
the two classes. An actual object called wheels can be
created from class Wheels and then we can create two
objects from FrontW and two from BackW. We can
even create a containment model (or data structure)
which we locate as an attribute value within wheels
that shows the composition of this particular wheels
object.
A key part of conceptual modeling is i l i lif r; -
the classes. For the most part, this procedure is ill-
defined but some rules and approaches do exist (1 -I! -
wick 1995; Graham 1991) to help in the model engi-
neering process. Natural language provides one basis
on which to base choices for classes, attributes and
methods. The following are heuristics to aid in the
creation of the conceptual model from a textual de-
scription of a 11!, -i; 1 scenario:

Make nouns classes or instances of a class.

Use adjectives to make class attributes, sub-
classes or instances.

Make transitive verbs methods which respond to
inputs.

Use intransitive verbs to Y"'. f., attributes.

In the ,1!l -1; 1 sciences and !,I;|.. ,i we use
models to describe the shape of objects as well as their
behavior. We call the combination of attributes and
methods structure. The two I- ,. of relations among
classes, generalization and *,,.,, ,,,"' are very pop-
ular and are frequently used in object-oriented design.
The reason for their 11I i I- and popularity is that they
involve the implicit act of passing structure from one
class to another. SInt Iiti,- passing is powerful and
enables us to fragment the world into classes, while
designing common structure through ;, 1i. .1 and
generalization relations.
The passing of structure for generalization is top
to bottom, of a hierarchy of classes related via gen-
eralization, and is frequently known as inheritance.
Let's consider an orange. An Orange class inherits
certain attributes and methods (i.e., structure) from
the Fruit class since an orange is a kind of fruit. A
walking robot is a I I" of general robot, and so inher-
its structure from the general robot. The uppermost
classes in a generalization hierarchy are base classes
and the child classes are derived classes from the par-
ticular base class.


We have discussed generalization and its associ-
ated structure-passing inheritance' i '.l. 1~ but there
is another key kind of relation: ;., .Ii Aggrega-
tion I i. the benefit of structure passing also, but
the structure passing in ;, 11. ', is bottom-up in-
stead of top-down. A class that is an ;.__. i ;..,,
of classes underneath it captures the structure of all
of its children. A robot contains all attributes and
methods associated with each of its sub-components,
such as links, cameras and the behaviors of those sub-
components. As we use inheritance for generaliza-
tion, we will use composition for ;._ _i-. i_ .1i, i -
ture passing is done, therefore, through inheritance
and composition. For our discussion of generalization
and ;, 11r, we assume that structure passing is
a logical operation; however, it ii ,- not be directly
implemented in a specific programming language or
implementation. For example, a large 106 square cell
space is an aggregate of 106 individual cells; an im-
plementation i ii choose not to cause the explicit
passing of structure from children (i.e., cell) to par-
ent (i.e., space), nevertheless, the structure passing is
a logical consequence of ;.__- i G 1i and is logically
present in our design, if not in our implementation.
Inheritance and composition are further defined
as follows:

Inheritance (or generalization) is the relational
property of a generalization hierarchy. Compo-
sition (or ,--_ -_ 11i r. i is the relational property
of an ; _ .11 r hierarchy.

To differentiate between layers in a hierarchy we
use the terms "- I!! 1 and -"1' !I A parent is
always above a child regardless of the relation
I" Therefore a child class in generalization
inherits from its parent, but a parent class ag-
gregates from its children.

The words "- [.i 1' and "1. are relative to
the l- ". of relation. Base classes in a gener-
alization tree are at the top with lower-level
classes deriving structure. For; -- i., it is
the opposite, with the base classes being at the
leaves of the tree. SInL IiLi.- passing for both
relations is derived from "I.. to "I. ,. I '
classes.

The only classes that can be used for construct-
ing objects are the leaf classes of a generaliza-
tion hierarchy. Internal tree nodes are used to
hold class structure but are not used for object
construction.

Inheritance occurs when a derived leaf class in
a generalization class hierarchy is used to con-
struct or create an object. The object "il ,!. i-










i all attributes and methods from its parent
(or parents in multiple inheritance).

Composition occurs when i,!! class in an ag-
gregation class hierarchy is used to construct or
create an object. The object passes all struc-
ture assigned to it upward to the parent (or
parents) in multiple composition). The deriva-
tion of structure moves from the base classes.

A --i i1,'i, and containment are two '!tilI i. but
related concepts. A_ _- -iri. involves composition,
which means that a class is composed of sub-classes.
A glass of marbles will contain marbles, but the glass
is not composed of marbles and so a Marble class, in
an ;. i i. ,! sense, is not a sub-class of Glass un-
less one redefines the meaning of Glass to encompass
not only the i,1! -i1 1 structure of a glass, but also
of i i- ll!'_ within the "- ..p.-" or i- ,ii!! i ii of
the glass.
Generalization and ;,i-. ,l;i are the key rela-
tions used in building a conceptual model, but they
are not the only I- ". of relations. If our 1i.1 -i;, ,
scenario was such that all robots were attached to
wooden boards, then one could form a relation arc be-
tween the class robot and the class board. However,
there are sometimes better mechanisms for handling
such cases. For the robot and the board, one can
form an aggregate class called Robot-env which ag-
gregates both board and robot classes. Some of these
other class relations 1 !! or i!! not involve structure
passing, but generalization and ;, i - 11;i i represent
the power of a transitive stucture-passing relation in-
volving ;,!! number of hierarchical levels. In ;,!i
event, by allowing arbitrary relations among classes,
we generalize conceptual models to have similar capa-
bilities in representation to that of semantic networks
and certain schemata in databases. That is, one can
use logical inference and t,. ii!- on the conceptual
model in addition to using it only for structure pass-
ing. Also, the conceptual model need not be static.
The conceptual model as it is originally defined rep-
resents a 1!l -i, 11 -- -1. i! at an initial time instant.
New classes and relations 1 !! be added over time to
permit a dynamically changing ,1! -;i ,1 environment.
Fig. 2 illustrates generalization (0) and aggrega-
tion (0) relations. It is not necessary to group all rela-
tions into one graph or 1i' i 1i, 1 iii 1!I!J,,-. graphs or
hierarchies are possible. Fig. 1 provides us with the
base classes for Fig. 3. The downward and upward
block arrows in Fig. 3 illustrates the respective direc-
tions of structure passing for inheritance and compo-
sition.
Inheritance and :, ii,, have rules that they
use to perform the movement of structure within a
tree. For inheritance, methods and attributes are


Thing

Agent Fixed Space

O b e t
Human Robot Animal Rect Hex
Arm Sensor

Fixed Mobile Lower i. ,I
Robot Robot Trophic I, i Camera Sonar


Arm Bs Wheels
F12 1 =1 it 1 [ =2h
Joit Upper Lower End Motor Computer FrontW BackW
Arm Arm Effector

I i,,.- 3: Phase 1, ,. p 1: Identify classes and rela-
tions.


copied from the tree root to the tree leaves except for
when one overrides an inherited attribute or method.
However, we need to be explicit about our "-i!, i i-
tance I,11. since copies can be made, potentially, not
only from the root of the generalization tree, or from
the immediate parent of a class, but also from ;,i,
class which lay in-between the root and leaf class.
An attribute type within class Agent can be set to
".I to- I I '. While the classes Human and Animal au-
tomatically inherit this attribute from Agent, Robot
overrides this by setting type to I IitI, i I Overrid-
ing method and attributes permits a kind of hetero-
_. 11. in the derived classes so that they need not all
be perfect copies of the base class. In addition to over-
riding, some structure from the base class 11 i'- not be
available for '. -1 i 1 to derived classes. A default in-
heritance rule is one where a derived class inherits
structure through '."." from its parent class.
For ;,__-. i.,! i, we have a more complex situa-
tion where an ;, _. -i. i, procedure must be speci-
fied for all attributes and methods in the base classes.
An example of the need for such procedures is when
two base-class methods or attributes are identical in
name. The ;,_ __ i-, I i. question is framed as "Given
a number of base classes, how do we glue the base
class attributes and methods to create attributes and
methods in the aggregate class?" There is a con-
flict and a resolution method is required. Consider
attribute contains in Arm, Base and Wheels. The
contains attribute points to a data structure of what
is contained within an object. Through composition,
Arm obtains all three of these contains structures but
what is Arm to do with them since they are all of the
same attribute name? A logical ;:-, -. ,i ,! proce-
dure here is to that all sub-classes of Arm with a
contains attribute are grouped together into a record
or ;i,! which is then placed in Arm. However, this
sort of -. .I i! is not always appropriate. If the










sub-classes contain an attribute count which specifies
how i i- objects there are of this class, then the cor-
rect ;,i_-_ I- ,11 rule for count within Arm involves
a sum of all count attributes in the sub-classes of
Arm. In;,_ i,,K some sort of "- -, I ,11 Ii 11i
is always necessary. Implicitly, one could define that
attributes of different names simply agglomerate into
aggregate objects in a set-union fashion. However,
there are 11i 1 i instances where this is not so. The
count attribute is just one example. Other examples
include ;,-- i~ 11 r i into a matrix or ; ii and aggre-
gation via model component ". ., pli,"!" composing a
dynamic model of sub-object methods. Rules can be
stored in their respective classes. We make no at-
tempt to formalize the rule structure-only to state
that some code or rules should be available within a
class to handle all ;,i ,,11. t1- that occur. A default
;,__ i, i, rule is one where a derived class aggre-
gates structure through set union of the child classes.
That is-they just collect structure together without
resolving conflicts, merging structure through sum-
mation or integration, or performing concatenation
of structure.
As to how we might refer to populations or groups
versus individuals, we consider the motor example.
The set of motors can be called motor which points
to a data structure *,, i motor objects, while an
individual motor requires an index such as motor[2].
When an object is created that uses the same root
name for an object that already exists, such as when
one created object motor[2] after having created mo-
tor, then the a hierarchy is assumed and ;, i- -i, , i
occurs as a result. This mechanism allows one to
attach recursive, hierarchical properties to ;,i! class
in the conceptual model without explicitly specify-
ing these properties at the time of conceptual model
formation. Instead, this sort of multi-level hierar-
chy is defined as a static model. An example of this
can be seen with the class Rect in Fig. 3. This class
can be used to create a rectangular space hierarchy
of ;,!! dimension. Let's first create a space object
called cell by defining Rect cell. If we wish to struc-
ture this space into a quadtree, for instance, we can
then create four new objects cell[0], cell[1], cell[2] and
cell[3]. Since we used the same name cell, there is an
automatic -. _- ,. i, .1 relation with cell composed of
cell[0], cell[l], cell[2] and cell[3]. Specifically, aggrega-
tion rules come into 1i1 as previously described. The
actual quadtree would be stored as a static model of
cell. The explicit creation of ,-_!. i- -i.i hierarchies
within the conceptual model is dictated by a hetero-
geneous ; -. 11 i, relation. If a robot arm consists
of exactly two links, which are 1!tl, !i I in nature,
then this ;- r i. relation belongs in the concep-
tual model. However, the potentially infinite recur-


Class Name

SVariables
Attributes Variabe
~ Static Models


OOPM
extension


Methods Code
Dynamic Models


1 i ,I.! 4: 1 ,i I !.. of a ('I -


sion of spatial decomposition suggests a homogeneous
aggregrate relation, and is relegated to a static model
stored within a "-1 ... object."
OOPM specifies that an attribute is one of two
SI" variable or static model. Likewise, a method of
one of two l- I code or .....', model. A method
can be of a functional (representing a function) or
constraint (representing a relation) nature. Once the
conceptual model has been constructed, we identify
the attributes and methods for each class. An at-
tribute is a variable, whose value is one of the com-
mon data I ". or a static model. A method can be
code, whose form depends on the programming lan-
guage, or a ., ..... i', model. The structure of a class
is seen in Fig. 4. Variables and code are described in
00 languages such as C++ (Stii.,1 -1i 1991). We
define a static model as a graph of objects and a dy-
namic model as a graph of attributes and methods.
The model I- i" of interest here are dynamic. How-
ever, the concept of static model complements the
concept of dynamic model: methods operate on at-
tributes to effect change in an object. Dynamic mod-
els operate on static models and variable attributes
to effect change. We will use the following notation
in discussing object-oriented terms. When we speak
of a class, we capitalize the first letter, as in Robot
or Arm. An object is lower case. An attribute that
is a variable is lower case, whereas an attribute that
is a static model is upper case for the first letter. A
similar convention is followed for methods: a code
method uses lower case with a parentheses "()" as a
-ii -., a dynamic model method is the same but with
a capitalized first letter. ('I --. are separated from
objects with a double colon "::" whereas objects are
separated from attributes and methods using a period
"." This convention is similar to the C++ language
and is a convenience when communicating conceptual
models textually. All classes, objects, attributes, and
methods will use an italics font to .t! l, i i II 1- them
from surrounding text.
Fig. 5 displays another robot-oriented conceptual
model to illustrate some of the points we've made
about generalization and abstraction. We use the fol-
lowing new ;, .!- i-i DigitalTech for -"[ 1!,I tech-


/I









5 CONCLUSIONS


I ,t i.- 5: Generic generalization and., i I sce-
nario.


i .1. ," DSP( Il for ", lii I signal processing chip,"
and Mux for multiplexer. For each relation, we need
to have a procedure. We'll proceed from left to right.

Relation 1 (.\-_ G.1;,'

1. By default, Base will aggregate all meth-
ods and attributes using the set operation
union (U) unless otherwise specified. We'll
use this default to pass up all attributes of
Motor and Computer except for id.
2. Base.id is formed by Motor.id and Com-
puter.id by concatenating them in a vector
[Base.id,Motor.id].

Relation 2 (Generalization):

1. By default, Computer and DSP( h!p in-
herit all structure from DigitalTech through
*.'I' i,- We'll adopt the default on this
one.

Relation 3 (Dual):

1. The default structure passing for this is the
same as for both; _-. .1 and general-
ization. We are stating that a CircuitCard
serves as a composition of DSP( !up and
Mux as well as stating that DSP( h!u and
Mux are !,i", *of CircuitCard.
2. For;, _i. .11_ we specify model Circuit)
as being defined by a functional coupling
of dsp() and Mux).
3. For generalization, we use the default for
inheriting maxvoltage, but override the
inheritance for busconnect since the bus
connection is an attribute of the circuit
card and not relevant to DSP( 1!,i or Mux.

We've seen that generalization and ;~, _- i. ,i, pro-
vide us with power for structure passing, but that we
require both default procedures as well as special pro-
cedures which either limit the structure passing in a
particular way or accurately define it.


To build simple -1. !1- we 1i sometimes get away
without using a model design. In such a case, we
1 i sketch a few formulae and proceed directly to the
coding phase. However, with the increasing speed of
personal computers, we are in a period of increased
development for model design that might best be cap-
tured by the word il I ,.i Ii, As scientists and
engineers, we have our own individual static and dy-
namic models for our part of the world. But this
this not enough when we want to integrate models
together. Suddenly, we find ourselves overwhelmed
with the sheer size of model I- 1, and frequently
some 1i not have model l- I" but have only coded
their simulations. To get a handle on this situation,
we need a blueprint as if we were going to perform this
integration as a metaphor to building a house. \\ il !-
out a blueprint, the electrician and carpenter are at
odds as to how to interact. They each construct their
own complex parts and one only hopes that the re-
sulting glued-together construction will function as a
whole. The blueprint helps them to work together.
Our iii. tI, .1, .1,.- for object-oriented ,1! -1; ,1 design
is like the blueprint, permitting models of l!!t. !i< I
SI" to fit together so that more complex and larger
*-1 in'- can be studied. These larger -- -1. It require
an interdisciplinary approach to model design and so
we must agree on a basic language for blueprints.
Our immediate goals are to apply this general
i 1., ,l', ,*1- to various technical areas including the
simulation of multi-phase particle flows in the Univer-
-i-I of Florida Engineering Research Center for Par-
ticle Science and T !ii, .1,.- and an integrated mod-
eling environment for -r11- 1, the effects of changes
in i1- ,li.,1.- to the Everglades ..-- -I. itl managed
by the South Florida Water Management District.
For decision making in the military, iii i- levels of
command and control exist, and the iit !, .,1..l -
provides a consistent approach in using models for
planning and mission ;,ii 1- -i- both "-1. 1..i.- ;, III..
and during Itl. i action review." All of these sys-
tems have a characteristic in common even though
they iii appear at first quite .1!l-, i, I I they involve
the modeling of highly complex, multi-level environ-
ments, often with individual code and models devel-
oped by [l!!l i. i!I people from lt!!. I, I disciplines.
MOOSE development is it!,il i- and C++ code
and GUI interfaces are being constructed to make
it possible for i,1- - to use our -- -. iit A longer
range goal is to allow our models to be distributed
over the Internet (or over processors for a parallel
machine). The object oriented concepts of re-use and
encapsulation will help greatly in this endeavor. Also,
we are i 11_ to create a bridge between the use of









modeling in simulation and general purpose program-
ming. As various authors have noted (Budd 1991;
I i-1 !- I !: '1.11,i1,J if one liberally applies the concept
of metaphor to software. i,. i -_ the Litl i. il. -
between software and -1. i!1- engineering begin to
dwindle to the point where software can be consid-
ered a modeling process.

ACKNOWLEDGMENTS

I would like to acknowledge the graduate students of
the MOOSE team for their individual efforts in mak-
ing MOOSE a i. ,li- Robert Cubert, Tolga Gok-
tekin, Gyooseok Kim, Jin Joo Lee, Kangsun Lee,
and Brian T`.iii 1- 1:. We would like to thank the
following funding sources that have contributed to-
wards our study of modeling and implementation of
a multimodeling simulation environment for analy-
sis and planning: (1) Rome Laboratory, (;i!!!-- Air
Force Base, New York under contract I ;1i11.i'-95-C-
0267 and grant 1 ;1i.1i .-95-1-0031; (2) Department
of the Interior under grant 14-45-0009-1544-154 and
the (3) National Science Foundation Engineering Re-
search Center (i.i1 1) in Particle Science and Tech-
!i..1 .- at the University of Florida (with Industrial
Partners of the 1. 1' ) under grant EEC-94-02989.

REFERENCES

Balci, O. and R. E. Nance. 1987. Simulation Model
Development Environments: A Research Pro-
SI" Journal of the Operational Research So-
(', l, 38(8), 753 -763.
Birtwistle, G. M. 1979. Discrete Event Modelling
on ,I.I[ULA. Macmillan.
Booch, G. 1990. On the Concepts of Object-
Oriented Design. In P. A. Ng and R. T. Yeh
(Eds.), Modern S! ....... .' F.,'', Chap-
ter 6, pp. 165 204. Van Nostrand Reinhold.
Booch, G. 1991. Object Oriented Design. D. !ni ,!i!i
Cummings.
Budd, T. 1991. An Introduction to Object Oriented
Programming. Addison-W. -1.
I i-l,- 1.:, P. A. 1995. Simulation Model Design and
Execution: Building Digital Worlds. Prentice
Hall.
I i-l,- I, !:, P. A. 1996a. Extending object oriented
design for 1i1i -i1 1 modeling. AC If 1,........ -
tions on Modeling and Computer Simulation.
Submitted for review.
1 -I;-l !:1 P. A. !''.i, Toward a Convergence
of Systems and Software Engineering. IEEE
l.'.. ..... ....- on l.,!. .... M an and Cl!, ., **-
ics. Submitted for review.


I l- i. !I P. A. and B. P. Zeigler. 1992. A Multi-
model ll!.,.1.,1.,_ for Qualitative Model En-
gineering. .I1 f I ..-...-.. : ....- on Modeling and
Computer Simulation 2(1), 52-81.
Graham, I. 1991. Object Oriented Methods. Addi-
son WT. -1.
Hill, D. R. C. 1996. Object-Oriented .1...J.,,', and
Simulation. Addison-W. -1.
Norman, D. A. 1988. 1!., Design of F,,,,,I,,,,
lb. ,.-: New York: C .1it. i. D.,.il.l. .1
Padulo, L. and M. A. Arbib. 1974. ,, '. I ..... b,
A U. "C; 1 .I ~~. Space Approach to Continuous
and Discrete S.,,,! ... Philadelphia, PA: W. B.
Saunders.
Praehofer, H. 1991. Systems Theoretic For-
malisms for Combined Discrete-Continuous
System Simulation. International Journal of
General S.,,,. -.. 19(3), 219-240.
Roberts, C. A., T. Beaumariage, C. Herring, and
J. Wallace. 1995. Object Oriented Simulation.
Society for Computer Simulation International.
Rothenberg, J. 1989. Object-Oriented Simulation:
Where do we go from here? Technical report,
RAND Corporation.
Rumbaugh, J., M. Blaha, W. Premerlani, E. Fred-
erick, and W. Lorenson. 1991. Object-Oriented
Modeling and Design. Prentice Hall.
Si,.,,I-1 iq B. 1991. 1!., C++ Programming Lan-
guage (2 ed.). Addison WT. -1.
Zeigler, B. P. 1972. Towards a Formal Theory of
Modelling and Simulation: ii,, Ii Preserv-
ing Morphisms. Journal of the Association for
Computing Machinery 19(4), 742 764.
Zeigler, B. P. 1989. DEVS Representation of Dy-
namical Systems: Event-Based Intelligent Con-
trol. Proceedings of the IEEE 77(1), 72 80.
Zeigler, B. P. 1990. Object Oriented Simulation
with Hierarchical, Modular Models: Intelligent
Agents and Endomorphic S,,. "i... Academic
Press.

BIOGRAPHY

Paul A. I i-l!- i. !: is an Associate Professor in the De-
partment of Computer and Information Science and
Engineering at the University of Florida. He received
the PhD in Computer and Information Science from
the U!!i i -i- of P. !- i, in 1986. He also has
six years of industrial/government production and re-
search experience. A complete ',* i 1 i,1 and resume
can be found at Dr. i i-l!- !: WWW home page:
http://www.cise.ufl.edu/f ishwick.




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