Multi-level modeling with MELANEE A Contribution to the MULTI2018 - - PowerPoint PPT Presentation

Multi-level modeling with MELANEE

A Contribution to the MULTI2018 Challenge

Arne Lange, Colin Atkinson

Software Engineering Group 2

The Challenge

 model a bicycle shop in a multi-level fashion  fulfill requirements, if necessary with the help

• f a constraint language

 solve some particular problems in the multi-

level modeling domain

 showcase strengths and weaknesses of

different multi-level modeling approaches

Software Engineering Group 3

The MELANEE tool

 supports a deep dialect of MLM

 OCA (Orthogonal Classification Architecture)  deep instantiation

 potency

 strict

 no leap potency etc.

 UML-like look and feel (LML)

 graphical

Software Engineering Group 4

Level-Spanning Content

 Linguistic Meta-models

 LML (Level-Agnostic Modeling Language)  deep OCL variant

 Enumeration Types

 “Material”  “CyclistSize”

 Constraint

 PAN-1

O0 O1 O2 O3

Software Engineering Group 5

Isonyms vs. Hyponymns1

A

Hyponyms

E:A A

Isonyms

E:A

• 1. Bastian Kennel. A Unified Framework for Multi-level Modeling . PhD thesis, University of Mannheim, 2012.

a:Integer a:Integer a:Integer a:Integer b:Integer

Software Engineering Group 6

PAN-Level Constraints

 ensuring the strictness of MELANEE

 only isonymic instantiation

 context is the DeepModel and allows for a

reflective query for a specific linguistic type

context DeepModel inv PAN-1: Clabject -> forAll(select(c|c.#getFeature()# -> select(f|f.#getDurability()# > 0)) -> size() = self.getDirectInstances() -> select(c|c.#getFeature()#) -> size())

Software Engineering Group 7

Product Level - O0

 basic concepts related to customers/products

context Product::revenue:Real (1,2) derive O3: self.allInstances() -> select(c|c.#getPotency()# = 0) -> select(c|c.Invoice.date.substring(7,10) = "2017") -> collectNested(Invoice.price)->sum()

Software Engineering Group 8

Bicycle Categories - O1

 product categories  exploits durability

and mutability of attributes

 invariant constraints

for the lower levels

context BicycleConfiguration (2,3) inv O1-wheelSize: self.frontWheel.size = self.rearWheel.size

Software Engineering Group 9

Bicycle Configurations Level - O2

 ChallengerA2XL configuration level  all invariant constraints must hold here

Software Engineering Group 10

Bicycle Instances - O3

 ChallengerA2XL instance  Invoice is read-only  all invariant constraints must hold here

Software Engineering Group 11

Example: OCL derivation

ProfessionRacingBikeConf.:Product revenue: Real = O1 O3 1341230:ChallengerA2XL price: Real = 4999.00 SusanStorm0:HumanCustomer

Defined on level O0 : context Product::revenue:Real (1,2) deriveO03: self.allInstances() -> select(c|c.#getPotency()# = 0)

• >select(c|c.Invoice.date.

substring(7,10) = "2017") -> collectNested(Invoice.price)

• > sum()

4299.00

 allInstances different for each

context

 date is not a data type but a string

Invoice0 price:Real= 4299.00 date:String=19.09.2017

Software Engineering Group 12

Strengths of the model

 clabject duality and durability/mutability

 allow an attribute abstraction to store different data for

different but related context

 e.g. revenue, averageRegularSalesPrice

 reflective and level aware/spanning constraints

 e.g. enforcing strictness, top seller constraint

 Linguistic and ontological classification

 allows non-ontologically typed clabjects

 e.g. ProfessionalRaceFrame

Software Engineering Group 13

Weaknesses of the model

 redundant instantiation of clabjects

 e.g. Invoice, Customer

 PeterParker (as CategoryManager) clabject

cannot be a Customer

 BicycleCategory clabject (O1) is actually an

abstract clabject, but has to be typed as Product → potency “2” instead of “0”

Software Engineering Group 14

Hyponymic instantiation

ProfessionalRaceFrame2 material2:MATERIAL topTubeLength2:Integer downTubeLength2:Integer seatTubeLength2:Integer ProfessionalRaceFrame2:Component material2:MATERIAL topTubeLength2:Integer downTubeLength2:Integer seatTubeLength2:Integer height2:Real = 1 size2:Real = 1 usn2:String = 2 weight2:Real = 1 colour2:String = 2

 Isonym without an

• ntological type

 Hyponym with an

• ntological type

 additional attributes

Frame2:Component height2:Real = 1 size2:Real = 1 usn2:String = 2 weight2:Real = 1 colour2:String = 2

Software Engineering Group 15

Conclusion and Future Work

 completely covered all requirements

 in a precise and concise way

 did not exploit the MELANEEs DSL features  in the future:

 Make MELANEE more flexible

 Allowing multiple modes of conformation (eg. strict

isonymic/hyponymic)

 Enhance MELANEE with TREACL

 Transformation, Reason, Enquiry, Action, Constraint – Language

Software Engineering Group 16

Thank You!