pubs/ 0040755 0066576 0066562 00000000000 07004071755 0012232 5 ustar 00rjp cs_lec 0000255 0004314 pubs/heidel/ 0040755 0066576 0066562 00000000000 06251536110 0013456 5 ustar 00rjp cs_lec 0000255 0004314 pubs/sne.html 0100644 0066576 0066562 00000020426 06214012644 0013700 0 ustar 00rjp cs_lec 0000255 0004314
Object Oriented Simulation and Object oriented
Databases
Object Oriented Simulation and Object oriented
Databases
Dr Rob Pooley and Dr Peter Thanisch
Department of Computer Science
University of Edinburgh
Edinburgh EH9 3JZ
Scotland
E-mail: rjp@dcs.ed.ac.uk
Introduction
The need for a way of managing simulation experiments has long been
recognised. The DEVS formalism was proposed by
Zeigler [zei1,zei2] as one way of
understanding this and a number of experimental tools have been
produced to
support this view. At the same time people have experimented with
expert
systems and databases [Beyn,zob] to support simulation but these
have encounterd a number
of difficulties. This short piece suggests how the emergence of object
oriented database technology may help to tackle such problems and
allow
effective support for simulation use.
Requirements
The need for some form of support arises from several causes. These
include:
- Experimental design requires that the structure of an
experiment, in terms
of replicated runs, parameter variation, definition of measures of
interest
and strategies for achieving goals, be specified clearly. This is
best done
in the context of a formal framework, where the statistical
interpretation
of the experiment can be properly understood. Methodologies like
DEVS
formalise this, but lack automated support, which could come from
software
tools.
- Efficient reuse of models requires that standard ways of
combining models
to answer new questions be found. This requires standards for
interfaces
between models and ways of documenting their external interface and
internal behaviour. This may be possible even for models produced
by
different modelling tools or using different solution techniques,
if a
common medium for data interchange is used. In the field of "man
in the
loop" simulation, the Distributed Interactive Simulation (DIS)
standard
provides this as a way of connecting distributed elements in
battlefield
simulations, for instance.
- Efficient execution of experiments, involving running and
collecting
results from possibly hundreds of model/parameter combinations,
requires
machine assistance. Such controlling software should be as general
as
possible, but be based on useful statistical facilities, such as
variance
reduction and analysis of variance techniques.
- Effective understanding of results requires that ways of
filtering,
collecting and analysing large volumes of output data be provided
in an
integrated manner. Again this can be achieved by defining data
interchange
formats and general analysis facilities with respect to data in
these
forms.
Databases
The potential for databases to meet some of these requirements has
long been
clear\cite{imse}. The systematic storing and retrieving of large
amounts of data in a
structured manner is in fact a reasonable definition of what a
database
is. Therfore we need to consider how well existing database
technology meets
our requirements. Unfortunately the initial answer is not encouraging.
Relational Databases
Most databases today use the relational model, where data is stored
in tables,
representing the interpretation of the values stored. Each row in a
table
represents a group of related fields or a record, while each column
defines
how fields in that column should be interpreted. This is highly
structured and
allows a wide range of queries to be posed in terms of the relations
defined. A standard language, known as SQL, exists for this purpose.
Surely then the relational model can be used to define the input and
output
parameter structure of our models and SQL queries used to define how
we wish
to interpret the results? Alas this is too simple a view. In
particular, the
definition of experiments involves complex objects, such as models,
and
relational databases only deal in simple data items, such as
arithmetic values
and character strings. Attempts at exploiting relational databases
have had to
resort to storing file names and accessing their contents indirectly.
This is
highly unsafe and cumbersome.
Object Oriented Databases
The restrictions on relational databases are not unique to their use
in
simulation support and there has been a great deal of interest in how
to
overcome them. This has resulted in the emergence of object oriented
databases, where the structure of data is represented by classes in
an object
oriented language, such as C++. relationships and properties can be
programmed
in the host language in a very flexible way.
The database manager in such a system provides secure persistent
storage of
objects from running programs, so that thh information is not lost
once
programs end. This is usually done in terms of a client/server
architecture
and so programs may exchange objects as well as storing and retieving
their
own, by making appropriate calls to the object manager.
The management system provides security, concurrency control,
versioning etc.
The functionality of the system is programmed in the host language,
rather
than in SQL. this requires more programming efort, but allows greater
flexibility.
Simulation Support in OO DBMS
The proposal of this paper is that effective support for simulation
experiments may be provided by exploiting the power of a good object
oriented
database management system. To demonstrate this work has been going
on at
Edinburgh on building such facilities into the HASE modelling
environment. So
far we have shown that the potential is real, with simple facilities
for
storing and analysing results from multiple runs under systematically
varying
parameter values. Variance reduction, by automatic replications under
fixed
parameter values, is also supported in this way.
The use of concurrency features in the database manager (in our case
ObjectStore from Object Design Inc.) is currently being investigated.
this
will allow replicated independent runs to be performed in parallel
under
control of the database manager [hase1]. Where a network of
workstations or PCs exists
this will offer linear speedup up to the number of independent runs
required
at little cost.
Further Issues
Work in this area at Edinburgh will soon be moving to look at two
further
ideas. The first is the use of database concurrency features, such as
rollback, to implement parallel simulation within a single model run,
possibly
via the TimeWarp mechanism. This is very speculative, but might be
useful for
very large discrete event simulations [hase2].
More open ended and, potentially more interesting still, is the
integration of object oriented description techniques with model and
experiment formulation. Many people are using object oriented
simulation languages or graphical objct based modelling tools. These
do not usually exploit the object structure to make modelling
systematic or experiments more intuitive. We believe that there
exists enormous potential fo rthis, and thereby encouraging the
convergence of modelling and software engineering.
References
- [Beyn]
- P. Beynon-Davies and A. R. Hutchings, Modelling and
Databases, European
Journal of Operational research, 64, pp 327-337 (1993)
- [hase1]
- P. Heywood, R.J. Pooley and P.T. Thanisch, Object
oriented Database Technology
Applied for Simulation Environments, UKSS '95 Conference Vol. II,
North
Berwick, April 1995
- [hase2]
- P. Heywood, G. MacKechnie, R.J. Pooley and P.T.
Thanisch, Object-Oriented
Database Technology Applied to Distributed Simulation, Eurosim
Congress '95,
Vienna, September 1995
- [imse]
- R.J Pooley, The Integrated Modelling Support
Environment, Computer Performance
Evaluation, Elsevier, 1991
- [zei1]
- B.P. Zeigler 1976 Theory of Modeling and Simulation,
Wiley, New York
- [zei2]
- B.P. Zeigler 1984 Multi-facetted Modeling and Discrete
Event Simulation,
Academic Press, New York
- [zob]
- R.N. Zobel Classification of Simulation Models in
Multi-disciplinary Object
Bases, UKSS '93 Conference, pp39-43