conclusion.tex 3.1 KB

1234567891011121314151617181920212223242526272829303132333435363738
  1. \chapter{Conclusion}
  2. In this paper, we described the Modelverse: a self-describable multi-paradigm modelling tool.
  3. Several axioms were presented, which served as guidelines while making decisions on the specification of the models.
  4. Our architecture was briefly presented, showing the distinction between the Interface (MvI), Kernel (MvK), and State (MvS).
  5. We presented a model of the Modelverse, which defines how an implementation has to behave.
  6. The model covers both the way data is represented (in the MvS), and the semantics of its action language constructs (in the MvK).
  7. Concerning data representation, we leave open how the graph could be physically implemented.
  8. This allows for a variety of implementations, allowing the developer to choose between available technologies.
  9. And as all implementations will be interoperable, users can try out different implementations and check whether it better matches with their goals.
  10. Concerning the action language, we described the execution context representation, and how language primitives modify this execution context.
  11. This needs to be explicitly specified if multiple tools need to interoperate on the same piece of execution data.
  12. For example, an external debugger can now access all internal execution data, as its representation has been specified.
  13. For performance, we allow implementations to ignore updates to the execution context, allowing for optimized execution or primitive operations.
  14. This allows users to achieve higher efficiency, for example through compiled functions, although limiting debugability.
  15. Tools can create and use additional elements in the execution context, which can be interpreted by compatible tools.
  16. However, tools have no obligation to support all these additional elements.
  17. An example is additional debugging information, such as tracing information.
  18. By splitting up the components of the Modelverse, and requiring that all parts need to be explicitly modelled, we arrived at different notions of conformance.
  19. We distinguished between a conformance closer to the physical level (conformance$_\perp$), and a linguistic type of conformance closer to the user level (conformance$_L$).
  20. Whereas the physical notion allows users to circumvent strict metamodelling, by switching to a graph representation, linguistic conformance allows the MvK, and ultimately the user through the MvI, to reason about the model in a level that is close to the problem domain.
  21. In future work, we will create a reference implementation of this specification.
  22. Apart from the reference implementation, multiple variations of components will be created, each with a different goal.
  23. After the creation of the reference implementation, the implementation will be scaled up to a distributed and parallel version.
  24. Multiple Modelverse Interfaces will also be created, each with a different kind of user in mind.
  25. First, a textual HUTN interface will be created.
  26. Afterwards, a graphical tool will be created.
  27. Our different notions of conformance will also be further extended with the introduction of ontological conformance.
  28. This would allow us to have three different kinds of mappings: physical, linguistic, and ontological~\cite{BrunoOntology}.