Page 137 -

134 J.M. Galán et al.

thematician did not specify any particular neighbourhood function, (b) different
neighbourhood functions lead to different results, and (c) the modeller is using only
one of them and believes that they all produce essentially the same results.
Errors could also appear at this stage, although it is not very likely. This is so
because the specifications that the modeller produces must be formal, and they are
therefore most often written down in a formal language. When this is the case, there
is little room for misunderstanding between the modeller and the computer scientist,
i.e. the modeller’s specifications and the formal model received by the computer
scientist would be the same, and thus there would be no error at this stage.
Theroleofthe computer scientist could introduce artefacts in the process. This
would be the case if, for instance, his specifications require the use of a particular
pseudorandom number generator; he believes that this choice will not have any
influence in the results obtained, but it turns out that it does. Similar examples could
involve the arbitrary selection of an operating system or a specific floating-point
arithmetic that had a significant effect on the output of the model.
Errors can quite easily appear in between the role of the computer scientist
and the role of the programmer. Note that in our framework, any mismatch
between the computer scientist’s specifications and the executable model received
by the programmer is considered an error. In particular, if the computer scientist’s
specifications are not executable, then there is an error. This could be, for instance,
because the computer scientist’s specifications stipulate requirements that cannot
be executed with present-day computers (e.g. real arithmetic) or because it does not
specify all the necessary information to be run in a computer in an unequivocal way
(e.g. it does not specify a particular pseudorandom number generator). The error
then may affect the validity of the model significantly, or may not.
Note from the previous examples that if the computer scientist does not provide
a fully executable set of requirement specifications, then he is introducing an error,
since in that case, the computer program (which is executable) would be necessarily
different from his specifications. On the other hand, if he does provide an executable
model but in doing so he makes an arbitrary accessory assumption that turns out to
be significant, then he is introducing an artefact.
Finally, the programmer cannot introduce artefacts because his specifications are
the same as the executable model by definition of the role (i.e. the programmer does
not have to make any accessory assumptions). However, he may make mistakes
when creating the computer program from the executable model.

7.4.3 Activities Aimed at Detecting Errors and Artefacts

In this section we identify various activities that the different roles defined in the
previous sections can undertake to detect errors and artefacts. We consider the use
of these techniques as a very recommendable and eventually easy to apply practice.
In spite of this, we should warn that, very often, these activities may require a
considerable human and computational effort.