OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Open Issues

  • Acronym: SysML
  • Issues Count: 199
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML2_-173 Flow connections are incorrectly both structure and behavior SysML 2.0b1 open
SYSML2_-1 Issues with SysML/KerML grammar SysML 2.0b1 open
SYSML2_-2 incorrect naming of * character SysML 2.0b1 open
SYSML2_-114 Symbol for metadata def is missing SysML 2.0b1 open
SYSML2_-3 incorrect naming of * character SysML 2.0b1 open
SYSML2_-136 Transformation of UML4SysML::State does not consider entry, do, and exit behavior SysML 2.0b1 open
SYSML2_-111 Mapping of ObjectFlows with ForkNodes SysML 2.0b1 open
SYSML2_-165 Semantic constraints missing for shorthand succession notation SysML 2.0b1 open
SYSML2_-180 Reuse of KerML textual notation productions in the SysML grammar SysML 2.0b1 open
SYSML2_-178 Long-form notation for bindings and successions SysML 2.0b1 open
SYSML2_-179 Change graphical notation for use cases to elliptic elements SysML 2.0b1 open
SYSML2-686 Reuse of KerML textual notation productions in the SysML grammar SysML 2.0b1 open
SYSML2-632 Long-form notation for bindings and successions SysML 2.0b1 open
SYSML2-639 Change graphical notation for use cases to elliptic elements SysML 2.0b1 open
SYSML2_-175 PortUsage direction SysML 2.0b1 open
SYSML2_-174 Enumerations not specializable SysML 2.0b1 open
SYSML2-593 Enumerations not specializable SysML 2.0b1 open
SYSML2-592 Flow connections are incorrectly both structure and behavior SysML 2.0b1 open
SYSML2-594 PortUsage direction SysML 2.0b1 open
SYSML2_-164 Add a distinguished attribute to capture the textual body of a requirement SysML 2.0b1 open
SYSML2-546 Add a distinguished attribute to capture the textual body of a requirement SysML 2.0b1 open
SYSML2-576 Semantic constraints missing for shorthand succession notation SysML 2.0b1 open
SYSML2_-159 Textual notation for send actions is too limited SysML 2.0b1 open
SYSML2-526 Textual notation for send actions is too limited SysML 2.0b1 open
SYSML2_-150 OccurrenceUsage missing portioningFeature SysML 2.0b1 open
SYSML2-503 OccurrenceUsage missing portioningFeature SysML 2.0b1 open
SYSML2_-145 Incorrect definition elements in interconnection-element SysML 2.0b1 open
SYSML2-483 Incorrect definition elements in interconnection-element SysML 2.0b1 open
SYSML2_-141 AssociationClass_Mapping is uncomplete SysML 2.0b1 open
SYSML2_-140 Initializer classes have to be rationalized SysML 2.0b1 open
SYSML2-476 Initializer classes have to be rationalized SysML 2.0b1 open
SYSML2-477 AssociationClass_Mapping is uncomplete SysML 2.0b1 open
SYSML2_-138 ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless SysML 2.0b1 open
SYSML2_-137 Optional language for documentation SysML 2.0b1 open
SYSML2-472 Optional language for documentation SysML 2.0b1 open
SYSML2-463 Transformation of UML4SysML::State does not consider entry, do, and exit behavior SysML 2.0b1 open
SYSML2-473 ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless SysML 2.0b1 open
SYSML2_-132 TimeEvent should be mapped to an accept action instead of TextualRepresentation SysML 2.0b1 open
SYSML2_-131 ChangeEvent should be mapped to an accept action instead of TextualRepresentation SysML 2.0b1 open
SYSML2_-133 Fork/JoinNode succession "other" end multiplicity validations missing SysML 2.0b1 open
SYSML2_-130 ConstraintProperty should be mapped to a AssertConstraintUsage SysML 2.0b1 open
SYSML2_-129 TransitionUsage requires binding to succession with mandatory end multiplicities SysML 2.0b1 open
SYSML2-445 ConstraintProperty should be mapped to a AssertConstraintUsage SysML 2.0b1 open
SYSML2-397 TransitionUsage requires binding to succession with mandatory end multiplicities SysML 2.0b1 open
SYSML2-450 Fork/JoinNode succession "other" end multiplicity validations missing SysML 2.0b1 open
SYSML2-449 TimeEvent should be mapped to an accept action instead of TextualRepresentation SysML 2.0b1 open
SYSML2-448 ChangeEvent should be mapped to an accept action instead of TextualRepresentation SysML 2.0b1 open
SYSML2_-124 Feature modifiers missing in Portion Membership examples SysML 2.0b1 open
SYSML2_-125 Representative example "Package with members" to be improved SysML 2.0b1 open
SYSML2_-126 Decision/MergeNode SuccessionSpecialization checks missing some constraints SysML 2.0b1 open
SYSML2-353 Feature modifiers missing in Portion Membership examples SysML 2.0b1 open
SYSML2-357 Representative example "Package with members" to be improved SysML 2.0b1 open
SYSML2-383 Decision/MergeNode SuccessionSpecialization checks missing some constraints SysML 2.0b1 open
SYSML2_-120 Package import wildcard is missing SysML 2.0b1 open
SYSML2_-119 Wrong imported package notation SysML 2.0b1 open
SYSML2_-122 Incomplete example "Individual Occurrence" SysML 2.0b1 open
SYSML2_-123 Feature modefiers missing in Feature Membership examples SysML 2.0b1 open
SYSML2_-121 Representative notation for filtered package import missing SysML 2.0b1 open
SYSML2-327 Package import wildcard is missing SysML 2.0b1 open
SYSML2-326 Wrong imported package notation SysML 2.0b1 open
SYSML2-329 Representative notation for filtered package import missing SysML 2.0b1 open
SYSML2-337 Incomplete example "Individual Occurrence" SysML 2.0b1 open
SYSML2-352 Feature modefiers missing in Feature Membership examples SysML 2.0b1 open
SYSML2_-117 Nesting parameter symbol is missing optional nested parameter SysML 2.0b1 open
SYSML2_-115 Metadata declaration needs clarification SysML 2.0b1 open
SYSML2_-118 Missing representative notation for causation and requirements derivation SysML 2.0b1 open
SYSML2_-116 Binding between action parameters and directed features on ports missing SysML 2.0b1 open
SYSML2-320 Binding between action parameters and directed features on ports missing SysML 2.0b1 open
SYSML2-317 Metadata declaration needs clarification SysML 2.0b1 open
SYSML2-323 Nesting parameter symbol is missing optional nested parameter SysML 2.0b1 open
SYSML2-324 Missing representative notation for causation and requirements derivation SysML 2.0b1 open
SYSML2_-112 Mapping of ObjectFlows with JoinNodes SysML 2.0b1 open
SYSML2_-113 Mapping of ObjectFlows with DecisionNodes SysML 2.0b1 open
SYSML2-315 Mapping of ObjectFlows with DecisionNodes SysML 2.0b1 open
SYSML2-316 Symbol for metadata def is missing SysML 2.0b1 open
SYSML2-313 Mapping of ObjectFlows with ForkNodes SysML 2.0b1 open
SYSML2-314 Mapping of ObjectFlows with JoinNodes SysML 2.0b1 open
SYSML2_-108 Various constraints need to take feature chaining into account SysML 2.0b1 open
SYSML2_-110 Transformation does not cover the mapping of Unit and QuantityKind SysML 2.0b1 open
SYSML2_-109 Transformation does not cover mapping of Parameter::isStreaming=true SysML 2.0b1 open
SYSML2-311 Transformation does not cover the mapping of Unit and QuantityKind SysML 2.0b1 open
SYSML2-309 Transformation does not cover mapping of Parameter::isStreaming=true SysML 2.0b1 open
SYSML2-307 Various constraints need to take feature chaining into account SysML 2.0b1 open
KERML-245 KerML should have syntax for enumerations SysML 2.0b1 open
KERML_-53 KerML should have syntax for enumerations SysML 2.0b1 open
SYSML2-304 Mapping of ActivityEdge does not consider ActivityParameterNodes SysML 2.0b1 open
SYSML2-312 Typo: Table 19 - requirres SysML 2.0b1 open
SYSML2-328 Incorrect private keyword notation SysML 2.0b1 open
SYSML2-322 Nesting parameter symbols should use rounded rectangles SysML 2.0b1 open
SYSML2-330 Incorrect entry name representative notation SysML 2.0b1 open
SYSML2-319 Wrong line style on action flow succession SysML 2.0b1 open
SYSML2-335 Incorrect keyword in example "Attributes Compartment" SysML 2.0b1 open
SYSML2-334 Incorrect example "Relationships Compartment" SysML 2.0b1 open
SYSML2-338 Incomplete example "Occurrences Compartment" SysML 2.0b1 open
SYSML2-332 Incorrect example "Variant Membership" SysML 2.0b1 open
SYSML2-341 Compartments still show nested feature notation SysML 2.0b1 open
SYSML2-339 Unnecessarily complicated examples "Timeslices Compartment" and "Snapshots Compartment" SysML 2.0b1 open
SYSML2-344 Missing «perform action» in example "Part with Graphical Compartment with perform actions ..." SysML 2.0b1 open
SYSML2-340 Examples "Timeslices Compartment" and "Snapshots Compartment" incorrectly declare state feature SysML 2.0b1 open
SYSML2-345 Incorrect inherited notation in example "Connection" SysML 2.0b1 open
SYSML2-342 Misleading port name in example "Part with Ports" SysML 2.0b1 open
SYSML2-347 Wrong reference usage notation SysML 2.0b1 open
SYSML2-325 Wrong compartment name: documentation SysML 2.0b1 open
SYSML2-348 Incorrect item flow notation in example "Message" SysML 2.0b1 open
SYSML2-300 validateDefinitionNonVariationMembership and validateUsageNonVariationMembership are redundant with validateVariantMembershipOwningNamespace SysML 2.0b1 open
SYSML2-296 validateFramedConcernUsageConstraintKind constraint is misnamed SysML 2.0b1 open
SYSML2-298 validateDefinitionVariationMembership and validateUsageVariationMembership are too strict SysML 2.0b1 open
SYSML2-302 validateOccurrenceUsageIndividualDefinition OCL is wrong SysML 2.0b1 open
SYSML2-301 validateUsageOwningType constraint is too restrictive SysML 2.0b1 open
SYSML2-303 validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization OCL is wrong SysML 2.0b1 open
SYSML2-306 validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization constraints are too restrictive SysML 2.0b1 open
SYSML2-356 The OCL for the body of ConstraintUsage::namingFeature is incorrect SysML 2.0b1 open
SYSML2-414 checkTransitionUsageSourceBindingConnector text and OCL are different SysML 2.0b1 open
SYSML2-424 WhileLoopsActionusage title typos SysML 2.0b1 open
SYSML2-423 checkIfActionUsageSpecialization OCL specifiesFromLibrary typo SysML 2.0b1 open
SYSML2-418 Description of TimeEvent_Mapping is a note SysML 2.0b1 open
SYSML2-437 The transformation specification does not explicitly specify how to map a ValueType SysML 2.0b1 open
SYSML2-420 InformationFlow mapping classes should use GenericTo mapping classes SysML 2.0b1 open
SYSML2-416 Description of ChangeEvent_Mapping is a note SysML 2.0b1 open
SYSML2-432 Part properties with AggregationKind::none or shared are not mapped to PartUsage with isComposite=false SysML 2.0b1 open
SYSML2-446 Document how SysML v1 properties are mapped to SysML v2 SysML 2.0b1 open
SYSML2-299 validateDefinitionVariationSpecialization and validateUsageVariationSpecialization OCL is wrong SysML 2.0b1 open
SYSML2-443 Property_Mapping should map to ItemUsage and the class name is misleading SysML 2.0b1 open
SYSML2-441 Change the table header of the overview tables in the mapping class specification chapters SysML 2.0b1 open
SYSML2-439 UML4SysML::Class should be mapped to ItemDefinition SysML 2.0b1 open
SYSML2-425 LoopActionUsage descriptions refer to property not in metamodel SysML 2.0b1 open
SYSML2-343 Mistake in example "Part performs a reference action (action1) that references ..." SysML 2.0b1 open
SYSML2-331 Incomplete textual notation in example "Subsetting" SysML 2.0b1 open
SYSML2-422 GenericToItemDefinition_Mapping should specialize GenericToOccurrenceDefinition_Mapping SysML 2.0b1 open
SYSML2-412 SYSML2-180 uses non-existing general mapping class GenericToItemUsage_Mapping SysML 2.0b1 open
SYSML2-350 Incomplete flow notation in example "Flow as Node" SysML 2.0b1 open
SYSML2-346 Incorrect notation in example "Binding Connection" SysML 2.0b1 open
SYSML2-349 Incorrect item flow notation in example "Interface as Node" SysML 2.0b1 open
SYSML2-333 Incomplete textual notation in example "Variants Compartment" SysML 2.0b1 open
SYSML2-453 Text error in List property construction SysML 2.0b1 open
SYSML2-451 Missing production for ConjugatePortTyping SysML 2.0b1 open
SYSML2-452 misspelled ConjugatePortTyping should be ConjugatedPortTyping SysML 2.0b1 open
SYSML2-431 Incorrect EBNF specification SysML 2.0b1 open
SYSML2-454 PrefixComment should not be a production for AnnotatingElement SysML 2.0b1 open
SYSML2-467 RequirementConstraintUsage should not have a RequirementBody SysML 2.0b1 open
SYSML2-513 Missing text in some main mapping sections SysML 2.0b1 open
SYSML2-511 Remove sentence in StateMachines overview section SysML 2.0b1 open
SYSML2-509 Remove sentence in Classification overview section SysML 2.0b1 open
SYSML2-378 Sample::calculation has an incorrect type SysML 2.0b1 open
SYSML2-488 Constraints missing to enforce variations being abstract SysML 2.0b1 open
SYSML2-393 Documentation of Time::defaultClock is missing SysML 2.0b1 open
SYSML2-500 The derivation of AssignmentActionUsage::referent is wrong SysML 2.0b1 open
SYSML2-490 Actions::acceptSubactions and sendSubactions should subset acceptActions and sendActions SysML 2.0b1 open
SYSML2-498 validateTriggerInvocationExpressionWhenArgument constraint is wrong SysML 2.0b1 open
SYSML2-305 Message and flow connection ends should be occurrence usages SysML 2.0b1 open
SYSML2-497 validateTriggerInvocationExpressionAfterArgument constraint is too strong SysML 2.0b1 open
SYSML2-491 KerML constraint requires updates to Systems Library models SysML 2.0b1 open
SYSML2-495 Textual notation BNF for TriggerExpression is wrong SysML 2.0b1 open
SYSML2-336 Incorrect notation in example "Individual Occurrence" SysML 2.0b1 open
SYSML2-499 Assignments parsed without a target will fail validateAssignmentActionUsageArguments SysML 2.0b1 open
SYSML2-459 Resolution of approved issue SYSML2-241 is not considered by merged issue SYSML2-240 SysML 2.0b1 open
SYSML2-556 Typos in Quantities and Units Domain Library SysML 2.0b1 open
SYSML2-481 Use of the term 'Feature' SysML 2.0b1 open
SYSML2-351 Unnecessary event declaration in example "Message" SysML 2.0b1 open
SYSML2-578 Incorrect graphical notation for message between ports SysML 2.0b1 open
SYSML2-560 Add note on FlowFeature direction to textual notation grammar SysML 2.0b1 open
SYSML2-566 Section containing tables about elements not mapped should get an introductory text SysML 2.0b1 open
SYSML2-577 Incorrect graphical notation for flow connection SysML 2.0b1 open
SYSML2-582 Incorrect graphical notation for flow between actions SysML 2.0b1 open
SYSML2-579 Incorrect graphical notation for flow connections in Flow as Node SysML 2.0b1 open
SYSML2-583 Incorrect graphical notation for successions examples with actions SysML 2.0b1 open
SYSML2-581 Mistakes in example Interface as Node (with flow) SysML 2.0b1 open
SYSML2-611 OCL rule deriveDefinitionOwnedFlow references non-existent class called FlowUsage SysML 2.0b1 open
SYSML2-580 Incorrect and incomplete sequence view with message SysML 2.0b1 open
SYSML2-612 OCL rule deriveUsageNestedFlow references non-existent class called FlowUsage SysML 2.0b1 open
SYSML2-620 Textual notation production for Comment is wrong SysML 2.0b1 open
SYSML2-616 User-defined keywords are not allowed on control nodes SysML 2.0b1 open
SYSML2-529 OCL for deriveViewDefinitionViewCondition and deriveViewUsageViewCondition are wrong SysML 2.0b1 open
SYSML2-597 checkFlowConnectionUsageSpecialization is too restrictive about FlowConnections SysML 2.0b1 open
SYSML2-558 checkStateUsageSpecialization constraint is incorrect SysML 2.0b1 open
SYSML2-552 Errors in the TradeStudy domain model SysML 2.0b1 open
SYSML2-554 Enumeration definitions VerdictKind and VerificationMethodKind are missing from specification document SysML 2.0b1 open
SYSML2-318 Adornments on ends missing in graphical syntax SysML 2.0b1 open
SYSML2-430 Subsetting of subjectParameter properties is wrong SysML 2.0b1 open
SYSML2-426 specializesFromLibrary arguments use inconsistent notation for strings SysML 2.0b1 open
SYSML2-626 Incorrect textual notation for TextualRepresentation SysML 2.0b1 open
SYSML2-561 Intersection missing for some multiple specializations SysML 2.0b1 open
SYSML2-562 Tables in overview sections have empty cells SysML v2 column SysML 2.0b1 open
SYSML2-564 Mapping tables in the overview sections show duplicates in the SysML v2 column SysML 2.0b1 open
SYSML2-569 Rename ~InterfaceBlock_Mapping SysML 2.0b1 open
SYSML2-613 Constraint on Definition variation memberships is too restrictive SysML 2.0b1 open
SYSML2-615 Constraint on Usage variation memberships is too restrictive SysML 2.0b1 open
SYSML2-640 Find a better way to differ between definition and instance elements in graphical notation SysML 2.0b1 open
SYSML2-636 package View and Viewpoint TBD should not be included in the xmi file SysML 2.0b1 open
SYSML2-634 VerificationCase::subVerificationCases is typed incorrectly SysML 2.0b1 open
SYSML2-641 Do not use abbreviations for key word in SysML v2/KerML textual concrete syntax SysML 2.0b1 open
SYSML2-844 Annotation diagram needs to be updated SysML 2.0b1 open
SYSML2-631 User-defined keywords are not allowed on metadata SysML 2.0b1 open
SYSML2-642 Make orthogonal and rounded corners the default connector style for architectural drawings SysML 2.0b1 open
SYSML2-635 Issues with SysML grammar SysML 2.0b1 open
SYSML2-637 User-defined keywords are not allowed on enumeration definitions SysML 2.0b1 open
SYSML2-643 Comment locale not in textual notation SysML 2.0b1 open
SYSML2-553 checkRequirementUsageObjectiveRedefinition is incorrect SysML 2.0b1 open
SYSML2-783 Parsing KerML Feature elements from SysML textual notation SysML 2.0b1 open

