sign in sign up
<<
Home , MOOSE (software)

MOOSE an ob jectoriented multimo deling and

application framework

Rob ert M Cub ert and Paul A Fishwick

DepartmentofComputer Information Science and Engineering

CSE Ro om

University of Florida

Gainesville FL

ABSTRACT

MOOSE Multimo del Ob ject Oriented Simulation Environment is an application framework for mo deling and

simulation under development at University of Florida based on Ob ject Oriented Physical Mo deling OOPM

OOPM extends ob jectoriented program design with and a denition of system mo deling that reinforces

the relation of model to program OOPM is a natural mechanism for mo deling largescale systems and facilitates

eectiveintegration of disparate pieces of co de into one simulation Comp onents of MOOSE are Human Computer

Interface HCI and BackEnd HCI in teracts with mo del author via GUI which

captures mo del design controls mo del execution and provides output visualization Library has a mo del rep ository

and ob ject store facilitating collab orative and distributed mo del denitions and managing ob ject p ersistence The

Back End automatically converts a mo del denition to a complete simulation program in some Translator Target

Language TTL presently C then compiles and links the program it wrote adding runtime supp ort and

creating an executable program which runs under control of the HCI to provide mo del execution Dynamic mo del

typ es include Finite State Machine Functional Blo ck Mo del Equational Constraint mo del and Rulebased Mo del

alternatively mo del authors may create their own C co de metho ds mo del typ es may b e freely combined through

multimo deling which glues together mo dels of same or dierenttyp es pro duced during mo del renement reecting

various abstraction p ersp ectives to adjust mo del delity during development and during mo del execution Underlying

multimo deling is Blo ck as fundamental ob ject Every mo del is built from Blo cks expressed in a Mo deling Assembly

Language

Keywords Simulation Multimo del Ob jectOriented Mo deling Mo del Abstraction Ob ject Oriented Physical

Mo deling Visualization Application F ramework

INTRODUCTION

MOOSE is an acronym for Multimo del Ob ject Oriented Simulation Environment a mo deling and simulation en

abling to ol under development at University of Florida MOOSE is an implementation of OOPM Ob ject Oriented

Physical Mo deling an approachtomodelingandsimulation which promises not only to tightly couple a mo dels

human author into the evolving mo deling and simulation pro cess through an intuitive HCI human computer in

terface but also to help a mo del author to perform any or all of the following to think clearly ab out to

b etter understand or to elucidate a mo del to participate in a collab orative mo deling eort to rep eatedly

and painlessly rene a mo del as required in order to achieve adequate delity at minimal development cost to

painlessly build large mo dels out of existing working smaller mo dels to start from a conceptual mo del whichis

intuitively clear to domain exp erts and to unambiguously and automatically convert this to a simulation program

to create or change a simulation program without b eing a to p erform simulation mo del execution

and to present simulation results in a meaningful way so as to facilitate the other ob jectives ab ove

In some cases mo del design without mo del execution suces to achieve the mo del authors ob jectives whichmay

b e to learn ab out or b etter understand a phenomenon or system or to communicate ab out such a system with ones

colleagues This purp ose is per se justication for the development of MOOSE But usually a mo del author wishes

not only to design a mo del but also to construct a simulation program to p erform mo del execution for reasons which

include to empirically validate the mo del based on observed b ehavior to select or adjust various parameters

and values and observe their eect to measure p erformance to gauge mo del delity and assess its adequacy

In prevalent practice a mo del author makes what is known as a conceptual model often similar to a blackb oard

picture with annotations and uses this mo del to describ e to one or more detailed requirements for

asimulation program to b e written based on the conceptual mo del Programmers then write a program but there

is not necessarily a relation between the conceptual model and the program subsequently produced MOOSE oers to

improve this situation MOOSE assists the mo del author with constructing the conceptual mo del and then builds

a simulation program in an unambiguous way from the conceptual mo del MOOSE thus provides a mapping from



conceptual mo del to simulation program Advantages include builtin mo del validation partial automation

of the development pro cess allowing mo del authors and programmers to fo cus on the dicult rather than on the

tedious easier accommo dation to change leading to a view of change as acceptable instead of as a threat

reducing the resp onse time asso ciated with system development allowing the mo del author to eectively drive the

development pro cess



The amount of detail in a mo del reects the mo del authors abstraction p ersp ective Renement to greater detail is



used to obtain mo del delity that is adequate in the eyes of the mo del author from a given abstraction p ersp ective



and with certain ob jectives for the mo del or simulation to meet MOOSE addresses this area with multimodeling

an approach which glues together mo dels of the same or dierent typ es pro duced during the activity of mo del



renement and reecting various abstraction p ersp ectives Renement can b e adjustable during mo del execution

as well as during mo del design The pieces that are put together to form a mo del such as describ ed ab ove are

dynamic models Dynamic mo del typ es supp orted include Finite State Machine FSM Functional Blo ck Mo del

FBM Equational ConstraintModelEQN and Rulebased Mo del RBM alternativelyusersmay create their

own C co de mo dels mo del typ es may b e freely combined The dynamic mo del typ es implemented so far form



a p opular collection of approaches used in simulation Additional dynamic mo del typ es are certainly in order and

will likely b e added to the MOOSE rep ertoire

Reuse of ones own previous work as wellasby one mo del author of the work of others is encouraged byavailability

of mo del rep ositories These form a resource of growing value as MOOSE matures For example the b oiling



water mo del is an FSM multimo del part of whichisshown in Fig Later we implemented a mo del of Rob ert



Fultons steamship whose FBM app ears in Fig When the Fulton mo del was built the b oiling water mo dels

Pot reemerged 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 suchaway that a class is not used in isolation but

within a design encouraged and supp orted by the framework The MOOSE Mo del Rep ository MMR is aptly named

b ecause it is not just a class library as a mo del rep ository it stores not only a collection of classes available for reuse

but also the design which relates those classes as to howtheyplay together within the geometry and dynamics of a

particular mo del This enables supp ort for one of Bo o chs ve attributes of a complex system p A complex

system that works is invariably found to have evolved from a simpler system that worked A complex system

designed from scratchnever works and cannot b e patched up to makeit work Using MMR mo del authors can

start from some piece of their overall system that happ ens to app eal to them intuitively When several such pieces

are working they may b e combined into a morecomplex working system

Comp onents of MOOSE fall into three groups Human Computer Interface HCI Library and Back End The

HCI is comprised of two comp onents Mo deler and Scenario Modeler interacts with the human mo del author via

graphical user interface GUI to construct the mo del In simulation parlance this is model design Mo deler relies

on the Library discussed b elow to store mo del denitions Scenario is a visualization enabler employing a GUI

Scenario activates and initializes simulation mo del execution which we call Engine at the b ehest of user who

mayormay not b e the original mo del author Scenario maintains synchronous interaction with Engine displaying

Engine output in a form meaningful to user optionally allowing user to interact with Engine including mo difying

simulation parameters and changing the rate of simulation progress The BackEndhastwo comp onents Translator

and Engine Translator is a bridge b etween mo del design and mo del execution Translator reads from the Library

a languageneutral mo del denition pro duced by Mo deler and emits a complete computer program for the mo del

in Translator Target Language TTL Presently MOOSE TTL is C potentially TTL can be Javaoranother

language This simulation program emitted byTranslator is called Engine Its source language is TTL presently

C Once compiled and linked with runtime supp ort the Engine executable program is activated under control

of Scenario to p erform mo del execution The Library has two comp onents MOOSE Model Repository MMR and

k of MOOSE Object Store MOS MOS holds ob ject data and MMR holds ob ject metadata MMR keeps trac

mo dels as they are b eing built MMR servers provide a management system DBMS for mo del denitions

MMR clients work with Mo deler and Translator to dene and use mo del denitions Mo dels and mo del comp onents

created by other mo del authors or the same mo del author previously are available for browsing inclusion andor

reuse Base classes such as sets for mo deling collections and p opular geometries for spatial mo dels are available

to the mo del author An MMR clientcansimultaneously maintain conversations with several MMR servers each

on a dierent machine which p ermits mo del denitions to be distributed An MMR Server can simultaneously

maintain conversations with several MMR clients on the same or dierent hosts which p ermits collab oration on

MOS works with Engine and mo del development MOS do es for ob jects much of what MMR do es for mo dels

Scenario in similar fashion to the wayMMRworks with Mo deler and Translator MOS manages ob ject p ersistence

Although the architecture p ermits MOS to b e capable of distributed op eration just like MMR this is not our present

fo cus in MOOSE thus MOS op erates in supp ort of mo del execution on a single host only at this time

There are two kinds of distributed op eration to consider one is where mo del denitions are distributed with some

classes dened here others there the second is where mo del execution pro ceeds as a distributed simulation executing

simultaneously on a numberofhostswith one ob ject instantiated here another there The MOOSE architecture

supp orts b oth kinds of distributed op eration The present implementation supp orts distributing denition of multi

mo dels as this is our primary researchfocus

The balance of this chapter is organized as follows section explains how an Ob ject Oriented approachis used

by MOOSE to capture the geometry and dynamics of a mo del section explains how MOOSE uses multimo dels

to facilitate mo del renementtoachieve appropriate levels of mo del delity section describ es the comp onents of

MOOSE in some detail and howtheyinteract section covers some imp ortant MOOSE internal classes as well as

our chosen platforms section is our conclusions and plans

AN OBJECTORIENTED APPROACH TO INTEGRATING MODEL GEOMETRY

AND DYNAMICS

An Ob ject Orien ted Approach

MOOSE is the implementation of a simulation environment built using the OOPM design philosophy Classes and

ob jects in the digital world b eing built corresp ond to classes and ob jects in the real world being mo deled This

Modeler Translator Model Author MMR

MOS Library

Scenario Engine

HCI Back End

Figure The three comp onents of MOOSE HCI Library and Back End are shown outlined with dashed line

boxes Parts within eachcomponent are shown outlined with solid b oxes within HCI Human Computer Interface

app ear Mo deler and Scenario within Back End app ear Translator and Engine within Library app ear MMR MOOSE

Mo del Rep ository and MOS MOOSE Ob ject Store Principal interactions are shown with arrows The most

imp ortant element is the mo del author who app ears at left interacting with b oth parts of the HCI

approachhasbeen found to not only b e intuitively app ealing to mo del authors but also to b e both eectiveand

ecient at capturing the elements of meaning which must be represented in the mo del Dynamic mo dels are an

extension to OO metho d static mo dels in the form of Abstract Data Typ es without dynamic b ehavior are an

extension to OO attribute

As class and ob ject identication are p erformed the mo del author is encouraged to explicitly recognize relations

among classes Most notable among these relations are sp ecialization or generalization and aggregation

Specialization is the relationship of derived class or sub class to base class such as an orange is a kind of fruit

Generalization is just the reverse such as Truck and Airplane are kinds of Vehicle Aggregation comprises not

one but several sometimes overlapping relations in the system b eing mo deled including containment composition



usage and association such asaCarhas Wheels the Mo on is made of GreenCheese a Customer uses an

automated teller machine ATM and a Teacher is associated with a University resp ectively Sometimes deciding

which particular relation applies is a gray area in any event relations should not be examined in a vacuum but

rather in the context of the mo del b eing built Containment a Car contains an Engine Litmus test do es

behavior of Car dep end in fundamental wayon Engine Yes is Engine inside or part of or attached to Car

Yes hence containment Comp osition a Basket is comp osed of Straw Contrast this with a Basket contains

Fruit hence not containment as the Straw forms the b oundary not the contents Constituent in a constructive

sense Usage a Person uses an ATM Litmus test do es b ehavior of Person dep end in fundamental wayon

ATM No is the ATM inside or p ermanently attached to the Person no Hence usage Asso ciation a Car

has a Manufacturer Litmus test do es b ehavior of car dep end in fundamental way on GM No Is General

Motors inside my Car No Do es the Car have an ongoing use for GM No although one can think ab out

recalls andor suing GM for defects but this is not within the ambit of Car b ehavior in most systems b ecause its

the owner who sues not the Car which sues and its GM which recalls the Car not vice versa

Sometimes these distinctions cannot b e drawn with certainty and sometimes the mo del can b e elucidated completely

without deciding the issue but discussing the nature of relations thinking ab out them and a reasonable amount

of eort sp ent in attempting to categorize the aggregations within a mo del is often a useful exercise b ecause of the

light it sheds as the discussion and debate unfold

An example of drawing such distinctions is containmentby reference vs asso ciation by referential attribute

Both are p ointers so there is no implementation issue but the dierence is with regard to lifetimes in the rst case

the ob ject contained by reference should live and die with the containing ob ject in the second case the ob jects have

indep endent lifetimes This distinction may b e useful for the mo del author to recognize

Teacher Teacher

A many V Adjunct

Students Style University Professor Lecturer

a b

Figure Class relations depicted graphically as they would app ear on a MOOSE HCI canvas to a mo del author At

left is aggregation at right generalization viewed upwards or sp ecialization viewed downwards The aggregation

relation is symb olized by the lled square the sp ecialization or generalization relation is symb olized by the lled

circle The small b oxes just ab oveeach class in the aggregation sp ecify cardinality which is explained in the text

This aggregation in words a Teacher has many Students has a Teaching style and has an asso ciation with a

University The sp ecialization in words Professor Lecturer and Adjunct are all kinds of Teacher

 

Sp ecialization and Generalization relation have b een thoughtfully investigated Aggregation ab ounds in most

mo dels we have encountered and we have found it to be of fundamental imp ortance to the pro cess of mo deling

Aggregation has also received attention although less so than sp ecialization generalization Aggregation has

received and continues to receive keen scrutinyaswe develop MOOSE under OOPM principles

As MOOSE is requiring the mo del author to communicate relevant ob ject identication and relations it is building

a conceptual mo del which can be a handy representation for the mo del author And this kind of blackb oard

mo del is often useful for one p erson involved in a pro ject to communicate with his or her coworkers Yet two other

imp ortant things are going on as the mo del takes shap e b efore his or her eyes the mo del author often gains

understanding as represented in the aphorism the b est way to learn something is to have to explain it to someone

else and a mo del description is b eing constructed which although indep endentofany is

nonetheless unambiguously and automatically convertible to a simulation program in some programming language

eg C when the mo del author wishes to do so Making explicit the classes and ob jects and their relationships

often sheds light on what is being mo deled and surfaces questions and ambiguities which must be addressed to

achieve the mo deling or simulation ob jective This is part of what is meant by tightly coupling the mo del author

into the mo deling and simulation developmentloop

Attributes Abstract Data Typ es and Containers

Attributes are dened for each class In addition to the primitive data typ es integer real and string MOOSE

also p ermits arbitrary abstract data typ es ADT to b e attributes These ADTs are just classes like all the other

classes in the mo del and they play an imp ortant role in representing aggregation Wehaveseveral ways in MOOSE

to represent aggregation as w e create the constituent elements as attributes of the aggregate class A decision as to

the b est representation rests on answers to questions such as whether the numb er of items of a constituenttyp e is

one eg acar has one steering wheel or more than one eg acarhas four tires whether the numberofitems

of a constituenttyp e elements is known in advance and xed numb er of cells on a checkerb oard or is inherently

variable a p opulation of deer

When sp ecifying aggregation the mo del author can cho ose from several cardinality alternatives for each aggregated

class many causes a container to b e created which holds contained ob jects of the aggregated class a value suchas

also causes a container to b e created but additionally automatically p opulates the container with the designated

number of contained anonymous ob jects A causes an asso ciation meaning a referential attribute which is a reference

p ointer to a named ob ject whose lifetime is indep endent of the lifetime of the ob ject of the aggregating class V

indicates containmentvalue which generates a value attribute within the aggregating class When the cardinality

of an aggregated class is one an ADT attribute will b e created in the aggregating class but a choice remains b etween

value and reference In the rst case an ob ject of the aggregated class is created at the constructor time of the ob ject

of the aggregating class This suggests the lifetime test as a decision criterion If the aggregated ob ject will havea

