=Paper=
{{Paper
|id=Vol-2245/multi_paper_3
|storemode=property
|title=Multi-Level Modeling with MELANEE
|pdfUrl=https://ceur-ws.org/Vol-2245/multi_paper_3.pdf
|volume=Vol-2245
|authors=Arne Lange,Colin Atkinson
|dblpUrl=https://dblp.org/rec/conf/models/LangeA18
}}
==Multi-Level Modeling with MELANEE==
https://ceur-ws.org/Vol-2245/multi_paper_3.pdf
Multi-level modeling with MELANEE
A contribution to the MULTI 2018 Challenge
Arne Lange, Colin Atkinson
University of Mannheim
Software Engineering Group
{atkinson, lange}@informatik.uni-mannheim.de
Abstract. This paper presents a solution to the MULTI 2018 Bicycle Challenge developed
using the MELANEE deep modeling tool. The structure of the paper therefore follows the
guidelines laid out in the Challenge description. After first outlining the case study and
documenting which aspects are supported in the MELANEE solution, the paper presents a
detailed description of the developed deep model. This is followed by a discussion of the
strengths and weaknesses of the approach and a discussion of its benefits over traditional
two-level modeling. The presented model covers all mandatory and optional aspects of the
Challenge case study.
1 Introduction
The MULTI 2018 Bicycle Challenge was established by the organizers of MULTI 2018 as a vehicle
for evaluating and comparing multi-level modeling approaches. This paper presents a solution to
the Challenge developed using the MELANEE deep modeling environment [14]. This supports a style
of multi-level modeling often referred to as deep modeling [6] since it is based on the use of (a) the
deep instantiation mechanism (using potency) to represent ontological classification relationships
[6] and (b) the tenet of strict modeling to define the different layers within a model [7].
For any modeling approach there are no hard and fast rules about what constitutes a good model
as opposed to a bad model. In other words, models can be optimized for different purposes based
on multiple criteria (e.g. minimality, readability, maintainability). The deep model presented in this
paper, which satisfies all mandatory and optional requirements laid out in the Challenge, has been
optimized to showcase MELANEE’s features and thus does not claim to be the best model for a specific
real-world modeling use case. Once the idiosyncrasies of MELANEE’s multi-level modeling approach
have been outlined in section 2, a complete overview of our solution to the Bicycle Challenge is
presented in section 3. Section 4 then discusses the strengths and weakness of this deep model,
before section 5 wraps up with some conclusions.
2 Multi-Level Modeling Approach
A full description of the case study at the heart of the MULTI 2018 Bicycle Challenge is available
as an addendum to the MULTI 2018 call for papers [1] and is not replicated here. In this section
we outline the distinguishing features of our solution built using the MELANEE multi-level modeling
environment. As mentioned above, MELANEE supports a flavor of multi-level modeling often referred
to as deep modeling. This means that ontological classification relationships are governed by potency
and the modeling levels are defined according to the principles of strict modeling. In our approach,
therefore, we refer to the complete multi-level model encompassing all domain information as a
“deep model” and each individual ontological level within this deep model as a “level” or a “model”.
In MELANEE, deep models are represented using two (sub) languages - the so called Level-agnostic
Modeling Language (LML) and a variant of OCL enhanced to be “aware of”, and exploit, deepness.
The LML contains three core constructs – “Entities”, “Connections” and “Generalizations”. Entities
correspond to classes and/or objects in classic UML-style structural modeling and are depicted
in a similar way, while connections correspond to association classes in the UML (although they
are represented in a different notation). Connections can be navigable or non-navigable and can
capture two forms of containment, composition and aggregation, using similar modifiers to the
UML. Entities and Connections are Clabjects which have a potency indicating over how many
levels they can be instantiated. The generalization relationship is used to represent inheritance
using the unfilled-triangle notion of the UML to designate super-types [11].
MELANEE is a domain specific language workbench that supports a variety of formats and visu-
alizations. It can be used to model in graphical, text-based, table-based and/or form-based formats
to provide stakeholders with diverse viewpoints on a deep model and multiple ways to edit it. These
visualizations can also be context aware, e.g. the background color of an entity can be dynamically
determined via a deep OCL expression [11].
Our deep model solution to the Bicycle Challenge contains four ontological levels. Like the UML
infrastructure, these are typically depicted in a vertical hierarchy with the most abstract (i.e. meta)
level at the top and the most concrete (i.e. instance) level at the bottom. However, by convention
MELANEE’s levels are numbered in the reverse order to the UML’s with the most abstract given the
number 0, the second most abstract the number 1 and so on. MELANEE also allows arbitrary names
to be given to levels to better characterize their content.
3 Model Design
The presented MELANEE model fully covers all mandatory and optional requirements defined in
the Challenge description. However, two of the mandatory elements are renamed in our solution
– the notion of Configuration is covered by Product (i.e. instances of Product are Configu-
rations) and the notion of Categories is covered by BicycleConfiguration (i.e. subclasses of
BicycleConfiguration are specific Categories).
3.1 Level-Spanning Domain Content
To understand the ontological levels themselves, it is necessary to understand the model information
that spans them – so called “pan-level” information.
Linguistic (Meta) Models. The most fundamental pan-level models are the linguistic (meta)
models of the LML and the deep OCL dialect used to define constraints. These are metamodels in
the sense that they define languages, but are not strictly “meta” to anything since the content of the
ontological levels exists at the linguistic level immediately below them. The LML linguistic model,
which contains about a dozen classes, defines the core concepts of deep modeling mentioned in the
previous section (e.g. clabjects, generalizations, attributes etc.) and has been designed to be as
simple and minimal as possible whilst providing a UML-like modeling experience for modelers. The
deep OCL variant supported by MELANEE is based on the OMG’s OCL version 2.4. Its linguistic
(meta)model has been enhanced to make it “aware” of (i.e. support) constraints over multiple
ontological levels. In particular, its allows constraints to be applied to explicit ranges of ontological
levels and to refer to linguistic as well as ontological attributes.
Pan-Level Enumeration Types. Most domains have domain specific data (i.e. value-only) types
that are used at multiple ontological levels. In MELANEE these are defined within a deep model, but
outside any specific ontological level so that in effect they span (i.e. are usable in) any level. For the
Challenge two enumerations are defined – Material and CyclistSize. The Material enumeration,
which is the type for the material attribute of racing frames, has three values CARBON, ALUMINUM
and STEEL. The CyclistSize enumeration, which is the type for the cyclistSize attribute in the
Purpose clabject, also has three values TALLCYCLIST, MEDIUMCYCLIST and SMALLCYCLIST.
Pan-Level Constraints. A powerful feature of the deep OCL dialect supported by MELANEE is
that it allows level spanning constraints to be defined that control the way clabjects can be used
within specific ontological level and/or in the whole deep model. This feature essentially supports
the notion of reflexive constraints [10], since level spanning constraints can control the fundamental
way the LML is used as exemplified by constraint PAN-1 below.
context DeepModel
inv PAN−1: C l a b j e c t −> f o r A l l ( s e l e c t ( c | c .# g e t F e a t u r e ()# −> s e l e c t ( f | f .# g e t D u r a b i l i t y ()#
> 0 ) ) −> s i z e ( ) = s e l f . g e t D i r e c t I n s t a n c e s ( ) −> s e l e c t ( c | c .# g e t F e a t u r e ()#) −> s i z e ( ) )
Although strict modeling requires the ontological type of a clabject to reside at the level im-
mediately above it, it does not specifically require that all clabjects have an ontological type.
Because MELANEE’s orthogonal classification architecture gives every clabject a linguistic type (i.e.
Clabject) as well as (possibly) an ontological type, it is perfectly possible to define ontologically-
unclassified clabjects in a model (i.e. clabjects without an explicit, direct ontological type). This is
important in practice since it allows the top (i.e. most abstract) ontological level to be populated
with clabjects that are not ontologically classified, and thus avoids the endless repetition of levels
that would be needed if every clabject had to be ontologically typed. It can also be useful to define
ontologically unclassified clabjects at lower levels, giving rise to a specific style of deep modeling.
The purpose of constraint PAN-1 is to ensure that every clabject that has an ontological type has
all, and only, the features (i.e. attributes and methods) required by the type. More specifically, it
states that if a clabject has an ontological type, it must possess all features defined by that type with
a durability greater than 0 and no more. Thus, only ontologically-untyped clabjects can introduce
new features. The ‘#’ symbol in the constraint is used to designate the linguistic dimension and
invoke linguistic methods.
3.2 Product Level - O0
Product3 Part0
Invoice3
price3:Real = 2
price3:Real date3:String = 2
Customer0
averageActualSalesPrice2:Real BasicPart3
date3:String
revenue2:Real
readOnly3:Boolean bestseller2:Real Component3
averageRegularSalesPrice2:Real
height3:Real = 2
HumanCustomer3 size3:Real = 2
OrganisationCustomer3 usn3:String = 3
Organisation2 weight3:Real = 2
Manages color3: String = 3
Person0 CategoryManager1
Fig. 1. Product Model (O0 )
Figure 1 shows the top, most abstract, ontological level of the deep model which captures the
domain of selling products to customers. A Product is defined as a composite of Components
and BasicParts using the composite pattern. Products can be certified by an Organization. An
important feature of the deep model is that this top level is completely independent of the bicycle
shop domain and thus can be instantiated for other domains.
The LML uses clabjects called connections to represent associations between entities, but they
are more like UML association classes than plain associations since they can have attributes, super
types and participate in connections themselves. Connections can be depicted in two ways in MELA-
NEE models depending on the amount of information the modeler wishes to display. The connection
between Product and Customer, called Invoice, is depicted in expanded form in Figure 1 to show
its two attributes, while the connection between CategoryManager and Product, called Manages,
is shown in collapsed form because it has no attributes.
The attributes of Invoice document the essential properties of sales transactions. The other
kind of relationship appearing in Figure 1 is specialization which is depicted using the UML unfilled-
triangle notation. The figure highlights the important point that the potencies of sub-clabjects need
not be the same as those of their super-clabjects because potency is based on direct classification
relationships (as opposed to indirect classification relationships arising from inheritance hierarchies).
The attributes averageActualSalesPrice, averageRegularSalesPrice, revenue and best-
seller of the clabject Product are responsible for storing the optional sales information described
in the section 2.2 of the Challenge description. Their values are defined by the following four de-
rive constraints which are applied at specifically defined levels. Constraint O0 1 derives the value of
the averageActualSalesPrice for every instance of Product at O1 and O2 . The context of the
derivation is iterated over every instance of Product so that the value is derived for each individual
instance. It therefore covers the first two derived properties of section 2.2 of the Challenge. The con-
straint O0 2 defines the value of the averageRegularSalesPrice attribute in a similar manner as
O0 1. Constraint O0 3 defines the value of the revenue attribute while O0 4 determines the top-seller
of each category and the top selling category.
context Product : : a v e r a g e A c t u a l S a l e s P r i c e : Real
d e r i v e O 0 1 : s e l f . a l l I n s t a n c e s ( ) −> s e l e c t ( c | c .# g e t P o t e n c y ()# = 0 ) −>
s e l e c t ( c | c . I n v o i c e . d a t e . s u b s t r i n g ( 7 , 1 0 ) = " 2 0 1 7 " ) −> c o l l e c t N e s t e d ( I n v o i c e . p r i c e )
−> sum ( ) / s e l f . a l l I n s t a n c e s ( ) −> s e l e c t ( c | c .# g e t P o t e n c y ()# = 0 ) −> s i z e ( )
context Product : : a v e r a g e R e g u l a r S a l e s P r i c e : Real
d e r i v e O 0 2 : s e l f . a l l I n s t a n c e s ( ) −> s e l e c t ( c | c .# g e t P o t e n c y ()# = 1 )
−> s e l e c t ( d a t e . s u b s t r i n g ( 7 , 1 0 ) = " 2 0 1 7 " ) −> c o l l e c t ( p r i c e ) −> sum ( ) /
s e l f . a l l I n s t a n c e s ( ) −> s e l e c t ( c | c .# g e t P o t e n c y ()# = 0 ) −> s i z e ( )
context Product : : r e v e n u e : Real
d e r i v e O 0 3 : s e l f . a l l I n s t a n c e s ( ) −> s e l e c t ( c | c .# g e t P o t e n c y ()# = 0 ) −>
s e l e c t ( c | c . I n v o i c e . d a t e . s u b s t r i n g ( 7 , 1 0 ) = " 2 0 1 7 " ) −> c o l l e c t N e s t e d ( I n v o i c e . p r i c e )−>sum ( )
context Product : : b e s t s e l l e r : Boolean
d e r i v e O 0 4 : l e t t o p S e l l e r : Boolean = f a l s e i n
i f C l a b j e c t −> s e l e c t ( c | c . isDeepKindOf ( B i c y c l e C o n f i g u r a t i o n ) = t r u e ) −>
s e l e c t ( d a t e . s u b s t r i n g ( 7 , 1 0 ) = " 2 0 1 7 " ) −> s o r t e d B y ( r e v e n u e ) −> l a s t ( ) = s e l f
then t o p S e l l e r = t r u e e l s e t o p S e l l e r = f a l s e e n d i f
3.3 Bicycle Categories Level - O1
Figure 2 shows the second level of the deep model, O1 where the ontological instances of clabjects in
O0 reside. This level describes the structures of the different kinds of bicycle product categories as
well as their different roles and stakeholders. The tenet of strictness requires all ontological instances
of O0 to reside at O1 , but does not require all elements in O1 to have a direct ontological type.
For example, the clabject ProfessionaleRacingFrame has no ontological type. This is because it
needs more attributes than a “normal” Component, so it inherits the normal component attributes
from Frame (an instance of Component) and adds its own attributes relevant to professional racing
frames. There are two connections needed between BicycleConfiguration and Wheel, one for the
front wheel and one for the rear wheel. Every instance of Product is connected to a Purpose.
Note that all the connections are depicted in collapsed form in Figure 2. Although this means their
attributes cannot be seen, it is still possible to display their names in the style of UML associations.
UML-style multiplicity constraints are used to indicate that a BicycleConfiguration must
have exactly one Frame and Fork. In addition, seven deep-OCL constraints are needed to fulfill the
mandatory requirements of the Challenge. Constraints O1 1 and O1 2 are defined on BicycleCon-
CarbonFrame2:Component ProfessionalRaceFrame2 CarbonWheel2:Component AluminumWheel2:Component
height2:Real = 1 material2:Material height2:Real = 1 height2:Real = 1
size2:Real = 1 topTubeLenght2:Integer size2:Real = 1 size2:Real = 1
usn2:String = 2 downTubeLenght2:Integer usn2:String = 2 usn2:String = 2
weight2:Real = 1 seatTubeLength2:Integer weight2:Real = 1 weight2:Real = 1
colour2:String= 2 colour2:String= 2 colour2:String= 2
Wheel2:Component SuspensionFork2
Frame2:Component RearSuspension2:BasicPart
height2:Real = 1 RacingFork2
height2:Real = 1
frontWheel
size2:Real = 1 size2:Real = 1
BicycleConfiguration2:Product Fork2:Component
usn2:String = 2 usn2:String = 2
weight2:Real = 1
rearWheel weight2:Real = 1 height2:Real = 1
price2:Real = 1
colour2:String= 2 colour2:String= 2 size2:Real = 1
date2:String = 1
1 1
averageActualSalesPrice1:Real = 3699.5 usn2:String = 2
revenue1:Real = 93030 weight2:Real = 1
MudMount2:BasicPart
MountainBikingPurpose1 1 colour2:String= 2
bestseller1:Boolean = false
1
cyclistSize:CyclistSize averageRegularSalesPrice0:Real = 2499.66 Invoice
HumanCustomer2:HumanCustomer
Invoice
OrganisationCustomer2:OrganisationCustomer
MountainBikeConfiguration2:Product
CityBikeConfiguration2:Product PeterParker0:CategoryManager
price2:Real = 1
date2:String = 1
price2:Real = 1
averageActualSalesPrice1:Real = RacingBikeConfiguration2:Product
date2:String = 1
revenue1:Real = 11098.5
averageActualSalesPrice1:Real = 3699.5
bestseller1:Boolean = false price2:Real = 1
revenue1:Real = 11098.5
averageRegularSalesPrice0:Real = date2:String = 1
bestseller1:Boolean = false
averageActualSalesPrice1:Real = 2321.00
averageRegularSalesPrice0:Real = 2500.00
revenue1:Real = 78232.00
bestseller1:Boolean = false
averageRegularSalesPrice0:Real = 2834.00
ElectricPart2:Component
height2:Real = 1 CityBikingPurpose1 BikeRacingPurpose1
size2:Real = 1 UCI1:Organisation
usn2:String = 2 cyclistSize1:CyclistSize cyclistSize1:CyclistSize
weight2:Real = 1
ProfessionalRacingBikeConfiguration2:Product
colour2:String= 1 Battery2:Component Motor2:Component
price2:Real = 1
height2:Real = 1 height2:Real = 1 date2:String = 1
size2:Real = 1 size2:Real = 1 averageActualSalesPrice1:Real = 2321.00
EnforcedBrakes2:BasicPart usn2:String = 2 usn2:String = 2 revenue1:Real = 78232.00
weight2:Real = 1 weight2:Real = 1 bestseller1:Boolean = true
colour2:String= 2 colour2:String= 2 averageRegularSalesPrice0:Real = 2834.00
Fig. 2. Bicylce Categories Model (O1 )
figuration. Constraint O1 1 ensures that the front wheel and the rear wheel have the same size. If
a bike has a carbon frame it needs to have carbon or aluminum wheels as well. This is expressed in
constraint O1 2. Constraints O1 3 and O1 4 are defined for RacingBikeConfiguration. Constraint
O1 3 states that every fork to which a RacingBikeConfiguration is connected must be an instance
(direct or indirect) of RacingFork and every frame must be an instance (direct or indirect) of Pro-
fessionalRacingFrame while constraint O1 4 ensures no instance of RacingBikeConfiguration
has a MudMount connected to it. Constraints O1 5 and O1 6 are defined for ProfessionalRacing-
BikeConfiguration and ensure the weight attribute is above the required minimum weight of that
bike category and that the bike is certified by an organization. The last constraint, O1 7, ensures
that no CityBikeConfiguration is connected to a RearSuspension. Every invariant constraint
displayed here is applied to all instances of each context at the O2 and O3 level.
context B i c y c l e C o n f i g u r a t i o n
inv O 1 1−w h e e l S i z e : s e l f . f r o n t W h e e l . s i z e = s e l f . r e a r W h e e l . s i z e
context B i c y c l e C o n f i g u r a t i o n
inv O 1 2−carbonFrame : s e l f . f ra m e . isDeepKindOf ( CarbonFrame ) i mp l i es
( s e l f . f r o n t W h e e l . isDeepKindOf ( CarbonWheel ) or
s e l f . f r o n t W h e e l . isDeepKindOf ( AluminumWheel ) )
context R a c i n g B i k e C o n f i g u r a t i o n
inv O 1 3−r a c i n g F o r k F r a m e : s e l f . f o r k . isDeepKindOf ( RacingFork ) and
s e l f . f r a m e . isDeepKindOf ( P r o f e s s i o n a l R a c i n g F r a m e )
context R a c i n g B i k e C o n f i g u r a t i o n
inv O 1 4−mudMount : not ( s e l f . f o r k . isDeepKindOf ( S u p e n s i o n F o r k ) ) and
s e l f . mudMount −> s i z e ( ) = 0
context P r o f e s s i o n a l R a c i n g B i k e C o n f i g u r a t i o n
inv O 1 5−minimumWeight : s e l f . f r a m e . w e i g h t >= 5200
context P r o f e s s i o n a l R a c i n g B i k e C o n f i g u r a t i o n
inv O 1 6− c e r t i f i c a t i o n : s e l f . o r g a n i s a t i o n −> s i z e ( ) >= 1
context C i t y B i k e C o n f i g u r a t i o n
inv O 1 7−r e a r S u s p e n s i o n : s e l f . f r a m e . r e a r S u p e n s i o n −> s i z e ( ) = 0
3.4 Bicycle Configurations Level - O2
ChallengerA2XL1:ProfessionalRacingBikeConfiguration RocketA1XL1:ProfessionalRaceFrame
Invoice1:Invoice
price1:Real = 4999.00 0 height1:Real = 600
price1:Real date1:String = 01.09.2017 0 1 1 size1:Real = 700
date1:String averageActualSalesPrice0:Real = 4532.00 usn1:String = 1
readOnly1:Boolean revenue0:Real = 78232.00 weight1:Real = 920.00
bestseller0:Boolean = true material1:Material = CARBON
1 topTubeLenght1:Integer
downTubeLenght1:Integer
seatTubeLength1:Integer
ProRaceBikeCustomer1:HumanCustomer Certification0:UCI colour1:String= 1
rearWheel
frontWheel
1
ProRaceFrontWheel1:CarbonWheel ProRaceFrontWheel1:CarbonWheel EndavorA3XL1:RacingFork
Suitable0:BikeRacingPurpose
height1:Real = 400 height1:Real = 400 height1:Real = 300
size1:Real = 340 size1:Real = 340 for:CyclistSize=TALLCYCLIST size1:Real = 300
usn1:String = 1 usn1:String = 1 usn1:String = 1
weight1:Real = 2000 weight1:Real = 2000 weight1:Real = 300
colour1:String= 1 colour1:String= 1 colour1:String = 1
Fig. 3. Bicycle Configuration Model (O2 )
Figure 3 shows the example bicycle configuration described in the Bicycle Challenge. This con-
figuration, called ChallengerA2XL is an instance of the ProfessionalRacingBike category and
has a regular sales price of 4999.00. The averageActualSalesPrice is determined by the derive
constraint O0 2 to have a value of 4349.25. The derived value for the revenue attribute (for 2017)
is 78232.0 as described in the Challenge description. It is also the best selling configuration at this
level. The connected components represent the minimum configuration satisfying the constraints
defined at the level above. For instance, the connected wheels both have the same size and can
be distinguished by the instance of the connection. The front wheel will be connected to the front
wheel connection instance and the rear wheel to the rear wheel connection.
3.5 Bicycle Instances Level - O3
Invoice0:Invoice 1341230:ChallengerA2XL
1
price0:Real = 4299.00 price0:Real = 4999.00
date0:String = 19.09.2017 date0:String = 01.09.2017
readOnly0:Boolean = true 1 1
1341230:RocketA1XL
rearWheel
SusanStorm0:ProRaceBikeCustomer
height0:Real = 60
1 size0:Real = 70
1341230:EndavorA3XL 1341230:ProRaceRearWheel 1341230:ProRaceFrontWheel usn0:String = s134123
frontWheel
weight0:Real = 920
height0:Real = 30 height0:Real = 40 height0:Real = 40 material0:Material = CARBON
size0:Real = 30 size0:Real = 34 size0:Real = 34 topTubeLenght0:Integer
usn0:String = 134123E usn0:String = 134123RW usn0:String = 134123FW downTubeLenght0:Integer
weight0:Real = 30 weight0:Real = 200 weight0:Real = 200 seatTubeLength0:Integer
colour0: String = 'BLUE' colour0: String = 'YELLOW' colour0: String = 'YELLOW' colour0:String = 'Black'
Fig. 4. Bicycle Instance Level (O3 )
Figure 4 shows the bicycle configuration instances described in the Challenge description at the
lowest (most concrete) level of the deep model. The Invoice connection captures the sales trans-
action and is the source of information for the derive constraints for the attributes revenue, best-
seller and averageActualSalesPrice. The bicycle concerned is an instance of ChallengerA2XL
sold for a price of 4299.00 instead of the regular price of 4999.00 as shown in the Invoice con-
nection. The values of the attribute of the clabjects derived from Component and Product cannot
be changed at this level because their mutability is set to zero at the level above. Except for the
attributes colour and usn of the Component clabject.
4 Discussion
Having presented our solution to the Bicycle Challenge, in the section we discuss its pros and cons
according to the criteria outlined in the Challenge description.
4.1 Mandatory Comparison Criteria
Basic Modeling Constructs. The basic benefit of multi-level modeling is that it simplifies the
modeling of domains inherently consisting of instantiation chains having two or more ontological
classification relationships, such as the Bicycle Challenge. There is no claim that multi-level mod-
eling makes it possible to represent scenarios that cannot be modeled using traditional two-level
languages, the basic value proposition is that it does so with less accidental complexity (e.g. by obvi-
ating the need for workaround patterns such as the type-object patterns etc.) [13]. The deep model
presented in this paper demonstrates this by capturing all information in the Bicycle Challenge in
the style of the UML/MOF core infrastructure language, but with minimal linguistic overhead.
Three features of the approach are primarily responsible for achieving this minimality. The first
is the compaction of elements that play both type and instance roles into elements represented using
a single amalgamated linguistic concept – “clabject”. The second is the separation of ontological
classification from linguistic classification, and the use of a modeling architecture that allows the
former to be concisely represented within an arbitrary number of “levels” spanned by the latter. In
our deep model, ontological classification is represented using the tradition UML “:” notion. The
third is the use of a single linguistic attribute of clabjects and attributes, called potency, to capture
their “instantiatability/changeability” over multiple levels. While the first two features are common
to most multi-level modeling approaches, potency is unique to deep modeling. It helps minimize
linguistic overhead by capturing important properties of a model without the need for additional
linguistic constructs. For example, the three forms of potency in MELANEE – clabject potency,
attribute potency (a.k.a. durability) and value potency (a.k.a. mutability) obviate the need for
features such as abstract classes, tags/tag values, static variables, power types and dependencies in
the UML. For example, Figure 1 shows the use of potency 0 clabjects to represent abstract classes,
durability 2 attributes to represent tags, and mutability 2 attribute values to represent tag values.
Levels and Layers. In the deep modeling approach supported by MELANEE, levels are defined
by ontological classification (i.e. instance-of) relationships according to the tenet of strictness. In
essence, this states that the ontological types of a clabject must reside at the level above that
clabject. However, the “level at which a clabject” resides does not necessarily correspond to its
order (i.e. instantiation power) as in most multi-level modeling approaches [8]. This is reflected by
the fact that although the direct type of a clabject must have a potency that is one higher than that
of the clabject, indirect types (i.e. superytpes of the direct type) can have a potency lower than
that of the direct type as illustrated in Figure 1. All inheritance (specialization-of) relationships
must reside within a single ontological level in a MELANEE deep model.
This approach has the advantage that abstractness can be represented in a nuanced and mini-
malistic way using potency as shown in Figure 1. How it also arguably has the disadvantage that
“unnecessary” clabjects have to be included in levels when an abstraction needs to be instantiated
at more than one level [9]. For example, since the abstraction HumanCustomer is defined at level
O0 , so that it can inherit from Person, but is “used” at O3 where actual human customers are
represented, the intermediate levels also have to contain offspring of HumanCustomer. This problem
could be alleviated by cross-level structural relationships of the kind suggested in [8], but this would
require a relaxation of the potency rules so that base-types could be more frequently used.
Abstraction. By making ontological classification a first class citizen of models alongside spe-
cialization, deep modeling allows model content to be organized into abstraction levels that best
match the concerns occurring in the domain of discourse. This is clearly illustrated by our Bicycle
Challenge deep model, where the O0 level focuses on the abstract concerns of product structure
and sales, the O1 focuses on describing bicycles categories as instances of products, O2 focuses
on describing specific bicycle configurations as instances of bicycle categories, and O3 represents
specific instances of bicycle configurations.
Reuse. The information in a deep model can be reused in two ways based on the two fundamental
relationships of ontological classification and specialization. Since the top level O0 metamodel is
independent of the bicycle domain, it can be used to support new product areas through classifi-
cation simply by instantiating new models from it. Alternatively, the existing models derived from
O0 can be customized by specializing the existing clabjects with more refined versions. To further
facilitate reuse, MELANEE also supports model importation and composition [2].
Cross-level relationships. MELANEE’s deep modeling approach strictly forbids any kind of re-
lationship other than ontological classification relationships between levels. This requires modelers
to be disciplined and create models which are organized into clear abstraction levels. However,
it arguably has the disadvantage that additional clabjects needed to be included in certain lev-
els to ensure that offspring of a certain concept exist at the correct level to avoid level-crossing
relationships.
Cross-level constraints. The deep OCL dialect used to define the constraints in our solution is
aware of, and can exploit, the two distinct modeling dimensions and multiple levels that occur with
the ontological dimension [12]. As illustrated in Section 3, this constraint language can be used to
define level-spanning (i.e. “reflective”) constraints which adjust the rules by which levels relate to
each other, as well as multi-level constraints that govern the contents of the offspring of a clabject
over an arbitrary number of levels
Integrity mechanisms. The ability to change any level of a deep model on-the-fly, in real time,
offers a great deal of power and flexibility when used correctly. However, it also means that simple
changes can have a dramatic impact on the correctness of a deep model. MELANEE therefore contains
a built-in emendation service [3] which checks the impact of any changes made by users and (a)
automatically updates the rest of the model to be consistent with them and/or (b) checks whether
they have consequences intended by the users by displaying them and asking for conformation.
Code Generation and Consistency. MELANEE does not have any in-built code generation capa-
bilities, but since it is a part of the ECLIPSE environment, its rich set of development plug-ins can
be used to map MELANEE models to other IT artifacts. The MELANEE toolkit is also accompanied
by a specially designed transformation language, deep ATL [5], which is aware of and supports
transformations between deep models.
4.2 Additional Comparison Criteria
In this paper, we have presented our solution to the Bicycle Challenge using the standard, general
purpose concrete syntax for the LML. However, MELANEE also allows users to define an arbitrary
number of alternative concrete syntaxes for (offspring of) an ontological level which can have mul-
tiple formats (i.e. graphical, text-based, form-based tabular). Not only can these different notations
be used side-by-side with each other and with the general syntax to provide multiple, concurrent
views on a deep model, they be can automatically applied at any depth below the level where
they are defined. Furthermore, the rendering of a clabject can also be made context-sensitive so
that different symbols are used in different situations. This ability to define deep, context-sensitive,
domain-specific language within the ontological levels of a deep model allows a wide range of ad-
vanced business services and tools to be supported. For example, because deep models contain
instance data as well as type data (i.e. they embody models@run-time), performance data can eas-
ily be collected and displayed in the style of a business analytics tool. Alternatively, by defining a
business process modeling language at the top level, business processes can not only be represented
in a domain specific syntax at the level below, but the execution of the instances of these process
can be displayed at run time using the same notation. Ultimately, this capability allows MELANEE
to support the full-scale simulation of deep models and the creation of model-driven tools [4].
5 Conclusion
This paper has presented a full solution to the MULTI 2018 Bicycle Challenge taking the form
of a deep model in MELANEE. By capturing all mandatory and optional requirements of the Chal-
lenge in a highly concise, precise and easy-to-understand way, the model reinforces the core value
proposition of multi-level modeling which is to reduce accidental complexity without loss of clarity.
In particular, the model demonstrates that it is possible to clearly and precisely describe com-
plex, multi-level domain scenarios in a UML-like way without resorting to the plethora of auxiliary
modeling features utilized by the UML (i.e. stereotypes, tag/tagged values, dependencies, static
variables, power types etc.). By treating all levels uniformly using the same core relational concepts
(inheritance, containments, classification etc.) the approach also provides a new dimension of flexi-
bility to modelers in which they can change abstract (i.e. meta) levels as easily as they can change
concrete (i.e. instance) levels. It therefore lays the foundation for models to support all phases of
a software system’s lifecycle (i.e. development, deployment and operations) and bring the vision of
models@runtime closer to reality. The next step is to develop a version of the Bicycle Challenge
based on traditional two-level modeling technologies to perform a concrete comparison.
References
1. 5th international workshop on multi-level modelling, https://www.wi-inf.uni-duisburg-
essen.de/MULTI2018/
2. Atkinson, C., Gerbig, R., Fritzsche, M.: A multi-level approach to modeling language extension in the
enterprise systems domain. Information Systems 54, 289–307 (2015)
3. Atkinson, C., Gerbig, R., Kennel, B.: On-the-fly emendation of multi-level models. In: Vallecillo, A.,
Tolvanen, J.P., Kindler, E., Störrle, H., Kolovos, D. (eds.) Modelling Foundations and Applications.
Lecture Notes in Computer Science, vol. 7349, pp. 194–209. Springer Berlin Heidelberg (2012)
4. Atkinson, C., Gerbig, R., Metzger, N.: On the execution of deep models. In: Mayerhofer, T., Langer, P.,
Seidewitz, E., Gray, J. (eds.) Proceedings of the 1st International Workshop on Executable Modeling.
EXE 2015, vol. 1560, pp. 28–33. CEUR Workshop Proceedings (2015)
5. Atkinson, C., Gerbig, R., Tunjic, C.: Towards multi-level aware model transformations. In: Hu, Z.,
de Lara, J. (eds.) Theory and Practice of Model Transformations. Lecture Notes in Computer Science,
vol. 7307, pp. 208–223. Springer Berlin Heidelberg (2012)
6. Atkinson, C., Kühne, T.: The essence of multilevel metamodeling. In: International Conference on the
Unified Modeling Language. pp. 19–33. Springer (2001)
7. Atkinson, C., Kühne, T.: Rearchitecting the uml infrastructure. ACM Trans. Model. Comput. Simul.
12(4), 290–321 (Oct 2002)
8. de Carvalho, V.A., Almeida, J.P.A.: Toward a well-founded theory for multi-level conceptual modeling.
Software and System Modeling 17(1), 205–231 (2018)
9. De Lara, J., Guerra, E., Cobos, R., Moreno-Llorena, J.: Extending deep meta-modelling for practical
model-driven engineering. The Computer Journal 57(1), 36–58 (2012)
10. Draheim, D.: Reflective constraint writing. In: Transactions on Large-Scale Data-and Knowledge-
Centered Systems XXIV, pp. 1–60. Springer (2016)
11. Gerbig, R.: Deep, seamless, multi-format, multi-notation definition and use of domain-specific lan-
guages. Verlag Dr. Hut (2017)
12. Lange, A.: dACL: the deep constraint and action language for static and dynamic semantic
definition in Melanee. Master’s thesis, University of Mannheim (2016), http://ub-madoc.bib.uni-
mannheim.de/43490/
13. Lara, J.D., Guerra, E., Cuadrado, J.S.: When and how to use multilevel modelling. ACM Transactions
on Software Engineering and Methodology (TOSEM) 24(2), 12 (2014)
14. Software Engineering Group University Mannheim: Melanee – the deep-modeling domain-specific lan-
guage workbench (2018), http://www.melanee.org/