Issues Descriptions

Flow connections are incorrectly both structure and behavior

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the KerML specification, "Structures and behaviors do not overlap". Consistent with this, the approved resolution to KERML-43 added validations to disallow a structure from specializing a behavior and vice versa.

    ConnectionDefinitions in SysML are kinds of PartDefinitions, which are (indirectly) kinds of KerML Structures. But FlowConnectionDefinitions are both ConnectionDefinitions and ActionDefinitions, and ActionDefinitions are kinds of KerML Behaviors. This means that FlowConnectionDefinitions are both Structures and Behaviors, violating the restrictions of KerML.

    As a result, the specializations in the declarations of MessageConnection and FlowConnection in the Systems Library model Connections now violate the new validateStructureSpecialization and validateBehaviorSpecialization constraints added by the resolution to KERML-43.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 17:04 GMT
  • Updated: Tue, 11 Jun 2024 19:04 GMT

Issues with SysML/KerML grammar

  • Key: SYSML2_-1
  • Status: open  
  • Source: itemis AG ( David Akehurst)
  • Summary:

    I raised a number of issues previously with regards to detailed/specific problems with the KerML textual syntax grammar.
    A more general issue is that I find the grammar (as written) hard to digest.
    It is not modular, and the chapters don't seem to relate fully to the Abstract Syntax packages.

    I have created an alternative grammar, using a different grammar-syntax, that allows for modular definition of grammars.
    I would like to offer you this.
    However, I cannot attach files to this issue!
    feel free to contact me if you would like me to provide them.

    In summary, one can modularise the KerML grammar into a Kernel, Core, Root (groups/packages)
    with each group/package containing 3-5 grammar modules and extension relationships to combine them.

    I plan to do the same for the full SysML grammar (later).

  • Reported: SysML 2.0b1 — Wed, 14 Feb 2024 11:32 GMT
  • Updated: Mon, 3 Jun 2024 21:27 GMT

incorrect naming of * character

  • Key: SYSML2_-2
  • Status: open  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Throughout the document, need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.

  • Reported: SysML 2.0b1 — Thu, 8 Feb 2024 18:16 GMT
  • Updated: Mon, 3 Jun 2024 21:24 GMT

Symbol for metadata def is missing

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add support for defining a metadata definition using the normal definition symbol (e.g., key word metadata def with metadata def name in name compartment). Separate compartment for attribute declarations. Add compartment redefined the annotated elements so they are constrained to be of a certain metaclass. (Note that MetadataDefinition is a kind of ItemDefinition but MetadataFeature (and therefore MetadataUsage) is a kind of AnnotatingElement.)

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:09 GMT
  • Updated: Mon, 3 Jun 2024 21:24 GMT

incorrect naming of * character

  • Key: SYSML2_-3
  • Status: open  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Throughout the document, we need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.

  • Reported: SysML 2.0b1 — Thu, 8 Feb 2024 18:14 GMT
  • Updated: Mon, 3 Jun 2024 21:24 GMT

Transformation of UML4SysML::State does not consider entry, do, and exit behavior

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation ignores the entry, do, and exit behavior of a state.

  • Reported: SysML 2.0b1 — Wed, 27 Sep 2023 21:38 GMT
  • Updated: Sat, 11 May 2024 08:45 GMT

Mapping of ObjectFlows with ForkNodes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In SysML v1, an output value of an action that is an input value of more than one action, is often modeled by an object flow and fork node which create object tokens pointing to the value.

    The mapping of ObjectFlow in combination with ForkNodes is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 13:16 GMT
  • Updated: Thu, 9 May 2024 15:12 GMT

Semantic constraints missing for shorthand succession notation

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:

    1. In 8.2.2.9.3 Occurrence Successions, the production SourceSuccession creates a SuccessionAsUsage that has a source end with no related feature and no target end.
    2. In 8.2.2.16.7 Action Successions, the production TargetSuccession creates a SuccessionAsUsage that has a source end as in SourceSuccession, but it has a full ConnectorEndMember for its target end, including an explicit related element.

    In both cases, the intent is that the implied related feature of the source end of the SuccessionAsUsage is a feature lexically previous to the declaration of the SuccessionAsUsage. In the first case, the implied related feature for the target end of the SuccessionAsUsage is a feature lexically following the SuccessionAsUsage. However, there are no semantic constraints given in 8.3.13.8 SuccessionAsUsage to enforce these implied relationships.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 17:12 GMT
  • Updated: Mon, 15 Apr 2024 18:45 GMT

Reuse of KerML textual notation productions in the SysML grammar

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The reuse of KerML BNF productions in the SysML textual notation grammar is not described sufficiently. It is not clear which productions are reused and which not. Reused productions are simply missing from the SysML definitions.

    (This issue was originally reported as part of SYSML2-635.)

  • Reported: SysML 2.0b1 — Fri, 19 Jan 2024 23:51 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Long-form notation for bindings and successions

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The genera textual notation for (binary) connections (see 8.2.2.13.1 Connection Definition and Usage) allows for both a "short form" (connect...to...;) and a "long form", in which the ends are explicitly declared within the connection body. The notations for binding connections (see 8.2.2.13.2 Binding Connectors) and successions (see 8.2.2.13.3 Successions) also have their own "short forms" (bind...=...; and first...then...;)). However, even though both notations allow for connection bodies, the short-form part is required, so it is not possible to declare the ends within the bodies. (Note that the corresponding KerML notations do allow fully "long form" declarations for bindings and successions; see 8.2.5.5.2 and 8.2.5.5.3 in the KerML specification.)

  • Reported: SysML 2.0b1 — Tue, 2 Jan 2024 20:04 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Change graphical notation for use cases to elliptic elements

  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    In the SysML v2 the graphical notation for use cases is a box with rounded corners containing the stereotype "use case" and the use case name.
    From the very beginning of UML and SysML v1.x use cases are visualized as elliptic elements. Nearly all people that have ever used or seen UML or SysML in the past are familiar with that notation. So why change it for SysML v2 here? It is not necessary from my perspective.
    A box with many textual things inside is not a good idea for a graphical language. Graphical languages should use as less text as possible. Instead they should use different graphical shapes, different stroke widths, stroke types and icons to express the semantics and what is modeled.
    A user should be able to recognize a diagram element on a first side, looking at a diagram drawing form far away. It should not be necessary to read all details to recognize that is a use case diagram and not any other diagram by reading the stereotype text elements first!

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 11:46 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Reuse of KerML textual notation productions in the SysML grammar

  • Key: SYSML2-686
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The reuse of KerML BNF productions in the SysML textual notation grammar is not described sufficiently. It is not clear which productions are reused and which not. Reused productions are simply missing from the SysML definitions.

    (This issue was originally reported as part of SYSML2-635.)

  • Reported: SysML 2.0b1 — Fri, 19 Jan 2024 23:51 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Long-form notation for bindings and successions

  • Key: SYSML2-632
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The genera textual notation for (binary) connections (see 8.2.2.13.1 Connection Definition and Usage) allows for both a "short form" (connect...to...;) and a "long form", in which the ends are explicitly declared within the connection body. The notations for binding connections (see 8.2.2.13.2 Binding Connectors) and successions (see 8.2.2.13.3 Successions) also have their own "short forms" (bind...=...; and first...then...;)). However, even though both notations allow for connection bodies, the short-form part is required, so it is not possible to declare the ends within the bodies. (Note that the corresponding KerML notations do allow fully "long form" declarations for bindings and successions; see 8.2.5.5.2 and 8.2.5.5.3 in the KerML specification.)

  • Reported: SysML 2.0b1 — Tue, 2 Jan 2024 20:04 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Change graphical notation for use cases to elliptic elements

  • Key: SYSML2-639
  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    In the SysML v2 the graphical notation for use cases is a box with rounded corners containing the stereotype "use case" and the use case name.
    From the very beginning of UML and SysML v1.x use cases are visualized as elliptic elements. Nearly all people that have ever used or seen UML or SysML in the past are familiar with that notation. So why change it for SysML v2 here? It is not necessary from my perspective.
    A box with many textual things inside is not a good idea for a graphical language. Graphical languages should use as less text as possible. Instead they should use different graphical shapes, different stroke widths, stroke types and icons to express the semantics and what is modeled.
    A user should be able to recognize a diagram element on a first side, looking at a diagram drawing form far away. It should not be necessary to read all details to recognize that is a use case diagram and not any other diagram by reading the stereotype text elements first!

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 11:46 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