lifetime which is indep endent of the lifetime of the aggregating ob ject then an asso ciation represented by a reference

p ointer is in order It is also p ossible for mo del author to cho ose a referential attribute when the lifetimes coincide

but then it will b e mo del authors resp onsibility to manage ob ject destruction Because this is usually an unwelcome

dutyvalue attributes should b e chosen whenever p ossible

A second criterion is the name test If the ob ject of the aggregated class needs to b e a named ob ject created in

another part of the mo del by the mo del author then a referential attribute also represented by a reference p ointer

is in order irresp ective of the lifetime issue Yet wehave found that named ob jects are the exception rather than the

rule b ecause names are often not a necessity named ob jects force more work onto the mo del author and unnamed

ob jects are still accessible as or within attributes of their aggregating class Wehave found that MOOSEs abilityto

create these anonymous objects is quite useful An example is a collection of individual mo dels of freeroaming

entities such as p olymers on a substrate or deer in a forest In b oth cases the mo del author considers the ob jects a

fungible collection and has no need to provide each of the ob jects with unique names MOOSE supp orts this

with containers

When there are multiple and esp ecially when there are an uncertain numb er of items of a kind an abstract data typ e

whichisaContainer class b ecomes the typ e of the attribute This container class attribute holds elements of the

contained typ e For example Tires a tire container might hold four tires and this tire container is an attribute of

the class Car Alternatively DeerPopadeercontainer might hold anynumb er of deer and this deer container is an

attribute of the class Everglades Container classes have b een found to b e an eectiveway to represent an imp ortant

asp ect of aggregation Provision is made in MOOSE for optional automatic p opulation of containers at constructor

time and alternativelytoallow the mo del author an optional co de fragment to app end to the constructor to instead

allow custom initialization of containers if required Container classes can b e sp ecied directly by the mo del author

such as the DeerPop example ab ove or are created automatically by MOOSE based on cardinality such as the

Tires example ab ove where the user actually only created the Tire class but mentioned that the cardinality is four

Containers have inherent b ehavior in MOOSE they knowhow to send information to their contained ob jects they

know how to execute one or more metho ds of their contained ob jects they know how to select a subset of their



contained ob jects based on some criterion This b ehavior is along lines discussed by Zeigler

Another asp ect of aggregation is ho w to relate an attribute of an aggregating class with the corresp onding attribute in

its aggregated classes when such corresp ondence exists In contrast to a delegation function which is a metho d of an

aggregating class that simply passes through a metho d to an aggregated class here we similarly have a metho d of an

aggregating class that has the same name as a metho d of an aggregated class however here the problem is to invoke

the corresp onding metho d of every aggregated class and in some way transform the results into an overall result for

the aggregating class This problem necessarily includes the problem of a container obtaining such information from

all its contained ob jects whichwehavesolved The container problem is easier b ecause all contained ob jects are

homogeneous and can b e dealt with in the same way This suggests the solution which istoderive all aggregated

classes from a base class which has the desired functionality and then package all the ob jects of the various aggregated

classes into a single container whose contained class is the common base class which has the requisite functionality

An example is biomass in an ecosystem simulation A deer has a biomass whichisitsweight Our deer p opulation

in the example ab ove thus has a total biomass which is the sum of the weights of every individual deer Moving

to higher levels of aggregation the Everglades has a biomass which is the sum of the biomasses of all p opulations

in the mo del Here the relation is summation and the base class common to deer and sh and sawgrass has this

functionality While summation is a p opular example it is by no means unique amodel author is free to sp ecify

whatever functionality is appropriate to the mo del

Capturing the Geometry of a Mo del

MOOSE is based on OOPM and OOPM in turn has a number of tenets two of its most imp ortant relate to

geometry and dynamics Geometry relates to space and Dynamics has to do with temp oral evolutions We rst

discuss MOOSE mo del geometry Geometry is represented by static mo dels in the form of Abstract Data Typ es

without dynamic b ehavior as an extension to OO attribute When asimulation involves a world where entities

interact and evolveover a eld with the eld often inuenced and changed by the presence and activities of the

entities one usually thinks of mo del geometry in the conventional sense of dening prop erties of the space over which

the eld is dened and through whichtheentities move This is certainly one form of mo del geometry and one which

 

MOOSE supp orts An example of this kind of simulation is John H Conways b oard game Life whichhas

b een implemented as a MOOSE mo del A complete explanation of the game is not feasible here but the interested



reader can learn details from the references Summarizing the mo del the Game is an aggregation of or has a

Board and Rules Board in turn has a container Cel ls and a BoardGeometry Cells container in turn contains many

individual Cel l ob jects BoardGeometry maps the real lo cation or identity of Cell ob jects in the Cells container

onto dimensional space Rules tells the Game howtotakeeach cell on the b oard from one tick of the simulation

clo ckto the next eg birth death This illustrates that MOOSE can mo del any space by mapping elements of

a container class of individual region ob jects onto a space of any sp eciable complexity In Fig a a general

framework is shown which applies to mo dels we call cellular Such mo dels are characterized as eld mo dels

and typically involvesomekindofphysical space with a certain geometry a collection of entities that roam over the

space p ossibly interacting with one another and the space itself and all of this evolving over time in accordance with

some laws which include initial and physical b oundary conditions An imp ortant subset of the cellular framework

applies when the dimensionalityistwo A framework for this subset which we term landscap e is shown in Fig

b The Life mo del was constructed from the landscap e framework MOOSE considers geometry not only in the

narrowconventional interpretation ab ove but also in a broader sense the space under consideration can b e a space

other than a physical space rather it can b e a space over which classes andor ob jects relate MOOSE is capable

of mo deling this sort of geometry as well through class denitions and relations among classes World Space Geometry

many V V Entity Space Laws Landscape

many A A

Cell Geometry MooreGeom

a b

Figure At the left is a MOOSE mo del that serves as a very general framework for a large variety of eld mo dels

whicharecharacterized byamultidimensional space over which entities range interacting with one another and

aecting the prop erties of the space in accordance with initial and b oundary conditions called Laws The space

is sub divided into cells and has a geometry At the right is a sp ecialization of the cellular mo del in which the

space is twodimensional and the geometry is that of a Moore Neighborhoodinwhich each cell has eight immediate

neighbors This mo del is encountered frequently so it to o has b een given a name Landscap e A Landscap e is a

kind of Space A Landscap e has a Mo ore geometrywhich is a kind of Geometry

The fo cus on MOOSE so far is in supp ort dynamic multimo dels but weenvision equal supp ort for static multimo dels

in the future Static multimo dels will dene geometry and semantic netw orks appropriate for an ob ject For example



the hierarchy tree is an example of a static mo del To fully supp ort static mo dels we will need to facilitate

aggregation and inheritance in ob jects as well as in classes

Capturing Dynamic Behavior of a Mo del

Classes would b e uninteresting indeed without metho ds In MOOSE these detailed asp ects of every class maybe

readily added changed and removed as part of mo del development at anytime Dynamic b ehavior of the system

is represented by dynamic models Here MOOSE makes go o d its promise to the mo del author to b e able to create or

change a simulation program without b eing a programmer MOOSE presently incorp orates several kinds of dynamic

mo del FBM FSM EQN and RBM with others contemplated suchasPetri nets and System Dynamics mo dels

From this ensemble of p opular and capable dynamic mo del typ es the mo del author picks one or more dynamic

mo del typ es to dene metho ds of the classes of the mo del Construction of each sp ecic dynamic mo del typically

involves drawing the kinds of pictures that p eople tend to makeonthebackofanenvelop e or a blackb oard when

informally describing a mo del to someone else The MOOSE HCI facilitates these constructions allowing the mo del

author to sp ecify comp onents connect comp onents provide inputs outputs conditions and so forth

Functional Blo ck Mo del FBM

AFunctional Blo ck Mo del FBM is constructed when the mo del author so designates a metho d eg Mj of some

class eg Ci The FBM editor enables the mo del author to construct the FBM for CiMj Basic to an FBM is

its blo cks The following are eligible to serveasblocks of the CiMj FBM metho ds of Ci itself metho ds of

