6-conclusion.tex 4.0 KB

1234567891011121314151617181920212223242526272829303132333435
  1. \section{Conclusions}
  2. \label{sec:conclusions}
  3. We have identified several shortcomings of current tools in how they handle the type/instance relation between models and metamodels.
  4. This relation is bidirectional, and consists of both the instantiation and conformance checking algorithm.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Explicit modelling of these semantics allowed us to clearly seperate model structure (a graph) from conformance semantics (an algorithm).
  10. Additionally, the mapping between different models also became available as a model that can be used like any other.
  11. 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.
  12. Previous approaches have limited themselves to providing users a pre-defined function which they had to deal with; deviations were not allowed.
  13. And even when extension was possible, this was limited to the implementation language of the tool, which might be unfamiliar to the user.
  14. 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.
  15. 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.
  16. Performance problems can be resolved through efficient algorithms, similar to those found in other interpreters.
  17. Our approach was illustrated with a small example that is prevalent in current programming languages: the semantics of subtyping.
  18. 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?
  19. For each of these possible choices, there has been at least one programming language which choses one over the other.
  20. Their choices are often well-founded, making us believe that the ideal semantics is dependent on the domain.
  21. 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.
  22. When a problem naturally lends itself best to structural subtyping, for example, it should not be implemented using nominal subtyping.
  23. In future work, we plan to address the usability problems we encountered in our tool, as well as performance.
  24. Another direction for future work is the definition of a general type/instance relation, which holds for every model.
  25. 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.
  26. Finally, the prospect of multiple type/instance relations, of which the semantics can be filled in by the user, raises many new research questions.
  27. Specifically, which current modelling operations can be lifted to this relation?
  28. For example, conformance between execution traces and an executable model, properties and models, and concrete syntax with abstract syntax.
  29. Similarly, can we then instantiate an executable model by giving an execution trace?
  30. Or automatically instantiate models with specific properties?
  31. 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?