© 2015 for the individual papers by the papers’ authors. Copying permitted for private and academic purposes. Re-publication of material from this volume requires permission by the copyright owners.
Universidad Autonoma de Madrid (Spain) develop group (Germany) Federal University of Esp rito Santo (Brazil) University of Mannheim (Germany) S23M (Australia) Middlesex University (United Kingdom) Johannes Kepler Universitat Linz (Austria) Universitat Duisburg-Essen (Germany) University of Mannheim (Germany) University of Bremen (Germany) Spanish National Research Council (CSIC) University of South Australia (Australia) Universidad Autonoma de Madrid (Spain) Universitat Bayreuth (Germany) University of Skovde (Sweden) Victoria University of Wellington (New Zealand) Bergen Univeristy College (Norway) Universidad Autonoma de Madrid (Spain) University of Helsinki (Finland) Universitat Salzburg (Austria) SINTEF (Norway) Johannes Kepler Universitat Linz (Austria) University of South Australia (Australia) TU Wien (Austria)
King's College London (Germany)
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Experimenting with Multi-Level Models in a Two-Level Modeling Tool . . . . . . . . . Martin Gogolla Aspect-oriented Concrete Syntax De nition for Deep Modeling Languages . . . . . Colin Atkinson and Ralph Gerbig Exploring Multi-Level Modeling Relations Using Variability Mechanisms . . . . . . . Iris Reinhartz-Berger, Arnon Sturm, and Tony Clark Multi-Language Modelling with Second Order Intensions . . . . . . . . . . . . . . . . . . . . . . . Vadim Zaytsev Practical Multi-level Modeling on MOF-compliant Modeling Frameworks . . . . . . Kosaku Kimura, Yoshihide Nomura, Yuka Tanaka, Hidetoshi Kurihara, and Rieko Yamamoto An algebraic instantiation technique illustrated by multilevel design patterns . . . Zoltan Theisz and Gergely Mezei 1 3 13 23 33 43 53 MULTI 2015 was the second installment of the MULTI workshop series focusing on multilevel modeling. It was held as a satellite event of the ACM/IEEE sponsored conference MODELS 2015, in Ottawa (Canada). The goal of this workshop was to continue the community building initiated in the rst edition held in conjunction with MODELS 2014 in Valencia (Spain). In order to increase the level of dissemination of work in multilevel modeling and to provide more opportunities for plenary discussions and/or group work, MULTI 2015 was organized as a two-day workshop rather than the typical one-day workshop.
The aim of the rst day of the workshop was to set the scene for discussions by means of paper presentations that included an invited paper and two regular paper sessions. The invited paper by Professor Martin Gogolla of the University of Bremen, entitled \Experimenting with Multi-Level Models in a Two-Level Modeling Tool", explored the extent to which multi-level models can be simulated in two-level modeling environments by explicitly modeling di erent underlying linguistic (meta) models at the class level, and simulating ontological classi cation relationships at the instance level in the form of links.
The rst paper in the rst regular paper session by Colin Atkinson and Ralph Gerbig, entitled \Aspect-oriented Concrete Syntax De nition for Deep Modeling Languages", described how to support a deep, context sensitive visualization of multi-level models using concepts from aspect-orientation to merge concrete syntax elements across instantiation chains. The second paper by Iris Reinhartz-Berger, Arnon Sturm and Tony Clark, entitled \Exploring Multi-Level Modeling Relations Using Variability Mechanisms", explored the relationship between the instantiation forms found in multi-level modelling and those used in product line engineering.
The rst paper of the afternoon session by Vadim Zaytsev, entitled \Multi-Language Modelling with Second Order Intensions", proposed the use of second-order intensions and extensions to more closely model linguistic and ontological conformance. The second paper by Kosaku Kimura, Yoshihide Nomura, Yuka Tanaka, Hidetoshi Kurihara and Rieko Yamamoto, entitled \Practical Multi-level Modeling on MOF-compliant Modeling Frameworks" explored how multi-level modeling can be supported using existing modeling frameworks based on the MOF. The third paper by Zoltan Theisz and Gergely Mezei, entitled \An algebraic instantiation technique illustrated by multilevel design patterns" proposed a new algebraic instantiation approach aiming to provide a solid, algebraic foundation for multi-level meta-modelling which is easily customizable. The rst day concluded with a plenary session that allowed participants to discuss issues raised in the presentations and nd consensus on how to best structure the second afternoon.
The morning of the second day of the workshop was devoted to providing an insight into the range of tools currently available to support multi-level modeling. Six di erent tools with various kinds of multi-level modeling capabilities were demonstrated over two sessions: the DPF workbench from Bergen University College, Norway (presented by Xiaoliang Wang and Yngve Lamo), WebDPF from Bergen University College, Norway (presented by Fazle Rabbi and Yngve Lamo, Melanee { The Deep Modeling Domainspeci c Language Workbench from the University of Mannheim, Germany (presented by Ralph Gerbig), MetaDepth { a tool for multi-level model-driven engineering, from the Universidad Autnoma de Madrid, Spain (presented by Juan de Lara and Esther Guerra), a tool for Multilevel Modelling and Reasoning with FOML from Ben-Gurion University, Israel and SUNY Stony Brook, USA (presented by Mira Balaban, Igal Khitron and Michael Kifer), and TouchCORE from McGill University, Montreal (presented by Jorg Kienzle).
The nal afternoon of the workshop was structured by two plenary sessions discussing the state of multi-level modelling technology and identifying areas where further clari cation would be helpful to the community. The debate included arguments on the nature of the distinction between linguistic and ontological classi cation and the roles these different forms of classi cation should play within classi cation architectures. One of the intensely discussed questions was whether ontological classi cation relationships should require certain syntactic conformance rules in addition to being based on (either explicitly or implicitly represented) mappings to the meaning of the related elements. Due to a lack of time, the idea of agreeing on a de nition of \multi-level modeling" could only be partially pursued by collecting a set of candidate de nitions. Likewise, a concrete identi cation of use cases, scenarios, reference architectures, etc. had to be deferred.
In order to further support the dissemination of new information and provide a common repository for de nitions, tool descriptions, modeling artifacts, etc., the participants agreed to establish a forum for online interaction for the multi-level modelling community in the form of a wiki web. The respective wiki can be found at: http://homepages.ecs.vuw.ac.nz/Groups/MultiLevelModeling/ and everyone is invited to update contents. The website devoted to the MULTI workshop series is still hosted at: http://www.miso.es/multi/.
We are grateful to all authors of submitted papers, to the reviewers for their constructive criticism, to all participants of the workshop for the interesting and lively discussions, and to the organizers of MODELS 2015 for their support.
Martin Gogolla Database Systems Group, University of Bremen, Germany
gogolla@informatik.unib-remen.de Abstract. This paper discusses two ways to establish the connection between two levels in a multi-level model. The first approach uses normal associations and generalizations under the assumption that the multi levels are represented in one UML and OCL model. The second approach views a middle level model both as a type model and as an instance model and introduces operations to navigate between the type and instance level. The paper reports on some experiments that have been carried out.
Keywords. UML, OCL, Model, Multi-level model, Metamodel, Level connection. 1
Introduction
Metamodeling has become a major topic in software engineering research [
Metamodeling is closely connected to multi-levels models because the instantiation of a metamodel is a model. That model, when viewed as a type model, may be instantiated again and can then be viewed as an instance model. Proceeding this way, at least three model levels arise.
This paper discusses two ways to establish the connection between two levels in
multi-level models. The first approach uses ordinary associations and
generalizations under the assumption that the multi levels are represented in one UML
and OCL model. The second approach views a middle level model both as a type
model and as an instance model and introduces operations in order to navigate
between the type and instance level. The paper reports on some experiments
that have been carried out. The first appr oach joins the metamodels of several
levels into one model as in our previous work [
Our work has links to other related or similar approaches. The tool Melanie [
The structure of the rest of the paper is as follows. Section 2 gives a small example for establishing the multi-level connection with associations and generalizations. Section 3 discusses the second approach that uses operations to connect the multi-levels. The contribution is closed with a conclusion and future work in sect. 4. 2
Connecting MultiL-evels with Associations and
Generalizations
The rfist approach connects multi-levels with usual model elements: associations
and generalizations. The example in Fig. 1 shows a substantially reduced and
abstracted version of the OMG four-level metamodel architecture with modeling
levels M0, M1, M2, and M3. Roughly speaking, the figure states: Ada is a Person,
Person is a Class, and Class is a MetaClass. The gfiure does so by formally
building an object diagram for a precisely defined class diagram including an
OCL invariant that requires cyclefreeness when constructing instance-of
connections. The distinction between MetaClass and Class is that when MetaClass
is instantiated something is created that can be instantiated on two lower levels
whereas for Class instantiation can only be done on one lower level. The model
has been formally checked with the tool USE [
Concepts on a respective level Mx are represented in a simplified way as a class Mx. All classes Mx are specializations of the abstract class Thing whose objects cover all objects in the classes Mx. On that abstract class Thing one association Instantiation is defined that is intended to represent the instance-of connections between a higher level object and a lower level: an object of a lower level is intended to be an instance of an object on a higher level. The association Instantiation on Thing (with role names instantiater and instantiated) is employed for the definition of the associations Typing0, Typing1, and Typing2 between Mx and Mx+1 all having roles typer and typed. The role typer is a redefinition of instantiater, and typed is a redenfiition of instantiated. The multiplicity 1 of typer narrows the multiplicity 0..1 of instantiater. The class diagram from the left side of Fig. 1 is made concrete with an object diagram on the right side. The fact that the three associations Typing0, Typing1, and Typing2 are all redenfiitions of association Instantiation is reflected in the object diagram by the three dashed links for association Instantiation with common role names instantiater and instantiated (dashed links in contrast to continuous links for ordinary links). Viewing Instantiation as a generalization (in terms of redefinition) of all Typingx associations allows to use the closure operations from class Thing on objects from classes M0, M1, M2 or M3. Thus the displayed OCL expressions and their results reflect the following facts: object Person is a (direct resp. indirect) instantiation of objects Class and MetaClass; objects Ada and Person are (direct resp. indirect) instantiations of object Class.
Metamodeling means to construct models for several levels. The metamodels on the respective level should be described and modeled independently (e.g., as M0, M1, M2, and M3). The connection between the models should be established in a formal way by a typing association (e.g., Typing0 gives a type object from M1 to a typed object from M0). The Typing associations are introduced as redefined versions of the association Instantiation from (what we call) a multi-level superstructure. This superstructure contains the abstract class Thing which is an abstraction of all metamodel elements across all levels and additionally contains the association Instantiation and accompanying constraints. Because Instantiation is defined as union, an Instantiation link can only connect elements of adjacent levels, i.e., the Typingx links are level-conformant and strict. The aim of the devices in the superstructure is to establish the connection between metamodel levels in a formal way and to provide support for formally restricting the connections. 3
Connecting MultiL-evels with Operations
The second approach for connecting multi-levels is based on viewing one model
both as a type model and as an instance model. In Fig. 2 an example as
elaborated with USE [
In Fig. 4 such a connection is indicated with (a) one operation accessing a model element through its String-valued name $_$ : String -> ModelElement and (b) one operation returning the String-valued name of a model element #_# : ModelElement -> String .
Apart from the two new operations dollar $ and sharp # some new modeling features for UML and OCL would be needed as well: (a) OCL clauses (for elements such as invariants or pre- and postconditions) should allow parameters that represent variables for model elements and (b) the new operations dollar and sharp should be allowed in expressions for model elements in clauses (e.g., for a class or an attribute). The following examples try to give an impression of the aimed functionality. parameter[rs:RelSchema] let relSchemaClass = $rs.name$ in - in this example: $rs.name$=rs let keyAttr = $rs.attr->any(a|a.isKey=true).name$ in context relSchemaClass inv keyAttrUnique: relSchemaClass.allInstances>-forAll(x,y |
x<>y implies x.keyAttr<>y.keyAttr) parameter[rs:RelSchema] let relSchemaClass = $rs.name$ in let keyAttr = $rs.attr->any(a|a.isKey=true).name$ in context x,y:relSchemaClass inv ’keyAttrUniqueIn’ + #rs#: x<>y implies x.keyAttr<>y.keyAttr In these examples it is assumed that there is exactly one key attribute for each class. When these parameterized features become actualized, then in this case the following invariants would be required. It is an open question whether the actualization is implicit or explicit: The actualization mechanism may be considered as being implicit for all actual features that are available in the model, or the actualization mechanism may be considered as being something the modeler has to explicitly ask for. context Town inv keyAttrUnique:
Town.allInstances>-forAll(x,y | x<>y implies x.name<>y.name) context Country inv keyAttrUnique:
Country.allInstances>-forAll(x,y | x<>y implies x.name<>y.name) context x,y:Town inv keyAttrUniqueInTown:
x<>y implies x.name<>y.name context x,y:Country inv keyAttrUniqueInCountry: x<>y implies x.name<>y.name This paper is based on the idea to describe different metamodels in one model and to connect the metamodels either (a) with generalizations and associations employing appropriate UML and OCL constraints or (b) with special operations allowing to navigate between different multi-levels in a model. The paper does not claim to present final results, but some experiments and ideas in the context of multi-level models.
Future research includes the following topics. We would like to work out for our
approach formal denfiitions for notions like potency or strictness. The notion of
powertype will be given special attention in order to explore how far this concept
can be integrated. Our tool USE could be extended to deal with different
metamodel levels simultaneously. So far USE deals with class and object diagram.
In essence, we think of at least a three-level USE (cubeUSE) where the middle
level can be seen at the same time as an object and class diagram, as has been
sketched in the second approach in this paper. Furthermore, larger examples and
case studies must check the practicability of the proposal.
12. Gogolla, M., Favre, J.M., Bu¨ttner, F.: On Squeezing M0, M1, M2, and M3 into a
Single Object Diagram. In et al., T.B., ed.: Proc. MoDELS’2005 Workshop Tool
Support for OCL and Related Formalisms, EPFL (Switzerland),
LGL-REPORT2005-001 (2005)
13. Gogolla, M., Sedlmeier, M., Hamann, L., Hilken, F.: On Metamodel
Superstructures Employing UML Generalization Features. In Atkinson, C., Grossmann,
G., Ku¨hne, T., de Lara, J., eds.: Proc. Int. Workshop on Multi-Level
Modelling (MULTI’2014), http://ceur-ws.org/Vol-1286/, CEUR Proceedings, Vol. 1286
(2014) 13–22
14. Guerra, E., de Lara, J.: Towards Automating the Analysis of Integrity Constraints
in Multi-Level Models. [
University of Mannheim {atkinson, gerbig}@informatik.uni-mannheim.de Abstract. Multi-level modeling tools provide inherent support for modeling domain scenarios with multiple classification levels. However, as the success of domain-specific modeling tools illustrates users increasingly expect to be able to visualize models using domain-specific languages. It is relatively straightforward to support this using traditional “two-level” modeling technologies, but many of the benefits of multi-level modeling would be lost. For example, in a multi-level context it is not only desirable to define concrete syntax that is applicable over more than just one instantiation level, it should also be possible to customize the visualization of model elements as they become more specialized over instantiation and inheritance levels. In this paper we present an approach for multi-level concrete syntax definition which addresses this need by using aspect-oriented principles to parametrize the visualization associated with model elements. We also explain how this is implemented in the Melanee deep modeling tool.
Keywords: aspect-orientation; deep modeling; concrete syntax 1
Introduction
Since concrete syntax definition is one of the core foundations of domain-specific,
model-driven development a large number of tools supporting this capability are
available today. Important examples include MetaEdit+ [
Deep modeling has the potential to address this problem because it inherently supports multiple classification levels. However, some challenges need to be addressed to support effective level-spanning concrete syntax definition and application within a deep modeling environment. The most significant is to find a suitable tradeoff between the need to define common syntax elements that are suitable across multiple levels whilst providing the flexibility to customize the common syntax elements as and where needed. In other words, the most significant challenge is to allow the concrete syntax used to visualize model elements to reflect the specialization that inherently takes place in the instantiation and inheritance hierarchies in a deep model.
The Melanee [
The remainder of this paper is structured as follows: In the next section (Section 2) the underlying deep modeling approach is introduced. Section 3 then introduces the concept of aspect-oriented concrete syntax definition while Section 4 presents pragmatic observations made during the use of the approach in three different domains. The paper closes with conclusions (Section 5). 2
OCA-based Deep Modeling The most widely implemented deep modeling architecture is the orthogonal classification architecture shown schematically in Figure 1. Its most obvious difference to the traditional linear modeling infrastructure of the UML is that there are two “orthogonal” classification dimensions. One dimension, the linguistic classification dimension, is represented by the vertical stack of levels labeled L2 to L0, and the other dimension, the ontological classification dimension, is represented by the horizontal stack of levels labeled O0 to O2.
The linguistic levels essentially capture the organization of the model information from the perspective of how deep modeling is realized in a meta-modeling framework such as EMF. The top most linguistic level (L2), contains all language constructs available in the deep modeling language, while the middle level (L1) contains the user-modeled domain languages and is thus often referred to as the domain level. The ontological dimension, in turn, consists of “ontological” levels which are stacked horizontally within L1. Each model element at this level is classified by exactly one model element at level L2, indicated by vertically dashed classification lines. The lowest level, L0, contains the real-world concepts modeled by L1. The light bulb represents the concept of EmployeeType which captures the common properties of all employees. The group of stick-men with a wrench ∨LT w w w w w w w w w w ∨∨LT δ- ∧∨LT δ∧ ε - ∧LT δ∨
? ι- ∨∧LT χ
PT δ-∧ ∧∧LT = ∧∧LC
δ∧ μ χ
χ - JP K μ
PC ∧LC δ∨
? ∨∧LC
ι χ
δ∧ ∧∨LC ε ∨LC w w w w w w w w w w - ∨∨LC
JP K with ∧P and using ∨P for the hypothetical set of all possible representations of a program P .
The notion of commitment to grammatical structure was discussed by Klint,
Lämmel and Verhoef [
Atkinson [
9
Apart from the Fregean perspective on intensional logic, Montague
considered a Russelian variant where the extension of the intension (called the “sense
denotation”) is not a fundamental concept [
10
Kosaku Kimura, Yoshihide Nomura, Yuka Tanaka,
Hidetoshi Kurihara, and Rieko Yamamoto
Fujitsu Laboratories, Kawasaki, Japan { kimura.kosaku,y.nomura,tanaka.yuka,kurihara.hide,r.yamamoto} @jp.fujitsu.com Abstract. 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 dataflow 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 Classification Architecture (OCA) pattern is easier to develop our tool than powertypes pattern, but regarding plugins for our tool, powertypes pattern can define modelto-text transformation templates more simply than OCA pattern. 1 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 1 http://www.omg.org/mof/ 2 https://eclipse.org/modeling/emf/ Fig. 1. EMF-based graphical editing tool for developing and executing big data processing. 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 define 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
Classification Architecture (OCA) [
Element M2 M1
Duplication +Input: Data +Output: Data[]
Output[0]
Output[
This paper describes practices for achieving multi-level models on EMF. We use a hierarchy of a dataflow model as an example model that is used on graphical editing tools. We design multi-level modeling patterns on EMF, and implement the dataflow 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
Motivating example: a dataflow model for graphical editing tools 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 define 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 flow diagram that consists of nodes and edges representing icons and lines, respectively.
Figure 2 shows the hierarchy of the dataflow model that we want to design. Layer M3 represents the original Ecore metamodel, and layer M2 represents the metamodel of the dataflow model. Objects in layer M2 (i.e., Dataflow, Data and Process) are instances of Class. An instance of Dataflow composes instances L1 L2
O0 M1 M0
powertype Class (EClass) instance-of subtype
Element instance-of
OCL
Definition
instance-of Instance Fig. 3. OCA pattern.
Fig. 4. Powertypes pattern.
of Data and Process, and represents how data is processed and the order of
execution in the processing methodologies as well as the definition in [
Layer M1 represents definitions 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 definitions 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 define their own properties and data schemata for storing databases. A plugin created by a third-party developer defines 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 defined by EventData. 3
Multi-level modeling on EMF
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 dataflow 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. 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
Dataflow data process DefinitionElement
InstanceElement property
property definition definition definition definition
Property +value: string
Data data output input
Port +index: int output input definition definition definition
instance-of Add timestamp -- for instance objects of Data context Data inv DataHasDefinition: definition <> null inv DataHasValidProperties:
definition.property->forAll(i | property->exists(definition = i)) inv DataHasValidFields:
definition.field->forAll(name <> null and type <> null) -- for instance objects of Process context Process inv ProcessHasDefinition: definition <> null inv ProcessHasValidProperties:
definition.property->forAll(i | property->exists(definition = i)) inv ProcessHasValidInputPorts:
definition.input->forAll(i | input->exists(definition = i)) inv ProcessHasValidOutputPorts:
definition.output->forAll(i | output->exists(definition = i))
Fig. 5. Dataflow model and excerpt of OCL constraints in OCA pattern. data
Data Model
in SVMModel
EventData +eventId: int +timeStr: string +millisStr: string +type: string +value: string Sensor data
process
Duplication instance-of
instance-of Add timestamp
A data processing
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 defining elements of ontological layers ( O0 and O1)in layer L1. Class DefinitionElement in layer O0 and class InstanceElement in layer O1 defines the type and the instance of elements of the dataflow model, respectively. Layer L2 contains definition objects and instance objects that are instances of class DefinitionElement and InstanceElement, respectively.
We represent an ontological instantiation relationship by a reference to a definition object. The instance object has a reference to the definition object, and the correctness of the relationship between them is verified by constraints written in Object Constraint Language (OCL).
Figure 5 shows the dataflow 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 definition classes, which are subclasses of class DefinitionElement. Object Dataflow, EventData and AddTimestamp are definition objects, i.e., instances of the definition 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. 3.2
Model applying powertypes pattern
Powertype-based metamodeling introduces a powertype that is defined as
a type whose instances are types inheriting a subtype [
Figure 6 shows the dataflow 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
Evaluation 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 field 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.
Model manipulation for our tool 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
Template description for plugins 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 definition of process AddTimestamp. The process produces a record that is appended a new field named as the string value of storedIn. The new field 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 defined modeling patterns of the following two methodologies: OCA and powertype-based metamodeling. We implemented the dataflow 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 define 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 benefit 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.
1 Huawei Design Centre, Ireland,
zoltan.theisz@huawei.com
2 Budapest University of Technology and Economics, Budapest, Hungary,
gmezei@aut.bme.hu
Abstract. Multi-level meta-modeling hinges on the precise
conceptualization of the instantiation relation between elements of the meta-model
and the model. In this paper, we propose a new algebraic instantiation
approach, the Dynamic Multi-Layer Algebra. The approach aims to
provide a solid algebraic foundation for multi-level meta-modeling, which is
easily customizable through different bootstrap elements and a dynamic
instantiation procedure. The paper describes the major parts of the
approach and also demonstrates their modeling capabilities by covering
some of the most-often used design patterns for multi-level modeling.
Keywords: multi-level meta-modeling, dynamic instantiation, design
patterns
1
Multi-level meta-modeling is enjoying a renaissance thanks to the dynamic
modeling needs of contemporary complex software systems. For example, next
generation telecom management systems set new challenges towards centralized,
model-based extendable network element repositories that must be able to be
used both in design- and run-time. The model repository must be open-ended
with respect to complex types: both through gradual extension and the
introduction of new elements. Therefore, many well-known meta-modeling patterns such
as type-object, dynamic features or the dynamic auxiliary domain concepts [
In this paper, we aim to illustrate how such an alternative multi-level
metamodelling approach, referred to as Dynamic Multi-Layer Algebra (DLMA) [
Background
Instantiation lies at the heart of any metamodel-based model development
technique. Instantiation is the key operation that defines the semantic linkage
between the meta-model and the model level. This linkage can be ontological or
linguistic, or even both at the same time, depending on the actual
methodology and the available tools used for meta-modelling. Standard approaches prefer
the linguistic interpretation which results in a two level architecture, where the
metamodel is built first and then it is instantiated into models. This
architecture has been implemented, for example, in Eclipse Modelling Framework
(EMF) [
With only linguistic interpretation enforced, the resulting multi-level models
may become ad-hoc and usually involve accidental complexity. In order to avoid
mixed ontological and linguistic instantiation and to overcome the limits set
by the two-meta-level architecture, pure multi-level meta-modeling approaches
have been put in action. These techniques can distinguish between two kinds of
instantiation: shallow instantiation means that information is used at the
immediate instantiation level, while deep instantiation allows to define information on
the deeper modeling levels as well. If we need each meta-level to be instantiable,
there must be some means to add new attributes and operations to the existing
models. There are two options: one can either bring the source of the
information along through all model levels (and use it where it may be needed), or one
can add the source of that information directly to the model element where it is
actually used. The concept of potency notion and dual field notion [
Although potency allocation at end-points can be consistently extended to
connections as well [
Data representation In DMLA, the model is represented as a Labeled Directed Graph. Each model element such as nodes and edges can have labels. Attributes of the model elements are represented by these labels. Since the attribute structure of the edges follows the same rules applied to nodes, the same labeling method is used for both nodes and edges. Moreover, for the sake of simplicity, we use a dual field notation in labeling that represents Name/Value pairs. In the following, we refer to a label with the name N of the model item X as XN .
We define the following labels: (i) XName (the name of the model element), (ii) XID (a globally unique ID of the model element), (iii) XMeta (the ID of the metamodel definition), (iv) XCardinality (the cardinality of the model element, which is applied during the instantiation as an explicit constraint imposed on the number of instances the model element may exist in within the instance model), (v) XV alue (the value of the model element is only used in the case of attributes!), (vi) XAttributes (a list of attributes)
Due to the complex structure of attributes, we do not represent them as atomic data, but as a hierarchical tree, where the root of the tree is always the model item itself. Nevertheless, we handle attributes as if they were model elements. More precisely, we create virtual nodes from them. Virtual here means that these nodes do not appear as real (modeling) nodes in diagrams but – from the algebra’s formal point of view – they behave just like usual model elements. This solution allows us to handle attributes and model elements uniformly and avoid multiplication of labeling and ASM functions. Since we use virtual nodes, all the aforementioned labels are also used for them: attributes have a name, an ID, a reference to their meta definition, a cardinality and they may have attributes as well. Moreover, they may also have a value. By the way, this is the reason why we have defined the Value label.
After the structure of the modeling elements has been briefly introduced, we now define the Dynamic Multi-Layer Algebra itself.
Definition 1. The superuniverse |A| of a state A of the Dynamic Multi-Layer Algebra consists of the following universes: (i) UBool (containing logical values {true/false}), (ii) UNumber (containing rational numbers {Q} and a special symbol representing infinity), (iii) UString (containing character sequences of finite length), (iv) UID (containing all the possible entity IDs), (v) UBasic (containing elements from {UBool ∪ UNumber ∪UString ∪UID}).
Additionally, all universes contain a special element, undef, which refers to an undefined value. The labels of the entities take their values from the following universes: (i) XName (UString), (ii) XID (UID), (iii) XMeta (UID), (iv) XCardinality ([UNumber,UNumber]), (v) XV alue (UBasic), (vi) XAttrib (UID[]).
Note that we modeled cardinality as a pair of lower and upper limits. Obviously, this representation could be extended to support ranges (e.g. “1..3”) as well. The label Attrib is an indexed list of IDs, which refers to other entities.
Now, let us have an example: BookID = 42, BookMeta= 123, BookCardinality = {0, inf}, BookV alue = undef , BookAttrib = [] The definition formalizes the entity Book with its ID of 42 and the ID of its metamodel being 123. Note that in the algebra, we do not require that the universe of IDs uses the universe of natural numbers, this is only one possible implementation we use for illustration. In effect, the only requirement imposed on the universe is that it must be able to identify its elements uniquely. Now, one can instantiate any number of the Book entities in the instance model, which will have no components and values defined. For the sake of legibility, we will use a more compact notation from now on without loosing the original semantics:
{"Book", 42, 123, [0, inf], undef, []}. Functions are used to define rules to change states in ASM. In DMLA, we rely on shared and derived functions. The current attribute configuration of a model item is represented using shared functions. The values of these functions are modified either by the algebra itself, or by the environment of the algebra (for example by the user). Derived functions represent calculations, they cannot change the model, they are only used to obtain and restructure existing information. Thus, derived functions are used to simplify the description of the abstract state machine. The vocabulary P of the Dynamic Multi-Layer Algebra formalism is assumed to contain the following characteristic shared functions: (i) Name(UID): UString, (ii) Meta(UID): UID, (iii) Card(UID): [UNumber,UNumber], (iv) Attrib(UID, UNumber): UID, (v) Value(UID): UBasic.
The functions are used to access the values stored in the corresponding
label. Note that the functions are not only able to query the requested
information, but they can also update the information. For example, one can
update the meta definition of an entity by simply assigning a value to the
Meta function: Meta(IDConcreteObject) : = IDNewMetaDefinition. Moreover, there
are two derived functions: (i) Contains(UID,UID): UBool and (ii)
DeriveFrom(UID,UID): UBool. The first function takes an ID of an entity and the
ID of an attribute and checks if the entity contains the attribute. The second
function checks whether the entity identified by the first parameter is an
instantiation, also transitively, of the entity specified by the second parameter. The
detailed, precise definition of the above functions are reported in [
Bootstrap mechanism The aforementioned functions make it possible to query and change the model. However by only these constructs, it is very hard to use the algebra since it lacks the basic, built-in modeling constructs. For example, entities are required to represent the basic types, otherwise one cannot use the label Meta when it refers to a string because the label is supposed to take its value from UID and not from UString. To draw a parallel, functions are like empty hardware components. They are useless unless an operation system to invigorates the system.
In DMLA, there is no universal setup for this initial set of modeling constructs. For example, one can restrict the usage of basic types to an absolute minimum, or one can extend them by allowing technology domain or metamodeling specific types. Also, meta-modeling constructs such as attribute injection or inheritance may be defined explicitly here. Using our previous analogy: we can install different operating systems on our hardware for different purposes. It is worth mentioning that the bootstrap and the instantiation mechanism cannot be defined independently of each other. When an entity is being instantiated there are constructs to be handled in a special way. For example, we can check whether the value of an attribute violates the type constraints of the meta-model only if the algorithm can find and use the basic type definitions. The bootstrap presented in this paper provides a practically useful minimal set of constructs, however that can be freely modified if needed without changing the foundational algebra. The bootstrap has two main parts: basic types and principal modeling entities.
The built-in types of the DMLA are the following: Basic, Bool, Number,
String, ID. All types refer to a value in the corresponding universe. In the
bootstrap, we define an entity for each of these types, for example we create an
entity called Bool, which will be used to represent Boolean type expressions.
Types Bool, Number, String and ID are inherited from Basic. Besides the basic
types, we also define three principal entities: Attribute, Node and Edge. They act
as the root meta elements of attributes, nodes and edges, respectively. All three
principal entities refer to themselves by meta definition (more precisely, they are
self-referring among themselves). Thus, for example, the meta of Attribute is the
Attribute entity itself.
{"Attribute",IDAttr,IDAttr,[0,inf],undef,
[{"Attributes",IDAttrs,IDAttr,[0,inf],undef,[]}]
}
We should also mention here that attributes are not only used as simple data
storage units, but also for creating annotations that are to be processed by
the instantiation. Similarly to basic types, we can define special attributes with
specific meaning. By adding these annotational attributes to entities, we can
finetune their handling. We define three annotation attributes: AttribType, Source
and Target. AttribType is used as a type constraint to validate the value of the
attribute in the instances. The Value label of AttribType specifies the type to be
used in the instance of the referred attribute. Using AttribType and setting its
Value field are mandatory if the given attribute is to be instantiated. AttribType
is only applied for attributes.
{"AttribType",IDAttrT,IDAttr,[
The instantiation process is specified via validation rules that ensure that if an invalid model may result from an instantiation, it is rejected and an alternative instantiation is selected and validated. The only constraint imposed on this procedure is that at least one instantiation step (e.g. instantiating an attribute, or model element) must succeed in each step. The procedure consists of instructions that involves a selector and an action. We model these instructions as a tuple {λselector, λaction} with abstract functions. The function λselector takes an ID of an entity as its parameter and returns a possibly empty list of IDs referring to the selected entities. The function λaction takes an ID of an entity and executes an action on it. The actions λaction must invoke only functions previously defined for the ASM. Hence, the functions λselector and λaction can be defined as abstract, which allows us to treat them as black boxes. Also, the operations can be defined a priori in the bootstrap similar to attributes.
Multi-level Modeling with DMLA
In our opinion, the most effective way to demonstrate the applicability of DMLA
to multi-level meta-modeling problems is through the reproduction of some of
the reoccurring practical meta-modeling patterns reported in [
Type-Object pattern The pattern serves to dynamically add both types and instances to the model. The pattern is broadly applied in network management systems where new device types may be added to the network on-demand, in an ad-hoc fashion, and those types serve to facilitate the management of their instances.
The example below shows the gradual binding of attributes in both type and object level. While potency @1 indicates that vat must take its value in the next meta-level, @2 allows price to get its value after another meta-level jump.
The DMLA formalism defines Product as a Node instance with two Attributes
whose value types are defined both as Numbers. Then, during the first
instantiation Attribute vat is instantiated to 4.0, which is followed by the instantiation
of price to 35. Since no further instantiation is possible the GoF object is ready.
The pattern serves to dynamically add new attributes to a type which also
become part of each instance of the type. The pattern is broadly applied in network
management systems where existing device types may be extended by new
features on-demand, in an ad-hoc fashion, and those features are automatically
made manageable on all the corresponding instances.
}
]}
Level 2:
{"Product",IDProduct,IDNode,[0,inf],undef,
[
},
{"price",IDprice,IDAttribute,[
Fig. 1. The Type-Object pattern
The example below shows the addition of attribute pages to Book and its later instantiation within GoF. The DMLA formalism defines Product as a Node instance and further enables the potential addition of an arbitrary number of attributes in it. Book introduces the attribute pages and binds its type to Number. It also shuts down the possibility to append more attributes by setting the cardinality of Attribute to zero. Finally, within GoF, the pages takes its value as 349.
Similar to the type-object pattern, DMLA can correctly replicate the original
potency example. Moreover, it provides the possibility to remove attributes by
setting their cardinality to 0. This feature derives from the formal ASM definition
of DMLA thanks to the explicit representation of cardinalities there. Hence, even
though an attribute may be allowed at some position by its structural definition,
it cannot be instantiated if the related upper cardinality is later set to 0.
Level 2:
{"Product",IDProduct,IDNode,[0,inf],undef, [
{"vat", IDvat,IDAttribute,[
IDNumber,[]}]
},
{"price",IDprice,IDAttribute,[
IDNumber,[]}]
},
{"Attribs",IDAF,IDAttribute,[0,inf],undef,[]}
]}
Level 1:
{"Book",IDBook,IDProduct,[0,inf],undef,[
{"vat",IDvatC,IDvat,[
IDNumber,[]}]
}
]}
Level 0:
{"GoF",IDBookC,IDBook,[0,inf],undef, [
{"vat",IDvatC,IDvat,[
Fig. 2. Dynamic features
Dynamic auxiliary domain concepts
The pattern serves to dynamically add new entities to a type whose instances will
be correctly related to the instance of the type. Also, the new entities may have
attributes and further related entities. The pattern is broadly applied in network
management systems where new network concepts are added to device types
based on network technology evolution, and those concepts and their instances
automatically become part of the management system. Due to the page limits
only an excerpt of the DLMA representation of the full design pattern is shown
here. In essence, this design pattern is a mixture of the previous two with the
extension that the meta-model must provide a possibility to inject new Nodes
and Edges at will. Therefore, a ”root container” element, let us call it Domain,
is to be added to the original bootstrap.
Then, arbitrary domain concepts can be introduced dynamically into Domain
until the model is ready as
5
We have applied our novel multi-level meta-modeling approach, DLMA, to three
well-known design patterns for deep meta-modeling. During this exercise, our
immediate purpose was to illustrate the expressivity of DLMA by rewriting these
well-known design patterns that were already published [
References