1234567891011121314151617181920212223242526272829303132333435 |
- \section{Conclusions}
- \label{sec:conclusions}
- We have identified several shortcomings of current tools in how they handle the type/instance relation between models and metamodels.
- This relation is bidirectional, and consists of both the instantiation and conformance checking algorithm.
- While it holds some advantages, primarily in terms of usability and efficiency, hardcoding type/instance semantics in the core of the tool has a significant set of disadvantages that limit what can be done with the tool.
- To make matters worse, there is no common consensus on what the semantics of some of these concepts should be and how to handle violations.
- As this semantics is hardcoded in the tool, users are forced to use it, with the semantics only being defined in the source code of the tool.
- We proposed a different approach, where both the instantiation and conformance checking algorithms, as well as the type mapping, is made explicit as a model.
- Explicit modelling of these semantics allowed us to clearly seperate model structure (a graph) from conformance semantics (an algorithm).
- Additionally, the mapping between different models also became available as a model that can be used like any other.
- The primary advantages of our approach are that users achieve full control over the modelling tool, and can themselves alter the semantics of what it means for a model to conform to a metamodel, or what it means to instantiate a metamodel.
- Previous approaches have limited themselves to providing users a pre-defined function which they had to deal with; deviations were not allowed.
- And even when extension was possible, this was limited to the implementation language of the tool, which might be unfamiliar to the user.
- In this stage of research, our approach has some problems with usability, as users are currently exposed to a great deal of complexity, to which they aren't exposed in other tools.
- We believe that this additional complexity can be handled through the use of more usable front-ends, which hide the complexity when it is not required.
- Performance problems can be resolved through efficient algorithms, similar to those found in other interpreters.
- Our approach was illustrated with a small example that is prevalent in current programming languages: the semantics of subtyping.
- Many languages have their own semantics in this regard: is subtyping allowed at all? Do we use nominal or structural subtyping? What about multiple-inheritance? And what with the resolution order in multiple-inheritance?
- For each of these possible choices, there has been at least one programming language which choses one over the other.
- Their choices are often well-founded, making us believe that the ideal semantics is dependent on the domain.
- As the Modelverse intends to be a general (meta-)modelling tool, we should always offer the users the most appropriate formalism to describe their problem.
- When a problem naturally lends itself best to structural subtyping, for example, it should not be implemented using nominal subtyping.
- In future work, we plan to address the usability problems we encountered in our tool, as well as performance.
- Another direction for future work is the definition of a general type/instance relation, which holds for every model.
- That would make it possible to store each model as a conforming model (by construction), and to manipulate even incompatible models or non-strict models.
- Finally, the prospect of multiple type/instance relations, of which the semantics can be filled in by the user, raises many new research questions.
- Specifically, which current modelling operations can be lifted to this relation?
- For example, conformance between execution traces and an executable model, properties and models, and concrete syntax with abstract syntax.
- Similarly, can we then instantiate an executable model by giving an execution trace?
- Or automatically instantiate models with specific properties?
- All of these models have some relation between them, but is this really conformance, and what is the usefulness of identifying these relations as conformance relations?
|