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.
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 [
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 [
MELANEE is a domain specific language workbench that supports a variety of formats and
visualizations. 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 [
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
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 Configurations) and the notion of Categories is covered by BicycleConfiguration (i.e. subclasses of BicycleConfiguration are specific Categories). 3.1
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 [
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.# getFeature ()# > 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.# getFeature ()#) > s i z e ( ) ) Although strict modeling requires the ontological type of a clabject to reside at the level immediately 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 ontologicallyunclassified 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
price3:Real date3:String readOnly3:Boolean
CategoryManager1 Manages Fig. 1. Product Model (O0) Product3 price3:Real = 2 date3:String = 2 averageActualSalesPrice2:Real revenue2:Real bestseller2:Real averageRegularSalesPrice2:Real
height3:Real = 2 size3:Real = 2 usn3:String = 3 weight3:Real = 2 color3: String = 3
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 MELANEE 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 unfilledtriangle 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 bestseller 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 derive constraints which are applied at specifically defined levels. Constraint O01 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 constraint O02 defines the value of the averageRegularSalesPrice attribute in a similar manner as O01. Constraint O03 defines the value of the revenue attribute while O04 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 O01 : s e l f . a l l I n s t a n c e s ( ) > s e l e c t ( c | c.# getPotency ()# = 0) > s e l e c t ( c | c . I n v o i c e . date . s u b s t r i n g ( 7 , 1 0 ) = "2017") > 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.# getPotency ()# = 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 O02 : s e l f . a l l I n s t a n c e s ( ) > s e l e c t ( c | c.# getPotency ()# = 1) > s e l e c t ( date . s u b s t r i n g ( 7 , 1 0 ) = "2017") > 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.# getPotency ()# = 0) > s i z e ( ) context Product : : revenue : Real d e r i v e O03 : s e l f . a l l I n s t a n c e s ( ) > s e l e c t ( c | c.# getPotency ()# = 0) > s e l e c t ( c | c . I n v o i c e . date . s u b s t r i n g ( 7 , 1 0 ) = "2017") > 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 O04 : 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 ( date . s u b s t r i n g ( 7 , 1 0 ) = "2017") > sortedBy ( revenue ) > l a s t ( ) = s e l f then t o p S e l l e r = t r u e else t o p S e l l e r = f a l s e endif 3.3
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 O11 and O12 are defined on BicycleCon
cyclistSize1:CyclistSize figuration. Constraint O11 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
height2:Real = 1 size2:Real = 1 usn2:String = 2 weight2:Real = 1 colour2:String= 2 Frame2:Component height2:Real = 1 size2:Real = 1 usn2:String = 2 weight2:Real = 1 colour2:String= 2 1
cyclistSize:CyclistSize
material2:Material topTubeLenght2:Integer downTubeLenght2:Integer seatTubeLength2:Integer
price2:Real = 1 1 advaeter2a:gSetArincgtu=alS1alesPrice1:Real = 3699.5 revenue1:Real = 93030 bestseller1:Boolean = false averageRegularSalesPrice0:Real = 2499.66 MountainBikeConfiguration2:Product price2:Real = 1 date2:String = 1 averageActualSalesPrice1:Real = revenue1:Real = 11098.5 bestseller1:Boolean = false averageRegularSalesPrice0:Real =
CityBikeConfiguration2:Product price2:Real = 1 date2:String = 1 averageActualSalesPrice1:Real = 3699.5 revenue1:Real = 11098.5 bestseller1:Boolean = false averageRegularSalesPrice0:Real = 2500.00
height2:Real = 1 size2:Real = 1 usn2:String = 2 weight2:Real = 1 colour2:String= 1
height2:Real = 1 height2:Real = 1 size2:Real = 1 size2:Real = 1 EnforcedBrakes2:BasicPart uwsenig2h:St2tr:iRnega=l =2 1 uwsenig2h:St2tr:iRnega=l =2 1 colour2:String= 2 colour2:String= 2
height2:Real = 1 size2:Real = 1 usn2:String = 2 weight2:Real = 1 colour2:String= 2
height2:Real = 1 size2:Real = 1 usn2:String = 2 weight2:Real = 1 colour2:String= 2
1 Invoice Invoice
height2:Real = 1 frontWheel size2:Real = 1 usn2:String = 2 rearWheel weight2:Real = 1 colour2:String= 2
height2:Real = 1 size2:Real = 1 usn2:String = 2 MudMount2:BasicPart weight2:Real = 1 1 colour2:String= 2
RacingBikeConfiguration2:Product price2:Real = 1 date2:String = 1 averageActualSalesPrice1:Real = 2321.00 revenue1:Real = 78232.00 bestseller1:Boolean = false averageRegularSalesPrice0:Real = 2834.00
cyclistSize1:CyclistSize ProfessionalRacingBikeConfiguration2:Product price2:Real = 1 date2:String = 1 averageActualSalesPrice1:Real = 2321.00 revenue1:Real = 78232.00 bestseller1:Boolean = true averageRegularSalesPrice0:Real = 2834.00 constraint O12. Constraints O13 and O14 are defined for RacingBikeConfiguration. Constraint O13 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 ProfessionalRacingFrame while constraint O14 ensures no instance of RacingBikeConfiguration has a MudMount connected to it. Constraints O15 and O16 are defined for ProfessionalRacingBikeConfiguration 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, O17, 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 O11 w h e e l S i z e : s e l f . frontWheel . s i z e = s e l f . rearWheel . 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 O12 carbonFrame : s e l f . frame . isDeepKindOf ( CarbonFrame ) implies ( s e l f . frontWheel . isDeepKindOf ( CarbonWheel ) or s e l f . frontWheel . isDeepKindOf ( AluminumWheel ) ) context RacingBikeConfiguration inv O13 racingForkFrame : s e l f . f o r k . isDeepKindOf ( RacingFork ) and s e l f . frame . isDeepKindOf ( ProfessionalRacingFrame ) context RacingBikeConfiguration inv O14 mudMount : not ( s e l f . f o r k . isDeepKindOf ( SupensionFork ) ) 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 O15 minimumWeight : s e l f . frame . weight >= 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 O16 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 O17 r e a r S u s p e n s i o n : s e l f . frame . rearSupensi on > s i z e ( ) = 0 3.4
price1:Real date1:String readOnly1:Boolean
price1:Real = 4999.00 0 date1:String = 01.09.2017 0 averageActualSalesPrice0:Real = 4532.00 revenue0:Real = 78232.00 bestseller0:Boolean = true
frontWheel ProRaceFrontWheel1:CarbonWheel ProRaceFrontWheel1:CarbonWheel height1:Real = 400 height1:Real = 400 size1:Real = 340 size1:Real = 340 usn1:String = 1 usn1:String = 1 weight1:Real = 2000 weight1:Real = 2000 colour1:String= 1 colour1:String= 1 rearWheel
for:CyclistSize=TALLCYCLIST
RocketA1XL1:ProfessionalRaceFrame height1:Real = 600 1 1 size1:Real = 700 usn1:String = 1 weight1:Real = 920.00 1 tmoaptTeurbiael1L:eMnagthetr1ia:Iln=teCgeArRBON downTubeLenght1:Integer seatTubeLength1:Integer colour1:String= 1 1 EndavorA3XL1:RacingFork height1:Real = 300 size1:Real = 300 usn1:String = 1 weight1:Real = 300 colour1:String = 1
Figure 3 shows the example bicycle configuration described in the Bicycle Challenge. This configuration, 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 O02 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
Invoice0:Invoice price0:Real = 4299.00 date0:String = 19.09.2017 readOnly0:Boolean = true 1341230:ChallengerA2XL 1
1 1341230:EndavorA3XL 1341230:ProRaceRearWheel 1341230:ProRaceFrontWheel fro n t W h e e l rr e a W h e e l height0:Real = 30 height0:Real = 40 size0:Real = 30 size0:Real = 34 usn0:String = 134123E usn0:String = 134123RW weight0:Real = 30 weight0:Real = 200 colour0: String = 'BLUE' colour0: String = 'YELLOW' height0:Real = 40 size0:Real = 34 usn0:String = 134123FW weight0:Real = 200 colour0: String = 'YELLOW'
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
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
modeling 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
obviating the need for workaround patterns such as the type-object patterns etc.) [
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 [
This approach has the advantage that abstractness can be represented in a nuanced and
minimalistic 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 [
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
classification 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 [
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 [
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
multiple 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
advanced 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
easily 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 [