1. Inheritance of Group Cardinality in Clafer Michał Antkiewicz April 06, 2015 http://gsd.uwaterloo.cahttp://necsis.ca http://clafer.org

2. What are Feature and Group Cardinality? Modeling constructs from cardinality-based feature modeling Wikipedia: http://en.wikipedia.org/wiki/Feature_model#/media/File:E-shopFM.jpghttp://en.wikipedia.org/wiki/Feature_model#/media/File:E-shopFM.jpg 2

3. What are Feature and Group Cardinality? Define constraints over feature configurations Wikipedia: http://en.wikipedia.org/wiki/Feature_model#/media/File:E-shopFM.jpghttp://en.wikipedia.org/wiki/Feature_model#/media/File:E-shopFM.jpg Config 1: E-Shop Catalogue Payment Bank transfer Credit card Security High Config 2: E-Shop Payment Security High Standard X X X 3

4. Feature and Group Cardinality in Clafer.... Group cardinality: how many instances of children are required Clafer cardinality: how many instances of the clafer are required 0..* Catalog 1..1 0..* Search 0..11..1 Security 1..11..* Payment 1..1 4

5. E-Shop in Clafer Wikipedia: http://en.wikipedia.org/wiki/Feature_model#/media/File:E-shopFM.jpghttp://en.wikipedia.org/wiki/Feature_model#/media/File:E-shopFM.jpg 0..* EShop 1..1 0..* Catalogue 1..1 1..* Payment 1..1 0..* BankTransfer 0..1 0..* CreditCard 0..1 1..1 Security 1..1 0..* High 0..1 0..* Standard 0..1 0..* Search 0..1 In Clafer (explicit): 5

6. E-Shop in Clafer Defaults optimized to support feature modeling 0..* EShop 1..1 0..* Catalogue 1..1 1..* Payment 1..1 0..* BankTransfer 0..1 0..* CreditCard 0..1 1..1 Security 1..1 0..* High 0..1 0..* Standard 0..1 0..* Search 0..1 EShop Catalogue or Payment BankTransfer CreditCard xor Security High Standard Search ? USE DEFAULTS AND KEYWORDS 6

7. Feature modeling notations do not support inheritance How should group cardinality work in the presence of inheritance in Clafer? 7

8. Inheritance in Clafer abstract EShop Catalogue or Payment BankTransfer CreditCard xor Security High Standard Search ? [ CreditCard => High ] MyEShop : EShop [ CreditCard ] [ no BankTransfer ] [ Search ] Reviews Inheritance MyEShop Catalogue Payment CreditCard Security High Search Reviews SPECIFIES Extension Specialization 8

9. Inheritance of Group Cardinality Should Payment2 inherit the or group? Should PayPal and Bitcoin extend the original group? Should Payment3 be able to refine or to xor ? abstract or Payment BankTransfer CreditCard abstract Payment2 : Payment PayPal Bitcoin abstract xor Payment3 : Payment2 9

10. Situation in Clafer < 0.3.9 10 abstract or Payment BankTransfer CreditCard abstract Payment2 : Payment PayPal Bitcoin abstract xor Payment3 : Payment2 some (BankTransfer ++ CreditCard) Payment2 inherits the or group cardinality and PayPal and Bitcoin form a new group some (PayPal ++ Bitcoin) Payment3 refines or to xor but it does not apply to anything because no new children

11. Highly confusing and unexpected behavior We declare one group, which is inherited but we get two groups PayPal and Bitcoin become optional by default since they belong to a group There’s no way to actually refine the group cardinality (actually, one could write an extra constraint but one cannot use keywords) 11

12. Solution Implemented in Clafer 0.3.9 12 abstract or Payment BankTransfer CreditCard abstract Payment2 : Payment PayPal Bitcoin abstract xor Payment3 : Payment2 myPayment : Payment3 or group declared but no constraint generated Payment2 inherits the or group cardinality but no constraint generated. PayPal and Bitcoin extend the existing group Payment3 refines or to xor and it applies to all inherited clafers but no constraint generated one (BankTransfer ++ CreditCard ++ PayPal ++ Bitcoin)

13. Allows for Group Refinement One can extend an existing group One can refine group cardinality Defers the generation of the final constraint to application site The resulting constraint applies to the concrete clafer 13

14. However… This only works because concrete clafers cannot be further inherited from Violates Liskov’s Substitution Principle abstract or Payment BankTransfer CreditCard abstract xor Payment2 : Payment PayPal Bitcoin myPayment : Payment2 [ Bitcoin ] payment -> Payment [ BankTransfer => … ] [ CreditCard => … ] [ payment = myPayment ] OK! Cannot rely on the Original or group! OK, because myPayment “Is A” Payment 14

15. An Alternative Solution: No Inheritance Of Group Cardinality Specification 15 abstract or Payment BankTransfer CreditCard abstract xor Payment2 : Payment PayPal Bitcoin myPayment : Payment2 [ CreditCard ] [ Bitcoin ] some (BankTransfer ++ CreditCard) Payment2 does not inherit the or group cardinality but inherits the constraint. PayPal and Bitcoin form a new xor group one (PayPal ++ Bitcoin) Payment3 inherits both constraints and its own constraints must be consistent

16. No group extension and cardinality refinement Group cardinality only applies locally but it generates a constraint which is inherited Allows for inheritance from concrete clafers Compositional and satisfies Liskov’s Substitution Principle abstract or Payment BankTransfer CreditCard abstract xor Payment2 : Payment PayPal Bitcoin myPayment : Payment2 [ CreditCard ] [ Bitcoin ] payment -> Payment [ BankTransfer => … ] [ CreditCard => … ] [ payment = myPayment ] OK OK, can rely on the original `or` group! OK, because `myPayment` “Is A” `Payment`

17. Conclusion Still, not clear which solution is the right one… The current (0.3.9) – seems pragmatic and natural The alternative – seems formally correct but unnatural 17

18. Questions? Thank You 18 http://gsd.uwaterloo.cahttp://necsis.ca http://clafer.org

19. Other concerns Module system? Is the solution 0.3.9 well-behaved in presence of modules? Using reference and enum for extensible groups 19