-In the context of MULTI 2017, and as a means of fostering discussion and test the limits of the paradigm, the Bicycle Challenge [1] was proposed to tackle the issue that multilevel modelling still lacks a strong conceptual basis, consensus and focus. This paper presents one solution to that challenge, i.e. creating a multilevel hierarchy that represents the domain of bicycles as products composed of different parts and with different features, starting from very abstract concepts (components with weight and basic parts) and ending with one particular model of bicycle with brand-specific parts, which in turn is instantiated by a specific bicycle. We analyse and “fix” the requirements, discuss them, and present our solution using the MultEcore tool.
SM 1 supplementary
typed SM 2
M1
Mn-1
M0 (fixed) ontologically typed ontologically typed ontologically typed ontologically typed
Mn (instance)
The approach to deep metamodeling which we have used to
solve this challenge is implemented in the MultEcore tool [
This tool combines the best from the two worlds: fixed-level • A multilevel modelling stack that does not require
linmetamodelling with its mature tool ecosystem, and multilevel guistic metamodels, synthetic typing relations or
“flattenmodelling 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 [
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 [
The differentiating aspects of our conceptual framework are • Not specifying a value for attributes is interpreted as that summarised as follows: attribute being optional. EReference
EClass 1-1
EClass
1-1 • All the bicycles are “well-formed”. That is, the hierarchy
does not allow bicycles with missing parts like a wheel. • Unclear requirements that do not look suitable to be
modelled are excluded.
The fact that the frame number for bicycles is unique can be specified higher up in the hierarchy but instantiated at the level of one particular bicycle. Moreover, the classifications defined in the description might be extended, adding even more intermediate levels of abstraction before reaching the actual, “final” instances, which represent individual bicycles.
We have focused on the requirements and aspects which we have extracted from the challenge description (see next section).
In this section, we present the multilevel hierarchy that
addresses the challenge. We have one subsection per level,
for the sake of clarity, starting from the top-most level 1. In
level 0 we locate Ecore, which is not displayed. However,
note that we will discuss the requirements sequentially as they
appear in the challenge description [
About the visual representations, it is important to mention that the cardinality of the references is only displayed in case it is different from 0..*, which is the default one, and the most common and generic.
The first configuration level resembles the traditional
objectoriented Composite pattern [
Apart from the classes themselves, the description mentions that components may have a weight and a minimum weight, included as attributes. The minimum weight attribute has potency 1–3, indicating that it can be instantiated directly in the level immediately below, two levels below or three levels below (levels L2, L3 and L4, respectively). This attempts to fulfil the requirement that the knowledge about the domain must be located as high as possible. In case we want to add more levels to our hierarchy, we may need to update this potency to a higher number. Also, the sentence “There is a difference between the type of a component and its instances” seems to clearly point out a separation between this level and the next one.
A hierarchy in MultEcore is tree-shaped and composed of
models with upwards typing relations among them (see [
The tool also provides a hierarchy view in which all the models in a branch could be visualised as a modeling stack, with typing relations between model elements at different levels being visualised as dashed arrows.
The next level on the hierarchy contains the abstract description of a bicycle and its parts (see Fig. 3). Most of the requirements from the description are quite straightforward to model. The most relevant design decision is giving cardinality 0..1 to purchasePrice , since some instances of it do not specify it. It has a potency of 2–2 since there are still two levels to instantiate it below. Also, the fact that both wheels must have the same size has been solved by the attribute wheelSize in the class Bicycle hence forcing all wheels to be of the same size. This design decision can be replaced by the more complex (but arguably more semantically adequate) solution of duplicating the attribute in both wheels and creating a constraint that ensures that they have the same value. See subsection III-G for an example of a constraint.
One remarkable usage of potency in this level is that all the relations (except for wheels) are defined with potency 1–3 so that they do not need to be redefined in the intermediate levels while they can be directly instantiated in the lower levels. The other interesting use of our range-like potency is for both color attributes. We chose 1–4 for it since we believe it is a nice example of flexibility, so that a colour can be specified at the upper levels if that component is made with that colour, but we allow for the lower instances to redefine it, so that a particular bike can differ from its original colours.
The fact that frames have a unique serial number can be easily provided by exploiting Ecore’s ID feature.
subc Component
1-1 subc fork@1-3 BasicPart 1-1 BasicPart 1-1
RacingFrame 1-1
RacingHandle
1-1 RacingBike
1-1 RacingFork 1-1
FrontWheel RearWheel 1-1 1-1
wheels
wheels Wheel 1-1 1-1 1-1 Material
Material
This level simply instantiates some attributes previously defined, and specifies new ones like the lengths of the different tubes for the frame (see Fig. 4). The fact that some bicycles are suitable to certain environments did not look suitable for explicitly modelling, since maintaining a list of them is cumbersome. At most, we consider that a simple string attribute with the description could be added.
This level is quite simple, and just instantiates the attributes previously defined (see Fig. 5). The most relevant feature is the restriction on the material of the wheels: “A carbon frame type allows for carbon or aluminium wheel types only”. This requirement is addressed in section III-G.
The last level required by the description is a specific bicycle model, where we can see the instantiation of three attributes, weight (for both frame and bicycle) and salesPrice, defined at higher levels (see Fig. 6). Since weight is defined at level ProRacingFra...
1-1
ProRacingHa...
1-1 frame@3
ProRacingBike prhandle@1-1 1-1 ProRacingFork 1-1 prfrontwheel@1-1
PRFrontWheel PRRearWheel frontWheel@2 1-1 1-1 prrearwheel@1-1
rearWheel@2 L1 together with minWeight, it is possible to also define a cross-level constraint where we forbid an actual weight to be less than the minimum weight. Specific instances of this model will instantiate the frame serial ID which will differentiate specific bicycles from each other.
The previous level defines a particular model of a bike, but probably more than one bike of that model is available. If the modeller wishes to represent this information, along with some specific differences between this bike an the rest of the Challenger A2-XL bikes, an instance of the previous model can be specified, like the one we depict in Fig. 7.
Here, the particular colours to which the bike was painted (or re-painted) can be specified, as displayed in MyRocketFrame and MyFork.
Some of the features represented in the previous subsections could have been addressed by means of (multilevel) constraints, Rocket-A1-XL 1-1
ChallengerHa...
1-1 1-1 prhandle ChallengerFork prfork 1-1 prfrontwheel@1-1
ChallengerFro...
prfrontwheel 1-1 prrearwheel@1-1 prrearwheel
ChallengerRe...
1-1
Implication
1-1 i Atomic
1-1
Element
1-1
F material=carbon *Frame right
Not
1-1 n Atomic
Element
W material=steel 1-1 has 1-1 *Wheel
multilevel constraint using a supplementary
using a language like the one we describe in [
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, just below the generic component model at level L1.
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, e.g. the ones on purchasePrice, serial, etc., would be updated so that these attributes could be instantiated at L3. Similarly, 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 at level L3 as an instance of L2, would be in a sibling branch of the metamodel Racing Bicycle in the model hierarchy.
The Racing Bicycle specialised DSL or software could further be refined and specialised to define a Pro Racing Bicycle 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 that the upper bound is *, we could relax on this restriction, if this was desirable. Hence, although the refinement process has given rise to more specialised DSLs for special kinds of bicycle, e.g. pro racing bicycles, we could still choose to create a DSL which enables usage of types from upper levels than the Pro Racing Bicycle. That is, in our alternative solution with relaxed potencies, a specific ordinary bicycle could be specified at level L3, L4, L5 or L6 depending on which created DSL one would like to use.
In http://prosjekt.hib.no/ict/multecore/ we show how
Sirius [
In a few cases in this solution, we could have used
generalisation (i.e. inheritance) instead of specialisation (i.e.
typing). For example, the specialisation of the Racing Bicycle
into Pro Racing Bicycle could be replaced with inheritance
among the elements of both. However, we believe that the
usage of typing in this scenario allows for a more flexible
specification and separation of abstraction levels. As we argue
in [
In our solution, it is not required to have associations between different levels. In the case of cross-level constraints, we have used multilevel constraints as shown in Fig. 8. These constraints would be parsed and transformed to validators by customized code-generators so that the created DSLs can enforce the restrictions given by them.
We have identified three of the requirements given by the
challenge description [
The main limitation of the approach lies in the fact that we cannot automatically propagate changes done to higher level models to lower level models. That is, if we change potencies or add/delete model elements, the lower level models which are depending on the potency or these elements might become invalid models. Addressing this challenge is part of a bigger development step in MultEcore which focuses on co-evolution and model repair.
In this paper, we have presented a solution to the Bicycle Challenge proposed at MULTI 2017 workshop. Our multilevel modeling hierarchy ended up having up to 7 abstraction levels where specific ordinary bicycles could be defined at the level L3, and with some potency relaxation also on L4, L5 and L6. However, specific pro racing bicycles could only be defined at level L5 since these are instances of a more specific or refined metamodel at L4. Our solution is based on the MultEcore tool and follows a conceptual framework which enables EMF with the potential of becoming a multilevel modelling framework. This facilitates usage of the rich ecosystem of EMF such as code generation and DSL editor creation.