anyvalue attribute of Ci which is an abstract data typ e ADT metho ds of anyreferential attribute of Ci which

is an ADT and metho ds of other asso ciated classes The rst two groups are b ound at class declaration time

The last two groups require or at least p ermit dynamic binding

The mo del author identies each functional blo ck of the FBM from the p o ol of eligible blo cks The blo cks app ear on

the canvas as rectangles likechips on a circuit b oard Inputs and outputs of eachblocklooklike the pins on a chip

The next job of the mo del author is to connect the various pins with traces forming the top ology of the FBM

Blo ck outputs are connected to blo ck inputs FBM inputs are connected to blo ck inputs Blo ck outputs are selected

Block Trace StateTransition Predicate

a b

Figure MOOSE Dynamic Mo dels On left a Functional Blo ck Mo del FBM On right a Finite State Machine

FSM

Figure MOOSE HCI Mo deler GUI Editor for FBM showing part of Fulton steamship mo del with functional

blo cks for Boiler Turbine Condenser and Pump

as outputs of the FBM Cycles are p ermitted in which case the value at one time step propagates to the next time

step

Several interesting collections are available to serveasblocks One such collection is the control collection consist

ing of Add Subtract Multiply Divide Integrate Constant PseudoRandom and Accumulate Another collection is

the queuing collection consisting of Source Sink Fork Join and Facility Yet another collection is the owchart

collection consisting of Begin End Decision Pro cess and Auxiliary The rst collection is useful for building FBMs

for control applications The second collection is useful for simulating traditional queuing mo dels The third collection

is useful for constructing mo dels from owcharts FBMs can b e constructed without using any of these collections

but these collections are available as readytouse comp onents for those who are familiar with this mo deling metaphor

and wish to stay with it within the context of MOOSE

Finite State Machine FSM

A Finite State Machine FSM is constructed when the mo del author so designates a metho d of some class The

FSM editor enables the mo del author to construct the FSM An FSM consists of states Eligible to app ear as a state

of an FSM are the same groups as are eligible to app ear as blo cks of an FBM discussed ab ove After all states have

b een created and identied by the mo del author they app ear on the canvas as circles

When states are in place the mo del author constructs transitions b etween them These transitions lo ok likearrows

If the arrowpoints from state to state this corresp onds to a transition of the FSM from state to state On

each FSM transition the mo del author places a predicate logical expression If the FSM is in a particular state and

a predicate on one of its outb ound transitions is true then the FSM transitions to the state to which that transition

points Awellconstructed FSM should hav e no more than one outgoing transition true at any time If several such

Figure MOOSE HCI Mo deler GUI Editor for FSM showing part of boiling water mo del with states for Heating

Co oling Boiling and Exception predicates dening FSM state transitions app ear as text near the tiny circles on

arcs Boiling water mo del is one comp onent of Fulton steamship mo del this FSM is actually inside the Boiler

functional blo ck of the FBM shown in the previous gure

transitions are true in a MOOSE FSM an arbitrary transition from among the transitions with true predicates is

selected

Rule Based Mo del RBM

A Rule Based Mo del RBM is constructed when the mo del author so designates a metho d of some class The RBM

editor enables the mo del author to construct the RBM An RBM has a numb er of rules Each rule is in the form

of a a conditional expression if premise then consequence The RBM editor main window creates anynumber of

rule templates in this form and sets up each premise and consequence to allow the mo del author to cho ose any

premise or any consequence to elab orate a new rule or to change an existing rule When the mo del author cho oses

a premise he or she enters a premiseediting window with various widgets that facilitate picking eligible items from

lists sp ecifying relational and logical op erators A premise maybe a simple logical expression or something more

complicated if the latter then the premise b ecomes a blo ck The mo del author also denes each consequence using

a consequenceediting window Each consequence is either a simple statement or something more complex if the

latter as is usually the case the consequence is a blo ck The ability to connect to blo cks in this way ts RBMs

into m ultimo deling hierarchies to b e discussed b elow

Figure MOOSE HCI Mo deler GUI Editor for RBM Rule Based Mo del showing the RBM editor main window

In this window the mo del author has decided to construct three rules which the editor has constructed as shown

The rst of these rules has b een turned from a template to an actual rule by the mo del author The other two

rule templates remain available By clicking on a premise the mo del author can edit the premise part of a rule

in the premiseediting window not shown similarlyby clicking on a consequence the mo del author can edit the

consequence part of a rule in the consequenceediting window also not shown A premise can be a blo ck A

consequence is always a blo ck Thus RBMs t into multimo dels just like other dynamic mo del typ es

Equation Constraint Mo del EQN

An Equation Constraint Mo del EQN is constructed when the mo del author so designates a metho d of some class

The EQN editor enables the mo del author to construct the EQN mo del A system of any number of nth order

dierential equations maybeentered using an intuitivesyntax Dierential equations are represented using symbols

such as x x for the rst derivative of x x for the second derivative of x and in general x followed by n single quote

marks to denote the nth derivativeofx Several variables may b e used The output of the system maybeany order

derivativeofanyvariable If a variable used in the system of equations also happ ens to b e an attribute of the class

to which the EQN mo del b elongs then at the b eginning of the computations of the EQN mo del at each time step

the EQN mo del is loaded with the value of that variable and when the computations are completed for that time

step the value is senttothatvariable

In addition to variables and their derivatives a set of equations maycontain additive and multiplicative parameters

and input signals Parameters may be attributes of the class to which the mo del belongs or they may be input

parameters to the EQN metho d or they maybeblocks with eligibility the same as was set forth in detail for the

FBM ab ove This will b e discussed more fully when multimo deling is considered in a later section

Co de Metho ds

Although promising mo dels without programming MOOSE also tries to b e tolerant and exible Thus if none of

the dynamic mo del typ es suits the mo del author is free to write what are termed co de mo dels or co de metho ds

A co de metho d is a function body written in the TTL used for the MOOSE system Presently this language is

C MOOSE design ideology suggests that co de metho ds b e the exception rather than the rule Typical use of a

co de metho d is to provide that one small piece of some mo dels that cannot b e describ ed using the available dynamic

mo del typ es and to rely on dynamic mo dels for the rest in a way that is analogous to construction of an Op erating

System kernel in a high level language with just a few assemblylanguage routines where needed

FACILITATING MODEL REFINEMENT

Constructing a mo del is almost always an iterative pro cess with mo del structure taking on a treelike app earance

The broadest description of the mo del is like the ro ot of a tree One then typically decomp oses this broad but

nebulous description into sub ordinate parts each part being a renement of the mo del in the broad description

statement The result typically is a tree with some leaves near the ro ot and others farther down Thus the level

in the tree is related to the level of abstraction which one asso ciates with thinking ab out and describing the mo del

To supp ort the kind of heterogeneous mo del hierarchies shown abstractly in Fig wemust ensure that our mo dels

are closed under coupling In short this suggests that the metho d of coupling one mo del comp onent to another

must be clearly dened Two kinds of coupling exist intralevel and interlevel Intralevel coupling reects mo del

comp onents coupled to one another in the same mo del For example one needs to sp ecify rules of howPetri nets

Figure Multimo deling tree structure for mo del renement Selective renements achieve required delity

Extensibility facilitates mo del development Polygons ab ove depict the heterogeneous nature of multimo deling each

typ e of p olygon represents one typ e of dynamic mo del

compartmental mo dels and System Dynamics graphs are formed With a System Dynamics graph a rule of mo del

building denes that any level has an input rate and an output rate A more interesting case arises in interlevel

coupling since wemust ensure that we dene rules as to how mo del comp onents from one mo del can b e rened into

mo dels of dierent typ es Can a nite state machine state be rened into a Petri net or can a functional blo ck

mo del contain nite state machines FSM inside blo cks What are the rules to guide this renement The rule for

intralevel coupling is based on functional comp osition The primitiveof function with its input and output denes the

coupling pro cedure in the following way All mo dels are encapsulated in a single function Fig demonstrates this

functional blo ck encapsulation This represents the outer shell to supp ort interlevel coupling Within a mo del there

