[comp.sw.components] OO simulation

muller@src.umd.edu (Christophe Muller) (08/02/90)

In article <71800006@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu writes:

>    From: johnson@m.cs.uiuc.edu
>    Newsgroups: comp.sw.components

>    murali@tut.cis.ohio-state.edu writes:

>    >I am surprised to read that the need for multiple implementations of an
>    >abstraction (specifically, almost constant function) is not obvious.

>    Your argument is logical.  However, it goes counter to my experience.
>    Smalltalk has ONE implementation of the almost constant function.  It

I'm taking this in the middle (as usual :-), sorry if my question is irrelevant but
I've always wondered what was the good way of implementing OO components for discret
event simulation objects.

The problem in real life models is that *there are* a lot of different possible
descriptions (models) of an object for a given physical object. The difference is the
_level of granularity_ of the model. Do I want an object like a factory to be just a simple
function of time depending on three or four flows of material (a simple exponential
distribution for instance), or a complete very detailed object that have the _same
interface_ vis-a-vis of the world (it knows how to do the same job, takes the same input..)
but with a lot of algorithms and sub-objects needed to have a very detailed execution of
the actual work?

The answer completely depends on the goal of my study: Am I studying the behaviour of
a country, in which case my factory is just an element of a biggest network of objects?
or am I studying a set of 4 or 5 factories of the same type? (or the factory itself?)

Of course, my results should always be good if I take the last one. The most detailed
the better! But it will cost me a billion Crays to run my simulation.. :-) (and worse:
years of engineer time to write each class).

For the modeler, the choice is generally obvious _for his project_, but how do you want
to make a component in that case. It seems like there is a third axe to the inheritance
tree, the axe of level of granularity of descriptions.

A solution could be to write an abstract description and dozens of actual models for
this object, but you can't even be sure that one of them will fit the next problem.

It seems to me that OO modelling is fantastic for the *design* of models (cleaner, easyer
to debug and to validate...) but poor on a reuse point of view. Or you must make
approximations which leads to models that are impossible to validate.

Any comments appreciated.

Cheers,
Christophe.

 = Got thirteen channels of shit on the T.V. to choose from ...to choose from =