the e hi high level el variability language e an
play

The e Hi High-Level el Variability Language: e: an ontological - PowerPoint PPT Presentation

The e Hi High-Level el Variability Language: e: an ontological approach Angela Villota, Ral Mazo and Camille Salinesi Context Differences Style: orthogonal Targets Structure Way to be used Similarities Syntax


  1. The e Hi High-Level el Variability Language: e: an ontological approach Angela Villota, Raúl Mazo and Camille Salinesi

  2. Context Differences • Style: orthogonal • Targets • Structure • Way to be used Similarities • Syntax • Semantics

  3. Context Translational Semantics Map models in propositional formulas or constraint satisfaction problems to perform reasoning tasks. Constraints

  4. Why don’t we use a constraint-based language to model variability?

  5. High-Level Constraint Language • Djebbi et al. (2009) • Mazo et al. (2011) • Dumitrescu et al. (2014) • Muñoz et al. (2015) • Villota et al. (2018)

  6. Context Feature models REFAS: variability, goals, soft-goals, claims Constraint graphs

  7. The Ontological Path Can we model variability comprehensively using HLCL? • Comparison with other PLMs languages. Asadi's Theory of ontological Knowledge et al. ontology expressiveness sources • User experience. 2 1 Ontological Conceptualization analysis • A more formal approach? Completeness Variability and clarity criteria Modeling glossary Legend Ontological approach 3 Re fi nement and input/ synthesis output • To evaluate the expressiveness of the intermediate language Process HLVL • To conceptualize and structure knowledge about variability modeling • To define variability constructs and language characteristics

  8. not completely different, not completely Parking Assistant System Feature-oriented VP VP VP1: Type VP4: Other VP-oriented Variability modeling languages Speed of vehicle signs Sensors sensor 1, 1 Processor Memory V V9: Road w/right V V V V of way start Position V1: Medium- V2: Upper- V3: Small V4: Big Feedback truck(3, 5t) truck(7, 5t) class car class car V Name: cores sensor Name: size V10: City limit MAX [1, 2] VP Domain: integers Domain: integers VP VP5 : Value: 1..7 Values: [2, 4, 8, 16, 32] VP VP3: Prohibition signs Visual Vibration Confort functions Excludes Mandatory Requires Optional VP2: Activation V V V Audio V11: No OR Alternative 1, 1 V7: No stopping V8: Overspeed vehicles feature Attribute warning warning V V V V5: Switchable V6: Durable V12: No cars VP V VP [min, max] the same Mandatory Optional Requires Excludes Mandatory Optional Variant Alternative What to buy? (name: scope; expected val 1:1): {"assemble yourself", "complete suite"}) Decision-oriented Constraint-oriented �������������� ��������������������������� Include glossary? Which tools? (name: glossary; (name: tools; expected val 1:3): expected val: bool) {"CW", "DK", "PK"}) ��������������� ������������� ��������������������� Width? Default resolution? (name: width; (name: resolution; expected val 1:1): expected val: number) {"800x600", }) ���������������������������������������������� Decision Decision effect Validity Cond. Visibility Cond. Variability unit Variant Variability relation

  9. Va Variability co concepts

  10. The High-Level Variability Language • Rich textual language to model variability. • Syntax that resembles programming languages, to make it human readable • HLVL is a language capable of supporting concepts of many variability languages. Why just features? Would you use it? • Would you leave your modeling tools for an HLVL-tool?

  11. The High-Level Variability Language AppServer E-shop [0, 1] [1, 5] Implementation [2, 10] Customer type Connection Machines Payment Sporadic Regular Debit Secure Insecure PayPal Card Gift Constraints Regular => Customer pro fi le Credit ~(Insecure /\ Credit) Name: Name: Excludes Mandatory con fi dentiality con fi dentiality Requires Optional OR Alternative Domain: integers Domain: integers feature Attribute Value: 5 Value: 3..5

  12. The High-Level Variability Language VP VP VP1: Type VP4: Other signs of vehicle 1, 1 V V9: Road w/right V V V V of way start V3: Small V4: Big V1: Medium- V2: Upper- class car class car truck(3, 5t) truck(7, 5t) V V10: City limit MAX VP VP VP5 : VP VP3: Prohibition signs Confort functions VP2: Activation V V V V11: No 1, 1 V7: No stopping V8: Overspeed vehicles warning warning V V V V5: Switchable V6: Durable V12: No cars V VP VP [min, max] Requires Mandatory Optional Excludes Mandatory Optional Variant Alternative

  13. The High-Level Variability Language What to buy? (name: scope; expected val 1:1): {"assemble yourself", "complete suite"}) ��������������������������� �������������� Include glossary? Which tools? (name: glossary; (name: tools; expected val 1:3): expected val: bool) {"CW", "DK", "PK"}) ��������������� ������������� ��������������������� Width? Default resolution? (name: width; (name: resolution; expected val 1:1): expected val: number) {"800x600", }) ���������������������������������������������� Decision Decision effect Validity Cond. Visibility Cond.

  14. What’s next? Coffee 5 Models and reasoning 4 HLVL models are transformed 1 Domain engineers model questions are processed 1 into constraint programs in HLCL variability using their preferred to choose the best solving language/tool tool and algorithm for 2 Then, models are 6 The solving tool is executed, answering each question transformed to produce the output is processed, and 2 their HLVL representation the questions about the 4 L L V V L L H H variability model are answered. Variability models 3 represented in HLVL are HLCL ready for the reasoning L L V V L L H H 3 HLVL % Autogenerated code from process % the Coffee framework HLCL 5 % Variables from elements defs. HL var 0..1: calls; model mobilePhone var 0..1: GPS; elements: var 0..1: screen; boolean calls var 0..1: basicScreen; boolean GPS 6 var 0..1: hrScreen; boolean screen The transformation process is var 0..1: camera; boolean basicScreen % Variables and constraints boolean hrScreen shorter using our HLVL constraint calls = 1; boolean camera constraint screen = 1; relations: variability modelling editor. constraint GPS + basicScreen <1; R0: coreElements(calls, constraint hrScreen < camera; screen) % Solving parameters R1: mutex(GPS, basicScreen) solve satisfy; R2: implies(camera, hrScreen)

  15. Thank you! Angela Villota Contact: angievig@gmail.com

Recommend


More recommend