Skip to content

Conversation

@seidewitz
Copy link
Member

@seidewitz seidewitz commented Jul 4, 2025

This PR fixes additional bugs in the transformation code for satisfying semantic constraints from the KerML and SysML specifications, mostly as identified in TODO annotations made in PR #665 (ST6RI-843).

KerML

  1. FeatureChainExpression – Updated the implementation of result typing in FeatureChainExpressionAdapter to more closely follow the OCL of the constraint checkFeatureChainExpressionSpecialization.
  2. Flow – Updated FlowAdapater to implement the implicit specialization of transfers for Flows with no ends, satisfying the constraint checkFlowSpecialization and consistent with checkFlowWithEndsSpecialization.
  3. IndexExpression – Fixed the implementation of result typing in IndexExpressionAdapter. Also revised it so that result typing is added in all cases in which the sequence type is not any kind of Collections::Collection. (See also KERML11-69.)

SysML

  1. AnalysisCaseUsage – Added the missing instantiation for AnalysisCaseUsageAdapter to the ElementAdapterFactory, which fixes the implicit specialization of subAnalysisCases to satisfy the constraint checkAnalysisCaseUsageSubAnalysisCaseSpecialization.
  2. IncludeUseCaseUsage – Fixed the implicit specialization of includedUseCases in IncludeUseCaseUsageAdapter, satisfying the constraint checkIncludeUseCaseSpecialization (which should be named checkIncludeUseCaseUsageSpecialization, see SYSML21-299).
  3. SuccessionAsUsage – Implemented implicit specialization in SuccessionAsUsageAdapter to satisfy the constraints checkDecisionNodeOutgoingSuccessionSpecialization and checkMergeNodeIncomingSuccessionSpecialization.
  4. TerminateActionUsage – Fixed the initialization of the ImpliedGeneralizationMap so that TerminateActionUsageImpl has the correct entry for subaction.
  5. VerificationCaseUsage – Added the missing instantiation for VerificationCaseUsageAdapter to the ElementAdapterFactory, which fixes the implicit specialization of subVerificationCases to satisfy the constraint checkVerificationCaseUsageSubVerificationCaseSpecialization.

The PR also proactively resolves the issue

  • SYSML21-309 Constraint checkRequirementUsageObjectiveRedefinition needs to handle feature chains

to avoid spurious validation errors when including a use case via a feature chain.

seidewitz added 7 commits July 4, 2025 16:54
- The extra "put" for TerminateActionUsageImpl_subaction replaced the
correct implicit generalization for a TerminateActionUsag subaction.

- Also added TerminateActionUsage to SysMLSpecializationTest.
- Fixed if test to correctly check specialization by seqResult.
- Generalized if test so that result typing is added for any seqResult
that does not have a Collection type.
- Also turned on tests for IncludeUseCaseUsage in
SysMLSpecializationTest.
Satisfied in SuccessionAsUsageAdapter:
- checkDecisionNodeOutgoingSuccessionSpecialization
- checkMergeNodeIncomingSuccessionSpecialization
To more closely correspond to the OCL of the constraint
checkFeatureChainExprssionSpecialization.
Also:
- Turned on checkFlowDefinitionSpecialization test.
- Fixed expected specialization for checkViewpointUsageSpecialization.
@seidewitz seidewitz added this to the 2025-06 milestone Jul 4, 2025
@seidewitz seidewitz requested a review from TheKorpos July 4, 2025 21:26
@seidewitz seidewitz self-assigned this Jul 4, 2025
@seidewitz seidewitz added the bug Something isn't working label Jul 4, 2025
seidewitz added 2 commits July 4, 2025 18:28
Proactively resolves issue SYSML21-309, so that an objective redefines
a general type that is a feature chain whose featureTarget is a
CaseUsage.
- For subtypes of ActionUsage other than StateUsage, this check is
unnecessary, because the conditions it was used in only applied in
cases in which the owningType was other than a StateDefinition or
StateUsage.
FeatureUtil.chainFeatures(sourceParameter, sourceTarget));
Feature sourceParameter = target.getOwnedFeature().stream().
filter(param->param.getDirection() == FeatureDirectionKind.IN).
findFirst().orElse(null);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use ifPresent on the Optional here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but whenever I do that, it seems clunky to then have to call get() to get the actual value. I'm an old school "check for null" guy. 😉

@seidewitz seidewitz merged commit bc3830f into master Jul 7, 2025
2 checks passed
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.

3 participants