[adaussy]

This PR revises the implementation of default multiplicities for SysML so that they are not physically inserted into the model during getter operations. It also proactively resolves the following OMG issue, presuming that the adopted resolution to the issue will insert default multiplicities during parsing, not as implied members.

• SYSML21-185 Default multiplicities are not formally specified

Background

The SysML Language Specification, subclause 7.6.3 Usages, describes three conditions for a SysML usage to have a default multiplicity of 1..1:

1. The usage is an attribute usage, an item usage (including a part usage, except if it is a connection usage), or a port usage.
2. The usage is owned by a definition or another usage (not a package).
3. The usage does not have any explicit owned subsettings or owned redefinitions.

In addition, subclause 7.13.2 Connection Definitions and Usages states that

If a multiplicity is not explicitly declared for an end feature, then a default of 1..1 is implicitly declared for it (regardless of the usual conditions for default multiplicity given in 7.6.3).

However, as identified in SYSML21-185, there is no formal specification (in normative specification Clause 8) for inserting a default multiplicity based on the above criteria. Nevertheless, a default multiplicity mechanism was implemented, following the criteria, except for a modification to the third ("The usage does not have any explicit owned subsettings or owned redefinitions that have no owning type").

Previously, the default multiplicity mechanism used the adapter addAdditionalMembers method to physically add default multiplicities as necessary during the transformation of the relevant kinds of elements. But addAdditionalMembers was also being called in other places. For example, TypeAdapter.getFeaturesRedefinedByType called it before computing its cache. As a result, calling getFeature on a usage with an implicit Redefinition sometimes caused a mutation of the model as default multiplicities were added.

Impact

As a result of the situation described above, code that merely read features could change loaded models, making resolution tests and serialized expected models depend on getter call order.

Changes

The following changes resolve the problem of possibly mutating a model when a getter is called, consistent with the expected resolution to SYSML21-185.

1. Moved the code for adding default multiplicity from adapter classes to post-processor classes.
2. Removed the adding of default multplicities for criterion 3 above.

As previously, "adding a default multiplicity" means adding a Multiplicity element (not a MultiplicityRange) via an OwningMembership (not a FeatureMembership). The default multiplicity bounds are determined later by adding an implied specialization to Base::exactlyOne. This is not changed by the PR.

[seidewitz]

The functional revisions look good. The only place I would like to see some changes is in the unit test class MultiplicityPreparationTest. Rather than list the changes here, I have pushed a commit with a proposed update to this class.

1. Removed the call that turned off use of the library index. Not using the index slows the test down considerably, and I don't understand what the benefit is.
2. Took more advantage of the functionality available in SysMLInteractive. This simplifies the test code a bit. I had some ideas for making the test a true SysMLInteractiveTest, but, in the end, it didn't seem worth the time and effort to get it to work that way.
3. Made some updates to other files:
   • Added getOwnedMultiplicitiesOf to TypeUtil, and used this method instead of your ownedMultiplicities method. This is a good utility method for future use.
   • Added setResource to SysMLInteractive.

The test results are the same as before the above changes. I have also checked that their are test failures if MultiplicityPreparationTest is run on the commit previous to this PR, which are fixed by the changes in the PR.

Please let me know if you concur.

[adaussy]

The functional revisions look good. The only place I would like to see some changes is in the unit test class MultiplicityPreparationTest. Rather than list the changes here, I have pushed a commit with a proposed update to this class.

1. Removed the call that turned off use of the library index. Not using the index slows the test down considerably, and I don't understand what the benefit is.

2. Took more advantage of the functionality available in SysMLInteractive. This simplifies the test code a bit. I had some ideas for making the test a true SysMLInteractiveTest, but, in the end, it didn't seem worth the time and effort to get it to work that way.

3. Made some updates to other files:

   • Added getOwnedMultiplicitiesOf to TypeUtil, and used this method instead of your ownedMultiplicities method. This is a good utility method for future use.
   • Added setResource to SysMLInteractive.

The test results are the same as before the above changes. I have also checked that their are test failures if MultiplicityPreparationTest is run on the commit previous to this PR, which are fixed by the changes in the PR.

Please let me know if you concur.

That looks good to me. Feel free to merge the PR whenever you're ready.