PortUsage direction

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The direction of a PortUsage can be specified like that of any other feature. However, this does not really seem to make sense. The direction of a PortUsage should be determined by the direction of features within it, consistent with the visualization of directions on ports shown, e.g., in the Representative Notation table in 7.11.1 Parts Overview.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 18:15 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Enumerations not specializable

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [From Mr. Ryan Noguchi] In the SysML v2 spec, section 7.8.1:

    An enumeration definition may not specialize another enumeration definition. This is because the semantics of specialization require that the set of instances classified by a definition be a subset of the instances of classified by any definition it specializes. The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.

    To comply with the Liskov Substitution Principle, a specialization of an enumeration definition should only remove literals, not add them. Why can’t the specialization’s definition either simply remove existing literals from the general definition or list the applicable literals—resulting in a syntax error if this list includes anything not present in the general definition? As a concrete example:

    enum def ClassificationLevel {
       enum unclassified;
       enum cui;
       enum secret;
       enum top_secret;
    }
    
    enum def ClassificationLevelClassified :> ClassificationLevel {
        enum secret;
        enum top_secret;
    }
    
  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 17:49 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Enumerations not specializable

  • Key: SYSML2-593
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [From Mr. Ryan Noguchi] In the SysML v2 spec, section 7.8.1:

    An enumeration definition may not specialize another enumeration definition. This is because the semantics of specialization require that the set of instances classified by a definition be a subset of the instances of classified by any definition it specializes. The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.

    To comply with the Liskov Substitution Principle, a specialization of an enumeration definition should only remove literals, not add them. Why can’t the specialization’s definition either simply remove existing literals from the general definition or list the applicable literals—resulting in a syntax error if this list includes anything not present in the general definition? As a concrete example:

    enum def ClassificationLevel {
       enum unclassified;
       enum cui;
       enum secret;
       enum top_secret;
    }
    
    enum def ClassificationLevelClassified :> ClassificationLevel {
        enum secret;
        enum top_secret;
    }
    
  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 17:49 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Flow connections are incorrectly both structure and behavior

  • Key: SYSML2-592
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the KerML specification, "Structures and behaviors do not overlap". Consistent with this, the approved resolution to KERML-43 added validations to disallow a structure from specializing a behavior and vice versa.

    ConnectionDefinitions in SysML are kinds of PartDefinitions, which are (indirectly) kinds of KerML Structures. But FlowConnectionDefinitions are both ConnectionDefinitions and ActionDefinitions, and ActionDefinitions are kinds of KerML Behaviors. This means that FlowConnectionDefinitions are both Structures and Behaviors, violating the restrictions of KerML.

    As a result, the specializations in the declarations of MessageConnection and FlowConnection in the Systems Library model Connections now violate the new validateStructureSpecialization and validateBehaviorSpecialization constraints added by the resolution to KERML-43.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 17:04 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

PortUsage direction

  • Key: SYSML2-594
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The direction of a PortUsage can be specified like that of any other feature. However, this does not really seem to make sense. The direction of a PortUsage should be determined by the direction of features within it, consistent with the visualization of directions on ports shown, e.g., in the Representative Notation table in 7.11.1 Parts Overview.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 18:15 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Add a distinguished attribute to capture the textual body of a requirement

  • Status: open  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    A requirement should include a text body to capture the shall statement or other human readable requirement statement. The doc annotating element is one way to accomplish this. However, a doc element on a requirement definition is inherited by its requirement usages, but it cannot be redefined on its usage. (Note: The texts of a RequirementUsage are the bodies of the documentation of the RequirementUsage.)

    The proposal is to add a distinguished attribute to capture the text body of a requirement that would replace the derived text attribute/documentation. This distinguished attribute can be redefined. This avoids a requirement usage from having both the original text in the requirement definition and the modified text in the usage.

    The concrete syntax should be updated accordingly.

  • Reported: SysML 2.0b1 — Wed, 15 Nov 2023 17:41 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Add a distinguished attribute to capture the textual body of a requirement

  • Key: SYSML2-546
  • Status: open  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    A requirement should include a text body to capture the shall statement or other human readable requirement statement. The doc annotating element is one way to accomplish this. However, a doc element on a requirement definition is inherited by its requirement usages, but it cannot be redefined on its usage. (Note: The texts of a RequirementUsage are the bodies of the documentation of the RequirementUsage.)

    The proposal is to add a distinguished attribute to capture the text body of a requirement that would replace the derived text attribute/documentation. This distinguished attribute can be redefined. This avoids a requirement usage from having both the original text in the requirement definition and the modified text in the usage.

    The concrete syntax should be updated accordingly.

  • Reported: SysML 2.0b1 — Wed, 15 Nov 2023 17:41 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Semantic constraints missing for shorthand succession notation

  • Key: SYSML2-576
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:

    1. In 8.2.2.9.3 Occurrence Successions, the production SourceSuccession creates a SuccessionAsUsage that has a source end with no related feature and no target end.
    2. In 8.2.2.16.7 Action Successions, the production TargetSuccession creates a SuccessionAsUsage that has a source end as in SourceSuccession, but it has a full ConnectorEndMember for its target end, including an explicit related element.

    In both cases, the intent is that the implied related feature of the source end of the SuccessionAsUsage is a feature lexically previous to the declaration of the SuccessionAsUsage. In the first case, the implied related feature for the target end of the SuccessionAsUsage is a feature lexically following the SuccessionAsUsage. However, there are no semantic constraints given in 8.3.13.8 SuccessionAsUsage to enforce these implied relationships.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 17:12 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Textual notation for send actions is too limited

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the SysML Specification, 8.2.2.16.4 Send and Accept Actions, the general textual notation for a send action has the form

    send payloadExpression via senderExpression to receiverExpression

    In this syntax, the via and to parts are optional, but the payloadExpression is not. Since the result of the required payloadExpression is bound to the payload parameter of the send action, this makes it difficult to model a case in which, e.g., it is desired use a flow to provide the value of the payload, rather than the result of an expression. It also makes it difficult to model a general send action with the payload not specified (or defaulted), with the actual payload bound in a specialization of the general action.

    While it is possible to get around these limitations by modeling the send action using a regular action usage typed by Actions::SendAction, this is no longer syntactically a send action usage and so, e.g., would not be rendered as such in the graphical notation. It would be better if the textual notation allowed the payloadExpression to be optional, while still declaring syntactic send action usage.

  • Reported: SysML 2.0b1 — Wed, 8 Nov 2023 17:26 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Textual notation for send actions is too limited

  • Key: SYSML2-526
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    According to the SysML Specification, 8.2.2.16.4 Send and Accept Actions, the general textual notation for a send action has the form

    send payloadExpression via senderExpression to receiverExpression

    In this syntax, the via and to parts are optional, but the payloadExpression is not. Since the result of the required payloadExpression is bound to the payload parameter of the send action, this makes it difficult to model a case in which, e.g., it is desired use a flow to provide the value of the payload, rather than the result of an expression. It also makes it difficult to model a general send action with the payload not specified (or defaulted), with the actual payload bound in a specialization of the general action.

    While it is possible to get around these limitations by modeling the send action using a regular action usage typed by Actions::SendAction, this is no longer syntactically a send action usage and so, e.g., would not be rendered as such in the graphical notation. It would be better if the textual notation allowed the payloadExpression to be optional, while still declaring syntactic send action usage.

  • Reported: SysML 2.0b1 — Wed, 8 Nov 2023 17:26 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

OccurrenceUsage missing portioningFeature

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.5.2 (Occurrence Usages) says

    If an OccurrenceUsage has a non-null portionKind, then it is also required to have a portioningFeature with the same portionKind. The following semantic constraints apply to a PortioningFeature:
    ...

    and the code example at the end of 8.4.5.2 has comments identifying some features as "Portioning", with text below it referring to portioningFeature

    However, portioningFeature doesn't appear in Figure 12 (Occurrence Definition and Usage) or anywhere else in the document.

  • Reported: SysML 2.0b1 — Thu, 2 Nov 2023 14:26 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

OccurrenceUsage missing portioningFeature

  • Key: SYSML2-503
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.5.2 (Occurrence Usages) says

    If an OccurrenceUsage has a non-null portionKind, then it is also required to have a portioningFeature with the same portionKind. The following semantic constraints apply to a PortioningFeature:
    ...

    and the code example at the end of 8.4.5.2 has comments identifying some features as "Portioning", with text below it referring to portioningFeature

    However, portioningFeature doesn't appear in Figure 12 (Occurrence Definition and Usage) or anywhere else in the document.

  • Reported: SysML 2.0b1 — Thu, 2 Nov 2023 14:26 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Incorrect definition elements in interconnection-element

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Definition elements incorrectly appear in graphical BNF productions for interconnection-element. Remove the following from interconnection-element productions: part-def in 8.2.3.11, port-def in 8.2.3.12, connection-def in 8.2.3.13, constraint-def in 8.2.3.19, requirement-def and concern-def in 8.2.3.20, viewpoint-def and view-def in 8.2.3.25.

  • Reported: SysML 2.0b1 — Wed, 18 Oct 2023 13:46 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Incorrect definition elements in interconnection-element

  • Key: SYSML2-483
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Definition elements incorrectly appear in graphical BNF productions for interconnection-element. Remove the following from interconnection-element productions: part-def in 8.2.3.11, port-def in 8.2.3.12, connection-def in 8.2.3.13, constraint-def in 8.2.3.19, requirement-def and concern-def in 8.2.3.20, viewpoint-def and view-def in 8.2.3.25.

  • Reported: SysML 2.0b1 — Wed, 18 Oct 2023 13:46 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

AssociationClass_Mapping is uncomplete

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect

  • Reported: SysML 2.0b1 — Mon, 25 Sep 2023 19:16 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Initializer classes have to be rationalized

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The intent of "initializer" classes is to factorize the opeations that provide default values for the properties of a target class so that it can be used for both mapping and factory classes. Initializers that do not generalize both a mapping and a factory class are useless and should be remove for clarity

  • Reported: SysML 2.0b1 — Mon, 25 Sep 2023 18:28 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Initializer classes have to be rationalized

  • Key: SYSML2-476
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The intent of "initializer" classes is to factorize the opeations that provide default values for the properties of a target class so that it can be used for both mapping and factory classes. Initializers that do not generalize both a mapping and a factory class are useless and should be remove for clarity

  • Reported: SysML 2.0b1 — Mon, 25 Sep 2023 18:28 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

AssociationClass_Mapping is uncomplete

  • Key: SYSML2-477
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect

  • Reported: SysML 2.0b1 — Mon, 25 Sep 2023 19:16 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Concern_Mapping is a main mapping that calls ConcernOwningMemberships_Mapping in its ownedRelationship() operation, which itself calls ConcernDocumentation_Mapping. However, the one defined in its ancestor Comment_Mapping should do the job without them.
    The redefinition should then be removed and both ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless and should be replace by a simpler version of the ownedRelationship() operation.

  • Reported: SysML 2.0b1 — Thu, 14 Sep 2023 16:56 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Optional language for documentation

  • Status: open  
  • Source: Robert Bosch GmbH ( Florian Beer)
  • Summary:

    Informal specification of requirements is realized as body of the documentation.
    Informal requirement specification often contains text formatting and images as illustrations. To facilitate exchange of requirements between different organizations and proper rendering, the used formatting language, the relative root path for included images and their allowed formats have to be aligned.

    • add optional 'language' keyword to doc
    • define the folder containing the sysml file as root for references made from documentation elements within this file

    To provide guidance for users on common formatting

    • reference jpg and png as suggested image formats
    • reference markdown "md" or other low-complex language as suggested formatting language

    example:
    requirement def SomeRequirement

    { doc language="md" /* The imprint of the serial number shall be positioned as shown in the illustration ![PositionOfSerialNumber](/images/PositionOfSerialNumber.png) */ }
  • Reported: SysML 2.0b1 — Mon, 2 Oct 2023 10:36 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Optional language for documentation

  • Key: SYSML2-472
  • Status: open  
  • Source: Robert Bosch GmbH ( Florian Beer)
  • Summary:

    Informal specification of requirements is realized as body of the documentation.
    Informal requirement specification often contains text formatting and images as illustrations. To facilitate exchange of requirements between different organizations and proper rendering, the used formatting language, the relative root path for included images and their allowed formats have to be aligned.

    • add optional 'language' keyword to doc
    • define the folder containing the sysml file as root for references made from documentation elements within this file

    To provide guidance for users on common formatting

    • reference jpg and png as suggested image formats
    • reference markdown "md" or other low-complex language as suggested formatting language

    example:
    requirement def SomeRequirement

    { doc language="md" /* The imprint of the serial number shall be positioned as shown in the illustration ![PositionOfSerialNumber](/images/PositionOfSerialNumber.png) */ }
  • Reported: SysML 2.0b1 — Mon, 2 Oct 2023 10:36 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

