This analysis assumes that an ISQ quantity «attribute» has multiplicity [*] as it does in the Cameo SysMLv2 Plugin model libraries.
This issue tracker is PROVISIONAL. It may come down to a difference in interpretation of the specification statements, but Webel suggests that the sentences of the specification quoted below could be clearer.
There are numerous examples in the SysMLv2 Annex example and the SysMLv2 PILOT GitHub samples of an «attribute» subsetting an ISQ quantity «attribute» but NOT providing an explicit multiplicity. The following are from the main Vehicle Example but there are many other similar ones:
part def Vehicle {
attribute mass :> ISQ::mass;
attribute dryMass:>ISQ::mass;
attribute cargoMass:>ISQ::mass;
attribute position:>ISQ::length;
attribute velocity:>ISQ::speed;
attribute acceleration:>ISQ::acceleration;
attribute electricalPower:>ISQ::power;
That these are intended to have multiplicity [1..1] is suggested from how they are used elsewhere:
constraint {electricalPower<=500[W]}
Note there are other cases that DO provide an explicit multiplicity:
attribute elapseTime[1] :> ISQ::time;
attribute position[1] :> ISQ::distance;
The cases that don't provide a multiplicity seem to be relying on this rule:
But they do not in fact meet those extra conditions:
Since they DO subset an ISQ quantity «attribute» with an explicitly declared multiplicity [*] (at least in Cameo) they inherit the explicitly declared multiplicity [*].
And they don't meet the other conditions anyway:
Maybe this part is supposed to offer a loophole:
But that does not apply, taken literally, because there is an explicitly declared multiplicity [*] to inherit (even if [*] and [0..*] are the same).
Perhaps it depends on how one interprets 'If no tighter constraint is inherited ..', since the inherited multiplicity [*] is not tighter than [0..*]. But then the conditions for 'a tighter default of [1..1] is implicitly declared' aren't met anyway, because the examples shown do 'have any explicit owned subsettings'.
Webel's advice is:
- Prefer using feature typing by an ISQ «attribute def» (noting the available ISQ «attribute» versions don’t cover all cases anyway).
- If you do use subsetting of an ISQ «attribute» always state the multiplicity!