Each mo del typ e are functional entry points These are inner shells where new mo dels may b e optionally inserted

has its own entry p oint dened dierently For example for the mo del typ e FSM wemay dene each state to b e

of the form v statef where f is an arbitrary function and v state denes the value of the attribute state

If state is not rened then f returns the value of the state as a character string or integer If state is rened then

f may b e replaced by any functionwhether this function is a dynamic mo del or a co de metho d The coupling

approaches are dened in more detail by Fishwick

Resources are limited and by this we mean b oth mo del development resources and simulation runtime resources

Thus one typically renes using a breadthrst approach and this treelike structure accordingly takes on an uneven

shap e with some parts of the tree b eing of greater height and others b eing of shorter height reecting the underlying

decision criterion which is to rene only as much as needed to achieve required levels of mo del delity But knowing

what is needed to achieve required levels of mo del delity often requires iterating through several mo del designs

and even measuring p erformance of the mo del execution Multimo deling can b e used in the development pro cess

to conservevaluable development resources including time by limiting the depth of some subtrees and to provide

a topdown skeleton within which developmentmay pro ceed A rude shallowmodel can be run and analysis can

pinp oint those mo del subtrees where additional delity is needed This is an adaptivemechanism to fo cus and guide

development The evolving mo del is thus its own prototyp e It neednt b e discarded as in throwaway prototyping

nor do es it suer the chaos that often accompanies the exploratory prototyping or exploratory programming



approach

 

Thus MOOSE provides facilities for multimo deling by which we mean mo del renement into more detailed



comp onent mo dels reecting a numb er of abstraction p ersp ectives This is a very intuitive concept most p eople

multimo del without thinking ab out it yet they do b enet from encouragement in this direction and esp ecially from

x’ = a*x + u x’

+

*

ax u

refinement candidate

Figure This gure illustrates a simplistic equation constraint mo del The purp ose is to indicate multimo deling

in this dynamic mo del typ e The rectangles representing parameters and inputs a and u resp ectively are eligible

to b e renement candidates in other words eachofthemmaybeblock which is a complete dynamic mo del in its

own right

automatic management of the resulting complexity The multimo del denition is recursive renement pro ceeds

as far as needed By facilitating this kind of work and encouraging this kind of thinking MOOSE contributes to

management of the mo del extending or reducing mo del renementatany stage of the game Typically renement

is extended when delity is inadequate and is reduced when the simulation takes to o long to execute Nowhaving

explained multimo deling in general we pro ceed to a sp ecic taxonomy There are two p ersp ectives from which one

maylookatmultimo deling time of binding and dynamic mo del typ e Each p ersp ective leads to a dichotomy The

overall result is a small taxonomywhichwillnow b e presented

Multimo del dichotomy based on time of Binding In a temp oral sense regarding the time at which the level

of renement is b ound or xed MOOSE recognizes two kinds of multimo del xed structure and variable structure

Fixed Structure Multimodels The evolution of mo del renement that takes place over the mo del development life

cycle results in a xed structure multimo del that is wechange the mo dels structure from time to time but whenever

we build a simulation program representing the mo del we freeze mo del structure as of that time Of course wecan

change it later and build a new simulation program but the xed structure multimo del p ersists until this is done

The second kind of multimo del is the Variable Structure Multimodel and the MOOSE runtime environment supp orts

this kind of multimo del to o Avariable structure multimo del changes its renementonthey in resp onse to system

constraints Atypical constraint is a realtime constraint on when the simulation must complete Presently MOOSE

do es not provide the executive logic which decides when to change renement depth but given such logic MOOSE

has the capability to recongure mo del renement on the y Others are presently working on providing this logic



for MOOSE

Multimo del dichotomy based on typ e of Dynamic Mo dels When a mo del is rened eachlevel is usually

describ ed by one or more dynamic mo dels Each dynamic mo del is of some typ e eg FSM If all the dynamic mo dels

yp es then the are of the same typ e then the multimo del is homogeneous If the dynamic mo dels are of dierentt

multimo del is heterogeneous In Fig for example the multimo del depicted is heterogeneous

THE COMPONENTS OF MOOSE

Intro duction

MOOSE has six comp onents which fall into three groups Human Computer Interface HCI Library and Back

End Each group has two comp onents The HCI is sub divided into Mo deler and Scenario Mo deler constructs a

mo del Scenario runs it The Library is sub divided into MOOSE Mo del Rep ository MMR and MOOSE Ob ject

Store MOS MOS holds ob ject data and MMR holds ob ject metadata MMR keeps track of mo dels as they are

b eing built MOS keeps track of ob jects as mo dels execute The Back End is sub divided into Translator and Engine

Translator converts a mo del denition to a program Engine is that program

Mo deler

The Mo deler comp onent of the MOOSE HCI interacts with the human mo del author via a graphical user interface

GUI to construct a mo del In simulation parlance this is model design Mo deler relies on the MOOSE Mo del

Rep ository MMR discussed b elow to store mo del denitions as they are constructed and also relies on MMR to

provide reuse comp onents develop ed elsewhere by others or earlier by the mo del author The Mo deler GUI is a

comp osite the main part denes classes and ob jects and relations among classes aggregation and sp ecialization

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 reecting the relations in the system b eing mo deled Some

mo dels lo ok cleaner if aggregations and sp ecializations are kept on separate canvases this is supp orted but not

required Similarly some mo dels are large enough that several canvases are needed to capture the representation

Each class is a b ox which when op ened reveals more information and p ermits the mo del author to dene the name

of the class its attributes its metho ds and its named ob jects Within each metho d the mo del author may sp ecify

input parameters and output parameters as well as identifying which dynamic mo del typ e the metho d is to b e In

addition to the main GUI presented ab ove there is a GUI editor for each dynamic mo del typ e ie the FSM

editor for nite state machines the FBM editor for functional blo ck mo dels the EQN editor for equation constraint

mo dels and the RBM editor for rulebased mo dels

Besides dynamic mo dels FSM FBM EQN and RBM the mo del author may also select co de metho ds ordinary

co de metho ds CODE constructor CSTR and destructor DSTR For these co de metho ds MOOSE provides a

text editor which p ermits the b o dy of each such metho d to b e co ded 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 mo del

author is free to use his or her favorite text editor to mo dify these co de metho ds Because the emphasis in MOOSE

is on dynamic mo dels not co de metho ds reliance on co de metho ds should be minimal in most mo dels But as

MOOSE philosophy is to facilitate rather than dictate the co de metho ds are available as the mo del author sees t

to use them

The ow of information b etween Mo deler and the mo del author is denitely bidirectional If the mo del author builds

a mo del from scratch then the information owis from mo del author to Mo deler We exp ect this not to be the

usual situation When the mo del author go es shopping for reusable comp onents to include or a previous mo del to

mo dify then the information ows from Mo deler to mo del author

Rep ository MMR MMR has a Central to Mo delers ability to ow information b oth ways is MOOSE Mo del

clientserver architecture and Mo deler is one of its clients Mo deler communicates via pip es with an MMR proxy

it starts as a subpro cess An MMR proxy is thus dedicated to this one instance of Mo deler The MMR proxy

resp onds to requests from Mo deler obtaining MMR services from one or more MMR servers whichmaybe lo cal

or remote In this way Mo deler has access to mo del denitions develop ed earlier here or elsewhere for reuse

Thus small working mo dels can b ecome elements of the mo del under constructions or a large working mo del can

a b

Figure In this view of the MOOSE HCI the Mo deler GUI is shown for a landscap e ecology mo del in which

apple snails in Floridas Everglades are mo deled as a collection of p opulation mo dels each within a spatial cell Cells

tessellate the p olygon that represents the marchenvironment of the Everglades Apple snails are an imp ortantfood

of wading birds and wading birds b ehavior are studied using a multimodel one piece of which will be the apple

snail mo del On the left the Mo deler canvas showing classes and their relations Aggregations aPolygon has a

geometry some Cells and manyEntitys a Marsh has a Hydrology Sp ecialization a Marsh is a kind of Polygon

On the right the view inside one of the classes is shown This is available by doubleclicking the class on the canvas

