Since Kermeta is an extension of MOF, a MOF meta-model can conversely be seen as a valid Kermeta program that just declares packages, classes and so on but does nothing. Kermeta can then be used to breath life into this meta-model by incrementally introducing aspects for handling concerns of static semantics, dynamic semantics, or model transformations.
Kermeta allow to keep the concerns seprated at design time and then merge them to build a runable tool. It uses a powerful mecanism of static introduction that works at the model level and at the model element level.
One of the key feature of the workbench is the static composition
operator
require
. This operator allows defining these various
aspects in separate
units and integrating them
automatically into the
meta-model. The
composition
is done statically and the composed model is
typed-checked to ensure
the safe integration of all units.
This
mechanism makes it easy to reuse
existing meta-models or to split
meta-models into reusable pieces.
It allows to compose the
various
files and models that will form
the final tool.
The workbench will seamlessly convert and merge the various files into the final kermeta program. The classic inputs will be ecore files, kmt files or uml profiles files. The finala assembly will depend on the capabilities of the inputs models. For example, a ecore model has a granularity at the class level (ie. it will just add new classes) whereas Kermeta has a granularity at the feature level and thus can add new features to a class(see next section Section 1.5.2, “ Model element static introduction : Aspect-oriented language ” for more details)
TODO add a sample
Text not verified for kermeta 2 | |
---|---|
One of the key features of Kermeta is the static composition
operator
require
allows extending an existing meta-model with new elements
such as
properties, operations,
constraints or classes. This operator
allows defining these various
aspects in separate units and
integrating them automatically into the
meta-model. The composition
is done statically and the
composed model is typed-checked to
ensure
the safe integration of all units.
This mechanism makes
it
easy to reuse existing meta-models or to split
meta-models into
reusable pieces.
It can be
compared to the open class paradigm.
Consequently a
meta-class that identifies a domain concept
can be
extended without editing the meta-model directly. Open classes
in
Kermeta are used to
organize
cross-cutting
concerns separately from the meta-model to which they belong, a key
feature of aspect-oriented
programming. With this mechanism,
Kermeta can support the addition of new
meta-class, new
subclasses,
new methods, new properties, new contracts to
existing meta-model.
The
require
mechanism also provides flexibility. For example,
several
operational semantics could be
defined
in separate units for
a single meta-model and then alternatively
composed depending on
particular
needs. This is the case for instance in the UML
meta-model when
several semantics
variation points
are defined.
Thank to this composition operator, Kermeta can remain a kernel platform to safely integrate all the concerns around a meta-model. This feature has proved to be extremly useful in the context of metamodel engineering.
You'll find more details in the Reference chapter, more precisely in: Section 2.22, “ Weaving Kermeta code ”