multi level modeling with melanee
play

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 The Challenge model a bicycle shop in a multi-level fashion fulfill requirements, if necessary with the help of a constraint language


  1. Multi-level modeling with MELANEE A Contribution to the MULTI2018 Challenge Arne Lange, Colin Atkinson

  2. The Challenge  model a bicycle shop in a multi-level fashion  fulfill requirements, if necessary with the help of 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 2

  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 3

  4. Level-Spanning Content  Linguistic Meta-models  LML (Level-Agnostic Modeling Language)  deep OCL variant  Enumeration Types O 0  “Material” O 1  “CyclistSize” O 2  Constraint O 3  PAN-1 Software Engineering Group 4

  5. Isonyms vs. Hyponymns 1 Isonyms Hyponyms A A a:Integer a:Integer E:A E:A a:Integer a:Integer b:Integer 1. Bastian Kennel. A Unified Framework for Multi-level Modeling . PhD thesis, University of Mannheim, 2012. Software Engineering Group 5

  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 6

  7. Product Level - O 0  basic concepts related to customers/products context Product::revenue:Real (1,2) derive O 3 : self.allInstances() -> select(c|c.#getPotency()# = 0) -> select(c|c.Invoice.date.substring(7,10) = "2017") -> collectNested(Invoice.price)->sum() Software Engineering Group 7

  8. Bicycle Categories - O 1  product categories  exploits durability and mutability of attributes  invariant constraints for the lower levels context BicycleConfiguration (2,3) inv O 1 -wheelSize: self.frontWheel.size = self.rearWheel.size Software Engineering Group 8

  9. Bicycle Configurations Level - O 2  ChallengerA2XL configuration level  all invariant constraints must hold here Software Engineering Group 9

  10. Bicycle Instances - O 3  ChallengerA2XL instance  Invoice is read-only  all invariant constraints must hold here Software Engineering Group 10

  11. Example: OCL derivation Defined on level O 0 : O 1 ProfessionRacingBikeConf.:Product context Product::revenue:Real (1,2) revenue: Real = 4299.00 deriveO0 3 : self.allInstances() -> select(c|c.#getPotency()# = 0) ->select(c|c.Invoice.date. O 3 134123 0 :ChallengerA2XL substring(7,10) = "2017") -> price: Real = 4999.00 collectNested(Invoice.price) -> sum() Invoice 0  allInstances different for each price:Real= 4299.00 date:String=19.09.2017 context  date is not a data type but a string SusanStorm 0 :HumanCustomer Software Engineering Group 11

  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 12

  13. Weaknesses of the model  redundant instantiation of clabjects  e.g. Invoice, Customer  PeterParker (as CategoryManager) clabject cannot be a Customer  BicycleCategory clabject (O 1 ) is actually an abstract clabject, but has to be typed as Product → potency “2” instead of “0” Software Engineering Group 13

  14. Hyponymic instantiation  Isonym without an  Hyponym with an ontological type ontological type Frame 2 :Component  additional attributes height 2 :Real = 1 ProfessionalRaceFrame 2 :Component size 2 :Real = 1 usn 2 :String = 2 material 2 :MATERIAL weight 2 :Real = 1 topTubeLength 2 :Integer colour 2 :String = 2 downTubeLength 2 :Integer ProfessionalRaceFrame 2 seatTubeLength 2 :Integer height 2 :Real = 1 material 2 :MATERIAL size 2 :Real = 1 topTubeLength 2 :Integer usn 2 :String = 2 downTubeLength 2 :Integer weight 2 :Real = 1 seatTubeLength 2 :Integer colour 2 :String = 2 Software Engineering Group 14

  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 15

  16. Thank You! Software Engineering Group 16

Recommend


More recommend