Dear Jan,

regarding some of your points:


Jan Burse wrote:

> I think many simulations are embedded into a task, that
> typically includes beside the run itself the preparation of
> the run and the interpretation of the run. This task might
> again be embedded into a learning situation, a decision
> situation, etc..
>
> So we have to construct the simulations, the tasks and
> the situations. A notation which works for all levels and
> connects them would be nice. UML has been shown,
> for example for business objects and business processes,
> to be seemless in this sense. In the end you not only have
> representations of the static and dynamic aspects of the
> simulations, but also of the tasks and situations.
>

I know understand that your aims are much higher than mine.

I would be happy to have a framework to express a few basic notions about simulation
programs while you are thinking of something that might support the whole cycle of
defining, implementing and analysing the results of simulation.

So basically you aim for a full Methodology.

That's perfectly fine but I'm not sure that this would solve the same problem I was
thinking of: providing formal or semiformal descriptions of simulation models that can
be easily and unambiguosly understood by a specialist, searched on the base of
simulation specific criteria, and in same cases even compiled to exacutable code.

> Yes, use cases alone are not of very much use. They have
> to be completed by something to get an executable spec.
> On the other hand they provide a nice abstraction to talk
> about a systems functionality.
>
> Whether this abstraction has some relevance to simulation
> is one of my questions that I was exploring a little bit recently.
> I found, that they can be very usefull. There is a link between
> use cases and the knowledge level B, see for example (Menzies
> 95) slides. Unfortunately use cases are not very common.
>

I didn't apply them to simulation but I agree that Use Cases are amazingly useful ,
especially considered their simplicity.

I guess that's because they remind us a very basic but often overlooked point: sofware
is written in order to accomplish some useful function and before writing any code you
have to have a pretty good idea of what these functions are going to be.


>  We
> could also go on, and assigne use cases to phaenomena that
> emerge in our code.

That's an interesting point: a way of defining what emerges from a simulation.

Could you elaborate on that ? It's not clear to me how it might be done and even less
how Use Cases might be helpful.


> (Menzies 95) http://www.cse.unsw.edu.au/~timm/pub/docs/kltut.zip
> (Gilbert and Troitzsch 99)  http://www.uni-koblenz.de/~kgt/Learn/Textbook/node4.html
>

Thanks for both links, they were quite useful !

--
Pasqualino "Titto" Assini
The Data Archive - University of Essex, UK




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%