Information ab out attributes metho ds and instantiated ob jects app ear

b e mo died to a new purp ose

As Mo deler receives information from the mo del author it is retained not in Mo deler itself but in MMR Mo deler

tells MMR whatever it learns of the mo del and later queries MMR when it needs information to display the mo del

This allows Mo deler to fo cus on its essential GUI mo del denition job rather than having to b e in the DBMS business

A go o d example is when a named ob ject is created in some class which happ ens to b e derived from a sp ecialization

of one or more base classes When the mo del author displays the ob ject with the intention of viewing its metho ds

a recursivetraversal is done up the generalization hierarchy b ecause metho ds of the ob ject include not only the

metho ds of its class but also the public and protected metho ds of its bases classes Mo deler gains this knowledge

from a query to MMR All such metho ds come back to Mo deler including their names and parameter lists Thus the

display includes the names and parameter lists of the metho ds of the ob ject as required without Mo deler having to

maintain this information explicitly

As a mo del author develops a mo del one go o d mo de of action is develop a little translate and save These steps

are then rep eated as the mo del grows It is go o d practice to translate every so often to check for errors If the change

from the previous version is small it facilitates lo calizing the source of such errors If for any reason the mo del

author cannot resolve such errors an option then exists to discard the latest change reverting to the previous saved

version A second development mo de is develop a little translate execute save Again these steps are rep eated as

the mo del grows The pro cedure is similar to that ab ove except this time the mo del author has the opp ortunitynot

erify the exp ected runtime b ehavior Again taking suciently only to surface translation time errors but also to v

small steps tends to improve pro ductivityby helping to lo calize the source of errors and allowing abandonmentof

a relatively small change that did not work as exp ected

Translator

The Translator comp onent of the MOOSE Back End uses a mo del denition from MMR to construct a simulation

program in Translator Target Language or TTL Our rst TTL was C and this C Translator is in use

presently A second Translator is under development with Java as its TTL

Translator may be invoked either from Mo deler or from Scenario During development it is most convenient for

the mo del author to invoke Translator from Mo deler For pro duction runs it is easier for the user who may

not be the mo del author to invoke Translator from Scenario Translators output as previously mentioned is a

complete Engine program written in TTL including indentation and comments The C Translator sp ecically

emits engineh a header le consisting primarily of class declarations and enginecpp a source le containing C

translation of each dynamic mo del metho d and eachcodemethodaswellascodetoinvoke engine runtime supp ort

and to synchronize with and accept commands from Scenario

Many decisions are made in the course of deciding what co de to emit and when The heuristic we adopted is to

moveasmuchintelligence as p ossible out of Translator and into MMR The eect of this is to make it easier to

construct future Translators as the same MMR serves them all The cost in increased size and complexity of MMR

app ears to b e justied MMR has ab out of the co de and Translator has ab out so this approach leverages

Translator developmentby something like through reuse

MOOSE Mo del Rep ository MMR

The Mo ose Mo del Rep ository MMR comp onent of the MOOSE Library holds ob ject metadata such as class

declarations including declarations of attributes and metho ds and class denitions including metho d denitions

MMR keeps track of MOOSE mo dels as they are b eing built MMR also maintains collections of previous mo dels

and mo del parts for reuse

MMR has a clientserver architecture and in some ways is patterned after the CORBA Common Ob ject Request



Broker Architecture IR Interface Rep ository The MMR servers provide a database management system DBMS

for mo del denitions MMR clients work with Mo deler and Translator to dene and reuse mo del denitions

Mo dels and mo del comp onents created by other mo del authors or the same mo del author previously are available

for browsing inclusion andor reuse Base classes such as sets for mo deling collections and p opular geometries for

spatial mo dels are available to the mo del author An MMR client can simultaneously maintain conversations with

to be distributed An MMR several MMR servers each on a dierent machine which p ermits mo del denitions

Server can simultaneously maintain conversations with several MMR clients on the same or dierent hosts which

p ermits collab oration within an engineering workgroup on mo del development

As was mentioned ab ove it is necessary at numerous p oints to analyze information b efore co de can b e emitted by

Translator Such analysis is p erformed by MMR as the data is entered The result is typically stored in a data

eld often as an enum typ e value or a b o olean Then in Translator b ecause the decision has already b een made

complexityistypically reduced to a switch or if statement to carry out that decision This makes MMR more than a

DBMS the mo del analysis asp ect is an integral part of understanding a mo del denition suciently well to convert it

automatically into a program Here is an example which o ccurs whenever a functional blo ck mo del FBM app ears

as a metho d within a mo del Each blo ck of the FBM must b e examined to ascertain whether it is a metho d of

the class containing the FBM a metho d of an ADT attribute of the class containing the FBM or a metho d

of some other class Each case is handled dierently when co de is emitted amemb er metho d name a metho d name

qualied with the attribute name or dynamic binding of a blo ck from the mo dels context MMR do es this analysis

and provides an enum typ e plus a b o olean containing the decision which allows Translator to eectuate the decision

when co de is emitted

In addition to the normal mo de of receiving mo del denitions from mo del authors MMR can also receivemodel

denitions in another way from text les These les can b e created using a text editor Historically such les were

originally created by Mo deler b efore MMR came into existence These les now serveasaway to initialize or reload

an MMR server

The Mo deler is connected to MMR via an interface that consists of pip es to a proxy pro cess and thence via TCP

to an MMR Server This architecture p ermits a proxy to maintain simultaneous conversations with several MMR

Servers some or all of whichmay b e lo cated elsewhere than the lo cal machine Additionally the MMR Servers may

converse with one another to establish and maintain distributed denitions of mo dels based either on a hot link or

a cached lo cal copyofeach distant comp onent

In the case of Translator and other C programs access to MMR is provided byanAPI whose co de is part of

the Translator pro cess itself rather than a proxy This is done for reasons of eciency and simplicity and do es not

compromise the architecture Both the proxy and the API are thin programs relying on the MMR Server for two

reasons so that more co de can b e shared b etween them and to ooad issues of synchronization and concurrency

to the MMR Server where it b elongs

MMR is presently a homegrown C creation intended as a pro of of concept rather than for pro duction use Upgrade

to industrial strength can b e done in future without altering the architecture as follo ws the MMR Server can b e

replaced by a DBMS either an OO DBMS or an RDBMS with OO wrapp er Proxy and API will then b e mo died

to make requests queries and up dates to the new DBMS rather than to the original MMR Server This brings to

MOOSE the synchronization lo cking and security capabilities oered by commercial DBMS software Imp ortantly

Mo deler and Translator never see the change and need not b e mo died

Engine

The Engine comp onent of the MOOSE Back End is generated byTranslator Translator emits Engine source co de

It is then necessary to translate the Engine to create an executable even with Java into byteco de In MOOSE this

is done automatically under the covers using a make utility program alternatively Engine can b e compiled and

linked directly by a such as Visual C or g At link time a number of runtime supp ort comp onents



are added from ob ject libraries the most imp ortant of whichisooSim

The o oSim event scheduling to olkit All dynamic mo dels are translated into C co de which relies on the

ent chains ooSim is an eventscheduling underlying eventscheduling of the ooSim dispatcher for propagating ev

simulation queuing mo del to olkit which arose as an ob ject oriented reimplementation and extension of the SimPack

  

to olkit SimPack is in turn based on SMPL In addition to eventscheduling o oSim also provides numerous

other forms of supp ort such as pseudorandom numb er generation But it is the eventscheduling that is o oSims

primary supp ort role

Engine source le contains co de to initiate one or more eventchains These eventchains propagate indep endently of

one another and the time step of eachchain is indep endent of the time step of every other eventchain The event

scheduler propagates eacheventchain until that eventchain terminates itself or until the simulation clo ck reaches

the overall time limit sp ecied for the simulation in the mo del denition In general an event chain propagates

by rescheduling a sp ecic event routine which the mo del author identies This is accomplished by enabling the

auto propagate feature which is done by default However it is also possible for the mo del author to disable

auto propagate in which case the mo del itself may generate anynumber of eventchains following any logic This is

an advanced feature which is recommended only to those who are familiar with eventscheduling in o oSim and wish

