Simile is billed as a “visual modelling environment”, meaning that models are developed diagrammatically (as opposed to writing lines of text, as in a programming language or a simulation language). However, a more fundamental feature of Simile is that it is a declarative modelling environment. In a sense, Simile’s visual modelling interface is just one way of building a Simile model: we could envisage other interfaces (such as a text editor) that would still produce a Simile model, but would not be visual.
What do we mean by “declarative modelling”? First, we note that the term contrasts with a procedural approach, which is what we do when we implement a model in a conventional (procedural) programming language, such as Fortran or C. In that case the lines in the program are in fact instructions to the computer: calculate this value, loop over the array elements, print the value for this variable. Some of the lines might look exactly like declaratively-expressed equations, but they are in fact assignment statements. Thus, without the use of strictly-observed (and arbitrary) conventions, we cannot really distinguish between the assignment statements in the program that constitute the model equations, and all the other assignments we might have in the program. Effectively, we can do only two things with the program: run it (to calculate the values for the model variables); or show it to a human who understands the programming language. And running it is the only thing that a computer can do for us.
In declarative modelling, we represent a model not as a series of assignment and control statements, but as a set of facts that are true about the model. The order in which we present the facts is (unlike a procedural program) irrelevant. The full set of facts defining a model actually constitute a specification for the model: given these facts, and knowledge about what the symbols mean, someone else can construct a working version of the models.
A good example is in architectural design. We would never dream of specifying a design for a building in a computer program: rather, we would express it as a set of facts, defining the walls, doors etc, and their size, location and materials. Given this information, we could draw a plan for the building. We also have all the information we need to do calculations about the building: how big it is; how quickly it would heat up and cool down. The program that does the calculations is indeed procedural; but the design of a particular building is held as a set of facts.
And so it can be with models. A model is a certainly a design, expressed in terms of the constituent parts of the model and the linkages between them. It can certainly be expressed declaratively: look at he “Model description” part of any modelling paper. The declarative statement of model structure is sufficient to enable someone else to make a runnable version of the model, provided that it is complete, unambiguous, and that the meaning of the terms used is understood.
There are significant advantages in adopting an declarative approach.
First, there is no risk of the description of the model failing to match the implementation of the model: the description is the implementation.
Second, once a model is represented declaratively, one can do many things with it as well as just simulating its behaviour: for example, generate descriptions in a variety of formats, interrogate its structure, compare it structure with that of another model, or transform it into a simpler or more complex model.
Third, one can generate runnable versions of the model in a variety of languages (including languages for parallel computers): you are not limited to one that the model happens to be written in. Finally, the adoption of a declarative modelling approach encourages the development of common standards for representing models, the distributed development of modelling tools, and the sustainability of the effort put into developing models.
Simile, in common with other modelling environments, necessarily adopts a declarative approach: it is hard to build up a representation of the model during the design process without doing this. However, in developing Simile we have also committed ourselves to the idea that the language for representing the model structure should be open, so that any other person or group can develop their own tools for processing Simile models — including tools for generating runnable versions of a model or indeed model-design environments.