Inheritance of Group Cardinality in Clafer

Michał AntkiewiczApril 06, 2015

http://gsd.uwaterloo.ca http://necsis.cahttp://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.jpg

3

What are Feature and Group Cardinality?• Define constraints over feature configurations

Wikipedia: http://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

4

Feature and Group Cardinality in Clafer

<gl>..<gu> <name> <cl>..<cu>

Group cardinality:how many instances ofchildren are required

Clafer cardinality:how many instances ofthe clafer are required

0..* Catalog 1..1 0..* Search 0..1 1..1 Security 1..11..* Payment 1..1

5

E-Shop in Clafer

Wikipedia: http://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):

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

7

Feature modeling notations do not

support inheritance

How should group cardinality work in the presence of inheritance in Clafer?

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

InheritanceMyEShop Catalogue Payment CreditCard Security High Search Reviews

SPECIFIES

Extension

Specialization

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

10

Situation in Clafer < 0.3.9

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)

12

Solution Implemented in Clafer 0.3.9

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

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

15

An Alternative Solution: No Inheritance Of Group Cardinality Specification

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

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

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

18

Questions?Thank You

http://gsd.uwaterloo.ca http://necsis.cahttp://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