Skip to content

ST6RI-812 Additional issue resolutions from SysML v2 FTF2 Ballot #6 (SYSML2_-89, SYSML2_-265)#612

Merged
seidewitz merged 6 commits intomasterfrom
ST6RI-812
Jan 14, 2025
Merged

ST6RI-812 Additional issue resolutions from SysML v2 FTF2 Ballot #6 (SYSML2_-89, SYSML2_-265)#612
seidewitz merged 6 commits intomasterfrom
ST6RI-812

Conversation

@seidewitz
Copy link
Member

@seidewitz seidewitz commented Jan 11, 2025

This PR implements resolutions to the following issues approved in SysML v2 FTF2 Ballot 6:

  • SYSML2_-89 Accepters on transition usages from entry actions
    • Revises the semantic constraints checkTransitionUsageActionSpecialization and checkTransitionUsageStateSpecialization and adds the validation constraint validateTransitionUsageActions, such that a composite TransitionUsage in a state model, with a source that is not a StateUsage, specializes decisionTransitions rather than stateTransitions.
  • SYSML2_-265 Missing semantic constraints related to features of Part
    • Adds the semantic constraints checkPortUsageOwnedPortSpecialization and checkStateUsageOwnedStateSpecialization.
    • Implied relationships corresponding to these constraints had already been implemented. However, the implementation for checkPortUsageOwnedPortSpecialization was incorrect and not working. This has now been fixed.

The implementation of SYSML2_-89 also highlighted an issue with the parsing of TransitionUsages. Names for the source (first) and target (then) elements of a TransitionUsage were being resolved starting in the local scope of the TransitionUsage. In particular, this meant that start and done resolved to those snapshots of the TransitionUsage itself, not the containing StateDefinition or StateUsage. This has now been changed so that the resolution of these names (including the initial name of a feature chain) begins in the scope of the owningNamespace of the TransitionUsage.

Textual Notation

Updated:

  • org.omg.sysml.xtext.scoping.SysMLScopeProvider
    • Added scoping for TransitionUsage source and target.

Abstract Syntax

Updated:

  • org.omg.sysml.xtext.validation.SysMLValidator
    • Added check for validateTransitionUsageActions.

Semantics

Adapters updated:

  • PortUsageAdapter
    • Fixed implementation of checkPortUsageOwnedPortSpecialization
  • TransitionUsageAdapter
    • Updated implementations of checkTransitionUsageActionSpecialization and checkTransitionUsageStateSpecialization.

Model Libraries

Systems Library

Updated:

  • States.sysml
    • In StateAction, added redefinitions of start and done, typing them by StateAction. This ensures, in particular, that a composite TransitionUsage in a state model with StateAction::start as its source will be a StateTransitionAction.

@seidewitz seidewitz self-assigned this Jan 11, 2025
@seidewitz seidewitz added this to the 2024-12 milestone Jan 11, 2025
@seidewitz seidewitz requested review from TheKorpos and himi January 11, 2025 21:03
@seidewitz
Copy link
Member Author

@TheKorpos
Note that semantic tests for checkTransitionUsageStateSpecialization are now done in SysMLSpecializationSpecialTest.

@himi
Copy link
Member

himi commented Jan 13, 2025

Maybe I do not understand the scope of this PR, but I could not check the constraints of SysML2_-265, those are checkPortUsageOwnedPortSpecialization and checkStateUsageStateSpecialization.

For example:

action a {
    port pp;
}

has no error. (Actually, I did not check owningType of pp. For that, I think I need to set up some test environment with pysysml.)

I could check SYSML2_-89.

@TheKorpos
Copy link
Contributor

We should probably add checkPortUsageOwnedPortSpecialization and checkStateUsageOwnedStateSpecialization to the sysml-simple-specialization.csv. I slipped through these as they were only mentioned in the Semantics and had no associated OCL.

@seidewitz
Copy link
Member Author

seidewitz commented Jan 13, 2025

@himi

Maybe I do not understand the scope of this PR, but I could not check the constraints of SysML2_-265, those are checkPortUsageOwnedPortSpecialization and checkStateUsageStateSpecialization.

These constraints only apply when a port or state usage is owned by a part definition or usage. They imply that the port or state usage has a subsetting of Part::ownedPorts or Part::ownedStates, respectively. (Note also that I have the name of checkStateUsageStateSpecialization slightly incorrect in the PR description, which I have now fixed.)

This PR fixes, specifically, the implicit specialization implementation for checkPortUsageOwnedPortSpecialization. So, in

part a {
    port p;
}

the port p should have an implicit subsetting of Parts::Part::ownedPorts(which you can see, e.g., in the Eclipse UI outline view).

@himi
Copy link
Member

himi commented Jan 13, 2025

@seidewitz, thank you. Now I think I can understand better. I found a state owned by a part does not have implicit subsettings of stateActions and suboccurrences, and is it ok? That is,
Screenshot 2025-01-13 at 12 50 05 PM

gets:

Screenshot 2025-01-13 at 12 50 37 PM

For:
- checkPortUsageOwnedPortSpecialization
- checkStateUsageOwnedStateSpecialization
@seidewitz
Copy link
Member Author

I found a state owned by a part does not have implicit subsettings of stateActions and suboccurrences, and is it ok?

Yes, that is OK. ownedStates already subsets stateActions and suboccurrences (the latter indirectly).

@seidewitz
Copy link
Member Author

We should probably add checkPortUsageOwnedPortSpecialization and checkStateUsageOwnedStateSpecialization to the sysml-simple-specialization.csv.

Good point. I have added these.

Copy link
Member

@himi himi left a comment

Choose a reason for hiding this comment

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

I checked the constraints and confirmed they worked.

@seidewitz seidewitz changed the base branch from ST6RI-811 to master January 14, 2025 19:40
@seidewitz seidewitz merged commit 5ecb5c5 into master Jan 14, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants