Skip to content

Comments

ST6RI-885 Usage should not be allowed to be typed by another usage#707

Merged
seidewitz merged 3 commits intomasterfrom
ST6RI-885
Oct 29, 2025
Merged

ST6RI-885 Usage should not be allowed to be typed by another usage#707
seidewitz merged 3 commits intomasterfrom
ST6RI-885

Conversation

@seidewitz
Copy link
Member

This PR implements a specific validation check to disallow a usage from being typed by another usage.

Background

KerML allows a Feature to by typed by any other kind of Type, including another Feature. However, in the SysML abstract syntax, Feature::type is redefined by Usage::definition such that all definitions of a Usage must be Classifiers (usually SysML Definitions). There were already validation checks implemented for specific kinds of Usages (for example, that an OccurrenceUsage must be typed by Classes, an ItemUsage must be typed by Structures, etc.). But there was previously no check implemented for the typing of a ReferenceUsage or a general Usage that was not of a more specific kind.

On the other hand, the implementation of Usage::getDefinition filters out all types of a Usage that were not Classifiers. Further, getType for Usage is delegated to getDefinition (or possibly an even more specific redefinition), so getting the the types of a Usage typed by a Feature instead of a Classifier would actually result in an empty list. So, previously, the following produced the confusing KerML validation error that "Features must have at least one type":

attribute a;
ref x : a; // ERROR

On the other hand, the following did not produce any error at all:

attribute def A;
attribute a;
ref x : a, A; // NO ERROR

This was because getting the types of x filtered out the invalid typing by the usage a, leaving only the valid type A.

Changes

This PR includes the following changes to resolve the problem identified above:

  1. Add a new check to SysMLValidation::checkUsage that all the "raw" types of a Usage (without filtering) are Classifiers. If the check fails, the error message is "A usage must be typed by definitions." The check is not performed if the usage is an AttributeUsage or OccurrenceUsage (or subclasses of those), because those kinds of usages already have more specific typing validation checks.
  2. Revise the check in KerMLValidation::checkFeature on Feature typing so that it checks the "raw" types of a Feature, regardless of filtering that may be done in overrides of the Type::getType method. That is, the validation check only fails if the Feature has no types at all, even if some of the types it has are not actually valid per other checks. This prevents the a redundant "Features must have at least one type" error from being produced in addition to a more specific typing validation error.

With these changes, both of the ReferenceUsage declarations above produce (only) the error "A usage must be typed by definitions."

- Also updated other tests to remove redundant KerML message that
"Features must have at least one type".
- Only validated on unspecialized Usages and ReferenceUsages, because
AttributeUsages and OccurrenceUsages (and their specializations) already
have their own typing validations.

- Also updated KerML validation so that the "Features must have at least
one type" error only happens if there are no types at all, not filtering
out invalid types.
@seidewitz seidewitz self-assigned this Oct 24, 2025
@seidewitz seidewitz added this to the 2025-10 milestone Oct 24, 2025
@seidewitz seidewitz added the bug Something isn't working label Oct 24, 2025
@seidewitz seidewitz requested a review from geneShreve October 24, 2025 03:39
@Systems-Modeling Systems-Modeling deleted a comment from geneShreve Oct 29, 2025
@seidewitz seidewitz merged commit 83869d2 into master Oct 29, 2025
2 checks passed
@geneShreve
Copy link

geneShreve commented Oct 29, 2025 via email

@seidewitz
Copy link
Member Author

@geneShreve
You should probably switch back to master. Whether you retest is up to you. No further approval is required.

@geneShreve
Copy link

geneShreve commented Oct 29, 2025 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants