1234567891011121314151617181920212223242526272829303132333435363738 |
- \chapter{Conclusion}
- In this paper, we described the Modelverse: a self-describable multi-paradigm modelling tool.
- Several axioms were presented, which served as guidelines while making decisions on the specification of the models.
- Our architecture was briefly presented, showing the distinction between the Interface (MvI), Kernel (MvK), and State (MvS).
- We presented a model of the Modelverse, which defines how an implementation has to behave.
- The model covers both the way data is represented (in the MvS), and the semantics of its action language constructs (in the MvK).
- Concerning data representation, we leave open how the graph could be physically implemented.
- This allows for a variety of implementations, allowing the developer to choose between available technologies.
- And as all implementations will be interoperable, users can try out different implementations and check whether it better matches with their goals.
- Concerning the action language, we described the execution context representation, and how language primitives modify this execution context.
- This needs to be explicitly specified if multiple tools need to interoperate on the same piece of execution data.
- For example, an external debugger can now access all internal execution data, as its representation has been specified.
- For performance, we allow implementations to ignore updates to the execution context, allowing for optimized execution or primitive operations.
- This allows users to achieve higher efficiency, for example through compiled functions, although limiting debugability.
- Tools can create and use additional elements in the execution context, which can be interpreted by compatible tools.
- However, tools have no obligation to support all these additional elements.
- An example is additional debugging information, such as tracing information.
- 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.
- 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$).
- 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.
- In future work, we will create a reference implementation of this specification.
- Apart from the reference implementation, multiple variations of components will be created, each with a different goal.
- After the creation of the reference implementation, the implementation will be scaled up to a distributed and parallel version.
- Multiple Modelverse Interfaces will also be created, each with a different kind of user in mind.
- First, a textual HUTN interface will be created.
- Afterwards, a graphical tool will be created.
- Our different notions of conformance will also be further extended with the introduction of ontological conformance.
- This would allow us to have three different kinds of mappings: physical, linguistic, and ontological~\cite{BrunoOntology}.
|