Transformation of UML4SysML::State does not consider entry, do, and exit behavior

  • Key: SYSML2-463
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation ignores the entry, do, and exit behavior of a state.

  • Reported: SysML 2.0b1 — Wed, 27 Sep 2023 21:38 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless

  • Key: SYSML2-473
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Concern_Mapping is a main mapping that calls ConcernOwningMemberships_Mapping in its ownedRelationship() operation, which itself calls ConcernDocumentation_Mapping. However, the one defined in its ancestor Comment_Mapping should do the job without them.
    The redefinition should then be removed and both ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless and should be replace by a simpler version of the ownedRelationship() operation.

  • Reported: SysML 2.0b1 — Thu, 14 Sep 2023 16:56 GMT
  • Updated: Wed, 10 Apr 2024 00:42 GMT

TimeEvent should be mapped to an accept action instead of TextualRepresentation

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the textual notation, a time event can be represented by an accept action with an at or after condition. The example below is from the vehicle model.
    transition normal_To_maintenance
    first normal
    accept at maintenanceTime
    then maintenance;

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 11:42 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

ChangeEvent should be mapped to an accept action instead of TextualRepresentation

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the textual notation, a change event can be represented by an accept action with a when condition. The example below is from the vehicle model.
    transition normal_To_degraded
    first normal
    accept when senseTemperature.temp > Tmax
    do send OverTemp() via targetPort
    then degraded;

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 11:35 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Fork/JoinNode succession "other" end multiplicity validations missing

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.12.4 (Control Nodes), under the Join and Fork headings says:

    validateJoinNodeIncomingSuccessions constraint requires that all incoming Successions to a JoinNode have source multiplicity 1..1.

    validateForkNodeOutgoingSuccessions requires that all outgoing Successions from a ForkNode have target multiplicity 1..1.

    but the validation rules are missing from 8.3.16.11 (JoinNode) and 8.3.16.8 (ForkNode), respectively.

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 15:26 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

ConstraintProperty should be mapped to a AssertConstraintUsage

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.

  • Reported: SysML 2.0b1 — Sun, 10 Sep 2023 16:27 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

TransitionUsage requires binding to succession with mandatory end multiplicities

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 7.13.3 (Bindings as Usages) says

    The end features of a binding always have multiplicity [1..1].

    and Clause 8.3.17.9 (TransitionUsage) includes a constraint requiring a (1 to 1) binding between its succession and transitionLink:

    checkTransitionUsageSuccessionBindingConnector
    A TransitionUsage must have an ownedMember that is a BindingConnector between its succession and the
    inherited Feature TransitionPerformances::TransitionPerformance::transitionLink.
    ownedMember->selectByKind(BindingConnector)->exists(b |
    b.relatedFeatures->includes(succession) and
    b.relatedFeatures->includes(resolveGlobal(
    'TransitionPerformances::TransitionPerformance::transitionLink')))

    with similar text in 8.4.13.3 (Transition Usages). A succession will typically have fewer values than its transition usage, because the succession won't be traversed for every value (occurrence) of its source feature, while its transition usage will have the same number of values as the source feature, conflicting with the 1-1 end multiplicities. Compare to the modeling pattern in KerML Clause 9.2.10.1 (Transition Performances Overview), excerpted in KERML-157.

  • Reported: SysML 2.0b1 — Fri, 25 Aug 2023 19:22 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

ConstraintProperty should be mapped to a AssertConstraintUsage

  • Key: SYSML2-445
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.

  • Reported: SysML 2.0b1 — Sun, 10 Sep 2023 16:27 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

TransitionUsage requires binding to succession with mandatory end multiplicities

  • Key: SYSML2-397
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 7.13.3 (Bindings as Usages) says

    The end features of a binding always have multiplicity [1..1].

    and Clause 8.3.17.9 (TransitionUsage) includes a constraint requiring a (1 to 1) binding between its succession and transitionLink:

    checkTransitionUsageSuccessionBindingConnector
    A TransitionUsage must have an ownedMember that is a BindingConnector between its succession and the
    inherited Feature TransitionPerformances::TransitionPerformance::transitionLink.
    ownedMember->selectByKind(BindingConnector)->exists(b |
    b.relatedFeatures->includes(succession) and
    b.relatedFeatures->includes(resolveGlobal(
    'TransitionPerformances::TransitionPerformance::transitionLink')))

    with similar text in 8.4.13.3 (Transition Usages). A succession will typically have fewer values than its transition usage, because the succession won't be traversed for every value (occurrence) of its source feature, while its transition usage will have the same number of values as the source feature, conflicting with the 1-1 end multiplicities. Compare to the modeling pattern in KerML Clause 9.2.10.1 (Transition Performances Overview), excerpted in KERML-157.

  • Reported: SysML 2.0b1 — Fri, 25 Aug 2023 19:22 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Fork/JoinNode succession "other" end multiplicity validations missing

  • Key: SYSML2-450
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.12.4 (Control Nodes), under the Join and Fork headings says:

    validateJoinNodeIncomingSuccessions constraint requires that all incoming Successions to a JoinNode have source multiplicity 1..1.

    validateForkNodeOutgoingSuccessions requires that all outgoing Successions from a ForkNode have target multiplicity 1..1.

    but the validation rules are missing from 8.3.16.11 (JoinNode) and 8.3.16.8 (ForkNode), respectively.

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 15:26 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

TimeEvent should be mapped to an accept action instead of TextualRepresentation

  • Key: SYSML2-449
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the textual notation, a time event can be represented by an accept action with an at or after condition. The example below is from the vehicle model.
    transition normal_To_maintenance
    first normal
    accept at maintenanceTime
    then maintenance;

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 11:42 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

ChangeEvent should be mapped to an accept action instead of TextualRepresentation

  • Key: SYSML2-448
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the textual notation, a change event can be represented by an accept action with a when condition. The example below is from the vehicle model.
    transition normal_To_degraded
    first normal
    accept when senseTemperature.temp > Tmax
    do send OverTemp() via targetPort
    then degraded;

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 11:35 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Feature modifiers missing in Portion Membership examples

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 15:37 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Representative example "Package with members" to be improved

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The representative notation example "Package with members compartment" shows the members compartment which is the default compartment and does not require a compartment label. Change members compartment label to the requirements compartment label and adjust the package content and textual notation accordingly, i.e. with requirement elements.

  • Reported: SysML 2.0b1 — Thu, 3 Aug 2023 20:39 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Decision/MergeNode SuccessionSpecialization checks missing some constraints

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Decision/MergeNodes are (indirectly) typed by KerML:Decision/MergePerformance (via specialization of Actions::Action::decisions/merges), which KerML Clause 9.2.9.1 (Control Performances Overview) requires:

    Successions going out of Steps typed by DecisionPerformance or its specializations must:
    • ...
    • be included in a Feature of its featuringBehavior that unions (see 7.3.2.7) all the outgoing Successions, and is bound to the outgoingHBLink of the Step (see 7.3.4.6 on feature chaining).

    Successions coming into Steps typed by MergePerformance or its specializations must:
    • ...
    • subset a Feature of its featuringBehavior that unions all the incoming Successions, and is bound to the incomingHBLink of the Step.

    while constraints in 8.3.16.7 (DecisionNode) and 8.3.16.13 (MergeNode) say

    checkDecisionNodeOutgoingSuccessionSpecialization
    All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode.
    sourceConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
    resolveGlobal("ControlPerformances::MergePerformance::outgoingHBLink")))

    checkMergeNodeIncomingSuccessionSpecialization
    All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode.
    targetConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
    resolveGlobal("ControlPerformances::MergePerformance::incomingHBLink")))

    with similar text in 8.4.12.4 (Control Nodes) under Decision / Merge Nodes. These constraints allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The KerML pattern above introduces a feature unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions. See Annex A.3.7 (Timing for behaviors, Decisions and merges) for an example, at the end of the model to be executed (first code listing), under "Decision and merge timing constraints".

  • Reported: SysML 2.0b1 — Wed, 16 Aug 2023 17:21 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Feature modifiers missing in Portion Membership examples

  • Key: SYSML2-353
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 15:37 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Representative example "Package with members" to be improved

  • Key: SYSML2-357
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The representative notation example "Package with members compartment" shows the members compartment which is the default compartment and does not require a compartment label. Change members compartment label to the requirements compartment label and adjust the package content and textual notation accordingly, i.e. with requirement elements.

  • Reported: SysML 2.0b1 — Thu, 3 Aug 2023 20:39 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Decision/MergeNode SuccessionSpecialization checks missing some constraints

  • Key: SYSML2-383
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Decision/MergeNodes are (indirectly) typed by KerML:Decision/MergePerformance (via specialization of Actions::Action::decisions/merges), which KerML Clause 9.2.9.1 (Control Performances Overview) requires:

    Successions going out of Steps typed by DecisionPerformance or its specializations must:
    • ...
    • be included in a Feature of its featuringBehavior that unions (see 7.3.2.7) all the outgoing Successions, and is bound to the outgoingHBLink of the Step (see 7.3.4.6 on feature chaining).

    Successions coming into Steps typed by MergePerformance or its specializations must:
    • ...
    • subset a Feature of its featuringBehavior that unions all the incoming Successions, and is bound to the incomingHBLink of the Step.

    while constraints in 8.3.16.7 (DecisionNode) and 8.3.16.13 (MergeNode) say

    checkDecisionNodeOutgoingSuccessionSpecialization
    All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode.
    sourceConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
    resolveGlobal("ControlPerformances::MergePerformance::outgoingHBLink")))

    checkMergeNodeIncomingSuccessionSpecialization
    All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode.
    targetConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
    resolveGlobal("ControlPerformances::MergePerformance::incomingHBLink")))

    with similar text in 8.4.12.4 (Control Nodes) under Decision / Merge Nodes. These constraints allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The KerML pattern above introduces a feature unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions. See Annex A.3.7 (Timing for behaviors, Decisions and merges) for an example, at the end of the model to be executed (first code listing), under "Decision and merge timing constraints".

  • Reported: SysML 2.0b1 — Wed, 16 Aug 2023 17:21 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Package import wildcard is missing

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add import qualifier text (* or **) to upper right corner of imported Package

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Wrong imported package notation

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:57 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Incomplete example "Individual Occurrence"

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Feature modefiers missing in Feature Membership examples

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 15:35 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Representative notation for filtered package import missing

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add example package with filter in 7.5.1. The filter should be one of the filters defined in 9.2.19.2.4. Good choice is filter for Requirement.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:10 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Package import wildcard is missing

  • Key: SYSML2-327
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add import qualifier text (* or **) to upper right corner of imported Package

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:58 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Wrong imported package notation

  • Key: SYSML2-326
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:57 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Representative notation for filtered package import missing

  • Key: SYSML2-329
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add example package with filter in 7.5.1. The filter should be one of the filters defined in 9.2.19.2.4. Good choice is filter for Requirement.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:10 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Incomplete example "Individual Occurrence"

  • Key: SYSML2-337
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:17 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Feature modefiers missing in Feature Membership examples

  • Key: SYSML2-352
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 15:35 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Nesting parameter symbol is missing optional nested parameter

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Metadata declaration needs clarification

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Clarify that the identifier for the metadata declaration is the metadata definition name.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing representative notation for causation and requirements derivation

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add representative notation for causation (9.5.2.1) and requirements derivation (9.6.2.1) including n-arys. This (and other representative notation examples for domain library models) should probably go into the respective 9.x Overview subclauses, rather than in Clause 7.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:33 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Binding between action parameters and directed features on ports missing

  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add graphical notation to represent binding between action inputs and outputs and directed features on ports.

    The request is to add a representative notation example to Table 11 that shows how directed features of performed actions in parts can be connected to directed features of ports.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:14 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Binding between action parameters and directed features on ports missing

  • Key: SYSML2-320
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add graphical notation to represent binding between action inputs and outputs and directed features on ports.

    The request is to add a representative notation example to Table 11 that shows how directed features of performed actions in parts can be connected to directed features of ports.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:14 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Metadata declaration needs clarification

  • Key: SYSML2-317
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Clarify that the identifier for the metadata declaration is the metadata definition name.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:11 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Nesting parameter symbol is missing optional nested parameter

  • Key: SYSML2-323
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Missing representative notation for causation and requirements derivation

  • Key: SYSML2-324
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add representative notation for causation (9.5.2.1) and requirements derivation (9.6.2.1) including n-arys. This (and other representative notation examples for domain library models) should probably go into the respective 9.x Overview subclauses, rather than in Clause 7.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:33 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of ObjectFlows with JoinNodes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ObjectFlow in combination with JoinNodes is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 14:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of ObjectFlows with DecisionNodes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 14:47 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of ObjectFlows with DecisionNodes

  • Key: SYSML2-315
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 14:47 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Symbol for metadata def is missing

  • Key: SYSML2-316
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Add support for defining a metadata definition using the normal definition symbol (e.g., key word metadata def with metadata def name in name compartment). Separate compartment for attribute declarations. Add compartment redefined the annotated elements so they are constrained to be of a certain metaclass. (Note that MetadataDefinition is a kind of ItemDefinition but MetadataFeature (and therefore MetadataUsage) is a kind of AnnotatingElement.)

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:09 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of ObjectFlows with ForkNodes

  • Key: SYSML2-313
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In SysML v1, an output value of an action that is an input value of more than one action, is often modeled by an object flow and fork node which create object tokens pointing to the value.

    The mapping of ObjectFlow in combination with ForkNodes is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 13:16 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Mapping of ObjectFlows with JoinNodes

  • Key: SYSML2-314
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of ObjectFlow in combination with JoinNodes is not covered yet by the transformation.

  • Reported: SysML 2.0b1 — Mon, 24 Jul 2023 14:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Various constraints need to take feature chaining into account

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    There are a number of cases in which derived properties require that a referenced feature by of a certain metaclass. For example, the EventOccurrenceUsage::eventOccurrence property is derived as the referencedFeature of the ownedReferenceSubsetting EventOccurrenceUsage (if it has one), but the property is typed as an OccurrenceUsage, so the referencedFeature must be an OccurrenceUsage. This is enforced by the validateEventOccurrenceUsageReference constraint.

    Unfortunately, this does not take feature chaining into account. If the referencedFeature has a feature chain, it will be parsed as a plain Feature, not an OccurrenceUsage. However, the last Feature in the chain should be an OccurrenceUsage, and this OccurrenceUsage is what should be the eventOccurrence of the EventOccurrenceUsage, and what is check by validateEventOccurrenceUsageReference.

    There are similar problems with at least the "reference" derivation and validation constraints for all the subtypes of EventOccurrenceUsage, and perhaps in other cases, too.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 21:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover the mapping of Unit and QuantityKind

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of a Unit and a QuantityKind is not covered by the transformation yet.

  • Reported: SysML 2.0b1 — Thu, 20 Jul 2023 15:04 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT
  • Attachments:

