-
Notifications
You must be signed in to change notification settings - Fork 14
Group Cardinality
Group cardinality expresses variability among children of a given clafer. In the car example with optional radio we were talking about cardinalities. Cardinalities allowed us to make radio an optional element of a car, thus introducing variability into car’s structure. The radio, if present, was able to play CDs. Modern cars, however, have more variants of radios. Some radios can also play mp3 files, while other radios can play mp3’s but cannot play CDs. The above situation cannot be modeled purely with cardinalities. We need to use group cardinalities:
car
engine
or radio ?
cdPlayer
mp3We made two changes to the previous car model. First, we introduced a new child
mp3 under radio. Second, radio is preceded by the or keyword that specifies group cardinality. It indicates that at least one child of radio (i.e. cdPlayer or mp3) must be present if radio is present. or is a shorthand for 1..*. The first number gives lower bound, the second gives upper bound. Group cardinality is a keyword or an interval that precedes clafer’s name. It tells how many instances of the children of a given clafer can be present.

What are group cardinalities of other clafers? Clafer assumes that by default group cardinality is equal to 0..*. It imposes no restriction on the number of allowed children and makes models more concise. The same model, but with explicit cardinalities and group cardinalities is shown below. Please note that cdPlayer and mp3 are optional.
0..* car 1..1
0..* engine 1..1
1..* radio 0..1
0..* cdPlayer 0..1
0..* mp3 0..1Why are cdPlayer and mp3 optional clafers? Did you not say that the default cardinality is 1..1? Yes, you are right. Partially. Clafer uses two rules that determine default cardinalities of clafers:
- Direct children of a clafer with group cardinality 0..*, regardless whether given explicitly by an interval or assumed by default, have cardinality 1.
- Direct children of a clafer with any other group cardinality, regardless whether given by an interval or a keyword, have clafer cardinality 0..1.
In other words, Default clafer cardinality is 1, except when they are direct children of a clafer with group cardinality different than 0..*. The above rules improve readability of clafer models and are also convenient when writing models.
We care about clafer’s group cardinality only if the clafer is present. In the above example, if there is no radio, then there is no cdPlayer and no mp3 player. It makes no sense to count group cardinality for radio’s children if radio does not exist. Our car example has a substantial portion of variability in it. There are several valid configurations that conform to that model:
- A car without a radio (and without a CD and mp3 player)
0..* car 1..1 0..* engine 1..1 1..* radio 0..0 0..* cdPlayer 0..0 0..* mp3 0..0 - A car with a radio (and with a CD player but no mp3 player)
0..* car 1..1 0..* engine 1..1 1..* radio 1..1 0..* cdPlayer 1..1 0..* mp3 0..0 - A car with a radio (and with mp3 but no CD player)
0..* car 1..1 0..* engine 1..1 1..* radio 1..1 0..* cdPlayer 0..0 0..* mp3 1..1 - A car with a radio (and with mp3 and CD player)
0..* car 1..1 0..* engine 1..1 1..* radio 1..1 0..* cdPlayer 1..1 0..* mp3 1..1
Any other configuration is invalid. For example:
0..* car 1..1
0..* engine 1..1
1..* radio 1..1
0..* cdPlayer 0..0
0..* mp3 0..0Radio requires that there is least one child, i.e., cdPlayer or mp3 player, present. Cardinality of both children is 0. Such a model is inconsistent. It would be consistent if the cardinality of radio was 0.
Most often used group cardinalities are specified by keywords.
-
mux : at most one of. Some people prefer to use titles, others do not. If they do, however, a person uses only one title. We model that situation as:
mux title mr mrs ms -
xor : exactly one of. Typically when filling-in a form, a person must select their gender. Exactly one gender must be selected. This is modeled as follows:
xor gender male female -
or : at least one of. Each person speaks at least one language, which is known as native language. Some people also know other languages. Below is an example of a corresponding Clafer model:
or spokenLanguage english portuguese german -
opt : any number of. People have various interests. Furthermore, each person has different interests, but some people have no interests. We need to make all interests optional. One could write optional cardinality next to each clafer, but that would be cumbersome if the list of interests is long. For such cases, we prefer to use the group cardinality:
opt hobbies reading sports music
Why in the example:
car
0..* engine 1..1
or radio ?
cdPlayer
mp3engine has 0..* group cardinality if there must be an engine?
Because group cardinality refers to children of engine. It says nothing about presence of engine.
What is the syntax for specifying group cardinalities?
The are three ways of specifying group cardinalities:
- Using the default group cardinality (which is 0..*), e.g. car. In this case, the default cardinality of each child is 1..1.
- As an interval, e.g., 2..7 car, 1..* car. In this case, the default cardinality of each child is 0..1.
- Using one of the keywords: mux car (at most one of, i.e., 0..1;), xor car (exactly one of, i.e., 1..1), or car (at least one of, i.e., 1..*), opt car (any number of, i.e., 0..*). In this cases, the default cardinality of each child is 0..1.
Does group cardinality refer to different types of children or children instances?
Group cardinality restricts children instances, i.e., it takes into account any combination of children instances. In the example:
0..3 parentClafer
child1
child2 ?
child3 +
child4 *group cardinality constraint is given as the following inequality: 0 ≤ #child1 + #child2 + #child3 + #child4 ≤ 3, where # counts the number of instances of given clafer. From all the children of parentClafer up to 3 instances of children will be chosen. Because of cardinality of child1 and child3, they must always be present. There are 4 valid configurations:
- One instance of child1, and one instance of child3: {child1 1, child3 1 },
- One instance of child1, and two instances of child3: {child1 1, child3 1, child3 2 },
- One instance of child1, one instance of child2, and one instance of child3: {child1 1, child2 1, child3 1 },
- One instance of child1, one instance of child3, and one instance of child4: {child1 1, child3 1, child4 1 }.
What happens if a child has cardinality that is greater than group cardinality of its parent clafer? Is the example below legal?
xor A 2
B 5
CNo. First the model is desugared to:
1..1 A 2..2
B 5..5
C 0..1xor means that exactly one child must be selected (where child includes all instances of B and C, not just different types). So for this example, group cardinality boils down to the inequality:
1 ≤ #B + #C ≤ 1. This inequality must hold for each instance of A separately (there are two instances of A). We know that #B = 5, and 0 ≤ #C ≤ 1. In any case, the constraint cannot be satisfied, so the model is inconsistent. Syntactically the model is correct (the translator will not complain about it). If a reasoner tries to instantiate the model, it will be unable to find any valid instance of that model.
What is the difference between the two examples below?
- Example 1:
opt transmission manual auto - Example 2:
transmission opt manual opt auto
The are quite different. Let us desugar both examples:
- Example 1:
0..* transmission 1..1 0..* manual 0..1 0..* auto 0..1 - Example 2:
0..* transmission 1..1 0..* manual 1..1 0..* auto 1..1
In the first exampletransmissionmay have any combination ofmanualandautochildren. In the second exampletransmissionalways has both children present. opt refers to group cardinality oftransmissionand makes its children optional; it does not maketransmissionoptional.
Generative Software Development Lab
University of Waterloo
200 University Avenue West
Waterloo, Ontario, Canada N2L 3G1