to or need to have the additional exibilitywhich manual eventscheduling provides Manual eventscheduling is

not required to get MOOSE mo dels to run

As the Engine runs it executes one simulation event after another driven by its underlying o oSim Future Event List

FEL As an event executes it may generate output on standard output cout All such output is presented to

Scenario for p ossible use See the Scenario subsection b elow for more detail After executing each simulation event

Engine checks with Scenario for instructions and new parameter values The relation b etween Engine and Scenario

is thus inherently interactive and bidirectional One such instruction p ermits Scenario to inject events into the FEL

of an Engine as it is running This is one feature necessary to supp ort distributed execution of simulation mo dels

Scenario

The Scenario comp onent of the MOOSE HCI is a visualization enabler employing a GUI Scenario activates and

initializes simulation mo del execution which we call Engine at the b ehest of user who may or may not be the

original mo del author Scenario maintains synchronous 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 mo difying simulation parameters and changing the rate of simulation progress

Once the Engine executable has b een built it can be run as many times as desired under auspices of Scenario

Scenario establishes a bidirectional pip e connecting it to Engine The eect is to activate Engine and to synchronize

Engines execution with that of Scenario so that whatever Scenario writes to the pip e app ears on the standard input

Figure MOOSE Scenario GUI for Conways game Life

cin of Engine and whatever Engine writes to standard output cout can b e read from the pip e by Scenario This

interactive connection controls the real progress of Engine Engine can b e allowed to freerun or can b e made to

single step through one event at a time the default or to run at any pace in between As a separate feature

simulation clo ck time scales can be stretched or compressed Both can be combined to generate animations with

which the mo del author can interact Things which ordinarily happ en blindingly fast can b e slowed down The rate

of progress can b e adjusted to fo cus 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 may not b e mo del author interacts Scenario can initialize parameters and pass

them to Engine Most imp ortant Scenario lters Engines output Scenario takes Engines dull b oring simulation

output and turns it into app ealing meaningful usually graphical output Engine is thus free to do what it do es b est

mo del execution pro ducing output Scenario then do es what it do es b est facilitating visualization of the output as

answers

Scenario detail is unique to eachmodel MOOSE has a to olkit 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 xy plot graphs and terrain maps This to olkit is extensible and as new mo dels are develop ed the

to olkit grows and b ecomes more useful Nonetheless some simulation output isnt necessarily amenable to graphical

 

realtime treatment and there is a very necessary role for traditional metho ds of analysis MOOSE can supp ort

this in two ways Engine can send output for this purp ose to a le separate from that examined by Scenario

alternatively Scenario can direct some of Engines to such ale Either way further analysis of such output can

then be handled by additional software provided by mo del author eg MATLAB Such software can be invoked

from Scenario or it may b e completely external to MOOSE

MOOSE Ob ject Store MOS

The MOOSE Ob ject Store MOS comp onent of the MOOSE Library holds ob ject data MOS do es for ob jects much

of what MMR do es for mo dels MOS works with Engine and Scenario in similar fashion to the way MMR works with

Mo deler and Translator MOS manages ob ject p ersistence and distributed ob jects An ob ject enters MOS either

to hib ernate p ersistence or to move to a dierent host distributed An ob ject in a MOOSE comp onent suchas

Engine decides to go into MOS MOS accommo dates this The ob ject can reemerge at any MOOSE lo cation either

on the same host or a dierent host but not to two or more lo cations at the same time What is supp orted here is

moving not copying corresp onding to the realworld constraint that there cannot b e more than one copyofagiven

ob ject in existence at any moment

Ob jects are attened as they go into MOS and inate again when they are come out Primitivetyp es suchas

int real and string are stored as themselves All other typ es are abstract data typ es ADTs formed from primitive

typ es andor other ADTs and are recursively eventually attened into primitivetyp es For example an image in

gif format b elongs to a class ADT with two attributes an arrayofbyte and an integer length

An ob ject can p ersist by sending itself to the MOS The ob ject can come back from the hib ernating to the active

state with a sp ecial form of its constructor that works with MOS This technique is extensible to supp ort distributed

op eration by having the two op erations o ccur on dierent hosts An ob ject can moveby placing itself into MOS

with a request to b e moved to a sp ecic host or an ob ject can place itself into MOS and wait for a request which

will cause it to move to some lo cation which need not b e known when the ob ject was stored Each MOOSE host has

an MOS and several MOSs collab orate to nd and retrieve ob jects so that an ob ject can movefromany MOOSE

host to any other MOOSE host where MOS is active

Although the architecture p ermits MOS to be capable of distributed op eration this is not our present fo cus in

MOOSE Wehave decided to fo cus on distributed mo del denition rather than distributed mo del execution Thus

MOS op erates in supp ort of mo del execution on a single host only at this time so that only p ersistence and not

distributed ob jects is supp orted Work on distributed ob jects to function as describ ed ab ove is currently underway

IMPLEMENTATION DETAIL SOME IMPORTANT CLASSES PLATFORMS

are comprised of Translator and Engine Blo cks This section describ es some key classes in MOOSE backend softw

First we discuss the Block class MOOSE mo dels are multimo dels built mostly of dynamic mo dels and every dynamic

mo del has a structure sub ordinate elements and a top ology how those sub ordinate parts are connected FSMs

for example have states connected by arcs lab eled with predicates that control state transitions and FBMs for

example have function blo cks connected by traces which carry output of one blo ck to input of another In MOOSE

every sub ordinate elementofevery dynamic mo del eg state of an FSM functional blo ck of an FBM is an ob ject

of a derived class of the base class Block so called for historical reasons our rst dynamic mo del typ e was FBM

This homogeneity facilitates mo del renement and so is an underlying supp ort for multimo dels of all kinds most

esp ecially heterogeneous multimo dels

Clusters Asso ciated with each Blo ck ob ject is a structure known as Clusters which hold pointers to ob jects

known to b elong to classes that have certain relations to the ob ject Each dynamic mo del metho d b elongs to a class

but the identity and true nature of eachblock within that dynamic mo del can b e b ound as late as every time the

metho d is dispatched Clusters are searched as needed to identify the blo ck ob jects to asso ciate with eachelementof

a dynamic mo del just b efore each execution of the dynamic mo del This dynamic blo ck binding facilitates dynamic

multimo deling It is also anticipated to supp ort distributed simulation when MOOSE moves onto the web

Context MOOSE engine is eventscheduled using ooSim This is essentially transparent to the mo del author

who only sp ecies the time step for each mo del within eacheventchain or one overall time step if all time steps are

the same Eventchains can terminate themselves or they can end when the simulation clo ck reaches a sp ecied

time The consequence of eventscheduling is that all events such as one execution of the co de of a dynamic mo del

are called from the o oSim event Dispatcher There cannot b e any lo ops in the dynamic mo dels the equivalentof

lo op b ehavior is attained by propagating eventchains Each dynamic mo del is a metho d of some class o oSim do es

not use global symb ols so to have the equivalent of static lo cal variables private to each objectaContext structure

holds this information Contexts are generated automatically b y Translator for dynamic mo dels This facilitates

eventscheduling

Glist MOOSE needed a base class for lists b ecause MOOSE has lots of lists to manage The Glist class is this

base class A Glist ob ject is a dynamically allo cated arrayofpointers When insertion is p erformed the array senses

when it is full and automatically expands in a way transparent to the caller Glist is not a linked list it is an



array so it has sp eed and safety advantages relativetolinked lists Derived classes of Glist are made typ esafe by

appropriate casts in derived class declarations not in calling co de There are sp ecialized metho ds that were needed

for one derived class or another and were put into the Glist base class and so b ecame available for all derived classes

present and future to use First Glist was handy in Translator then it was reused in Engine runtime supp ort most

recently it has b ecome the foundation of the container classes which facilitate representing aggregation

Dynamic The present MOOSE implementation includes several of dynamic mo dels FSM FBM EQN and RBM

uzzy mo dels and We see needs for other kinds of dynamic mo dels suchasPetri nets System Dynamics mo dels F

