This paper describes practices for multi-level modeling by only using existing modeling frameworks that comply Meta-Object Facility (MOF). We design modeling patterns for achieving the multi-level modeling methodologies on Eclipse Modeling Framework, and implement the data ow model by applying the patterns. Moreover, we attempt to compare the patterns regarding the facilitation of developing both our tool and plugins. We found Orthogonal Classi cation Architecture (OCA) pattern is easier to develop our tool than powertypes pattern, but regarding plugins for our tool, powertypes pattern can de ne modelto-text transformation templates more simply than OCA pattern.
Model-driven engineering (MDE) gains productivity of software developments providing several powerful tools for designing, developing or verifying software. Especially, model transformation technologies (i.e., model-to-model and modelto-text) are important for facilitating agile software developments. For the modelto-text transformation enables to generate executable source codes from a model, developers can develop complex applications by using graphical editors.
There are various kinds of graphical editing tools for developing and
executing applications, e.g., Extract-Transform-Load [
Many of the tools are based on modeling frameworks and provide automatic
generation features for executable source codes. However, extending models of
the tools tends to be difficult for third-party developers, and therefore, there have
been a few plugins published from developer communities. Nowadays, the
metamodels of graphical editing tools have to be easily extensible so that developers
can develop more plugins [
Meta-Object Facility (MOF)1 is a standard for MDE provided by Object Management Group (OMG), and Eclipse Modeling Framework (EMF)2 is one
of mature MOF-compliant modeling frameworks, and there are various toolkits in the EMF community, such as Acceleo3, Query/View/Transformation (QVT) Operational4 and ATL Transformation Language5. Those toolkits also conform to or follow the OMG's standards. In this paper, we attempt to achieve multilevel modeling on EMF. EMF provides the Ecore metamodel, which is compatible with Essential MOF, and tools for creating models that conform to the Ecore metamodel.
One of the major drawbacks of EMF is that it is hard to de ne and use
a new metamodel located at the same level as the Ecore metamodel, because
EMF is basically adequate to create models and objects just based on the Ecore
metamodel. If we use our own metamodel, although it is obviously possible to
develop a proprietary tool based on it by using the code generation feature
of EMF [
In order to overcome the drawbacks of existing modeling frameworks, various methodologies of multi-level modeling have been proposed such as Orthogonal
modeling [
M2 M1 M0
Element Dataflow
Data
This paper describes practices for achieving multi-level models on EMF. We use a hierarchy of a data ow model as an example model that is used on graphical editing tools. We design multi-level modeling patterns on EMF, and implement the data ow model by applying the patterns. Moreover, we attempt to compare the patterns regarding the facilitation of developing both our tool and plugins.
The remainder of this paper is organized as follows. Section 2 describes a model of a graphical editing tool as our motivating example. Section 3 describes patterns for multi-level modeling on EMF. In Sect. 4 we discuss the comparison of the patterns, and our conclusions are presented in Sect. 5. 2
A typical graphical editing tool consists of a palette and a canvas as well as Fig. 1. The palette shows icons representing types of nodes, and the canvas is used to de ne a diagram by putting a node of the type selected from the palette and drawing an edge between nodes. By using such tool, we can easily develop a data processing application as a ow diagram that consists of nodes and edges representing icons and lines, respectively.
Figure 2 shows the hierarchy of the data ow model that we want to design. Layer M3 represents the original Ecore metamodel, and layer M2 represents the metamodel of the data ow model. Objects in layer M2 (i.e., Dataflow, Data and Process) are instances of Class. An instance of Dataflow composes instances L1 L2
O0 DefinitionElement definition InstanceElement
OCL M1 M0
powertype Class (EClass) instance-of subtype
Element instance-of
OCL
Definition
instance-of
Instance
of Data and Process, and represents how data is processed and the order of
execution in the processing methodologies as well as the de nition in [
Layer M1 represents de nitions of types and subtypes of Data and Process that are displayed on the palette. Classes in layer M1 are instances of the classes in layer M2 and have de nitions of type names, input ports, output ports and owned properties. In Fig. 2, Table and Model are instances of Data, and AddTimestamp and Duplication are instances of Process. Moreover, EventData and TemporaryData are subclasses of Table, and SVMModel is subclasses of Model. Those subclasses de ne their own properties and data schemata for storing databases. A plugin created by a third-party developer de nes a new instance of Process in layer M1, i.e., a new type of nodes in the palette.
Layer M0 represents an instance of Dataflow edited on the canvas in Fig. 1. Objects in layer M0 are instances of the objects in layer M1. Data node Sensor data in layer M0 represents data that is produced and sent by sensors and has the schema de ned by EventData. 3
Several multi-level modeling methodologies introduce a new concept of objects.
A clabject is an object that is both a class and an instance of another class [
We attempt to implement the data ow model described in Sect. 2 by applying the following two methodologies: OCA and powertype-based metamodeling. Figure 3 and 4 show modeling patterns as workarounds for each methodology. 3.1
The OCA has two dimensions of model layers: linguistic layers and ontological layers. In Fig. 3, L and O denotes linguistic layers and ontological layers, respectively. Layer L0 contains the Ecore metamodel and class Element that is an DefinitionElement
InstanceElement property
property
PropertyDefinition +type: string +defaultValue: string
DataDefinition field +category: string
data
PortDefinition +multiplicity: int output
input
ProcessDefinition +category: string inv ProcessHasValidInputPorts:
definition.input->forAll(i | input->exists(definition = i)) inv ProcessHasValidOutputPorts:
definition.output->forAll(i | output->exists(definition = i)) data
Dataflow in out
in outFirst outSecond out
AddTimestamp +time: string +millis: string +storedIn: string context EClass def: isA(typeName : String) : Boolean = name = typeName or oclIsKindOf(EClass) and oclAsType(EClass).eAllSuperTypes->exists(name = typeName) -- for subclasses of Data inv DataHasNoExtraProcessRefs: isA('Data') implies eReferences->forAll(
eReferenceType.isA('Process') implies name.matches('in|out') ...
) ) -- for subclasses of Process inv ProcessHasValidInputPorts: isA('Process') implies eReferences->forAll(
name.matches('^in.*') implies eReferenceType.isA('Data') ) inv ProcessHasValidOutputPorts: isA('Process') implies eReferences->forAll(
name.matches('^out.*') implies eReferenceType.isA('Data') instance of class Class, for de ning elements of ontological layers (O0 and O1)in layer L1. Class DefinitionElement in layer O0 and class InstanceElement in layer O1 de nes the type and the instance of elements of the data ow model, respectively. Layer L2 contains de nition objects and instance objects that are instances of class DefinitionElement and InstanceElement, respectively.
We represent an ontological instantiation relationship by a reference to a de nition object. The instance object has a reference to the de nition object, and the correctness of the relationship between them is veri ed by constraints written in Object Constraint Language (OCL).
Figure 5 shows the data ow model that conforms to the OCA pattern. Class Dataflow, Data, Process, Port and Property are instance classes, which are subclasses of class InstanceElement, and all of them respectively have their own de nition classes, which are subclasses of class DefinitionElement. Object Dataflow, EventData and AddTimestamp are de nition objects, i.e., instances of the de nition classes. Object A data processing, Sensor data and Add timestamp are instance objects, i.e., instances of the instance classes.
Examples of OCL constraints for instance objects of class Data and Process
are shown in the lower part of Fig. 5.
Powertype-based metamodeling introduces a powertype that is de ned as
a type whose instances are types inheriting a subtype [
Figure 6 shows the data ow model that conforms to the powertypes pattern. As class Dataflow, Data and Process are subclasses of class Element, the hierarchy of all classes are represented as inheritance relationships. Class EventData, which is a subclass of class Table, has attributes that represent data schema. Class AddTimestamp, which is a subclass of class Process, has attributes that represent parameters of the process. Class AddTimestamp also has an input port and an output port as references to class Table, which means that it consumes and produces Table-typed data.
Object A data processing, Sensor data and Add timestamp are instances of class Dataflow, EventData and AddTimestamp respectively.
Examples of OCL constraints for subclasses of class Data and Process are shown in the lower part of Fig. 6. 4
We attempt to compare our modeling patterns, OCA and powertypes, regarding the facilitation of the following developments: developing our tool by
Name Description Input a single port that consumes a subclass of Table Output a single port that produces a subclass of Table time a formatted date string, e.g., ``yyyy-MM-dd hh:mm:ss'' millis an integer string of a millisecond value storedIn a eld name to which a timestamp value is assigned ourselves and developing plugins for our tool by third-party developers. We consider there are a lot of viewpoints regarding the facilitation, but we have not yet completed the comprehensive evaluation from the viewpoints. In this paper, we concentrate the following two viewpoints: model manipulation for our tool and template description for plugins. 4.1
Regarding the development of our tool, we focus on how to manipulate the model on the methodology. The OCA pattern can utilize the code generation features of EMF, because we do not need to extend metamodels in layer L0 of Fig. 3. All objects that are added by plugins for new types of data or processes are located in layer O0, and they can be manipulated by using automatically generated codes. On the other hand, when we apply the powertypes pattern, we have to extend the Ecore metamodel dynamically, so it is difficult to utilize the code generation. We have to manipulate objects in layer M0 by only using the default Ecore APIs that are not intuitive and troublesome to manipulate. 4.2
Regarding the development of plugins, we focus on the description of the modelto-text transformation template for process AddTimestamp in Fig. 1, 2, 5 and 6. Table 1 shows the de nition of process AddTimestamp. The process produces a record that is appended a new eld named as the string value of storedIn. The new eld is assigned a string value of a timestamp that is calculated by using time, and millis of an original record.
Now, we consider a template for producing the following SQL-like processing query. insert into <Output> select <Field of Input>[,<Field of Input> ...], UDF.timestamp(<time>, <millis>) as <storedIn> from <Input>
We use Acceleo, which is an implementation of MOFM2T6, for generating the query. By applying the OCA pattern, the template can be described as follows. 6 http://www.omg.org/spec/MOFM2T/ [template public generate(aProcess : Process) overrides generate ? (definition.name='AddTimestamp')] insert into [output->any(definition.name='out').data.name/] select [for (input->any(definition.name='in') .data.definition.field) separator(',')][name/][/for] , UDF.timestamp( [property->any(definition.name='time').value/], [property->any(definition.name='millis').value/] ) as [property->any(definition.name='storedIn').value/] from [input->any(definition.name='in').data.name/] [/template]
By applying the powertypes pattern, the template can be described as follows. [template public generate(aProcess : AddTimestamp) overrides generate] insert into [out.name/] select [for (_in.eClass().eAttributes) separator(',')][name/][/for] , UDF.timestamp([time/],[millis/]) as [storedIn/] from [_in.name/]; [/template]
By contrasting those descriptions, the powertypes pattern can describe the template more simply than the OCA pattern. This is because objects in layer M1 of Fig. 4 are just models of the Ecore metamodel, so we can directly access the attribute values of their instances. This advantage is valid not only Acceleo but also other EMF-based toolkits, and the fact indicates that the powertypes pattern is more usable by following the existing common manners of MOFcompliant modeling frameworks. 5
In this paper, we described the practices for achieving multi-level modeling by only using EMF. We de ned modeling patterns of the following two methodologies: OCA and powertype-based metamodeling. We implemented the data ow model for graphical editing tools by applying the patterns. By comparing the implementations on the two methodologies, We found the OCA pattern is easier to develop our tool than the powertypes pattern, but regarding plugins for our tool, the powertypes pattern can de ne model-to-text transformation templates more simply than the OCA pattern.
We consider we have to achieve the ease of developing plugins for our tool rather than the ease of developing our tool itself, because increasing the number of plugins can bene t our tool and our communities. Although regarding the simplicity of template descriptions, the powertypes pattern is a better choice than the OCA pattern, further evaluations from other viewpoints are needed for determining the best pattern.
We hope that the multi-level modeling methodology is standardized adequately following the existing common manners of MOF-compliant modeling frameworks.