MOOSE: an object-oriented multimodeling and simulation
Robert '.1 Cubert and Paul A. Fi-l-i. 1:
Department of Computer & Information Science and Engineering
CSE Room 301
University of Florida
Gainesville, FL 32611-6120
MOOSE (. ,I ,IIl .. I Object Oriented Simulation Environment) is an application framework for modeling and
simulation, under development at University of Florida, based on Object Oriented PLi -; A1 Modeling (OOPM).
OOPM extends object-oriented program design with visualization and a definition of -- -1I 11, modeling that reinforces
the relation of model to program. OOPM is a natural mechanism for modeling large-scale -- -I. I,- and facilitates
effective integration of disparate pieces of code into one simulation. Components of MOOSE are Human Computer
Interface (HCI), Library, and Back End. HCI interacts with model author via graphical user interface (GUI) which
captures model design, controls model execution, and provides output visualization. Library has a model repository
and object store facilitating collaborative and distributed model definitions, and managing object persistence. The
Back End automatically converts a model definition to a complete simulation program in some Translator Target
Language (TTL), presently C++, then compiles and links the program it wrote, adding runtime support, and
creating an executable program which runs under control of the HCI to provide model execution. Dynamic model
SI," include I iii.- 1 1 .- Machine, Functional Block Model, Equational Constraint model, and Rule-based Model;
alternatively, model authors ii ,- create their own C++ code methods; model I- i. iii be freely combined through
multimodeling, which glues together models of same or different I- ". produced during model refinement, reflecting
various abstraction perspectives, to ;,li I -1 model 1 1. li during development and during model execution. Ui I1. '! i
multimodeling is "i;!. !: as fundamental object. Every model is built from Blocks, expressed in a Modeling Assembly
Keywords: Simulation, Multimodel, Object-Oriented Modeling, Model Abstraction, Object Oriented P1, -;, 1
Modeling, Visualization, Application Framework
MOOSE is an ,, !-.i! i! for ". lii! i11l. I Object Oriented Simulation I.! ii, i,!!. I a modeling and simulation en-
abling tool under development at University of Florida. MOOSE is an implementation of OOPM (Object Oriented
Pl- -;i ,1 .Il. 1!i,,1,1 an approach to modeling and simulation which promises not only to tightly couple a model's
human author into the evolving modeling and simulation process through an intuitive HCI (human computer in-
terface), but also to help a model author to perform ;,!- or all of the following: (1) to think clearly about, to
better understand, or to elucidate a model; (2) to participate in a collaborative modeling effort; (3) to repeatedly
and painlessly refine a model as required, in order to achieve adequate i;l. li- at minimal development cost; (4) to
painlessly build large models out of existing working smaller models; (5) to start from a conceptual model which is
intuitively clear to domain experts, and to unambiguously and automatically convert this to a simulation program;
(6) to create or change a simulation program without being a programmer; (7) to perform simulation model execution
and to present simulation results in a meaningful way so as to facilitate the other objectives above.
In some cases model design, without model execution, -ithI. to achieve the model author's objectives, which ii i,
be to learn about or better understand a phenomenon or -i. ,i or to communicate about such a -- -I. i with one's
colleagues. This purpose is per se justification for the development of MOOS1. But usually a model author wishes
not only to design a model but also to construct a simulation program to perform model execution, for reasons which
include : (1) to empirically validate the model based on observed behavior; (2) to select or ;,liit-1 various parameters
and values and observe their effect; (3) to measure performance; (4) to gauge model ;,1. 1i- and assess its ;,1l. ,1,
In prevalent practice, a model author makes what is known as a conceptual model, often similar to a -"I :I, I 1....
pl.i in. with annotations, and uses this model to describe to one or more programmers detailed requirements for
a simulation program to be written, based on the conceptual model. Programmers then write a program, but there
is not -..... 'I.... a relation between the conceptual model and the program .., .... .... il, produced. MOOSE offers to
improve this situation: MOOSE assists the model author with constructing the conceptual model, and then builds
a simulation program in an unambiguous way from the conceptual model. MOOSE thus provides a mapping from
conceptual model to simulation program. Advantages include: (1) built-in model validation2; (2) partial automation
of the development process, allowing model authors and programmers to focus on the .Lit i [il1, rather than on the
tedious; (3) easier accommodation to change, leading to a view of change as acceptable instead of as a threat; (4)
reducing the response time associated with -I. i development, allowing the model author to effectively drive the
The amount of detail in a model reflects the model author's abstraction perspective.3 Refinement to greater detail is
used to obtain model ~1l. li that is adequate in the eyes of the model author, from a given abstraction perspective,4
and with certain objectives for the model or simulation to meet.5 MOOSE addresses this area with I... ,i' ......l, Ir.,;
an approach which glues together models of the same or lt. i. i I I I- ,. produced during the ;, 11 r i; of model
refinement, and reflecting various abstraction perspectives.6 Refinement can be ;,,liP-l ,1J1.- during model execution
as well as during model design. The pieces that are put together to form a model, such as described above, are
I.,,.... .. ', models. Dynamic model I I" supported include I !!i,..- i I.. Machine (I S. !), Functional Block Model
(FBM), Equational Constraint Model (i., N), and Rule-based Model (: ;. !); alternatively, users i!! create their
own C++ -" i., ri.. l. 1I ; model I- Hi i- be freely combined. The dynamic model I- I implemented so far form
a popular collection of approaches used in simulation.7 Additional dynamic model I- I are certainly in order and
will likely be added to the MOOSE repertoire.
Reuse of one's own previous work, as well as by one model author of the work of others, is encouraged by ;,- 1 i.;l-
of model repositories. These form a resource of growing value as MOOSE matures. For example, the "lI.!I.!,
; 1. i model,7 is an 1 S., I multimodel, part of which is shown in Fig. 6. Later, we implemented a model of Robert
Fulton's steamship,8 whose 1 i;.l appears in Fig. 5. When the Fulton model was built, the boiling water model's
Pot re-emerged as the Boiler of the steamship. Yet, an application framework is more than just a class library. In
an application framework, classes from the library are related in such a way that a class is not used in isolation but
within a design encouraged and supported by the framework. The MOOSE Model Repository (MMR) is aptly named
because it is not just a class library; as a model repository, it stores not only a collection of classes available for reuse,
but also the design which relates those classes as to how they 1i1 i together within the geometry and dynamics of a
particular model. This enables support for one of Booch's five attributes of a complex -I. i!, (p.13): "A complex
- -I i that works is invariably found to have evolved from a simpler -- -I. ii that worked .... A complex -- -l. i,
designed from scratch never works and cannot be patched up to make it work.". Using MMR, model authors can
start from some piece of their overall -- i, that happens to appeal to them intuitively. When several such pieces
are working, they i!! be combined into a more-complex ( .!1. J i -- -I' i.t
Components of MOOSE fall into three groups: Human Computer Interface (HCI), Library, and Back End. The
HCI is comprised of two components: Modeler and Scenario. Modeler interacts with the human model author via
graphical user interface (GUI) to construct the model. In simulation parlance, this is model design. Modeler relies
on the Library (discussed below) to store model definitions. Scenario is a visualization enabler !!!.l-' ii;- a GUI.
Scenario activates and initializes simulation model execution (which we call Engine) at the behest of user (who
i i, or i!! not be the original model author). Scenario maintains synchronous interaction with Engine, 1li-1-1 i;,l
Engine output in a form meaningful to user, optionally allowing user to interact with Engine, including ri. .li ; it -
simulation parameters and changing the rate of simulation progress. The Back End has two components: Translator
and Engine. I ../ ....i.. is a bridge between model design and model execution: Translator reads from the Library
a language-neutral model definition produced by Modeler, and emits a complete computer program for the model,
in Translator Target Language (TTL). Presently MOOSE TTL is C++; potentially, TTL can be Java or another
language. This simulation program emitted by Translator is called Engine. Its source language is TTL, presently
C++. Once compiled and linked with runtime support, the Engine executable program is activated under control
of Scenario to perform model execution. The Library has two components: MOOSE Model Repository (MMR) and
MOOSE Object ..... (.11OS). MOS holds object data and I. 11 holds object meta-data. I. 11 keeps track of
models as they are being built. I I., II1 servers provide a database management -I. i (Dl;., IS) for model definitions.
SI. 11:I clients work with Modeler and Translator to define and use model definitions. Models and model components
created by other model authors (or the same model author previously) are available for browsing, inclusion, and/or
reuse. Base classes such as sets for modeling collections and popular geometries for spatial models are available
to the model author. An 1. 11; client can simultaneously maintain conversations with several -1. 11 servers, each
on a t!. 1I i machine, which permits model definitions to be distributed. An -I .11 Server can simultaneously
maintain conversations with several 1. 11; clients, on the same or different hosts, which permits collaboration on
model development. MOS does for objects much of what I 1. 11: does for models. MOS works with Engine and
Scenario, in similar fashion to the way I1., I'1 works with Modeler and Translator. MOS manages object persistence.
Although the architecture permits MOS to be capable of distributed operation, just like MMR, this is not our present
focus in MOOSi. thus, MOS operates in support of model execution on a single host only at this time.
There are two kinds of distributed operation to consider: one is where model definitions are distributed, with some
classes defined here, others there; the second is where model execution proceeds as a distributed simulation, executing
simultaneously on a number of hosts, with one object instantiated here, another there. The MOOSE architecture
supports both kinds of distributed operation. The present implementation supports distributing definition of multi-
models, as this is our primary research focus.
The balance of this chapter is organized as follows : section 2 explains how an Object Oriented approach is used
by MOOSE to capture the geometry and dynamics of a model; section 3 explains how MOOSE uses multimodels
to facilitate model refinement to achieve appropriate levels of model 6,l. 1i I section 4 describes the components of
MOOSE in some detail and how they interact; section 5 covers some important MOOSE internal classes, as well as
our chosen platforms; section 6 is our conclusions and plans.
2. AN OBJECT-ORIENTED APPROACH TO INTEGRATING MODEL GEOMETRY
2.1. An Object Oriented Approach
MOOSE is the implementation of a simulation environment built using the OOPM design I '! -'i....1 -. ('I -. and
objects in the digital world being built correspond to classes and objects in the real world being modeled. This
-- ----------- -------------
Scenario i Engine
HCI Back End
Figure 1. The three components of MOOSE (HCI, Library, and Back End) are shown outlined with dashed line
boxes. Parts within each component are shown outlined with solid boxes: within HCI (Human Computer Interface)
appear Modeler and Scenario; within Back End appear Translator and Engine; within Library appear I. 1 11: (MOOSE
Model Repository) and MOS (MOOSE Object l,,., i Principal interactions are shown with arrows. The most
important element is the model author, who appears at left interacting with both parts of the HCI.
approach has been found to not only be intuitively appealing to model authors, but also to be both effective and
. t!n I. ii at capturing the elements of meaning which must be represented in the model.9 Dynamic models are an
extension to "00 method"; static models, in the form of Abstract Data Types without dynamic behavior, are an
extension to "00 ;ii1i il t.
As (class and) object identification are performed, the model author is encouraged to explicitly recognize relations
among classes. Most notable among these relations are specialization (or generalization) and aggregation.
Specialization is the relationship of derived class (or subclass) to base class, such as ,!i orange is a kind of ti ,LI ;
Generalization is just the reverse, such as 1 ,L. and Airplane are kinds of \. I!i I! ~, ., ,*,i'! '.,. comprises not
one but several sometimes overlapping relations in the -, ii being modeled, including containment, composition,
usage, and association,10-12 such as "a Car has Wl. !- "I !.. Moon is made of ( .. i! '! . -. ', "a Customer uses an
automated teller machine (ATM)", and "a Teacher is associated with a i i -ii respectively. Sometimes deciding
which particular relation applies is a gray area; in ;,,i event, relations should not be examined in a vacuum but
rather in the context of the model being built. Containment: "a Car contains an 1.ki. Litmus test: (1) does
behavior of Car depend in fundamental way on Engine? Yes. (2) is Engine inside or part of or attached to Car?
Yes, hence containment. Composition: "a Basket is composed of l i,- '. Contrast this with "a Basket contains
1i ii, ; hence, not containment, as the i i ;- forms the boundary not the contents. Constituent in a constructive
sense. Usage: "a Person uses an ATM". Litmus test: (1) does behavior of Person depend in fundamental way on
ATM: No. (2) is the ATM inside or permanently attached to the Person: no. Hence usage. Association: "a Car
has a -I 1 it LI 11 I i 11 Litmus test: (1) does behavior of car depend in fundamental way on (;. I No. (2) Is General
Motors inside ii- Car? No. (3) Does the Car have an ongoing use for (;. No (although one can think about
recalls, and/or suing (;., I for defects, but this is not within the ambit of Car behavior in most -- -I. i- because it's
the owner who sues, not the Car which sues; and it's (;., I which recalls the Car, not vice versa).
Sometimes these distinctions cannot be drawn with I. I ,;I i, and sometimes the model can be elucidated completely
without deciding the issue; but discussing the nature of relations, thinking about them, and a reasonable amount
of effort spent in attempting to categorize the ;, - 1 i. .1 within a model is often a useful exercise, because of the
light it sheds as the discussion and debate unfold.
An example of drawing such distinctions is ".. !I ,It,,i !Ii by I. i vs "- .-.... by referential iill..
Both are pointers so there is no implementation issue; but the 'Lti. ii. .. is with regard to lifetimes: in the first case,
the object contained by reference should live and die with the containing object; in the second case, the objects have
independent lifetimes. This distinction 11i be useful for the model author to recognize.
Students Style Unversity Professor Lecturer Adjunct
Figure 2. ('I - relations depicted graphically as they would appear on a MOOSE HCI canvas to a model author. At
left is ; -_i ; !.' at right, generalization (viewed upwards) or specialization (viewed downwards). The; ,_ _I i, Ir.
relation is symbolized by the filled square; the specialization or generalization relation is -- !1,,..1 i. '1 by the filled
circle. The small boxes just above each class in the; _!i--. ._ 1r.; specify ..... l',,1,l'l, which is explained in the text.
This ,i__- i i,, in words: a Teacher has 111 i~- 1 11 [. II -, has a Teaching -1 l1 and has an association with a
UCiii- -i' The specialization, in words: Professor, Lecturer, and A'liii. l are all kinds of Teacher.
Specialization and Generalization relation have been thoughtfully investigated.13'14 A-- il.,! abounds in most
models we have encountered, and we have found it to be of fundamental importance to the process of modeling.
A_ _!i. -i,.! has also received attention,11,10 although less so than specialization / generalization. A ,. i.,,i has
received, and continues to receive, keen -,i iL il1- as we develop MOOSE under OOPM principles.
As MOOSE is requiring the model author to communicate relevant object identification and relations, it is building
a conceptual model, which can be a handy representation for the model author. And this kind of -", :I, Il ....
model" is often useful for one person involved in a ,. i. I to communicate with his or her co-workers. Yet two other
important things are going on: (1) as the model takes shape before his or her eyes, the model author often gains
understanding, as represented in the aphorism "i I!- best way to learn something is to have to explain it to someone
S! ; and, (2) a model description is being constructed which although independent of .i!, programming language, is
nonetheless unambiguously and automatically convertible to a simulation program in some programming language,
e.g., C++, when the model author wishes to do so. Making explicit the classes and objects, and their relationships
often sheds light on what is being modeled and surfaces questions and ambiguities which must be addressed to
achieve the modeling or simulation objective. This is part of what is meant by tightly coupling the model author
into the modeling and simulation development loop.
2.2. Attributes, Abstract Data Types, and Containers
Attributes are defined for each class. In addition to the "- iii! i1 data I- i" (integer, real, and -li! i MOOSE
also permits arbitrary abstract data I- i" (ADT) to be attributes. These ADT's are just classes like all the other
classes in the model, and they 1i1 an important role in representing , -1 i, .11 We have several ways in MOOSE
to represent ;, i ,,i as we create the constituent elements as attributes of the aggregate class. A decision as to
the best representation rests on answers to questions such as whether the number of items of a constituent I i is
one, (e.g, a car has one steering wheel), or more than one (e.g. a car has four tires); whether the number of items
of a constituent I "- elements is known in advance and fixed (number of cells on a checkerboard), or is inherently
variable (a population of deer).
When -i-" f - -i ir. the model author can choose from several ,.1,,',./',*l alternatives for each; i 1 1 .1
class: many causes a container to be created, which holds contained objects of the ;- _. i._ 1 class; a value such as
64 also causes a container to be created but additionally automatically populates the container with the designated
number of contained ;, ii ,i! 11i .i objects; A causes an association, meaning a referential attribute, which is a reference
(pointer) to a named object whose lifetime is independent of the lifetime of the object of the ;, -. Ji class; V
indicates containment (value), which generates a value attribute within the ;,- _-i ,I i- class. When the cardinality
of an i -, ,- 1 class is one, an ADT attribute will be created in the ;, i i 11 class, but a choice remains between
value and reference. In the first case an object of the ;, i 1 I1 class is created at the constructor time of the object
of the ;, i 1 class. This suggests the "lt!, I i i, I -I as a decision criterion. If the ;,-, i ,-, 1 object will have a
lifetime which is independent of the lifetime of the ;, i i 11 object, then an association, represented by a reference
(pointer), is in order. It is also possible for model author to choose a referential attribute when the lifetimes coincide,
but then it will be model author's responsibility to manage object destruction. Because this is usually an unwelcome
Illl value attributes should be chosen whenever possible.
A second criterion is the "! iii I, -i If the object of the ;,, iJ, ,1 class needs to be a named object created in
another part of the model by the model author, then a referential attribute, also represented by a reference (pointer),
is in order, irrespective of the lifetime issue. Yet we have found that named objects are the exception rather than the
rule, because: names are often not a ii. ~- .- -;i named objects force more work onto the model author; and, unnamed
objects are still accessible as or within attributes of their ;,- _, i class. We have found that MOOS1. ;,1,lii- to
create these ........,I ...-.. objects is quite useful. An example is a collection of 1000 individual models of free-roaming
entities, such as I. ,1 i i i on a substrate or deer in a forest. In both cases the model author considers the objects a
fungible collection, and has no need to provide each of the 1000 objects with unique names. MOOSE supports this
When there are multiple, and especially when there are an uncertain number of items of a kind, an abstract data l- I'
which is a Container class becomes the I 1 "- of the attribute. This container class attribute holds elements of the
contained I ,. For example, I ., a tire container, might hold four tires, and this tire container is an attribute of
the class Car. Alternatively, DeerPop, a deer container, might hold; :ii number of deer, and this deer container is an
attribute of the class Everglades. Container classes have been found to be an effective way to represent an important
aspect of; ,. 11r. Provision is made in MOOSE for optional automatic population of containers at constructor
time; and alternatively, to allow the model author an optional code fragment to append to the constructor to instead
allow custom initialization of containers if required. Container classes can be specified directly by the model author,
such as the DeerPop example above; or, are created automatically by MOOSE based on !,1,li ili- such as the
Tires example above, where the user actually only created the Tire class but mentioned that the cardinality is four.
Containers have inherent behavior in MOOS. they know how to send information to their contained objects, they
know how to execute one or more methods of their contained objects; they know how to select a subset of their
contained objects based on some criterion. This behavior is along lines discussed by Zeigler.12
Another aspect of; i- -1. 11 ..1 is how to relate an attribute of an;. -!. i i class with the corresponding attribute in
its ; i classes, when such correspondence exists. In contrast to a delegation function, which is a method of an
_ i_ 1 i_ class that simply passes through a method to an ;, i I1 class, here we similarly have a method of an
S_ 1 i class that has the same name as a method of an ;, I ,1 class; however, here the problem is to invoke
the corresponding method of every ; i 1 1 class and in some way transform the results into an overall result for
the ; i 11i- class. This problem necessarily includes the problem of a container obtaining such information from
all its contained objects, which we have solved. The container problem is easier because all contained objects are
homogeneous and can be dealt with in the same way. This suggests the solution, which is to derive all -_ i. ,1
classes from a base class which has the desired f5 l i li, I11 1 and then package all the objects of the various .i 1 1
classes into a single container whose contained class is the common base class, which has the requisite functionality.
An example is biomass in an .. .- -l. i i simulation. A deer has a biomass which is its weight. Our deer population
in the example above thus has a total biomass which is the sum of the weights of every individual deer. Moving
to higher levels of ., _. -_ ,i i the Everglades has a biomass which is the sum of the biomasses of all populations
in the model. Here the relation is summation, and the base class common to deer and fish and sawgrass has this
functionality. While summation is a popular example, it is by no means unique; a model author is free to specify
whatever functionality is appropriate to the model.
2.3. Capturing the Geometry of a Model
MOOSE is based on OOPM, and OOPM in turn has a number of tenets, two of its most important relate to
geometry and dynamics. Geometry relates to space, and Dynamics has to do with temporal evolutions. We first
discuss MOOSE model geometry. Geometry is represented by static models, in the form of Abstract Data Types
without dynamic behavior, as an extension to "00 ;, ,il.L When a simulation involves a world where entities
interact and evolve over a field, with the field often influenced and changed by the presence and activities of the
entities, one usually thinks of model geometry in the conventional sense of defining properties of the space over which
the field is defined and through which the entities move. This is certainly one form of model geometry, and one which
MOOSE supports. An example of this kind of simulation is John H. C., w- '- board game "Li. t 15,16 which has
been implemented as a MOOSE model. A complete explanation of the game is not feasible here, but the interested
reader can learn details from the references .17 Summarizing the model, the Game is an .; _. - i. lr of, or -"I, a",
Board and Rules. Board in turn has a container Cells and a BoardGeometry. Cells container in turn contains i! !ii
individual Cell objects. BoardGeometry maps the real location or -1l. !ii of Cell objects in the Cells container
onto 2-dimensional space. Rules tells the Game how to take each cell on the board from one tick of the simulation
clock to the next (e.g., birth, death). This illustrates that MOOSE can model ...-, space by mapping elements of
a container class of individual region objects onto a space of ;.ii specifiable '.!ii! 1.. ."i- In Fig. 3(a), a general
framework is shown which applies to models we call ". i1111! '. Such models are characterized as "t1 !I models,
and I ,11- involve some kind of I 1! -i, 1 space with a certain geometry, a collection of entities that roam over the
space, possibly interacting with one another and the space itself, and all of this evolving over time in accordance with
some laws, which include initial and '1!i -1" 1 boundary conditions. An important subset of the ", Iii framework
applies when the ,1i!i. !i-i..i, li- is two. A framework for this subset which we term "!I I,-, '-"" is shown in Fig.
3(b). The Life model was constructed from the landscape framework. MOOSE considers geometry not only in the
narrow conventional interpretation above; but also, in a broader sense, the space under consideration can be a space
other than a i'1! -i 1 space; rather, it can be a space over which classes and/or objects relate. MOOSE is capable
of modeling this sort of geometry as well, through class definitions and relations among classes.
I -----------r -----------
World Space Geometry
I -- --- -- - -
many V | V |
Entity Space Laws Landscape
Cell Geometry MooreGeom
Figure 3. At the left is a MOOSE model that serves as a very general framework for a large i;, of "!t !I [" models,
which are characterized by a multi-dimensional space over which entities range, interacting with one another, and
affecting the properties of the space, in accordance with initial and boundary conditions called Laws. The space
is subdivided into cells, and has a geometry. At the right is a specialization of the cellular model, in which the
space is two-dimensional and the geometry is that of a Moore Neighborhood, in which each cell has eight immediate
neighbors. This model is encountered frequently, so it too has been given a name: "1. 1 ,1-, '1" A Landscape is a
kind of Space. A Landscape has a Moore geometry, which is a kind of Geometry.
The focus on MOOSE so far is in support dynamic multimodels, but we envision equal support for static multimodels
in the future. I ,1 i, multimodels will define geometry and semantic networks appropriate for an object. For example,
the hierarchy tree8s is an example of a static model. To fully support static models, we will need to facilitate
;,__- _! -i. ,! and inheritance in objects, as well as in classes.
2.4. Capturing Dynamic Behavior of a Model
(' .--- would be uninteresting indeed without methods. In MOOSi. these detailed aspects of every class 1! be
readily added, changed, and removed, as part of model development, at ;,i! time. Dynamic behavior of the -- -., i!
is represented by ,.M..i ', models. Here MOOSE makes good its promise to the model author to be able to create or
change a simulation program without being a programmer. MOOSE presently incorporates several kinds of dynamic
model: FBM, 1 S., FQN, and RBM, with others contemplated, such as Petri nets, and System Dynamics models.
From this ensemble of popular and capable dynamic model I- ,. the model author picks one or more dynamic
model I- i, to define methods of the classes of the model. Construction of each specific dynamic model I- i,;, 11
involves drawing the kinds of "--1 I ,i that people tend to make on the back of an envelope or a blackboard when
informally describing a model to someone else. The MOOSE HCI facilitates these constructions: allowing the model
author to specify components, connect components, provide inputs, outputs, conditions, and so forth.
2.4.1. Functional Block Model (FBM)
A Functional Block Model (FBM) is constructed when the model author so designates a method, e.g., Mj, of some
class, e.g., Ci. The I I;.l editor enables the model author to construct the FBM for C; ,i(). Basic to an 1 I;.l is
its blocks. The following are eligible to serve as blocks of the Ci li FBM: (1) methods of Ci itself; (2) methods of
.I! value attribute of Ci which is an abstract data I "- (ADT); (3) methods of., I- referential attribute of Ci which
is an ADT; and (4) methods of other associated classes. The first two groups are bound at class declaration time.
The last two groups require (or at least permit) dynamic binding.
The model author identifies each functional block of the 1 I;., I from the pool of eligible blocks. The blocks appear on
the canvas as rectangles, like chips on a circuit board. Inputs and outputs of each block look like the pins on a chip.
The next job of the model author is to connect the various pins with "-- ... -", forming the I. I,. ,1. _*- of the FBM.
Block outputs are connected to block inputs. 1 I;., I inputs are connected to block inputs. Block outputs are selected
I................--- - - - - - -
Figure 4. MOOSE Dynamic Models.
(I S ,1 1.
*0B State Transition Predicate
On left, a Functional Block Model (FBM) On right, a
I i!!! 'I ,.. M machine
IONHg~l11mglR~mll(lb EJW~: L~ ~: h RB
File Edit Func Link
Figure 5. MOOSE HCI Modeler GUI Editor for FBM,
blocks for Boiler, Turbine, Condenser, and Pump.
showing part of Fulton steamship model, with functional
as outputs of the FBM. Cycles are permitted, in which case the value at one time step propagates to the next time
Several interesting collections are available to serve as blocks. One such collection is the "..ii I. !' collection, consist-
ing of Add, Subtract, Multiply, Divide, Integrate, Constant, PseudoRandom, and Accumulate. Another collection is
the "'1,L. ,'L ii" collection, consisting of Source, Sink, Fork, Join, and Fr 11, Yet another collection is the "-ti.., I '
collection, consisting of Begin, End, Decision, Process, and Auxiliary. The first collection is useful for building 1 1;. -
for control applications. The second collection is useful for simulating traditional queuing models. The third collection
is useful for constructing models from flowcharts. 1 i;. can be constructed without using :,!I of these collections,
but these collections are available as 1- -1. ,-use components for those who are familiar with this modeling metaphor
and wish to -I with it within the context of MOOS1.
2.4.2. Finite State Machine (FSM)
A 1 !!ii.- State Machine (1 S. 1) is constructed when the model author so designates a method of some class. The
1 S. I editor enables the model author to construct the 1 S. An 1 S. I consists of states. .!,I i.!.. to appear as a state
of an 1 S. I are the same groups as are eligible to appear as blocks of an FBM, discussed above. After all states have
been created and identified by the model author, they appear on the canvas as circles.
When states are in place, the model author constructs transitions between them. These transitions look like arrows.
If the arrow points from state 1 to state 2 this corresponds to a transition of the 1 S., I from state 1 to state 2. On
each I S. I transition, the model author places a predicate (logical expression). If the 1 S., I is in a particular state and
a predicate on one of its outbound transitions is true, then the 1 S., I transitions to the state to which that transition
points. A well-constructed I S., I should have no more than one outgoing transition true at :i, time. If several such
T 100 Boilingu
Heating .--- ---... Exception
I' OFF ==OF
C 'ling .
Figure 6. MOOSE HCI Modeler GUI Editor for I S., !I showing part of boiling water model, with states for Heating,
Cooling, Boiling, and Exception; predicates defining I S. state transitions appear as text near the I i; circles on
arcs. Boiling water model is one component of Fulton steamship model: this 1 S. I is actually inside the Boiler
functional block of the FBM shown in the previous figure.
transitions are true in a MOOSE 1 S. I an arbitrary transition from among the transitions with true predicates is
2.4.3. Rule Based Model (RBM)
A Rule Based Model (1:i;. !) is constructed when the model author so designates a method of some class. The RBM
editor enables the model author to construct the RBM. An RBM has a number of rules. Each rule is in the form
of a a conditional expression: if premise then consequence. The RBM editor main window creates ;~i- number of
rule templates in this form, and sets up each premise and consequence to allow the model author to choose ;i!i
premise or ;i! consequence to elaborate a new rule, or to change an existing rule. When the model author chooses
a premise, he or she enters a premise-editing window, with various widgets that facilitate picking eligible items from
lists, -,." if -;! relational and logical operators. A premise !i be a simple logical expression or something more
complicated; if the latter, then the premise becomes a block. The model author also defines each consequence, using
a consequence-editing window. Each consequence is either a simple statement or something more complex; if the
latter (as is usually the case), the consequence is a block. The ability to connect to blocks in this way fits 1:I;. -
into multimodeling hierarchies (to be discussed below).
NEW EDIT |DEL |
Figure 7. MOOSE HCI Modeler GUI Editor for RBM (Rule Based Model), showing the RBM editor main window.
In this window, the model author has decided to construct three rules, which the editor has constructed as shown.
The first of these rules has been turned from a template to an actual rule by the model author. The other two
rule templates remain available. By clicking on a premise, the model author can edit the premise part of a rule
in the premise-editing window (not shown); similarly, by clicking on a consequence, the model author can edit the
consequence part of a rule in the consequence-editing window (also not shown). A premise can be a block. A
consequence is always a block. Thus 1il;. fit into multimodels just like other dynamic model i" -
IF temperature == 20 AND knoh_psn == ON
2.4.4. Equation Constraint Model (EQN)
An Equation Constraint Model (I., IN) is constructed when the model author so designates a method of some class.
The E^IN editor enables the model author to construct the FQIN model. A -- -. i! of :I!i number of nth order
differential equations 1! i, be entered, using an intuitive syntax. Differential equations are represented using -- i1 '1-
such as x, x' for the first derivative of x, x" for the second derivative of x, and in general x followed by n single quote
marks to denote the nth derivative of x. Several variables i be used. The output of the -- -. I i, i! be ;,I! order
derivative of I variable. If a variable used in the -I, i, of equations also happens to be an attribute of the class
to which the EQ N model belongs, then at the beginning of the computations of the EQ7N model at each time step,
the E IN model is loaded with the value of that variable; and, when the computations are completed for that time
step, the value is sent to that variable.
In addition to variables and their derivatives, a set of equations i i, contain (additive and multiplicative) parameters
and input signals. Parameters 1!! i be attributes of the class to which the model belongs; or, they i!! be input
parameters to the E(TN method; or, they i!! be blocks, with 1 _l ili,- the same as was set forth in detail for the
FBM above. This will be discussed more fully when multimodeling is considered in a later section.
2.4.5. Code Methods
Although promising models without !"-i iiiii,- MOOSE also tries to be tolerant and flexible. Thus, if none of
the dynamic model I- i" suits, the model author is free to write what are termed i . I I !- or "i,- 1. In i .I
A code method is a function body written in the TTL used for the MOOSE -- -l. i Presently this language is
C++. MOOSE design bi1. .1.._ suggests that code methods be the exception rather than the rule. Typical use of a
code method is to provide that one small piece of some models that cannot be described using the available dynamic
model I- |" and to rely on dynamic models for the rest, in a way that is analogous to construction of an Operating
System kernel in a high level language, with just a few;, i.i il 1 -1I 1 _.- routines where needed.
3. FACILITATING MODEL REFINEMENT
Constructing a model is almost always an iterative process, with model structure taking on a tree-like appearance.
The broadest description of the model is like the root of a tree. One then I- 1.,i 11 decomposes this broad but
nebulous description into subordinate parts, each part being a refinement of the model in the broad description
statement. The result I- i'. ,11- is a tree with some leaves near the root, and others farther "-- ..I- '. Thus the level
in the tree is related to the level of abstraction which one associates with thinking about and describing the model.
To support the kind of heterogeneous model hierarchies shown abstractly in Fig. 8, we must ensure that our models
are closed under coupling. In short, this suggests that the method of coupling one model component to another
must be clearly defined. Two kinds of coupling exist: intralevel and interlevel. Intralevel coupling reflects model
components coupled to one another in the same model. For example, one needs to specify rules of how Petri nets,
Figure 8. Multimodeling tree structure for model refinement. Selective refinements achieve required Cf~. li;
F-'.. I, i-i. facilitates model development. Polygons above depict the heterogeneous nature of multimodeling: each
I of I" 1 -1, represents one I of dynamic model.
compartmental models and System Dynamics graphs are formed. \\ ,i 1 a System Dynamics graph, a rule of model
building defines that ,i!! level has an input rate and an output rate. A more interesting case arises in interlevel
coupling since we must ensure that we define rules as to how model components from one model can be refined into
models of different I- i" Can a finite state machine state be refined into a Petri net, or can a functional block
model contain finite state machines (1 S., !I inside blocks? What are the rules to guide this refinement? The rule for
intralevel coupling is based on functional composition. The primitive of function with its input and output defines the
coupling procedure in the following way. All models are encapsulated in a single function. Fig. 4 demonstrates this
functional block encapsulation. This represents the outer shell to support interlevel coupling. \\ 1 !11 a model there
are functional entry points. These are inner shells where new models 1!! i be optionally inserted. Each model I i "
has its own entry point defined .tl!!. i. III For example, for the model I "1 S. I ', we 1 !! define each state to be
of the form: v(state) = f() where f() is an arbitrary function and v(state) defines the value of the attribute state.
If state is not refined, then f() returns the value of the state as a character string or integer. If state is refined, then
f() !! ,i be replaced by ...., function-whether this function is a dynamic model or a code method. The coupling
approaches are defined in more detail by I i -! I- !: 19
Resources are limited, and by this we mean both model development resources and simulation runtime resources.
Thus one typically refines using a breadth-first approach, and this tree-like structure accordingly takes on an uneven
shape, with some parts of the tree being of greater height, and others being of shorter height, reflecting the LI. !'1 i1 i
decision criterion, which is to refine only as much as needed to achieve required levels of model 1l. 1i But knowing
what is needed to achieve required levels of model ~1. li- often requires iterating through several model designs,
and even measuring performance of the model execution. Multimodeling can be used in the development process,
to conserve valuable development resources, including time, by limiting the depth of some subtrees; and to provide
a top-down skeleton within which development i!! proceed. A rude shallow model can be run, and ,!! 1- -i- can
pinpoint those model subtrees where additional f~1. li is needed. This is an adaptive mechanism to focus and guide
development. The evolving model is thus its own "i .11 I.. It needn't be discarded, as in throw-away i .1 .11* i.i -
nor does it suffer the chaos that often accompanies the "- .1.Ii,! o,! !'.i...I i!!!i- or ".1...i! .'r'i I1!"o! "!i!
Thus MOOSE provides facilities for multimodeling,20'21 by which we mean model refinement into more detailed
component models, reflecting a number of abstraction perspectives.6 This is a very intuitive concept: most people
multimodel without thinking about it; yet, they do benefit from encouragement in this direction, and especially from
:x' = a*x + u
a X 11
Figure 9. This figure illustrates a simplistic equation constraint model. The purpose is to indicate multimodeling
in this dynamic model I- i" The rectangles representing parameters and inputs (a and u, respectively) are eligible
to be refinement candidates; in other words, each of them in i- be block, which is a complete dynamic model in its
automatic management of the resulting .!ii 1,1. '.1 The multimodel definition is recursive: refinement proceeds
as far as needed. By facilitating this kind of work and encouraging this kind of thinking, MOOSE contributes to
management of the model: extending (or reducing) model refinement at : ii stage of the game. Typically, refinement
is extended when 61-. li- is inadequate, and is reduced when the simulation takes too long to execute. Now having
explained multimodeling in general, we proceed to a specific taxonomy. There are two perspectives from which one
i, look at multimodeling: time of binding and dynamic model I ,. Each perspective leads to a 1 1. L.I ,- The
overall result is a small I '.-. ,. .1', which will now be presented.
Multimodel dichotomy based on time of Binding: In a temporal sense, regarding the time at which the level
of refinement is bound or fixed, MOOSE recognizes two kinds of multimodel: fixed structure and variable structure.
Fixed 5 ..... :... Multimodels: The evolution of model refinement that takes place over the model development life
cycle results in a fixed structure multimodel; that is, we change the model's structure from time to time, but whenever
we build a simulation program representing the model, we freeze model structure as of that time. Of course we can
change it later and build a new simulation program, but the fixed structure multimodel persists until this is done.
The second kind of multimodel is the Variable -..... .... Multimodel, and the MOOSE runtime environment supports
this kind of multimodel too. A variable structure multimodel changes its refinement on the fly, in response to -1. i
constraints. A I- 1.i ,1 constraint is a realtime constraint on when the simulation must complete. Presently, MOOSE
does not provide the executive logic which decides when to change refinement depth; but, given such logic, MOOSE
has the 'bil ,1ll-h to reconfigure model refinement on the fly. Others are presently working on providing this logic
for MOOS. 8
Multimodel dichotomy based on type of Dynamic Models: When a model is refined, each level is usually
described by one or more dynamic models. Each dynamic model is of some I i. e.g., 1 S. I If all the dynamic models
are of the same I then the multimodel is homogeneous. If the dynamic models are of different I- i" then the
multimodel is heterogeneous. In Fig. 8, for example, the multimodel depicted is heterogeneous.
4. THE COMPONENTS OF MOOSE
MOOSE has six components, which fall into three groups: Human Computer Interface (HCI), Library, and Back
End. Each group has two components. The HCI is subdivided into Modeler and Scenario. Modeler constructs a
model; Scenario runs it. The Library is subdivided into MOOSE Model Repository (MMR) and MOOSE Object
MI.,,.- (MOS). MOS holds object data and -I II: holds object meta-data. -I II. keeps track of models as they are
being built. MOS keeps track of objects as models execute. The Back End is subdivided into Translator and Engine.
Translator converts a model definition to a program; Engine is that program.
The Modeler component of the MOOSE HCI interacts with the human model author via a graphical user interface
(GUI) to construct a model. In simulation parlance, this is model design. Modeler relies on the MOOSE Model
Repository (MMR, discussed below) to store model definitions as they are constructed, and also relies on -I 11: to
provide reuse components developed elsewhere by others or earlier by the model author. The Modeler GUI is a
composite: the "--i iii part defines classes and objects and relations among classes (;:i i. .1i.I and specialization
or generalization) on one or more canvases. On the canvas, rectangles represent classes. These rectangles are joined
by relations to form a tree, or, more generally, a graph, reflecting the relations in the -- I. i being modeled. Some
models look cleaner if :, i l.,,,- and specializations are kept on separate canvases; this is supported but not
required. Similarly, some models are large enough that several canvases are needed to capture the representation.
Each class is a box which, when opened, reveals more information, and permits the model author to define the name
of the class, its attributes, its methods, and its named objects. \\ I I!, i each method, the model author i,! specify
input parameters and output parameters, as well as i1l. I i i! which dynamic model I- i"- the method is to be. In
addition to the "--!!! ii' GUI presented above, there is a GUI editor for each dynamic model I- i. i.e.: the 1 S. I
editor for finite state machines, the FBM editor for functional block models, the E AN editor for equation constraint
models, and the RBM editor for rule-based models.
Besides dynamic models (1 S. FBM, FQN, and ili;. !, the model author i! i also select code methods: ordinary
code methods (CODE), constructor (('S 1i), and destructor (DSTR). For these code methods, MOOSE provides a
text editor which permits the body of each such method to be coded in Translator Target Language (TTL, presently
C++). Since MOOSE is not really in the text editor business, and its text editor is relatively primitive, the model
author is free to use his or her favorite text editor to modify these code methods. Because the emphasis in MOOSE
is on dynamic models, not code methods, reliance on code methods should be minimal in most models. But as
MOOSE I'.!- .1.-.1 is to facilitate rather than dictate, the code methods are available as the model author sees fit
to use them.
The flow of information between Modeler and the model author is definitely bidirectional. If the model author builds
a model from scratch, then the information flow is from model author to Modeler. We expect this not to be the
usual situation. When the model author goes shopping for reusable components to include, or a previous model to
modify, then the information flows from Modeler to model author.
Central to Modeler's ability to flow information both ways is MOOSE Model Repository (MMR). I. 1I. has a
client/server architecture, and Modeler is one of its clients. Modeler communicates via pipes with an I1. II proxy
it starts as a "--,l.p1,... --". An I'1. !II; proxy is thus dedicated to this one instance of Modeler. The ,I:. li proxy
responds to requests from Modeler, obtaining 1 II services from one or more 1. .11: servers, which ii be local
or remote. In this way, Modeler has access to model definitions developed earlier I"!. or -". 1-. !i. ', for reuse.
Thus small working models can become elements of the model under constructions; or, a large working model can
I I C $- I EI l- _1
IIla Ed Ila6; -icl|l I ,r.
flEEMHM aBU _
_2J- I IF-l....
I I I.
Figure 10. In this view of the MOOSE HCI, the Modeler GUI is shown for a landscape ....- ,1 model in which
apple snails in Florida's Everglades are modeled as a collection of population models each within a spatial cell. Cells
tessellate the I "1 -i that represents the march environment of the Everglades. Apple snails are an important food
of wading birds, and wading birds' behavior are studied using a multimodel, one piece of which will be the apple
snail model. On the left, the Modeler canvas, showing classes and their relations. A -_ -, i. ,!- a Polygon has a
geometry, some Cells, and ii, i F' I I- '- a Marsh has a II- 1!i 1..- Specialization: a Marsh is a kind of Polygon.
On the right, the view inside one of the classes is shown. This is available by double-clicking the class on the canvas.
Information about attributes, methods, and instantiated objects appear.
be modified to a new purpose.
As Modeler receives information from the model author, it is retained not in Modeler itself, but in :-I I; Modeler
tells I- 1. II; whatever it learns of the model, and later queries I- 1., 11: when it needs information to .1 -1I ,1 the model.
This allows Modeler to focus on its essential GUI model definition job rather than having to be in the Dl;. IS business.
A good example is when a named object is created in some class which happens to be derived from (a specialization
of) one or more base classes. When the model author displays the object with the intention of viewing its methods,
a recursive traversal is done "up" the generalization hierarchy, because methods of the object include not only the
methods of its class but also the (public and protected) methods of its bases classess. Modeler gains this knowledge
from a query to I II.11: All such methods come back to Modeler including their names and parameter lists. Thus the
display includes the names and parameter lists of the methods of the object, as required, without Modeler having to
maintain this information explicitly.
As a model author develops a model, one good mode of action is: develop a little, translate, and save. These steps
are then repeated as the model grows. It is good practice to translate every so often to check for errors. If the change
from the previous version is small, it facilitates localizing the source of such errors. If for i ii reason, the model
author cannot resolve such errors, an option then exists to discard the latest change, reverting to the previous saved
version. A second development mode is: develop a little, translate, execute, save. Again, these steps are repeated as
the model grows. The procedure is similar to that above, except this time the model author has the opp, ii I not
only to surface translation time errors, but also to verify the expected runtime behavior. Again, taking -,i!!, ,. I I;
small steps tends to improve prodll- I by helping to localize the source of errors, and allowing abandonment of
a relatively small change that did not work as expected.
The Translator component of the MOOSE Back End uses a model definition from -I II. 1i; to construct a simulation
program in Translator Target Language or TTL. Our first TTL was C++, and this C++ Translator is in use
presently. A second Translator is under development, with Java as its TTL.
Translator ii ,- be invoked either from Modeler or from Scenario. During development, it is most convenient for
the model author to invoke Translator from Modeler. For production runs, it is easier for the user, who ii, ,
not be the model author, to invoke Translator from Scenario. Translator's output, as previously mentioned, is a
complete "-.ii., i.-" program written in TTL (including indentation and comments). The C++ Translator specifically
emits: engine.h, a header t!!.i consisting primarily of class declarations, and engine, cpp, a source il!-I containing C++
translation of each dynamic model method and each code method, as well as code to invoke engine runtime support,
and to -- i I i!. with and accept commands from Scenario.
I i!i, decisions are made in the course of deciding what code to emit and when. The heuristic we adopted is to
move as much "-!!i II!,- !, .." as possible out of Translator and into -I1. 1II1 The effect of this is to make it easier to
construct future Translators, as the same I1. 11: serves them all. The cost in increased size and *,!ii I!. '.i- of I I.
appears to be justified: I I. I11: has about 2/3 of the code and Translator has about 1/3, so this approach leverages
Translator development by something like 3:1 through reuse.
4.4. MOOSE Model Repository (MMR)
The Moose Model Repository (MMR) component of the MOOSE Library holds object meta-data, such as class
declarations, including declarations of attributes and methods, and class definitions, including method definitions.
I. I.11 keeps track of MOOSE models as they are being built. I I., II1 also maintains collections of previous models
and model parts for reuse.
I .II;i has a client/server architecture, and in some ways is patterned after the CORBA (Common Object Request
Broker Architecture) IR (Interface Repository).22 The I. II; servers provide a database management -l. (Di;. IS)
for model definitions. -1. ,I; clients work with Modeler and Translator to define and (re)use model definitions.
Models and model components created by other model authors (or the same model author previously) are available
for browsing, inclusion, and/or reuse. Base classes such as sets for modeling collections and popular geometries for
spatial models are available to the model author. An -.I I; client can simultaneously maintain conversations with
several 1.II; servers, each on a different machine, which permits model definitions to be distributed. An 1.II;
Server can simultaneously maintain conversations with several -I lII clients, on the same or l!!. i. i Ii hosts, which
permits collaboration within an engineering workgroup on model development.
As was mentioned above, it is necessary at numerous points to : I! I1- information before code can be emitted by
Translator. Such :i !! -i- is performed by -1. 11i: as the data is entered. The result is I- i'i ,11 stored in a data
field, often as an enum I value or a boolean. Then in Translator, because the decision has already been made,
* .~ I.1. -. I is I 1 ';. 11- reduced to a switch or if statement to carry out that decision. This makes I 1. I 11 more than a
Dl;. Is the model ,!i i 1 -1- aspect is an integral part of understanding a model definition -it !!l !i I II well to convert it
automatically into a program. Here is an example, which occurs whenever a functional block model (FBM) appears
as a method within a model. Each block of the 1 I;., I must be examined to ascertain whether it is (1) a method of
the class containing the FBM, (2) a method of an ADT attribute of the class containing the FBM, or (3) a method
of some other class. Each case is handled differently when code is emitted: a member method name, a method name
qualified with the attribute name, or dynamic binding of a block from the model's context. I II. does this ,!! ,i1 -1-
and provides an enum I *" plus a boolean containing the decision, which allows Translator to effectuate the decision
when code is emitted.
In addition to the normal mode of receiving model definitions) from model authorss, 1. I. 11i can also receive model
definitions in another way: from text !il These il!h can be created using a text editor. Historically, such !i. were
originally created by Modeler before I I., 11: came into existence. These !il now serve as a way to initialize or reload
an I I.1i: server.
The Modeler is connected to I 1., 11: via an interface that consists of pipes to a proxy process, and thence via TCP
to an 1. II: Server. This architecture permits a proxy to maintain simultaneous conversations with several Il.II:
Servers, some or all of which i be located elsewhere than the local machine. Additionally, the I, I. II Servers 11 i
converse with one another, to establish and maintain distributed definitions of models, based either on a hot link or
a cached local copy of each distant component.
In the case of Translator and other C++ programs, access to I1. 1: is provided by an API whose code is part of
the Translator process itself, rather than a proxy. This is done for reasons of I!, in and -il!i' i and does not
compromise the architecture. Both the proxy and the API are I! programs, i, 1 iii_ on the I, II. 11 Server, for two
reasons: so that more code can be shared between them, and to .Il... issues of synchronization and concurrency
to the I I. II: Server (where it "I, !I..! -").
I, I. 11 is presently a homegrown C++ creation intended as a proof of concept rather than for production use. Upgrade
to ",Il, ,-ii i! -II. I can be done in future without altering the architecture, as follows: the I I. II: Server can be
replaced by a Dl;. IS! either an 00 Dl;., IS or an RDi;., IS with 00 wrapper. Proxy and API will then be modified
to make requests (queries and updates) to the new Dl;., IS rather than to the original I I. 11: Server. This brings to
MOOSE the -- i .!I, -i I i, i, locking, and security capabilities offered by commercial Dl;., IS software. Importantly,
Modeler and Translator never see the change and need not be modified.
The Engine component of the MOOSE Back End is generated by Translator. Translator emits Engine source code.
It is then necessary to translate the Engine to create an executable (even with Java, into bytecode). In MOOSE this
is done automatically under the covers using a "-- !: ." Iili program; alternatively, Engine can be compiled and
linked directly by a compiler such as Visual C++ or g++. At link time, a number of runtime support components
are added from object libraries, the most important of which is ooSim.23
The ooSim event scheduling toolkit: All dynamic models are translated into C++ code which relies on the
,11 il. i1- il- event-scheduling of the ooSim dispatcher for propagating event chains. ooSim is an event-scheduling
simulation queuing model toolkit which arose as an object oriented re-implementation and extension of the SimPack
toolkit7,24; SimPack is, in turn, based on ., !pL.25 In addition to event scheduling, ooSim also provides numerous
other forms of support, such as pseudo-random number generation. But it is the event scheduling that is ooSim's
primary support role.
Engine source t I!. contains code to initiate one or more event chains. These event chains propagate independently of
one another, and the time step of each chain is independent of the time step of every other event chain. The event
scheduler propagates each event chain until that event chain terminates itself, or until the simulation clock reaches
the overall time limit specified for the simulation in the model definition. In general, an event chain propagates
by rescheduling a specific event routine which the model author identifies. This is accomplished by enabling the
autopropagate feature, which is done by default. However, it is also possible for the model author to disable
autopropagate, in which case the model itself 1i i- generate ii' number of event chains following ii' logic. This is
an advanced feature which is recommended only to those who are familiar with event scheduling in ooSim and wish
to (or need to) have the additional flexibility which manual event scheduling provides. Manual event scheduling is
not required to get MOOSE models to run.
As the Engine runs, it executes one simulation event after another, driven by its l 1I. 1!- !1 ooSim Future Event List
(FEL). As an event executes, it 11i generate output on standard output court) All such output is presented to
Scenario for possible use. See the Scenario subsection below for more detail. After executing each simulation event,
Engine checks with Scenario for instructions and new parameter values. The relation between Engine and Scenario
is thus inherently interactive and bidirectional. One such instruction permits Scenario to i, i. I events into the FEL
of an Engine as it is running. This is one feature necessary to support distributed execution of simulation models.
The Scenario component of the MOOSE HCI is a visualization enabler ii!'1.. ii,- a GUI. Scenario activates and
initializes simulation model execution (which we call Engine) at the behest of user (who 11ii or iii not be the
original model author). Scenario maintains i 1....', t- bidirectional interaction with Engine. In the visualization
role, Scenario displays Engine output in a form meaningful to user. In the controlling role, Scenario allows the user
to interact with Engine, ri.. li"1 ii1- simulation parameters and changing the rate of simulation progress.
Once the Engine executable has been built, it can be run as 1ii ii' times as desired, under auspices of Scenario.
Scenario establishes a bidirectional pipe connecting it to Engine. The effect is to activate Engine, and to synchronize
Engine's execution with that of Scenario, so that whatever Scenario writes to the pipe appears on the standard input
OC.ern Liie File
Figure 11. MOOSE Scenario GUI for C..! '- game Life.
(cin) of Engine, and whatever Engine writes to standard output court ) can be read from the pipe by Scenario. This
interactive connection controls the real progress of Engine: Engine can be allowed to free-run, or can be made to
single step through one event at a time (the default), or to run at ;~i! pace in between. As a separate feature,
simulation clock time scales can be stretched or compressed. Both can be combined to generate animations with
which the model author can interact. Things which ordinarily happen blindingly fast can be slowed down. The rate
of progress can be ;-1li -l.- 1 to focus on parts of the simulation execution that are of particular interest.
The bane of simulation is output in the form of reams of computer printout. Scenario improves the situation with
a GUI with which the user (who 1iii not be model author) interacts. Scenario can initialize parameters and pass
them to Engine. Most important, Scenario tll. i Engine's output. Scenario takes Engine's dull boring simulation
output and turns it into appealing, meaningful, usually graphical, output. Engine is thus free to do what it does best:
model execution, producing output. Scenario then does what it does best: facilitating visualization of the output as
.. 111 .
Scenario detail is unique to each model. MOOSE has a toolkit of visualization instrumentation for reuse. This kit
includes dials and gauges, like those seen in an automobile or those which measure progress when installing software,
as well as simple , plot graphs and terrain maps. This toolkit is extensible and as new models are developed, the
toolkit grows and becomes more useful. Nonetheless, some simulation output isn't necessarily amenable to graphical
realtime treatment, and there is a very necessary role for traditional methods of ,ii ,1 -- 26-28 MOOSE can support
this in two ways: Engine can send output for this purpose to a ti!h. separate from that examined by Scenario;
alternatively, Scenario can direct some of Engine's to such a til! Either way, further ,! ,ii1- -,- of such output can
then be handled by additional software provided by model author, e.g., MATLAB. Such software can be invoked
from Scenario, or it ii be completely external to MOOSi.
4.7. MOOSE Object Store (MOS)
The MOOSE Object 'i, ,,.. (MOS) component of the MOOSE Library holds object data. MOS does for objects much
of what 1 I. I11; does for models. MOS works with Engine and Scenario, in similar fashion to the way 1 I. I11; works with
Modeler and Translator. MOS manages object persistence and distributed objects. An object enters MOS either
to hibernate (persistence), or to move to a different host (distributed). An object in a MOOSE component such as
Engine decides to go into MOS. MOS accommodates this. The object can re-emerge at ii;~ MOOSE location, either
on the same host or a l! ii !I host, but not to two (or more) locations at the same time. What is supported here is
moving not ,;,'.i, corresponding to the real-world constraint that there cannot be more than one copy of a given
object in existence at i,!! ii,!..!i. ".
Objects are "II 1i, I 1' as they go into MOS, and "itl ! I again when they are come out. Primitive I- i such as
int, real, and string, are stored as themselves. All other l- I" are abstract data I- i" (ADT's) formed from primitive
- I and/or other ADT's, and are recursively (eventually) flattened into primitive I- i" For example, an image in
.gif format belongs to a class (ADT) with two attributes: an i of byte and an integer length.
An object can persist by sending itself to the MOS. The object can come back from the "l I, i ii ii to the i
state with a special form of its constructor that works with MOS. This technique is extensible to support distributed
operation by having the two operations occur on Ltil, i. ii, hosts. An object can move by placing itself into MOS
with a request to be moved to a specific host; or, an object can place itself into MOS and wait for a request which
will cause it to move to some location which need not be known when the object was stored. Each MOOSE host has
an MOS, and several MOS's collaborate to find and retrieve objects, so that an object can move from ,i!! MOOSE
host to ; !! other MOOSE host where MOS is active.
Although the architecture permits MOS to be capable of distributed operation, this is not our present focus in
MOOS1. We have decided to focus on distributed model definition rather than distributed model execution. Thus,
MOS operates in support of model execution on a single host only at this time, so that only persistence (and not
distributed .1,i, I -1 is supported. Work on distributed objects to function as described above is currently Li!! 1 i
5. IMPLEMENTATION DETAIL: SOME IMPORTANT CLASSES; PLATFORMS
Blocks: This section describes some key classes in MOOSE back-end software, comprised of Translator and Engine.
I ii we discuss the Block class: MOOSE models are multimodels built mostly of dynamic models, and every dynamic
model has a structure (subordinate elements) and a I. i. 1.,_-- (how those subordinate parts are connected). 1 S. -
for example, have states connected by arcs labeled with predicates that control state transitions; and, I I;. -, for
example, have function blocks connected by traces which carry output of one block to input of another. In MOOSi
every subordinate element of every dynamic model (e.g., state of an 1 S. 1 functional block of an FBM, is an object
of a derived class of the base class Block, so called for historical reasons (our first dynamic model I I". was FBM).
This ].ii..i. if. !l- facilitates model refinement and so is an 11,,1. il 1i-_ support for multimodels of all kinds, most
especially heterogeneous multimodels.
Clusters: Associated with each Block object is a structure known as ('I1L-i. i- which hold pointers to objects
known to belong to classes that have certain relations to the object. Each dynamic model method belongs to a class,
but the 1I. I iI and true nature of each block within that dynamic model can be bound as late as every time the
method is dispatched. ('II-i. i are searched as needed to identify the block objects to associate with each element of
a dynamic model, just before each execution of the dynamic model. This dynamic block binding facilitates dynamic
multimodeling. It is also anticipated to support distributed simulation when MOOSE moves onto the web.
Context: MOOSE engine is event-scheduled using ooSim. This is essentially transparent to the model author,
who only specifies the time step for each model within each event chain (or one overall time step if all time steps are
the same). Event chains can terminate themselves, or they can end when the simulation clock reaches a specified
time. The consequence of event scheduling is that all events, such as one execution of the code of a dynamic model
are called from the ooSim event Dispatcher. There cannot be ;, I loops in the dynamic models: the equivalent of
loop behavior is attained by propagating event chains. Each dynamic model is a method of some class. ooSim does
not use global symbols, so to have the equivalent of static local variables private to each object, a Context structure
holds this information. Contexts are generated automatically by Translator for dynamic models. This facilitates
Glist: MOOSE needed a base class for lists, because MOOSE has lots of lists to manage. The (r/ .: class is this
base class. A Glist object is a dynamically allocated ; i i of pointers. When insertion is performed, the 1, i senses
when it is full, and automatically expands, in a way transparent to the caller. (;!l-I is not a linked list, it is an
.ii so it has speed and If advantages relative to linked lists. Derived classes of Glist are made I- I" -- i.29 by
appropriate casts in derived class declarations (not in calling code!). There are specialized methods that were needed
for one derived class or another, and were put into the Glist base class, and so became available for all derived classes,
present and future, to use. I i -i Glist was handy in Translator, then it was reused in Engine runtime support; most
recently, it has become the foundation of the container classes which facilitate representing i. i i ,.
Dynamic: The present MOOSE implementation includes several of dynamic models: 1 S. 1 FBM, EQN, and RBM.
We see needs for other kinds of dynamic models, such as Petri nets, System Dynamics models, F, models, and
perhaps others. There is a requirement that MOOSE be painlessly extensible to new dynamic model i,. The
D,....... '' class is an abstract base I --' in Translator, from which all current dynamic model classes internal to
Translator are derived, and which will facilitate creation of new dynamic model I.. in future.
Portability: Platforms and Languages: We chose two target platforms for MOOS1. the first is Sun Solaris
dialect of System V Unix; the second is Microsoft \\ i,, ...- NT. The code also seems to run under \\ n [...- -'i, but
we do not develop under \\ ,i, T..I- -',i The Unix platform was chosen for convenience, as it is ubiquitous in our
Departmental environment, as it is across academia. The \\ i [1.. - NT platform was chosen because it runs not
only on the IBM-compatible PC with Intel x86 CPU, but also on RISC processors like Digital's Alpha AXP, the
PowerPC, and MIPS RISC.30 For MOOSE programming languages, we chose TclTk for our components with GUI's
(.I .. 1. I. i and Scenario); and, C++ for our back end components (Translator, TTL, and Engine runtime support).
MOOSE back end code has been compiled under : IS Visual C++, Borland C++, Borland Turbo C++, and g++.
6. CONCLUSIONS AND PLANS
TclTk is our programming language for Modeler and Scenario GUI's. As TclTk neither enforces nor facilitates
object-oriented ii. il.1 -; we are looking at ways to retain the benefits of TclTk while improving the i, 11- i1 .iil-
and extensibility of the code. The MOOSE Model Repository (MMR) has been a substantial step in the right
direction, .III ... 1,! from Modeler the job of keeping track of all the details of a model. We will also explore object-
oriented alternatives to TclTk. Scenario has a 'L[t 1 11I job: it must facilitate visualization even though every model
is different in surface appearance. Scenario is also presently written in TclTk so the remarks above regarding lack
of object-oriented support apply as well. Nonetheless, we are working on building a toolkit of popular and reusable
dials, gauges, graphs, and clip art, and are looking at XF and SpecTcl GUI builders. Our HCI needs constant
review and improvement, especially as new immersive technologies beckon. It is a fundamental tenet of MOOSE and
OOPM, that the HCI must fit the model author like a glove. Our objective is to make it fun to use the MOOSE
HCI. Accordingly we are prepared for the HCI to evolve.
The present MOOSE implementation includes several kinds of dynamic models: 1 S. FBM, EQN, and RBM. We
see needs for other kinds of dynamic models, such as Petri nets, Rule based models, FL models, and perhaps
others. A --_! -, ir, and the implications of ,i--_ -,I r.i pose interesting questions, especially as we distinguish
among containment, usage, composition, and association. Although we have significant results, more work lies
ahead. We plan to take MOOSE onto the worldwide web, to distribute model execution. For web-based operation,
a plan is iL 1. i;- to embed distributed model execution within a MOOSE method using CGI (Common Gateway
Interface). We also plan to evaluate a Java alternative in this context.
ACKNOWLEDGE EN IENTS
We would like to thank the following funding sources that have contributed towards our study of modeling and
implementation of a multimodeling simulation environment for ,!, 1- -i- and planning: (1) Rome Laboratory, (; I tI--
Air Force Base, New York under contract 1 ;i.1 C'2-95-C-0267 and grant 1 ;11t1 .'-95-1-0031; (2) Department of the
Interior under grant 14-45-0009-1544-154 and the (3) National Science Foundation Engineering Research Center
(i.1l i1) in Particle Science and T !! !. .1 i - at the U! i i of Florida (with Industrial Partners of the 1. i 1:) under
grant EEC-94-02989. We also acknowledge with thanks the help of Tolga Goktekin for development of the Modeler,
Kangsun Lee in providing assistance with LaTeX and Scenario issues, as well as model development, Gyooseok Kim
for the RBM figure and for discussions regarding ili;.l -, Youngsup Kim for I I;.l editor, and Doug Dillard for the
Life Scenario and other Scenario support.
1. P. A. I i- - !: "I.-.I. i .!i object oriented design for 1!- -i, ,1 modeling," .lIi ._ l....-... : ...f- on M odeling and
Computer Simulation July 1996. Submitted for review.
2. I. Sommerville, q,.f!i ... F.'.,,,' "." ''.. Fourth Ed., Addison-W. -1. 1992.
3. P. A. 1 i-!L !: "The role of process abstraction in simulation," IEEE I ..i. ... on ,n '....A. Man and
C.i, ,. .. 18, pp. 18 39, January/February 1988.
4. P. A. I i-I- i !:, "Abstraction level traversal in hierarchical modeling," in Modelling and Simulation Methodology:
Knowledge ,!t ....i Paradigms, B. P. Zeigler, M. 1.! 1- and T. Oren, eds., pp. 393 -429, 1.!- i. c North Holland,
5. V. Berzins, M. Gray, and D. Naumann, "Abstraction-based software development," Communications of the
I i .1 29(5), pp. 402 415, 1986.
6. P. A. 1 i !-!- .! : and K. Lee, "Two methods for exploiting abstraction in -- A, i- AI, Simulation and Planning
in High Autonomous S.,.,.. ,.i pp. 257-264, 1996.
7. P. A. I i-!h i, !: Simulation Model Design and Execution : Building Digital Worlds, Prentice Hall, 1995.
8. K. Lee and P. A. i i-l!- !: "S. 11 i,11.. i, 1. method for dynamic model abstraction," in SPIE C-,.*f. ...
9. B. P. Zeigler, Object Oriented Simulation with Hierarchical, Modular Models: Intelligent Agents and Endomor-
phic ,!4 !... Academic Press, 1990.
10. G. Booch, Object-Oriented .1 ....1,', and Design with applications, 2nd ed., Addison-W. -1. 1994.
11. A. J. Riel, Object-Oriented Design Heuristics, Addison-W. -1. 1996.
12. B. P. Zeigler, Objects and S., .! .... Springer-Verlag, 1997.
13. B. S, I, ,11-1 ii,, 1!,, C++ Programming Language, second edition, Addison-W. -1. 1991.
14. G. Booch and J. Rumbaugh, U, ', .I Method for Object-Oriented Development, Rational Software, 1995.
15. M. Gardner, ".,I i~Il, 1 it.i i games," '. .!'-;. American, Oct 1970 1970.
16. M. Gardner, ".,I i~Il. ,i i i!,, I games," '. .!' ;. American, Feb 1971 1971.
17. M. Gardner, i !/.. I, Life, and Other Mathematical Games, publisher, 1983.
18. J. D. F !. A. van Dam, S. K. Feiner, and J. F. Hughes, Computer Graphics: Principles and Practice, Addison-
W. -1. 1990. Second Edition.
19. P. A. I -1 !;- i. !: "A visual object-oriented multimodeling design approach for '1!i -1; i modeling," submitted April
1997 to AC .1I ...-..!.. .1.. on Modeling and Computer Simulation, 1997.
20. P. A. I1 -I !: and B. P. Zeigler, "A Multimodel M,, I. 1! .1 ,l for Qualitative Model F! -_;,, ;i .It .1
.......-... ... -on Modeling and Computer Simulation 2(1), pp. 52-81, 1992.
21. P. A. I i-1- i, !: "A Simulation Environment for Multimodeling," Discrete Event D, .....i. S.,. I..' I! .... j and
Applications 3, pp. 151-171, 1993.
22. R. Orfali, D. II il: and J. Edwards, I., Essential Distributed Objects Survival Guide, John \\l. and Sons,
23. R. M. Cubert, "The oosim object oriented simulation library," Tech. Rep. '1I il' !I 1 Uii i -1 of Florida ('1S.
Simulation Group, 1995.
24. P. A. I ,i-! i !: "S,11 !: Getting started with simulation programming in c and c++," in II ,.'., Simulation
C.-.f, .. .. .. WS( ,.' Proceedings, J. J. S. et al., ed., pp. 154-162, 1992.
25. M. H. MacDougall, Simulating Computer ,i, *... : Techniques and Tools, MIT Press, 1992.
26. J. A. P, i Introduction to Simulation : programming techniques and methods of ....... McGraw-Hill, 1982.
27. A. M. Law and W. D. Kelton, Simulation Modeling and I ..1..1-,' McGraw-Hill, 1991.
28. G. S. 1 i-I!! iii Concepts and Methods in Discrete Event Digital Simulation, John \\ i 1. & Sons, 1973.
29. B. International, I ., World of C++, Borland International, Scotts Valley, CA, 1991.
30. K. Siyan, II ./..... NT Server, New Riders, 1995.
Robert M. Cubert is a PhD student in ('1S. at University of Florida. His research interest is object-oriented
distributed simulation. He holds BS degrees in EE from MIT and in 7.. ....- from U ii i -I -I of Oklahoma, and an
IS in Computer Science from University of Oklahoma. He spent 3 years on Computer Science faculty at California
I .- UI i -ii Sacramento, and has a decade of industry experience writing software for realtime control -I. i,-
and data communications.
Paul A. Fishwick is an associate professor in the Department of Computer and Information Sciences at the
Uii i I of Florida. He received the BS in Mathematics from the P. iiii- 1 ,i,, i .. Uii i -1 i IS in Applied
Science from the College I I \\ ii and Mary, and PhD in Computer and Information Science from the University of
P. iiI 1 i 1; in 1986. He also has six years of industrial/government production and research experience working at
Newport News S!iqli L[!, ti! and Dry Dock Co. (doing CAD/CAM parts definition research) and at NASA I. !_1.
Research Center (-ir 1 l- ii engineering data base models for structural ii -i,.. ,iii. His research interests are in
computer simulation modeling and ; ii ,1 -i- methods for complex -. i He is a senior member of the IEEE and
the Society for Computer Simulation. He is also a member of the IEEE Society for Systems, Man and Cybernetics,
ACM and AAAI. Dr. 1I i- I !: founded the comp.simulation Internet news group (Simulation Digest) in 1987,
which now serves over 15,000 subscribers. He was chairman of the IEEE Computer Society technical committee on
simulation (T( 'SI. for two years (1988-1990) and he is on the editorial boards of several journals including the
ACM Transactions on Modeling and Computer Simulation, IEEE Transactions on Systems, Man and Cybernetics,
The Transactions of the Society for Computer Simulation, International Journal of Computer Simulation, and the
Journal of Systems Engineering.