Multilevel Modelling with MultEcore A Contribution to the MULTI 2017 Challenge Fernando Macías∗† , Adrian Rutle∗ , Volker Stolz∗† ∗ Deparment of Computing, Mathematics and Physics Western Norway University of Applied Sciences P.O. Box 7030, 5020 Bergen, Norway Email: {fmac,aru,vsto}@hvl.no † Department of Informatics University of Oslo P.O. Box 1072 Blindern, 0316 Oslo, Norway Abstract—In the context of MULTI 2017, and as a means M0 of fostering discussion and test the limits of the paradigm, (fixed) the Bicycle Challenge [1] was proposed to tackle the issue ontologically typed that multilevel modelling still lacks a strong conceptual basis, SM 1 consensus and focus. This paper presents one solution to that M1 challenge, i.e. creating a multilevel hierarchy that represents ontologically typed the domain of bicycles as products composed of different parts supplementary ... and with different features, starting from very abstract concepts typed ontologically typed (components with weight and basic parts) and ending with one particular model of bicycle with brand-specific parts, which in Mn-1 SM 2 turn is instantiated by a specific bicycle. We analyse and “fix” ontologically typed the requirements, discuss them, and present our solution using the MultEcore tool. Mn (instance) I. I NTRODUCTION Figure 1: Overview of the multilevel conceptual framework The approach to deep metamodeling which we have used to solve this challenge is implemented in the MultEcore tool [2]. This tool combines the best from the two worlds: fixed-level • A multilevel modelling stack that does not require lin- metamodelling with its mature tool ecosystem, and multilevel guistic metamodels, synthetic typing relations or “flatten- modelling with an unlimited number of abstraction levels, ing” of the ontological stack. potencies and multiple typing. Using our approach, model • A realization of linguistic extension that differs from designers can seamlessly create a multilevel version of their other approaches and allows for several, independent hierarchies while still keeping all the advantages they get from linguistic hierarchies (called supplementary hierarchies in fixed-level ones. MultEcore facilitates multilevel modelling our approach), orthogonal to the ontological stack. without leaving the EMF (Eclipse Modeling Framework [3]) • Looser linguistic typing: while every element in every world, and hence allowing reuse of existing EMF tools and model has an ontological type, it does not require a plugins. The tool (and the solution to this challenge) is available linguistic type for each plugged linguistic metamodel. for download from http://prosjekt.hib.no/ict/multecore/. • An extension of the two-level cascading approach that A multilevel model hierarchy in MultEcore is defined as aides the implementation of the framework as an extension an ontological hierarchy of models with a fixed, common and of EMF which preserves full compatibility with its model generic topmost metamodel. In other words, the ontological representations and tools, i.e. we make use of EMF native hierarchy does not require a linguistic metamodel in order to APIs and formats, and keep the overload of the models be consistent, as opposed to the clabject-based proposals such as transparent as possible. as [4], [5]. Therefore, this hierarchy is similar to MOF, but does In the following sections we will show how we have designed not restrict the number of new levels that the user can create. the bicycle model in the MultEcore tool, and argue for our An overview of the conceptual framework behind MultEcore design decisions. is displayed in Fig. 1. Note that since the ontological stack can grow downwards an arbitrary number of levels, these are II. C ASE A NALYSIS indexed increasingly from the top. A detailed evaluation of our The considerations we took to complete the case description design choices and formalisations can be found in [2], [6]. are: The differentiating aspects of our conceptual framework are • Not specifying a value for attributes is interpreted as that summarised as follows: attribute being optional. EClass 1-1 A hierarchy in MultEcore is tree-shaped and composed of models with upwards typing relations among them (see [6]). subc@1-1 We have chosen the following concrete syntax in our tool. The type of a node is indicated as a blue ellipse, e.g. EClass is EReference the type of Composite. The type of an arrow is written near EClass 1-1 EClass 1-1 the arrow in italic font type, e.g. EReference. The names of the nodes are used as labels in the class-like rectangles; italics font means the node is abstract. The potency of each node is written in a red rectangle on its top right corner. For arrows, it is written after the arrow name separated by the @ character. Figure 2: Level 1: Configuration For attributes, the potency is written just before the attribute name. The potencies in MultEcore have a range, having the • All the bicycles are “well-formed”. That is, the hierarchy default “1–1”, which means that they only can be instantiated does not allow bicycles with missing parts like a wheel. directly at the next level below. This means that the tool does • Unclear requirements that do not look suitable to be not restrict whether an instance of a node with potency 1–1 modelled are excluded. is reinstantiated or not. With the same reasoning, a node with potency 2–4 would mean that we can instantiate it directly at The fact that the frame number for bicycles is unique can 2, 3 and 4 levels below, or a combination of those, or we may be specified higher up in the hierarchy but instantiated at the not do so since instantiation is optional. This realisation also level of one particular bicycle. Moreover, the classifications keeps the potency of the instances independent of the potency defined in the description might be extended, adding even of their types, and it could be seamlessly combined with the more intermediate levels of abstraction before reaching the more traditional understanding of potency as depth (just by actual, “final” instances, which represent individual bicycles. adding a third value), i.e. how many times instances, instances We have focused on the requirements and aspects which we of instances, etc. can be created. have extracted from the challenge description (see next section). The tool also provides a hierarchy view in which all the III. M ODEL D ESIGN models in a branch could be visualised as a modeling stack, In this section, we present the multilevel hierarchy that with typing relations between model elements at different levels addresses the challenge. We have one subsection per level, being visualised as dashed arrows. for the sake of clarity, starting from the top-most level 1. In B. Level 2 - Bicycle level 0 we locate Ecore, which is not displayed. However, note that we will discuss the requirements sequentially as they The next level on the hierarchy contains the abstract appear in the challenge description [1], which causes changes description of a bicycle and its parts (see Fig. 3). Most of the in previously defined levels. These cases will be pointed out requirements from the description are quite straightforward to to avoid confusion. model. The most relevant design decision is giving cardinality About the visual representations, it is important to mention 0..1 to purchasePrice , since some instances of it do not specify that the cardinality of the references is only displayed in case it. It has a potency of 2–2 since there are still two levels to it is different from 0..*, which is the default one, and the most instantiate it below. Also, the fact that both wheels must have common and generic. the same size has been solved by the attribute wheelSize in the class Bicycle hence forcing all wheels to be of the same size. A. Level 1 - Configuration This design decision can be replaced by the more complex (but The first configuration level resembles the traditional object- arguably more semantically adequate) solution of duplicating oriented Composite pattern [7]. Hence, this model exploits the attribute in both wheels and creating a constraint that inheritance to achieve the pattern, as displayed in Fig. 2. ensures that they have the same value. See subsection III-G Apart from the classes themselves, the description mentions for an example of a constraint. that components may have a weight and a minimum weight, One remarkable usage of potency in this level is that all the included as attributes. The minimum weight attribute has relations (except for wheels) are defined with potency 1–3 so potency 1–3, indicating that it can be instantiated directly in the that they do not need to be redefined in the intermediate levels level immediately below, two levels below or three levels below while they can be directly instantiated in the lower levels. The (levels L2, L3 and L4, respectively). This attempts to fulfil other interesting use of our range-like potency is for both color the requirement that the knowledge about the domain must attributes. We chose 1–4 for it since we believe it is a nice be located as high as possible. In case we want to add more example of flexibility, so that a colour can be specified at the levels to our hierarchy, we may need to update this potency upper levels if that component is made with that colour, but we to a higher number. Also, the sentence “There is a difference allow for the lower instances to redefine it, so that a particular between the type of a component and its instances” seems to bike can differ from its original colours. clearly point out a separation between this level and the next The fact that frames have a unique serial number can be one. easily provided by exploiting Ecore’s ID feature. RacingFrame 1-1 RacingHandle 1-1 BasicPart 1-1 BasicPart 1-1 handle@1-3 subc subc frame@1-3 RacingBike 1-1 Component 1-1 RacingFork 1-1 FrontWheel 1-1 subc fork@1-3 wheels@1-1 subc BasicPart 1-1 BasicPart 1-1 RearWheel 1-1 Figure 3: Level 2: Bicycle Figure 5: Level 4: Pro Racing Bicycle Frame 1-1 Handle 1-1 ProRacingFra... 1-1 ProRacingHa... 1-1 Material prframe@1-1 frame@3 prhandle@1-1 handle@3 Wheel 1-1 ProRacingBike 1-1 Bicycle 1-1 Material frontWheel@1-2 wheels fork@3 prfork@1-1 frontWheel@2 prfrontwheel@1-1 ProRacingFork 1-1 rearWheel@1-2 wheels PRFrontWheel 1-1 Fork 1-1 Wheel 1-1 PRRearWheel 1-1 Material prrearwheel@1-1 rearWheel@2 Figure 4: Level 3: Racing Bicycle Figure 6: Level 5: Challenger A2-XL C. Level 3 - Racing Bicycle This level simply instantiates some attributes previously L1 together with minWeight, it is possible to also define a defined, and specifies new ones like the lengths of the different cross-level constraint where we forbid an actual weight to be tubes for the frame (see Fig. 4). The fact that some bicycles less than the minimum weight. Specific instances of this model are suitable to certain environments did not look suitable will instantiate the frame serial ID which will differentiate for explicitly modelling, since maintaining a list of them is specific bicycles from each other. cumbersome. At most, we consider that a simple string attribute F. Level 6 - My Challenger with the description could be added. The previous level defines a particular model of a bike, but D. Level 4 - Pro Racing Bicycle probably more than one bike of that model is available. If This level is quite simple, and just instantiates the attributes the modeller wishes to represent this information, along with previously defined (see Fig. 5). The most relevant feature is some specific differences between this bike an the rest of the the restriction on the material of the wheels: “A carbon frame Challenger A2-XL bikes, an instance of the previous model type allows for carbon or aluminium wheel types only”. This can be specified, like the one we depict in Fig. 7. requirement is addressed in section III-G. Here, the particular colours to which the bike was painted (or re-painted) can be specified, as displayed in MyRocketFrame E. Level 5 - Challenger A2-XL and MyFork. The last level required by the description is a specific bicycle model, where we can see the instantiation of three attributes, G. Constraints weight (for both frame and bicycle) and salesPrice, defined Some of the features represented in the previous subsections at higher levels (see Fig. 6). Since weight is defined at level could have been addressed by means of (multilevel) constraints, Rocket-A1-XL 1-1 ChallengerHa... 1-1 IV. E VALUATION The proposed multilevel modeling hierarchy ended up having up to 7 abstraction levels L0, . . . , L6, where the L0 level is the Ecore metamodel. The knowledge domain is at level L2, prhandle@1-1 prframe@1-1 prframe prhandle just below the generic component model at level L1. Challenger-A... 1-1 The model at L2 can be used as a DSL, or as a starting point for a software system which could be used by bicycle retailers. This would imply that some of the potencies in L2, prfork@1-1 e.g. the ones on purchasePrice, serial, etc., would be updated prfork prfrontwheel@1-1 prfrontwheel ChallengerFork 1-1 so that these attributes could be instantiated at L3. Similarly, ChallengerFro... 1-1 the model at level L3 can be used as a DSL, or as a starting point for a software system which could be used by racing bicycle retailers. An ordinary bicycle model, which is specified ChallengerRe... 1-1 at level L3 as an instance of L2, would be in a sibling branch prrearwheel@1-1 of the metamodel Racing Bicycle in the model hierarchy. prrearwheel The Racing Bicycle specialised DSL or software could further be refined and specialised to define a Pro Racing Bicycle Figure 7: Level 6: My Challenger metamodel. This specialised DSL would disallow racing bicycle and pro racing bicycle retailers from defining ordinary bicycles. However, by changing the potency of the nodes at level L2 so property Implication 1-1 that the upper bound is *, we could relax on this restriction, left right i if this was desirable. Hence, although the refinement process left@1-1 right@1-1 has given rise to more specialised DSLs for special kinds of Not 1-1 bicycle, e.g. pro racing bicycles, we could still choose to create Atomic 1-1 a DSL which enables usage of types from upper levels than CarbonFrame n the Pro Racing Bicycle. That is, in our alternative solution with relaxed potencies, a specific ordinary bicycle could be has@1-1 has f@1-1 formula specified at level L3, L4, L5 or L6 depending on which created Atomic 1-1 DSL one would like to use. Element 1-1 F SteelWheel In http://prosjekt.hib.no/ict/multecore/ we show how material=carbon *Frame Sirius [8] could be used to create editors for a bicycle DSL has@1-1 has given by the metamodel at level L2. Indeed, editors could Element 1-1 be created for any of the models in the hierarchy. This also W demonstrates the strength of our approach in not leaving the *Wheel material=steel EMF world which makes it easy to create editors and other artefacts. Moreover, from the .ecore version of the models it is possible to use EMF’s native code generation facilities Figure 8: A multilevel constraint using a supplementary and generate Java code, or write other templates to generate hierarchy custom code. In a few cases in this solution, we could have used generalisation (i.e. inheritance) instead of specialisation (i.e. using a language like the one we describe in [6]. We chose, typing). For example, the specialisation of the Racing Bicycle however, to create a hierarchy as simple and self-contained into Pro Racing Bicycle could be replaced with inheritance as possible. Hence, the only constraint we create is specified among the elements of both. However, we believe that the as an implication, in the following manner: A frame with usage of typing in this scenario allows for a more flexible the attribute material=carbon implies that either the front specification and separation of abstraction levels. As we argue and rear wheels have also material=carbon or that they have in [6], our framework leaves this possibility open to the user. material=aluminium. This constraint uses a supplementary In our solution, it is not required to have associations between hierarchy, as depicted in Fig. 1, in order to define double-typed different levels. In the case of cross-level constraints, we have elements that relate the atomic propositions of the language of used multilevel constraints as shown in Fig. 8. These constraints boolean logic to actual elements in the ontological hierarchy would be parsed and transformed to validators by customized (called application hierarchy in our approach). Fig. 8 displays code-generators so that the created DSLs can enforce the the constraint, using the same notation as the previous diagrams, restrictions given by them. but with two different colours to distinguish between the We have identified three of the requirements given by the application type (blue) and the supplementary type (green). challenge description [1], namely the domain knowledge is specified at the highest possible level, the models could be the potential of becoming a multilevel modelling framework. used as a foundation for a software system, and possibility to This facilitates usage of the rich ecosystem of EMF such as define cross-level constraints. code generation and DSL editor creation. The main limitation of the approach lies in the fact that we cannot automatically propagate changes done to higher level R EFERENCES models to lower level models. That is, if we change potencies or add/delete model elements, the lower level models which [1] MULTI2017. (2017, Jul.) Bicycle Challenge description. [Online]. Avail- are depending on the potency or these elements might become able: https://www.wi-inf.uni-duisburg-essen.de/MULTI2017/#challenge invalid models. Addressing this challenge is part of a bigger [2] F. Macías, A. Rutle, and V. Stolz, “MultEcore: Combining the best of fixed- level and multilevel metamodelling,” in MULTI, ser. CEUR Workshop development step in MultEcore which focuses on co-evolution Proceedings, vol. 1722, 2016. and model repair. [3] Eclipse Modeling Framework, Web site. [Online]. Available: http: //www.eclipse.org/modeling/emf V. C ONCLUSIONS [4] C. Atkinson and R. Gerbig, “Flexible deep modeling with Melanee,” in Modellierung 2016, ser. LNI, S. Betz and U. Reimer, Eds., vol. 255. In this paper, we have presented a solution to the Bicycle Bonn: Gesellschaft für Informatik, 2016, pp. 117–122. Challenge proposed at MULTI 2017 workshop. Our multilevel [5] J. de Lara and E. Guerra, “Deep meta-modelling with Metadepth,” in modeling hierarchy ended up having up to 7 abstraction levels Objects, Models, Components, Patterns, ser. LNCS, vol. 6141. Springer, Jul. 2010, pp. 1–20. where specific ordinary bicycles could be defined at the level [6] F. Macías, A. Rutle, V. Stolz, R. Rodriguez-Echeverria, and U. Wolter, L3, and with some potency relaxation also on L4, L5 and L6. “Formalisation of flexible multilevel modelling,” Submitted, available at However, specific pro racing bicycles could only be defined at http:// prosjekt.hib.no/ ict/ multecore/ , 2016. level L5 since these are instances of a more specific or refined [7] E. Gamma et al., Design Patterns: elements of reusable object-oriented software. Addison-Wesley, 1994. metamodel at L4. Our solution is based on the MultEcore tool [8] The Eclipse Project, “Eclipse Sirius,” Dec. 2016. [Online]. Available: and follows a conceptual framework which enables EMF with http://www.eclipse.org/sirius/