On model typing

Abstract

Where object-oriented languages deal with objects as described by classes, model-driven development uses models, as graphs of interconnected objects, described by metamodels. A number of new languages have been and continue to be developed for this modelbased paradigm, both for model transformation and for general programming using models. Many of these use single-object approaches to typing, derived from solutions found in object-oriented systems, while others use metamodels as model types, but without a clear notion of polymorphism. Both of these approaches lead to brittle and overly restrictive reuse characteristics. In this paper we propose a simple extension to object-oriented typing to better cater for a model-oriented context, including a simple strategy for typing models as a collection of interconnected objects. We suggest extensions to existing type system formalisms to support these concepts and their manipulation. Using a simple example we show how this extended approach permits more flexible reuse, while preserving type safety.

Flexible Model-to-Model Transformation Templates: An Application to ATL.

“…Since we do not want to define different concepts and templates for each design possibility, and in order to provide more reuse opportunities for a given template, a mechanism to overcome such heterogeneities is desirable. A first solution is to resort to subtyping relations between concepts [SJ07]. In this case, the commonalities of the different solution concepts are extracted to a supertype concept, which can be extended in order to provide alternative solutions for specific fragments.…”

Matching Model-Snippets

“…To allow features to be optional, we just set its lower bound as zero. These restrictions can be taken rewritten as invariants over a group of classes S, and any group of classes with a weaker invariant could be taken as a generalisation of S [6].…”

“…The need for identifying relationships between models, including modelsnippets, suggests that we might examine model-typing [6]. Indeed, we need to identify a type for the model-snippet in order to verify if a pattern can still be applied in a certain domain, after changes in the meta-model.…”

“…3) as a parametrized type operation, that can be performed to any model that conforms to a criterion. A good starting point for this criterion is to use type checking based on the type relationship matching [6] (< #), where any operation Op[X < #M M T ] parametrized with the group of types X can be successfully performed when X matches to a group of types M M T . Generally speaking, matching 2 in this context is satisfied when all class c t in M M T has a respective class c x in X that matches to it.…”

“…The main goal of simplifying the expression of patterns at the model level, avoiding any textual regular expressions, is to assist the design of these patterns with existing model editors for the user, whatever the meta-model. Moreover, we consistently define model patterns upon the concepts of model-typing [6], which permits us to better manage such patterns during model evolution. The results of this work are also integrated with existing technologies, such as EMF 1 (Eclipse Modelling Framework), Kermeta 1 (a metamodel engineering environment within Eclipse) and Flora-2 1 (An object-oriented knowledge base language that extends Prolog).…”