p erhaps others There is a requirement that MOOSE b e painlessly extensible to new dynamic mo del typ es The



Dynamic class is an abstract base class in Translator from which all current dynamic mo del classes internal to

Translator are derived and which will facilitate creation of new dynamic mo del typ es in future

Portability Platforms and Languages We chose two target platforms for MOOSE the rst is Sun Solaris

dialect of System V the second is Microsoft Windows NT The co de also seems to run under Windows but

we do not develop under Windows The Unix platform was chosen for convenience as it is ubiquitous in our

Departmental environment as it is across academia The Windows NT platform was chosen b ecause it runs not

only on the IBMcompatible PC with Intel x CPU but also on RISC pro cessors like Digitals Alpha AXP the



PowerPC and MIPS RISC For MOOSE programming languages wechose TclTk for our comp onents with GUIs

Mo deler and Scenario and C for our back end comp onents Translator TTL and Engine runtime supp ort

MOOSE back end co de has b een compiled under MS Visual C Borland C Borland Turb o C and g

CONCLUSIONS AND PLANS

TclTk is our programming language for Mo deler and Scenario GUIs As TclTk neither enforces nor facilitates

ob jectoriented metho dologywe are lo oking at ways to retain the b enets of TclTk while improving the reusability

and extensibility of the co de The MOOSE Mo del Rep ository MMR has b een a substantial step in the right

direction ooading from Mo deler the job of keeping track of all the details of a mo del We will also explore ob ject

oriented alternatives to TclTk Scenario has a dicult job it must facilitate visualization even though every mo del

is dierent in surface app earance Scenario is also presently written in TclTk so the remarks ab ove regarding lack

of ob jectoriented supp ort apply as well Nonetheless weareworking on building a to olkit of p opular and reusable

dials gauges graphs and clip art and are lo oking at XF and Sp ecTcl GUI builders Our HCI needs constant

review and improvement esp ecially as new immersivetechnologies b eckon It is a fundamental tenet of MOOSE and

OOPM that the HCI must t the mo del author like a glove Our ob jectiveistomakeit fun to use the MOOSE

HCI Accordingly we are prepared for the HCI to evolve

The present MOOSE implementation includes several kinds of dynamic mo dels FSM FBM EQN and RBM We

see needs for other kinds of dynamic mo dels such as Petri nets Rule based mo dels Fuzzy mo dels and p erhaps

others Aggregation and the implications of aggregation pose interesting questions esp ecially as we distinguish

among containment usage comp osition and asso ciation Although we have signicant results more work lies

ahead Weplantotake MOOSE onto the worldwide web to distribute mo del execution For webbased op eration

aplanisunderwaytoemb ed distributed mo del execution within a MOOSE metho d using CGI Common Gateway

Interface We also plan to evaluate a Java alternativeinthiscontext

ACKNOWLEDGEMENTS

We would like to thank the following funding sources that have contributed towards our study of mo deling and

implementation of a multimo deling simulation environment for analysis and planning Rome Lab oratory Griss

Air Force Base New York under contract FC and grant F Department of the

Interior under grant and the National Science Foundation Engineering Research Center

ERC in Particle Science and Technology at the University of Florida with Industrial Partners of the ERC under

grant EEC Wealsoac knowledge with thanks the help of Tolga Goktekin for development of the Mo deler

Kangsun Lee in providing assistance with LaTeX and Scenario issues as well as mo del development Gyo oseok Kim

for the RBM gure and for discussions regarding RBMs Youngsup Kim for FBM editor and Doug Dillard for the

Life Scenario and other Scenario supp ort

REFERENCES

PAFishwick Extending ob ject oriented design for physical mo deling ACM Transactions on Modeling and

Computer Simulation July Submitted for review

I Sommerville Software Engineering Fourth Ed AddisonWesley

P A Fishwick The role of pro cess abstraction in simulation IEEE Transactions on Systems Man and

Cybernetics ppJanuaryFebruary

PAFishwick Abstraction level traversal in hierarchical mo deling in Model ling and Simulation Methodology

Know ledge Systems ParadigmsBP Zeigler M Elzas and T Oren eds pp Elsevier North Holland

are development Communications of the V Berzins M Gray and D Naumann Abstractionbased softw

ACM pp

P A Fishwick and K Lee Two metho ds for exploiting abstraction in systems AI Simulation and Planning

in High Autonomous Systems pp

PAFishwick Simulation Model Design and Execution Building Digital WorldsPrentice Hall

K Lee and P A Fishwick Semiautomated metho d for dynamic mo del abstraction in SPIE Conference

Proceedings

B P Zeigler Object Oriented Simulation with Hierarchical Modular Models Intel ligent Agents and Endomor

phic Systems Academic Press

G Bo o ch ObjectOrientedAnalysis and Design with applications nd ed AddisonWesley

A J Riel ObjectOriented Design Heuristics AddisonWesley

B P Zeigler Objects and Systems SpringerVerlag

B Stroustrup The C Programming Language second edition AddisonWesley

G Bo o ch and J Rumbaugh Unied Method for ObjectOriented Development Rational Software

M Gardner Mathematical games Scientic American Oct

M Gardner Mathematical games Scientic American Feb

M Gardner Wheels Life and Other Mathematical Games publisher

J D FoleyAvan Dam S K Feiner and J F Hughes Principles and Practice Addison

Wesley Second Edition

PAFishwick A visual ob jectoriented multimo deling design approachforphysical mo deling submitted April

to ACM Transactions on Modeling and Computer Simulation

P A Fishwick and B P Zeigler A Multimo del Metho dology for Qualitative Mo del Engineering ACM

Transactions on Modeling and Computer Simulation pp

PAFishwick A Simulation Environment for Multimo deling Discrete Event Dynamic Systems Theory and

Applications pp

R Orfali D Harkey and J Edwards The Essential Distributed Objects Survival Guide John Wiley and Sons

R M Cub ert The o osim ob ject oriented simulation library Tech Rep TR University of Florida CISE

Simulation Group

PAFishwick Simpack Getting started with simulation programming in c and c in Winter Simulation

Conference WSC Proceedings J J S et al ed pp

M H MacDougall Simulating Computer Systems Techniques and Tools MIT Press

J A Payne Introduction to Simulation programming techniques and methods of analysis McGrawHill

A M Law and W D Kelton Simulation Modeling and Analysis McGrawHill

G S Fishman Concepts and Methods in Discrete Event Digital Simulation John Wiley Sons

B International The World of C Borland International Scotts Valley CA

K Siyan Windows NT Server New Riders

AUTHORS BIOGRAPHIES

Rob ert M Cub ert is a PhD student inCISEatUniversity of Florida His researchinterest is ob jectoriented

distributed simulation He holds BS degrees in EE from MIT and in Zo ology from University of Oklahoma and an

MS in from University of Oklahoma He sp entyears on Computer Science faculty at California

State University Sacramento and has a decade of industry exp erience writing software for realtime control systems

and data communications

Paul A Fishwick is an asso ciate professor in the Department of Computer and Information Sciences at the

University of Florida He received the BS in Mathematics from the Pennsylvania State University MS in Applied

Science from the College of William and Mary and PhD in Computer and Information Science from the Universityof

Pennsylv ania in He also has six years of industrialgovernment pro duction and research exp erience working at

Newp ort News Shipbuilding and Dry Do ckCo doing CADCAM parts denition research and at NASA Langley

ResearchCenter studying engineering data base mo dels for structural engineering His researchinterests are in

computer simulation mo deling and analysis metho ds for complex systems He is a senior memb er of the IEEE and

the So ciety for Computer Simulation He is also a memb er of the IEEE So ciety for Systems Man and Cyb ernetics

ACM and AAAI Dr Fishwick founded the compsimulation Internet news group Simulation Digest in

whichnow serves over subscrib ers He was chairman of the IEEE Computer So ciety technical committee on

simulation TCSIM for two years and he is on the editorial b oards of several journals including the

ACM Transactions on Mo deling and Computer Simulation IEEE Transactions on Systems Man and Cyb ernetics

and the The Transactions of the So ciety for Computer Simulation International Journal of Computer Simulation

Journal of Systems Engineering