Transformation does not cover mapping of Parameter::isStreaming=true

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not map the Parameter::isStreaming.

  • Reported: SysML 2.0b1 — Tue, 18 Jul 2023 17:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Transformation does not cover the mapping of Unit and QuantityKind

  • Key: SYSML2-311
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of a Unit and a QuantityKind is not covered by the transformation yet.

  • Reported: SysML 2.0b1 — Thu, 20 Jul 2023 15:04 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT
  • Attachments:

Transformation does not cover mapping of Parameter::isStreaming=true

  • Key: SYSML2-309
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The transformation does not map the Parameter::isStreaming.

  • Reported: SysML 2.0b1 — Tue, 18 Jul 2023 17:12 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

Various constraints need to take feature chaining into account

  • Key: SYSML2-307
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    There are a number of cases in which derived properties require that a referenced feature by of a certain metaclass. For example, the EventOccurrenceUsage::eventOccurrence property is derived as the referencedFeature of the ownedReferenceSubsetting EventOccurrenceUsage (if it has one), but the property is typed as an OccurrenceUsage, so the referencedFeature must be an OccurrenceUsage. This is enforced by the validateEventOccurrenceUsageReference constraint.

    Unfortunately, this does not take feature chaining into account. If the referencedFeature has a feature chain, it will be parsed as a plain Feature, not an OccurrenceUsage. However, the last Feature in the chain should be an OccurrenceUsage, and this OccurrenceUsage is what should be the eventOccurrence of the EventOccurrenceUsage, and what is check by validateEventOccurrenceUsageReference.

    There are similar problems with at least the "reference" derivation and validation constraints for all the subtypes of EventOccurrenceUsage, and perhaps in other cases, too.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 21:30 GMT
  • Updated: Wed, 10 Apr 2024 00:41 GMT

KerML should have syntax for enumerations

  • Key: KERML-245
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    SysML v2 includes syntax for enumeration definitions and usages. The semantics for enumerations are based on the general variation/variant semantics in SysML v2, which is itself based on KerML semantics. However, there currently is no syntax for enumerations in KerML. In particular, this leads to an awkward mapping in 9.2.17 KerML of MOF enumerations to KerML data types without specific syntax for enumeration.

    Enumerations are the only modeling element in the CMOF subset of UML that does not have a clear mapping to a KerML element. Especially as KerML is considered further for use as the basis of other languages, including their reflective abstract syntaxes, it would be better if enumeration syntax was codified in KerML. This would also make it easier to incorporate enumerations consistently into SysML v2 and future KerML-based languages themselves.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 16:02 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

KerML should have syntax for enumerations

  • Key: KERML_-53
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    SysML v2 includes syntax for enumeration definitions and usages. The semantics for enumerations are based on the general variation/variant semantics in SysML v2, which is itself based on KerML semantics. However, there currently is no syntax for enumerations in KerML. In particular, this leads to an awkward mapping in 9.2.17 KerML of MOF enumerations to KerML data types without specific syntax for enumeration.

    Enumerations are the only modeling element in the CMOF subset of UML that does not have a clear mapping to a KerML element. Especially as KerML is considered further for use as the basis of other languages, including their reflective abstract syntaxes, it would be better if enumeration syntax was codified in KerML. This would also make it easier to incorporate enumerations consistently into SysML v2 and future KerML-based languages themselves.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 16:02 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Mapping of ActivityEdge does not consider ActivityParameterNodes

  • Key: SYSML2-304
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The SysML v1 to v2 transformation does not map ActivityParameterNode, but only the references Parameter. The mapping of ActivityEdge must map the ends of the edge, which are connected to an ActivityParameterNode to the target element of the mapping of the Parameter.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 10:57 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Typo: Table 19 - requirres

  • Key: SYSML2-312
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 19, Requirement, compartment for require constraints:

    Typo in compartment headline should be "require constraints" => "requirre"

  • Reported: SysML 2.0b1 — Sun, 23 Jul 2023 19:11 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Incorrect private keyword notation

  • Key: SYSML2-328
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Package with imported packages (nested packages)" should have «private» enclosed by guillemets

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Nesting parameter symbols should use rounded rectangles


Incorrect entry name representative notation

  • Key: SYSML2-330
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Usage Definition" should be labeled "Part defined by Part Definition"

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:11 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Wrong line style on action flow succession

  • Key: SYSML2-319
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    A succession relationship on an action flow should be a solid line with an open arrow head. In 7.16.1 in example "Accept and Send Action Flow". Check for other locations.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:13 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Incorrect keyword in example "Attributes Compartment"

  • Key: SYSML2-335
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Attributes Compartment" textual notation should use nonunique instead of unique.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:16 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect example "Relationships Compartment"



Incorrect example "Variant Membership"

  • Key: SYSML2-332
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Variant Membership" the variants should be defined by Part1a and Part1b respectively. Currently they are both defined by Part1.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:12 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Compartments still show nested feature notation

  • Key: SYSML2-341
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Remove nested features (textual) notation from compartments in graphical symbols in all Representative Notation tables where they occur. This capability was discarded.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:24 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Unnecessarily complicated examples "Timeslices Compartment" and "Snapshots Compartment"


Missing «perform action» in example "Part with Graphical Compartment with perform actions ..."


Examples "Timeslices Compartment" and "Snapshots Compartment" incorrectly declare state feature

  • Key: SYSML2-340
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In examples "Timeslices Compartment" and "Snapshots Compartment" remove state state1 feature, since it is confusing, and potentially incorrect.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:20 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect inherited notation in example "Connection"

  • Key: SYSML2-345
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Connection" (1) remove circumflex on end1 and end2, since they are (implicitly) redefinitions of the ends from the connection definition, not inherited features.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:29 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Misleading port name in example "Part with Ports"


Wrong reference usage notation

  • Key: SYSML2-347
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Replace nested reference usage notation with dotted outline notation. Add BNF production for this notation.
    Reference usage notation is used in interconnection diagrams, and potentially action flow diagram. The solution is to add explicit production for dotted usages of parts, constraints, and requirements references and include those production in interconnection diagrams. Create productions of action usage references and add them to action flow.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:37 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Wrong compartment name: documentation

  • Key: SYSML2-325
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Documentation Compartment", the documentation keyword should read doc

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:56 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT


validateDefinitionNonVariationMembership and validateUsageNonVariationMembership are redundant with validateVariantMembershipOwningNamespace

  • Key: SYSML2-300
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraints validateDefinitionNonVariationMembership and validateUsageNonVariationMembership check that a non-variation Definition or Usage owns no VariantMemberships. However, validateVariantMembershipOwningNamespace already checks that the membershipOwningNamespace of a VariantMembership is a variation, so the other constraints are redundant.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 16:23 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateFramedConcernUsageConstraintKind constraint is misnamed

  • Key: SYSML2-296
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraint validateFramedConcernUsageConstraintKind is owned by FramedConcernMembership, not FramedConcernUsage (which doesn't exist). Therefore, the constraint should be named validateFramedConcernMembershipConstraintKind.

  • Reported: SysML 2.0b1 — Thu, 13 Jul 2023 02:38 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateDefinitionVariationMembership and validateUsageVariationMembership are too strict

  • Key: SYSML2-298
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraints validateDefinitionVariationMembership and validationUsageVariationMembership require that all the owned members of a variation definition or usage be variant members. This is too strong:

    • It disallows any variation Usage from having a Multiplicity, because that is a non-variant owned member of the Usage.
    • It disallows a variation PortDefinition from having a required ConjugatedPortDefinition, because that is a non-variant owned member of the definition.
  • Reported: SysML 2.0b1 — Thu, 13 Jul 2023 20:20 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateOccurrenceUsageIndividualDefinition OCL is wrong

  • Key: SYSML2-302
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The OCL for the constraint validateOccurrenceUsageIndividualDefinition is

    occurrenceDefinition->select(isIndividual).size() <= 1
    

    However, the type of OccurrenceUsage::occurrenceDefinition is actually Class, not OccurrenceDefinition, but the property isIndividual is only defined on OccurrenceDefinition.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 18:26 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateUsageOwningType constraint is too restrictive

  • Key: SYSML2-301
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraint validateUsageOwningType constrains the owningType of a Usage to be a Definition or Usage. However, this is two restrictive, because it prevents, e.g., a Usage from being declared within a body expression (as used with collect, select, etc.), which is a KerML Expression.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 16:26 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization OCL is wrong

  • Key: SYSML2-303
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The OCL for the constraints validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization both use ownedGeneralization (which doesn't exist) instead of ownedSpecialization.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 19:23 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization constraints are too restrictive

  • Key: SYSML2-306
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization prohibit parallel state definitions and usages from owning specializations of non-parallel state definitions and usages (and vice versa). However, this would prevent even, e.g., an empty non-parallel state definition from having a usage that was parallel, for example:

    state def S;
    state s : S parallel {  // validation error!
        state s1;
        state s2;
    }
    

    Further, it is also a validation error for a parallel state definition to explicitly specialized the base state definition StateAction (which is not parallel), even though an implicit specialization is not checked:

    state def S1 parallel { } // legal, implicitly specializes StateAction
    state def S2 :> States::StateAction parallel { } // validation error!
    

    For consistency, it would seem that, at least, a parallel state definition or usage should be able to explicitly specialize a non-parallel one. But perhaps the constraints are really not semantically necessary at all.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 21:17 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

The OCL for the body of ConstraintUsage::namingFeature is incorrect

  • Key: SYSML2-356
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The body OCL for the namingFeature operation of ConstraintUsage references ownedFeatureMembership. This should instead be owningFeatureMembership.

  • Reported: SysML 2.0b1 — Thu, 3 Aug 2023 14:22 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

checkTransitionUsageSourceBindingConnector text and OCL are different

  • Key: SYSML2-414
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In 8.3.17.9 (TransitionUsage), the text for checkTransitionUsageSourceBindingConnector requires binding of the first input parameter

    A TransitionUsage must have an ownedMember that is a BindingConnector between its source and its first input parameter (which redefines Actions::TransitionAction::transitionLinkSource).

    while the OCL gives it as binding the second parameter

    ownedMember->selectByKind(BindingConnector)->exists(b |
    b.relatedFeatures->includes(source) and
    b.relatedFeatures->includes(inputParameter(2)))

  • Reported: SysML 2.0b1 — Tue, 29 Aug 2023 18:07 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

WhileLoopsActionusage title typos

  • Key: SYSML2-424
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The title of 8.3.16.18 is WhileLoopsActionusage, with plural "Loops" and lower case "u", but in Figure 28 (Structured Control Actions) these are singular and capitalized, respectively.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 14:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

checkIfActionUsageSpecialization OCL specifiesFromLibrary typo

  • Key: SYSML2-423
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In 8.3.16.10 (IfActionUsage), the OCL for checkIfActionUsageSpecialization refers to specifiesFromLibrary instead of specializesFromLibrary.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 14:51 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Description of TimeEvent_Mapping is a note

  • Key: SYSML2-418
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description of the TimeEvent_Mapping class is a note from the development team instead of a description text.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 10:34 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

The transformation specification does not explicitly specify how to map a ValueType

  • Key: SYSML2-437
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping of a ValueType is identical to the mapping of a DataType. Therefore, there is no explicit mapping class for ValueType. However, that hides the information of the mapping of ValueTypes in the transformation specification.

  • Reported: SysML 2.0b1 — Fri, 8 Sep 2023 16:08 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

InformationFlow mapping classes should use GenericTo mapping classes

  • Key: SYSML2-420
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The mapping classes InformationFlowEnd_Mapping, InformationFlowFeatureTyping_Mapping, and InformationFlowEndFeatureMembership_Mapping updated by SYSML2-180 should use more specialized GenericTo mapping classes instead of the GenericToElement_Mapping class:

    InformationFlowEnd_Mapping => GenericToFeature_Mapping
    InformationFlowFeatureTyping_Mapping => GenericToFeatureTyping_Mapping
    InformationFlowEndFeatureMembership_Mapping => GenericToFeatureMembership_Mapping

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 11:32 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Description of ChangeEvent_Mapping is a note

  • Key: SYSML2-416
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description of the ChangeEvent_Mapping class is a note from the development team instead of a description text.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 10:31 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Part properties with AggregationKind::none or shared are not mapped to PartUsage with isComposite=false

  • Key: SYSML2-432
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Part properties with AggregationKind::none or shared are mapped to Feature, but should be a PartUsage with isComposite=false.

  • Reported: SysML 2.0b1 — Fri, 8 Sep 2023 15:23 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Document how SysML v1 properties are mapped to SysML v2

  • Key: SYSML2-446
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The SysML v1 properties like part property, are concepts, but not stereotypes or metamodel elements. Therefore, they are explicitly covered by a mapping class or are listed in the overview tables.

    Add a documentation in section 7.8.4.1 that describes how the different SysML v1 property concepts are mapped to SysML v2.

  • Reported: SysML 2.0b1 — Sun, 10 Sep 2023 16:32 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateDefinitionVariationSpecialization and validateUsageVariationSpecialization OCL is wrong

  • Key: SYSML2-299
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The OCL for both of the constraints validateDefinitionVariationSpecialization and validateUsageVariationSpecialization is:

    isVariation implies
        not ownedSpecialization.specific->exists(isVariation)
    

    These constraints should be checking Specialization::general, not Specialization::specific. In addition, the type of both specific and general is Type, which doesn't have an isVariation property. Only Definition and Usage types have such a property.

  • Reported: SysML 2.0b1 — Fri, 14 Jul 2023 15:50 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Property_Mapping should map to ItemUsage and the class name is misleading

  • Key: SYSML2-443
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Property_Mapping maps properties typed by a Class or Interface. The target element should be ItemUsage instead of Feature.

    The name of the mapping class is misleading. It creates the impression that it maps all kinds of properties, but it only covers the cases where a Class or Interface types properties. Rename the mapping class to PropertyTypedByClassInterface_Mapping.

    The specialized mapping classes ConstraintParameter_Mapping, Port_Mapping, and Part_Mapping should specialize PropertyCommon_Mapping instead of Property_Mapping.

  • Reported: SysML 2.0b1 — Sun, 10 Sep 2023 10:33 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Change the table header of the overview tables in the mapping class specification chapters

  • Key: SYSML2-441
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The table headers state that the rows list SysML v1 and v2 concepts. Actually, they only list stereotype and metamodel elements but not all the concepts. For example, the part property is not listed because it is not a SysML v1 stereotype but only a concept.

  • Reported: SysML 2.0b1 — Sat, 9 Sep 2023 11:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

UML4SysML::Class should be mapped to ItemDefinition

  • Key: SYSML2-439
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    UML4SysML::Class is currently mapped to OccurrenceDefinition, but should be ItemDefinition.

  • Reported: SysML 2.0b1 — Fri, 8 Sep 2023 17:45 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

LoopActionUsage descriptions refer to property not in metamodel

  • Key: SYSML2-425
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The descriptions in 8.3.16.9 (ForLoopActionUsage) and 8.3.16.18 (WhileLoopsActionusage) refer to "bodyClause", but in Figure 28 (Structured Control Actions) the association end for this (presumably) is called "bodyAction".

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 15:09 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mistake in example "Part performs a reference action (action1) that references ..."

  • Key: SYSML2-343
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Part performs a reference action (action1) that reference subsets another action (action3)" replace «perform action» action1 with «perform» action2, and «action» action3 : Action3 with «action» action2 : Action2, and adapt the textual notation accordingly. This also makes it consistent with the preceding example.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:26 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incomplete textual notation in example "Subsetting"

  • Key: SYSML2-331
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Subsetting" is missing specification of the perform action action1 : Action1 that is shown as inherited in the graphical notation. Add part def Part1 in textual notation from preceding example "Usage Definition".

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:12 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

GenericToItemDefinition_Mapping should specialize GenericToOccurrenceDefinition_Mapping

  • Key: SYSML2-422
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The generic mapping class GenericToItemDefinition_Mapping specializes GenericToDefinition_Mapping. However, it should specialize GenericToOccurrenceDefinition_Mapping which is a subclass of GenericToDefinition_Mapping as well as ItemDefinition specializes OccurrenceDefinition.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 13:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

SYSML2-180 uses non-existing general mapping class GenericToItemUsage_Mapping

  • Key: SYSML2-412
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The approved resolution for issue SYSML2-180 uses the mapping class GenericToItemUsage_Mapping which does not exist. It seems that it was overseen to add the creation of the mapping class to the revised text of the resolution.

  • Reported: SysML 2.0b1 — Tue, 29 Aug 2023 13:22 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incomplete flow notation in example "Flow as Node"

  • Key: SYSML2-350
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Flow as Node" check whether flow from source :> action1.item1 should be reference subsetting? Add keyword from to the nested flows.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:43 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Incorrect notation in example "Binding Connection"

  • Key: SYSML2-346
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Binding Connection" «ref part» part4R should use the graphical notation as specified in the graphical BNF in subclause 8.2.3.11.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:31 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Incorrect item flow notation in example "Interface as Node"

  • Key: SYSML2-349
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In example "Interface as Node" remove arrow heads from the nested connections, and move arrow head between pa and pb to end of line, add message of item1:Item1 from pa to pb to the interface2 usage in the textual notation. Also add open curly bracket directly after interface2, and closing curly bracket after the ellipsis.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:42 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Incomplete textual notation in example "Variants Compartment"


Text error in List property construction

  • Key: SYSML2-453
  • Status: open  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    The production for <SourceSuccessionMember > has "+" and it should be "+="

    SourceSuccessionMember : FeatureMembership =
    'then' ownedRelatedElement + SourceSuccession
    

    The production for <SourceEndMember> has "+" and it should be "+="

    SourceEndMember : EndFeatureMembership =
    ownedRelatedElement + SourceEnd
    
  • Reported: SysML 2.0b1 — Wed, 13 Sep 2023 18:02 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Missing production for ConjugatePortTyping

  • Key: SYSML2-451
  • Status: open   Implementation work Blocked
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    In the production:

    FeatureTyping = OwnedFeatureTyping | ConjugatePortTyping
    

    There is no corresponding production for the non-terminal <ConjugatePortTyping>.
    <ConjugatedPortDefinitionMember> or <ConjugatedPortDefinition> may be correct for <FeatureTyping>.

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 21:01 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

misspelled ConjugatePortTyping should be ConjugatedPortTyping

  • Key: SYSML2-452
  • Status: open  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    Prior error report on this production can be replaced with this error report.

    The issue is with the production:

    FeatureTyping = OwnedFeatureTyping | ConjugatePortTyping
    

    The correct conjugate nonterminal should be <ConjugatedPortTyping>

  • Reported: SysML 2.0b1 — Tue, 12 Sep 2023 21:27 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect EBNF specification

  • Key: SYSML2-431
  • Status: open  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    The current specification:

    SourceSuccessionMember : FeatureMembership =
        'then' ownedRelatedElement + SourceSuccession
    
    SourceSuccession : SuccessionAsUsage =
        ownedRelationship += SourceEndMember
    
        SourceEndMember : EndFeatureMembership =
    ownedRelatedElement + SourceEnd
    

    is incorrect. It should be:

    SourceSuccessionMember : FeatureMembership =
        'then' ownedRelatedElement += SourceSuccession
    
    SourceSuccession : SuccessionAsUsage =
        ownedRelationship += SourceEndMember
    
        SourceEndMember : EndFeatureMembership =
    ownedRelatedElement += SourceEnd
    
  • Reported: SysML 2.0b1 — Sat, 2 Sep 2023 13:29 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

PrefixComment should not be a production for AnnotatingElement

  • Key: SYSML2-454
  • Status: open  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    The option for <PrefixComment> has been deprecated, but is still an option for AnnotatingElement. Remove PrefixComment.

    AnnotatingElement =
      Comment
    | PrefixComment
    | Documentation
    | TextualRepresentation
    | MetadataUsage
    
  • Reported: SysML 2.0b1 — Wed, 13 Sep 2023 20:34 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

RequirementConstraintUsage should not have a RequirementBody

  • Key: SYSML2-467
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the textual notation grammar, RequirementConstraintUsage produces a ConstraintUsage, but the first alternative in the production allows the ConstraintUsage to have a RequirementBody. The RequirementBody production allows kinds of declarations (such as subjects and actors) that are not valid in the body of a ConstraintUsage (because of validation constraints such as validateSubjectMembershipOwningType, validateActorMembershipOwningType, etc.). There is no point in syntactically allowing owned members that are then invalid, so the first alternative in RequirementConstraintUsage should have a CalculationBody (like the second alternative) rather than a RequirementBody.

  • Reported: SysML 2.0b1 — Wed, 4 Oct 2023 09:19 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Missing text in some main mapping sections

  • Key: SYSML2-513
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Sections 7.7.4 - 7.7.14 and Section 7.8.5 should contain the introductory sentence:

    This chapter lists all mapping specifications of <namespace> model elements.

    For example, as in Section 7.7.3:

    This chapter lists all mapping specifications of UML4SysML::Activities model elements.

  • Reported: SysML 2.0b1 — Fri, 3 Nov 2023 10:20 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Remove sentence in StateMachines overview section

  • Key: SYSML2-511
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The sentence "The justifications for the elements without mapping are given in view link does not exist" in the State Machines overview sentence does not make sense and should be removed.

  • Reported: SysML 2.0b1 — Fri, 3 Nov 2023 10:15 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Remove sentence in Classification overview section

  • Key: SYSML2-509
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The sentence "The justifications for the elements without mapping are given in view link does not exist" in the Classification overview sentence does not make sense and should be removed.

  • Reported: SysML 2.0b1 — Fri, 3 Nov 2023 06:45 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Sample::calculation has an incorrect type

  • Key: SYSML2-378
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 9.4.3.2.5 Sample (in the Sampled Function model in the Analysis Domain LIbrary), the feature calculation has type CalculationUsage. However, in the actual library model, calculation is a CalculationUsage, which means it should have the base library definition Calculation as its type, not the abstract syntax element CalculationUsage

  • Reported: SysML 2.0b1 — Thu, 10 Aug 2023 02:35 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Constraints missing to enforce variations being abstract

  • Key: SYSML2-488
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the SysML Specification, 7.6.7 Variations and Usages states “A variation is always abstract, so the abstract keyword is not used on a variation.” And, indeed, the textual notation BNF in 8.2.2.6.1 Definitions and 8.2.2.6.2 Usages allows either the abstract or variation keyword to be applied to a definition or usage declaration, but not both. However, there are no constraints in the abstract syntax subclauses 8.3.6.2 Definition or 8.3.6.4 Usage to enforce this.

  • Reported: SysML 2.0b1 — Thu, 19 Oct 2023 16:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Documentation of Time::defaultClock is missing

  • Key: SYSML2-393
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Subclause 9.8.8 on the Time package in the Quantities and Units Domain Library does not include documentation of defaultClock, which is in the normative library model.

  • Reported: SysML 2.0b1 — Thu, 24 Aug 2023 14:55 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

The derivation of AssignmentActionUsage::referent is wrong

  • Key: SYSML2-500
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the SysML Specification, 8.3.16.5 AssignmentActionUsage, the constraint deriveAssignmentActionUsageReferent states that "The referent of an AssignmentActionUsage is the first Feature that is the memberElement of a ownedMembership that is not an OwningMembership." However, according to the BNF in 8.2.2.16.5 Assignment Action Usages, the intended referent of an assignment is parsed as a FeatureChainMember, and, for an actual chain of more than one Feature, the chaining Feature is owned by the AssignmentActionUsage via OwningMembership. Therefore, it will not be identified as the referent of the assignment according to the current derivation.

  • Reported: SysML 2.0b1 — Sat, 28 Oct 2023 10:57 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Actions::acceptSubactions and sendSubactions should subset acceptActions and sendActions

  • Key: SYSML2-490
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Systems Model Library, the features Actions::Action::acceptSubactions and Actions::Action::sendSubactions should subset Actions::acceptActions and Actions::sendActions, respectively.

  • Reported: SysML 2.0b1 — Fri, 20 Oct 2023 14:07 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateTriggerInvocationExpressionWhenArgument constraint is wrong

  • Key: SYSML2-498
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to SYSML2-28 included adding the constraint validateTriggerInvocationExpressionWhenArgument, which requires:

    If a TriggerInvocationExpression has kind = when, then it must have an argument Expression with a result that conforms to the type ScalarValues::Boolean.

    However, the argument to a when trigger is not supposed to be an Expression with a Boolean result. Rather, it is an Expression whose result is the Evaluation of an Expression whose result is Boolean. That is, a trigger like when x > 0 is parsed as TriggerWhen({x > 0}), not as TriggerWhen(x > 0). So all properly parsed when triggers will violate validateTriggerInvocationExpressionWhenArgument as specified in the resolution to SYSML2-28.

  • Reported: SysML 2.0b1 — Fri, 27 Oct 2023 09:39 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Message and flow connection ends should be occurrence usages

  • Key: SYSML2-305
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The end features of MessageConnection, FlowConnection and SuccessionFlowConnection in the standard library package Connections are typed as Occurrences, but they are currently syntactically reference usages, not occurrence usages. However, the abstract syntax for EventOccurrenceUsage requires that its referenced eventOccurrence must actually be an OccurrenceUsage. This means that the source and target ends of, e.g., a message, if inherited from MessageConnection and not redefined, cannot be referenced by EventOccurrenceUsages, which prevents an intended use in "sequence diagram" modeling.

  • Reported: SysML 2.0b1 — Sun, 16 Jul 2023 20:35 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

validateTriggerInvocationExpressionAfterArgument constraint is too strong

  • Key: SYSML2-497
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to SYSML2-28 includes adding the constraint validateTriggerInvocationExpressionAfterArgument, which requires:

    If a TriggerInvocationExpression has kind = after, then it must have an argument Expression with a result that conforms to the type ISQ::DurationValue.

    However, in a typical relative time trigger such as, e.g., after 10[SI::s], the result of the expression 10[SI::s] is not a DurationValue. Rather it is a ScalarQuantityValue whose mRef is the DurationUnit SI::s. Therefore, this example time trigger violates validateTriggerInvocationExpressionAfterArgument as specified in the resolution to SYSML2-28.

  • Reported: SysML 2.0b1 — Fri, 27 Oct 2023 09:31 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

KerML constraint requires updates to Systems Library models

  • Key: SYSML2-491
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to KERML-20 adds the validation constraint validateFeatureValueOverriding that "All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues." This constraint causes problems for two models in the Systems Model Library. These library models do not actually violate the constraint, but using the models as intended my violate the constraint.

    1. In the action definition Actions::AcceptAction, the inout paramater payload is redefined with a feature value binding it to aState.aTransition.aPayload. However, when an accept action is parsed with a change or time trigger, the payload is implicitly bound to the generated change or time signal, and this violates the validateFeatureValueOverriding constraint.
    2. In the analysis case definition AnalysisCases::AnalysisCase:
      • The subject of the objective of AnalysisCase is bound to the result parameter of the AnalysisCase. However, when specifying an analysis case, it is sometimes convenient to compute a check of the case objective by evaluating it on a given subject value. However, the binding of such an subject argument then violates the validateFeatureValueOverring constraint.
      • The result parameter is bound to the result of the AnalysisCase::resultEvaluation calculation feature. However, when defining an analysis case in a user model, it is natural to bind the computation of the result of the case to the result parameter as a feature value. But this then violates the validateFeatureValueOverriding constraint.
  • Reported: SysML 2.0b1 — Tue, 24 Oct 2023 14:00 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Textual notation BNF for TriggerExpression is wrong

  • Key: SYSML2-495
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Time and change triggers for an accept action are supposed to be parsed as a TriggerInvocationExpression with a single argument: for a time trigger, the argument is a duration or time instant, while for a change trigger it is a boolean expression. However, the textual notation BNF for TriggerExpression in 8.2.2.16.4 is not properly parsing the textual notation as an invocation with arguments. As a result, the intended argument expression for the TriggerInocationExpression will not actually be recognized as an argument of the invocation.

  • Reported: SysML 2.0b1 — Thu, 26 Oct 2023 13:33 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect notation in example "Individual Occurrence"

  • Key: SYSML2-336
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Example "Individual Occurrence" should include individual def from preceding example, and rename occurrence1 to occurrence1-1.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:16 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Assignments parsed without a target will fail validateAssignmentActionUsageArguments

  • Key: SYSML2-499
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to SYSML2-28 included the adding of the constraint validateAssignmentActionUsageArguments, which requires that an AssignmentActionUsage have two arguments. However, in the SysML Specification, 8.2.2.16.5 Assignment Action Usages, the AssignmentTargetParameter is optional for an AssignmentNodeDeclaration. An AssignmentActionUsage parsed without a target parameter argument will then fail the validateAssignmentActionUsageArguments.

    In 7.16.9 Assignment Action Usages it states that "If the target expression of an assignment action usage is omitted, then the target is implicitly the occurrence owning the assignment action usage." However, there is no semantic constraint enforcing this, so it is not clear how the informal statement is supposed to be realized.

  • Reported: SysML 2.0b1 — Fri, 27 Oct 2023 16:30 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Resolution of approved issue SYSML2-241 is not considered by merged issue SYSML2-240


Typos in Quantities and Units Domain Library

  • Key: SYSML2-556
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    1. Subclause 9.8.1 paragraph 2 sentence 2, contains a typo: "The library also provides enables the specification ..." should read "The library also enables the specification ...", i.e. delete "provides".
    2. Subclause 9.8.2.1 example 1 under Free versus Bound Quantities and Vector Spaces, contains a typo: "Displacement vector (free) and the position vector (bound), ..." should read "Displacement vector (free) and position vector (bound), ...", i.e. delete "the".

  • Reported: SysML 2.0b1 — Sun, 26 Nov 2023 13:32 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Use of the term 'Feature'

  • Key: SYSML2-481
  • Status: open  
  • Source: itemis AG ( Dr. David Akehurst)
  • Summary:

    The use of the term feature in the document is inconsistent with the ISO standard definition

    Feature - ISO/IEC/IEEE 29148:2018
    A feature is an externally desired service by the system that may require a sequence of inputs to effect the desired result.

    • For example, in a telephone system, features include
      • local call,
      • call forwarding and
      • conference call.
    • Each feature is generally described in a sequence of stimulus response pairs.

    I.e. a feature of a system is about externally visible system behaviour

    Feature is a generic term and has many different meanings in different fields/contexts.
    However in System Engineering, the word is usually used as defined by the ISO standard (above).

    The use of the term 'feature' in the SysML 2 document is definitely NOT consistent with the ISO definition.
    Suggestion for a better term in the SysML 2 would be something like Member, Attribute, Aspect, Detail.

  • Reported: SysML 2.0b1 — Wed, 18 Oct 2023 07:26 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Unnecessary event declaration in example "Message"

  • Key: SYSML2-351
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In (the second) example "Message" the event details should be removed from textual notation. The message becomes message msg1 from a1 to a2 in textual notation.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 13:44 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for message between ports

  • Key: SYSML2-578
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 11, in example "Message" the message symbol between two ports of parts should use the message open arrow head. Also the text above the message edge should read «message» «of» item1 : Item1.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:52 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Add note on FlowFeature direction to textual notation grammar

  • Key: SYSML2-560
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The approved resolution to KERML-195 adds a note to the ItemFlowFeature production in the KerML concrete syntax grammar on properly setting the direction of the synthesized feature. A similar note should be added to the FlowFeature production in subclause 8.2.2.13.4 of the SysML textual notation grammar.

  • Reported: SysML 2.0b1 — Fri, 1 Dec 2023 04:14 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Section containing tables about elements not mapped should get an introductory text

  • Key: SYSML2-566
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The section containing the tables about the elements that have no mapping defined should start with a text that briefly describes the purpose of the section.

  • Reported: SysML 2.0b1 — Mon, 4 Dec 2023 17:15 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for flow connection

  • Key: SYSML2-577
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 11, in example "Flow" the flow connection between directed features of two actions should use the filled black arrow head. Also, the rounded square symbols for the parameters (directed features) should be placed adjacent to the action box outlines.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:48 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for flow between actions

  • Key: SYSML2-582
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.16.1, Table 14, in example "Action with Graphical Compartment showing standard action flow view" the flow between the actions should use a black filled arrow head.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for flow connections in Flow as Node

  • Key: SYSML2-579
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 11, in example "Flow as Node" the 3 flow connections in the «flow» node should use the black filled arrow head for flow connection.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:53 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect graphical notation for successions examples with actions

  • Key: SYSML2-583
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.16.1, Table 14, in the 7 examples "Perform Actions Swimlanes", "Actions with and without Conditional Succession", "Actions with and without Conditional Succession", "Actions with Control Nodes", "Action with Loop (body in textual notation)", "Action with Loop (body in graphical notation)", "Accept and Send Action Flow", the successions should be represented as dashed lines. The arrow heads are correct.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:59 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Mistakes in example Interface as Node (with flow)

  • Key: SYSML2-581
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Subclause 7.14.1, Table 12, example "Interface as Node (with flow)" has the following mistakes: (1) label item1 : Item1 near the flow arrow head on interface2 should be prepended with «flow» «of». (2) the message flows in the interface2 node should use the open message arrow heads. (3) . (4) The textual and graphical notation should use reference-subsetting in the specification of interface2, i.e. replace :> with ::> (two times in graphical notation, and two times in textual notation). It is also recommended to use shorter names in the example to make it more compact.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:58 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

OCL rule deriveDefinitionOwnedFlow references non-existent class called FlowUsage

  • Key: SYSML2-611
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The description indicates that this should be FlowConnectionUsage.

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 09:02 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Incorrect and incomplete sequence view with message

  • Key: SYSML2-580
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    In subclause 7.13.1, Table 11, in example "Message" the message transfer between the life lines should use the open arrow head for message.

  • Reported: SysML 2.0b1 — Tue, 5 Dec 2023 21:57 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

OCL rule deriveUsageNestedFlow references non-existent class called FlowUsage

  • Key: SYSML2-612
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The description indicates that it should be FlowConnectionUsage

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 09:04 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Textual notation production for Comment is wrong

  • Key: SYSML2-620
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the textual notation grammar, the BNF production for Comment requires that a Comment always include the keyword comment. This is inconsistent with the description in 7.4.2 Comments and Documentation, which allows comments of the form /* ... */, without the keyword.

  • Reported: SysML 2.0b1 — Thu, 21 Dec 2023 04:44 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

User-defined keywords are not allowed on control nodes

  • Key: SYSML2-616
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the textual notation grammar, in 8.2.2.16.3 Control Nodes, the ControlNodePrefix production does not allow the use of user-defined keywords in the prefix of control-node declarations in the body of an action. There is no real reason why this should not be allowed. It seems to be simply an oversight in the BNF.

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 22:05 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

OCL for deriveViewDefinitionViewCondition and deriveViewUsageViewCondition are wrong

  • Key: SYSML2-529
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The OCL for the constraints deriveViewDefinitionViewCondition and deriveViewUsageViewCondition are both

    viewCondition = featureMembership->
        selectByKind(ElementFilterMembership).
        condition
    

    This is clearly wrong, since ElementFilterMemberships are not featureMemberships.

    In addition, the description of the deriveViewUsageViewCondition constraint refers to ViewDefinition instead of ViewUsage, as do the descriptions of deriveViewUsageSatsifiedViewpoint, deriveViewUsageViewRendering and validateViewUsageOnlyOneViewRendering. (And the description of deriveViewUsageExposedElement is missing.)

  • Reported: SysML 2.0b1 — Sat, 11 Nov 2023 22:19 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

checkFlowConnectionUsageSpecialization is too restrictive about FlowConnections

  • Key: SYSML2-597
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.13.7 FlowConnectionUsage, the constraint checkFlowConnectionUsageSpecialization states that

    If a FlowConnectionUsage has no itemFlowEnds, then it must directly or indirectly specialize the base FlowConnectionUsage Connections::messageConnections from the Systems Library model. Otherwise, it must directly or indirectly specialize the FlowConnectionUsage Connections::flowConnections.

    The property itemFlowEnds is derived as all connectorEnds that are ItemFlowEnds. The (Kernel) metaclass ItemFlowEnd is used when a FlowConnectionUsage is parsed from the special flow notation. However, a FlowConnectionUsage can also be written using regular connection notation, which will not have ItemFlowEnds, e.g.,

    flow {
        end ::>> operator {
            out cmd : Command :>> sourceOutput;
        }
        end ::>> device {
            in cmd  : Command :>> targetInput;
        }
    }
    

    But, currently, this will implicitly specialize messageConnections, not flowConnections, which seems unexpected, since this is structurally a complete flow declaration.

  • Reported: SysML 2.0b1 — Thu, 14 Dec 2023 21:46 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

checkStateUsageSpecialization constraint is incorrect

  • Key: SYSML2-558
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.17.6 StateUsage, the description of checkStateUsageSpecialization is

    A StateUsage must directly or indirectly specialize the StateUsage States::stateActions from the Systems Model Library.

    but the OCL is

    specializesFromLibrary('States::StateAction')
    

    which requires specialization of StateAction, not stateActions.

  • Reported: SysML 2.0b1 — Wed, 29 Nov 2023 21:10 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Errors in the TradeStudy domain model

  • Key: SYSML2-552
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Analysis Domain Library model TradeStudies::TradeStudy, the requirement definitions MinimizeObjective and MaximizeObjective explicitly redefine the parameter best from the TradeStudyObjective definition they specialize, but do not declare any other parameters. However, this violates the checkFeatureParameterRedefinition constraint, which requires that parameters be redefined in order. And, if the implied redefinition is added to the actual first parameter selectedAlternative, then this also violates the validateRedefinitionDirectionConformance constraint (add by the approved resolution to KERML-20), because best is an out parameter, while selectedAlternative is an in parameter.

  • Reported: SysML 2.0b1 — Tue, 21 Nov 2023 22:35 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Enumeration definitions VerdictKind and VerificationMethodKind are missing from specification document

  • Key: SYSML2-554
  • Status: open  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    The enumeration definitions VerdictKind and VerificationMethodKind, which are in the normative Systems Model Library package VerificationCases, are missing from Systems Model Library subclause 9.2.16 Verification Cases in the SysML Specification.

  • Reported: SysML 2.0b1 — Wed, 22 Nov 2023 18:58 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

Adornments on ends missing in graphical syntax

  • Key: SYSML2-318
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    Graphical notation is missing support for adornments on ends of ConnectionDefinitions, such as ordered, nonunique, readonly, subsets, and redefines. This is needed for information modeling and compatibility with UML and SysML v1. In UML (and SysML v1) these adornments are called 'property modifiers'. Analogously, in KerML and SysML v2 the term 'feature modifiers' would seem appropriate.

  • Reported: SysML 2.0b1 — Wed, 2 Aug 2023 12:12 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT
  • Attachments:

Subsetting of subjectParameter properties is wrong

  • Key: SYSML2-430
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The properties RequirementUsage::subjectParameter and CaseUsage::subjectParameter in the abstract syntax SysML.xmi currently subset Behavior::parameter. However, neither RequirementUsage nor CaseUsage specialize Behavior. Rather they (indirectly) specialize Step, so the subjectParameter properties should be subsetting Step::parameter rather than Behavior::parameter.

    (Note that this error is not apparent in the specification document, because, in the annotation for subsetting, the subsetted parameter is shown without qualification – e.g., just parameter, not Behavior::parameter.)

  • Reported: SysML 2.0b1 — Mon, 4 Sep 2023 18:27 GMT
  • Updated: Mon, 8 Apr 2024 18:21 GMT

specializesFromLibrary arguments use inconsistent notation for strings

  • Key: SYSML2-426
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The arguments for specializesFromLibrary are sometimes single quoted and sometimes double quoted. Search on specializesFromLibrary(' and specializesFromLibrary(" to find them.

  • Reported: SysML 2.0b1 — Thu, 31 Aug 2023 15:35 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Incorrect textual notation for TextualRepresentation

  • Key: SYSML2-626
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The textual notation for example "Annotation-Textual Representation" in clause 7.4.1 Table 2 is incorrect. A TextualRepresentation is always owned by its represented element, so the keyword about should not be used.

  • Reported: SysML 2.0b1 — Fri, 22 Dec 2023 16:04 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Intersection missing for some multiple specializations

  • Key: SYSML2-561
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Some multiple specializations in the libraries might be intended to be intersections, including feature specializations. For example, from SYSML2-490, under Actions::Actions

    action sendSubactions: SendAction[0..*] :> subactions, sendActions {
      doc /* 
          * The subactions of this Action that are SendActions. 
          */ 
    }
    
    action acceptSubactions: AcceptAction[0..*] :> subactions, acceptActions {
      doc /* 
          * The subactions of this Action that are AcceptActions. 
          */ 
    }
    
  • Reported: SysML 2.0b1 — Fri, 1 Dec 2023 15:34 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Tables in overview sections have empty cells SysML v2 column

  • Key: SYSML2-562
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The table in the mapping chapters' overview sections sometimes has no information about the SysML v2 target element. There should be a target element or a note that the rationale for not having a target element can be found in the following section that lists the elements that are not mapped with a justification.

  • Reported: SysML 2.0b1 — Mon, 4 Dec 2023 15:11 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Mapping tables in the overview sections show duplicates in the SysML v2 column

  • Key: SYSML2-564
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Some entries in the mapping overview tables show duplicate entries in the SysML v2 column.

  • Reported: SysML 2.0b1 — Mon, 4 Dec 2023 16:47 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Rename ~InterfaceBlock_Mapping

  • Key: SYSML2-569
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The special symbol ~ at the beginning is allowed, but it could lead to issues in mapping implementations because most script and programming languages do not allow it.

    The mapping class was introduced by SYSML2-139.

  • Reported: SysML 2.0b1 — Mon, 4 Dec 2023 21:14 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Constraint on Definition variation memberships is too restrictive

  • Key: SYSML2-613
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    with these two part defs:

    part def Source {
      part B;
    }
    
    part def Target{
      part C;
    }
    

    I want to define a variation of an allocation definition thus:

    variation allocation def theSet {
        end s:Source;
        end t:Target;
        variant allocation Scenario1:theSet {
            allocate s.B to t.C;
        }
    }
    

    and then use it thus:

    part Top {
        part b:Source;
        part a:Target;
    }
    
    allocation alloc1:theSet allocate Top.b to Top.a {
        assert constraint {alloc1 == Scenario1}
    }
    

    However, it seems that variations can only contain variants as members and hence I need to create another allocation definition to hold the ends, thus:

    allocation def theOtherSet {
        end s:Source;
        end t:Target;
    }
    

    and have the variation specialise this new definition thus:

    variation allocation def theSet:>theOtherSet {
        end s:Source;
        end t:Target;
        variant allocation Scenario1:theSet allocate s to t{
            allocate s.B to t.C;
        }
    }
    

    This seems unnecessarily restrictive and I can find no rationale in the spec for this.

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 09:31 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Constraint on Usage variation memberships is too restrictive

  • Key: SYSML2-615
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    with these two part defs:

    part def Source {
      part B;
    }
    
    part def Target{
      part C;
    }
    

    I want to define a variation of an allocation definition thus:

    variation allocation def theSet {
        end s:Source;
        end t:Target;
        variant allocation Scenario1:theSet {
            allocate s.B to t.C;
        }
    }
    

    and then use it thus:

    part Top {
        part b:Source;
        part a:Target;
    }
    
    allocation alloc1:theSet allocate Top.b to Top.a {
        assert constraint {alloc1 == Scenario1}
    }
    

    However, it seems that variations can only contain variants as members and hence I need to create another allocation definition to hold the ends, thus:

    allocation def theOtherSet {
        end s:Source;
        end t:Target;
    }
    

    and have the variation specialise this new definition thus:

    variation allocation def theSet:>theOtherSet {
        end s:Source;
        end t:Target;
        variant allocation Scenario1:theSet allocate s to t{
            allocate s.B to t.C;
        }
    }
    

    This seems unnecessarily restrictive and I can find no rationale in the spec for this.

  • Reported: SysML 2.0b1 — Wed, 20 Dec 2023 09:50 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Find a better way to differ between definition and instance elements in graphical notation

  • Key: SYSML2-640
  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    In SysML v2 parts are drawn in the graphical notation with rounded corners. In UML and and also in SysML v1.x there is a clear graphical language paradigm to use rounded corners only for behavioral elements like activities, states and use cases and all elements showing static aspects of a system like data structures, architectural things etc. are defining elements that have no rounded corners (e.g. classes, objects, blocks, parts, nodes etc.).
    Would it not be possible to find a better graphical notation to differ between definition elements and their instances? What about using different shapes or different stroke widths? Also icons could be used in graphical elements to express a what kind of element it is - like it is done in BPMN for example.
    I think following the rule, that behavioral aspects are modeled with rounded elements and static aspects with not-rounded elements would provide a better compatibility to still existing and well known standards like UML, SysML v1.x, BPMN etc.
    Many people are still trained with high effort in using this notations in their daily work and I think they will be very confused when the should use SysML v2 in the future with that big paradigm shift in the graphical notation.

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 12:01 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

package View and Viewpoint TBD should not be included in the xmi file

  • Key: SYSML2-636
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    package x View and Viewpoint TBD should not be included in the SysML.xmi file.

  • Reported: SysML 2.0b1 — Fri, 12 Jan 2024 17:59 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

VerificationCase::subVerificationCases is typed incorrectly

  • Key: SYSML2-634
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Systems Model Library file VerificationCases.sysml, the feature VerificationCase::subVerificationCases is declared as having the type Case. It should instead be VerificationCase. (Note that this is actually specified correctly in the SysML Specification document, 9.2.16.2.2 VerificationCase.)

  • Reported: SysML 2.0b1 — Tue, 9 Jan 2024 00:04 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Do not use abbreviations for key word in SysML v2/KerML textual concrete syntax

  • Key: SYSML2-641
  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    I would like to recommend, that abbreviations are not used in key words for the SysML v2 textual notation (resp. KerML). A good example is the key word "def" instead of "definition".
    Why it is here an abbreviation and other (longer) key words are not?
    To make the textual notation more consistent for users, eliminate all abbreviations and write it out.

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 12:09 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Annotation diagram needs to be updated

  • Key: SYSML2-844
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The kernel abstract syntax diagram in Figure 4. Annotations (in 8.3.4 Annotations Abstract Syntax) needs to be updated consistent with the resolution to KERML-21 approved by the KerML FTF.

  • Reported: SysML 2.0b1 — Tue, 23 Jan 2024 23:09 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT
  • Attachments:

User-defined keywords are not allowed on metadata

  • Key: SYSML2-631
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The productions for MetadataDefinition and MetadataUsage in 8.2.2.26 Metadata Textual Notation do not provide for the use of user-defined keywords, even though it is allowable to have nested metadata usages in both cases.

  • Reported: SysML 2.0b1 — Tue, 2 Jan 2024 19:50 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Make orthogonal and rounded corners the default connector style for architectural drawings

  • Key: SYSML2-642
  • Status: open  
  • Source: MDD4All ( Dr. Oliver Alt)
  • Summary:

    In UML and SysML v1 a connector that is used to connect two ports can be a direct connection what is drawn vertically between one port and another.
    The semantics does not differ if it is a direct connection or an orthogonal bented line. SysML user are often electrical or mechanical engineers and they are trained to draw connections between inputs and outputs in an orthogonal way. So why not make this the default connector shape in SysML for all connectors use to connect two ports together?
    Another advice would be to round the corner where the connector is bented. This would avoid misunderstandings when you zoom into a diagram. You can directly recognize that this a connector and not a corner of a component for example. Such a connector style is used as default in the BPMN 2.0 notation and it produces very readable diagrams.

  • Reported: SysML 2.0b1 — Tue, 16 Jan 2024 12:22 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Issues with SysML grammar

  • Key: SYSML2-635
  • Status: open   Implementation work Blocked
  • Source: itemis AG ( David Akehurst)
  • Summary:

    Reuse of KerML rules in SysML grammar is not described sufficiently.
    Not clear which rules are reused and which not.
    Reused rules are simply missing from the SysML definitions.

    Additionally,
    1. AnnotatingElement defined twice: In 8.2.2.4.1 and in 8.2.2.5.2
    2. Extra ')' in 8.2.2.15 AllocationUsageDeclaration
    3. MetadataUsageDeclaration not defined, used in 8.2.2.26 in MetadataUsage
    4. PerformActionDeclaration not defined, used in 8.2.2.17.3 in TransitionPerformActionUsage - should this be PerformActionUsageDeclaration?
    5. StakeholderDefinition not defined, used in 8.2.2.5.2 in DefinitionElement
    6. BindingConnector not defined, used in 8.2.2.6.4 in VariantUsageElement and 8.2.2.14.1 in InterfaceNonOccurrenceUsageElement - should this be BindingConnectorAsUsage
    7. Succession not defined, used in 8.2.2.6.4 in VariantUsageElement and 8.2.2.14.1 in InterfaceNonOccurrenceUsageElement - should this be SuccessionAsUsage
    8. AnnotatingMember defined twice, in 8.2.2.8 and in 8.2.2.4.1
    9. MessageEvent not defined, used in 8.2.2.13.4 in MessageEventMember - should the definition of MessageEnd (after it) be named MessageEvent?
    10. ItemFeature not defined, used in 8.2.2.13.4 in FlowPayloadFeatureMember - should it be FlowPayloadFeature
    11. ItemFlowEnd not defined, used in 8.2.2.13.4 in FlowEndMember - should it be FlowEnd
    12. InterfaceNonOccurrenceUsageMember not defined, used in 8.2.2.14.1 in InterfaceBodyItem - should it be InterfaceNonOccurrenceMember
    13. FeatureChain not defined, used in 8.2.2.16.5 in OwnedFeatureChainMember - should this be OwnedFeatureChain

  • Reported: SysML 2.0b1 — Wed, 10 Jan 2024 18:48 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

User-defined keywords are not allowed on enumeration definitions

  • Key: SYSML2-637
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The BNF in 8.2.2.8 Enumerations Textual Notation does not allow user-defined keywords on EnumerationDefinitions, even though nested metadata feature annotations are allowed in both cases. (Note that the syntax for EnumerationUsages does allow for user-defined keywords.)

  • Reported: SysML 2.0b1 — Mon, 15 Jan 2024 22:42 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Comment locale not in textual notation

  • Key: SYSML2-643
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.4 Annotations Abstract Syntax, in Figure 4 Annotation (from KerML), Comment is shown as having a locale attribute. However, the is no provision for specifying this in the concrete syntax for Comments, neither the textual (8.2.2.4.2 Comments and Documentation) nor graphical (8.2.3.4 Annotations Graphical Notation).

  • Reported: SysML 2.0b1 — Thu, 18 Jan 2024 23:25 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT
  • Attachments:

checkRequirementUsageObjectiveRedefinition is incorrect

  • Key: SYSML2-553
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.20.9 RequirementUsage, the checkRequirementUsageObjectiveRedefinition constraint requires that "A RequirementUsage whose owningFeatureMembership is a ObjectiveMembership must redefine the objectiveRequirement of each CaseDefinition or CaseUsage that is specialized by the owningType of the RequirementUsage." However, the objectiveRequirement property of a CaseDefinition (see 8.3.21.2) or a CaseUsage (see 8.3.21.3) is derived to be only the owned objective of the case. This means that, if a case declares an owned objective, but specializes a case with an inherited objective, then checkRequirementUsageObjectiveRedefinition will actually not be satisfiable.

  • Reported: SysML 2.0b1 — Wed, 22 Nov 2023 04:58 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT

Parsing KerML Feature elements from SysML textual notation

  • Key: SYSML2-783
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In some cases, parsing certain short-hand SysML notations results in the creation of KerML Feature elements. In particular, according to 8.2.2.13.1 Connection Definition and Usage, shorthand connection notation such as

    connection connect x to y;
    

    is parsed into a ConnectionUsage with two end features that are KerML Features. However, it is not possible to create ends that are KerML Features in "long hand" SysML notations. For example, in the notation

    connection {
        end references x;
        end references y;
    }
    

    the two ends are parsed as SysML ReferenceUsages, not KerML Features.

    This means that these two examples, while semantically equivalent, are not actually just different surface notations for the same underlying abstract syntax representation. it would be better to have the shorthand notations parse to fully SysML abstract syntax, as much as possible, so that the shorthand notation is just a different surface representation of a certain abstract syntax pattern that can also be equally represented in the full notation.

  • Reported: SysML 2.0b1 — Mon, 22 Jan 2024 04:35 GMT
  • Updated: Mon, 8 Apr 2024 18:20 GMT