Page 116 -

112 P.-O. Siebers and F. Klügl

Sometimes it can be helpful to create a sequence diagram as described in
Sect. 6.3.8 to visually show the order of execution describing the actions taken on
various elements at each step of the simulation from a high-level approach. The
way and order in which all entities are initialised, as well as the way and order in
which they are updated and how their interactions are handled, is often not trivial
and a major source of artefacts. In such a case, it therefore needs to be clearly
documented and specified. Since we do not have any obvious complex dependencies
in our illustrative example, it was not necessary to create such a high-level sequence
diagram.
At this point, we have all the information for a conceptual model together. Using
the collection of diagrams and tables that we produced, the model to be implemented
should be fully specified and as well understood as it can be without running it.
The next step is to take this specification and either start with the implementation
ourselves or let a professional software developer deal with it.

Conclusion

There seems to be a fear of non-computer scientists with regard to “formal
approaches”. This might be due to the fact that formal approaches are often
presented in a way that makes modelling a very complex and costly task and that
seems to take away opportunities for exploratory model development. While this
might be true for very large projects, it is usually not the case for smaller ones as
tools and techniques do not have to be applied in a dogmatic fashion. They are
there to aid the modelling process wherever one thinks it would be appropriate or
helpful to use them. Thinking about this as being a more structured approach that
adds transparency to model development rather than a formal approach that makes
modelling a complex task might take away some of the fear. While there will always
be a place for informal modelling (in software engineering often coined as “fast
prototyping” to quickly try out things), we believe that there is also a place for a
more structured approach to modelling.
We have found the framework described in the second part of the chapter very
helpful in terms of communicating in multidisciplinary teams during focus group
meetings and also for documenting the outcomes of these discussions. It (or parts
of it) has been extensively used by the group of PO Siebers (the first author of this
chapter) for many different projects, ranging from “Studying People Management
Practices in Retail” (Siebers and Aickelin 2011), where we worked with colleagues
from Economics and Work Psychology and a leading UK retailer, to “Simulating
Peace Building Activities in Africa” (Siebers et al. 2017), where we worked with
colleagues from the School of Politics and Psychology. We are currently also
applying the framework in several new projects including industrial partners.
So far the feedback from the participating team members has always been very
positive. Using these methods has aided “the fun” of collaborative model devel-
opment. Applying object-oriented principles and tools from software engineering