Dear Titto
> A basic description of the Shelling model might for example be
> expanded by a second researcher providing the relevant
> implementation details for, say, Java.
I have two thoughts, and one after thought:
1) The ends of a model doesn't have to be its execution only. This point is
especially difficult to aprehend if we nevertheless claim that we need computers.
It has to do with the conceptualisation of computers, or more correctly of
what a computer has been designed for. I see the following
conceptualisations:
(A) The computer is an algorithmic device: So the main task that we delegate,
or better amputate, to the computer is processing. (numerical models,
agent-based simulations, etc..)
(B) The computer is an augmentative media: Here the tasks that we delegate
to the computer are storage, presentation and transport. (wordprocessing,
internet, databases, etc..)
We can prescribe (A) as the ultimate application of a computer, and we can
view (B) only as a means to reach the end (A). On the other a simple obser-
vation of someones environment shows that (B) is often the main application
of a computer.
2) The scenario of the use for an intermediate language doesn't have to be
refinement only. I suggest an important application would be crossfertili-
sation. For this purpose we have first to look at what we can capture with
an intermedia language, and what we can do with
what we have captured:
(I) The intermediate model captures the main characteristics of a class of
simulations tasks. For example in the shelly model, it captures the
characteristics of a model that observes segregation. The intermediate
model would not be executable, but could at different places be extended
to a simulation task.
(II) The intermediate model captures an element that reoccures in different
classes of simulation tasks. For example in edmunds model of the El Farror
Bar problem, trees are used in the genetic algorithms. The concept of a
trees could also be used in other models. The intermediate model would
not be executable, but could at different places be used in a simulation
task.
So I have added a second form of reuse, which is not top-down refinement,
but rather bottom-up assemblage. But I was still following the track that
the intermediate language is a means to the end of execution. Before I will
leave this track, I would like to make a note on how a reuse program could fail,
and what could be the cure.
On first sight an intermediate model itself could be conceptualized as a catalog,
or schema, or class diagramm or equivalently RDF model which describes the
abstract or concrete components that are just there. This is a dead-end. To give
you an example, imagine that you have the list of all toolbox calls of a macintosh
and that your job is to draw a circle into a window. You will not find the right calls
in a sensible time. So what is missing is a description of the mechanism between
the components, so that you know how you have to sequence your calls. You
need to know the use of the components.
Modern modelling languages like UML have behavioural views. These views don't
only show the static structure of the problem domain. They can also show the dynamic
behaviour of the problem domain. There has also been a little hipe about a new
view, which was already introduced '87, but which has only recently become widely
accepted. This is the use case view which denotes the most important ingre-
dients of a mechanism, namely the client and the collaborators. So use cases are
currently used to give a view on patterns, business process, etc.. and they can serve
as a glue between different views and different phases in a project.
So lets try to leave the execution track. As somebody with a computer science back-
ground I am very comfortable with the notion of an execution. Unfortunately this
notion is of no use for the scientists I am working with. They can get away without
it. The traditional methods don't depend on it except for a little statistics. So
conceptualisation (A) of a computer is essentially void for them. On the other
had they are hard knowledge workers, so they read a lot of publications and
they communicate with a lot of peoples. So they very much use the computer
in the sense of (B).
We have already left the execution track. Lets see whether there is a relation to
the intermediate level. On one hand, because execution is an alien concept, the
use of models to study phenomena is refused and intermediate models of level
(I) are of no use. On the other hand, intermediate models of level (II) generate
a lot of interest, because they give clues for traditional theorizing. So there is
a flow from software models back to wetware models. The flow demands a lot
of learning on the side of the scientist.
A lot of learning is demanded because harmless concepts like for example the
tree in the before mentioned edmunds model are again alien. To understand
the tree, again the scientist has not only to understand the recursive structure
of the tree, but also its behavioural use. In the case of the edmunds model
the use is evaluation, so two patterns come together the composite patterns
and the visitor pattern. The scientist can now go on, and read something
about trees and even develop a formal theory about trees. And/or he can
develop a little program for a tree and check some scenarios.
3) After thought: So the basic question arises again, should execution be used
to study a phenomena? In my opinion there is no fixed purpose of a computer.
So its up to us how we want to study a phenomena and to what degree we want
computer support. Execution or processing can mean a lot and is an open ended
term. An intermediate language which is able to express behavioural views and
not only structural views could be a means to shape our requirements from case
to case.
Best Regards
--
Jan Burse
Umweltphysik, EAWAG
8600 Dübendorf
tel: +41-1-823 55 34
E-mail: [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|