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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend