Throughout the document, we need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.
Throughout the document, need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.
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).
The mapping of a UML4SysML::ActivityFinalNode is not covered by the transformation rules.
The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:
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.
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.
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!
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.)
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.)
Keywords introduced in the graphical notation BNF are surrounded by guillemets («...»). However, the graphical notation also uses snippets of textual notation in many places, often by referencing productions from the textual notation BNF, which does not put guillemets around keywords. In some cases, though, the graphical BNF will include productions for text that introduce keywords that parallel the textual notation, but don't directly use textual notation BNF productions. The resolution to SYSML2-59 includes such productions for message-label and flow-label that include the «of» keyword surrounded by guillemets, but other such productions in the graphical BNF do not put guillemets around keywords. There needs to be a consistent rule on how guillemets are to be used in the graphical notation.
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.)
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.)
Keywords introduced in the graphical notation BNF are surrounded by guillemets («...»). However, the graphical notation also uses snippets of textual notation in many places, often by referencing productions from the textual notation BNF, which does not put guillemets around keywords. In some cases, though, the graphical BNF will include productions for text that introduce keywords that parallel the textual notation, but don't directly use textual notation BNF productions. The resolution to SYSML2-59 includes such productions for message-label and flow-label that include the «of» keyword surrounded by guillemets, but other such productions in the graphical BNF do not put guillemets around keywords. There needs to be a consistent rule on how guillemets are to be used in the graphical notation.
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!
[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; }
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.
Both Enumeration and ValueType have main mappings and their specified filters do prevent a double match
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.
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.
State shall be able to have proxy nodes on their boundaries. Currently not covered by the GBNF
Both Enumeration and ValueType have main mappings and their specified filters do prevent a double match
[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; }
State shall be able to have proxy nodes on their boundaries. Currently not covered by the GBNF
The current algorithm crashes if the data type provided has no name defined or if the type is not defined
The current specification is not computable in some cases (where the "any" OCL iterator find no value). E.g. : MIWG Test Case#27
In some cases (e.g. MIWG test case #11) it is unable to compute the requested type.
As a consequence SysMLv literals generated by the transformation have no value defined
The current specification is not computable in some cases (where the "any" OCL iterator find no value). E.g. : MIWG Test Case#27
As a consequence SysMLv literals generated by the transformation have no value defined
In some cases (e.g. MIWG test case #11) it is unable to compute the requested type.
The current algorithm crashes if the data type provided has no name defined or if the type is not defined
The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:
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.
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.
ownedRelationship() operation. There is the following code:
else if from.oclIsTypeOf(UML::FlowFinalNode) then ObjectFlowItemFlowEndRedefinition_Factory.create(ElementMain_Mapping.getMapped(SysMLv2::ActionUsage.allInstances()->any(e | e.qualifiedName = 'Actions::Action::done')))
The point is that the parameter of a getMapped operation shall be an element form the source model, while the code above povide a SysMLv2 element from a library. This makes the MIWIG test case #27 failing
The multiplicities that the transformation specifies are wrong when the source element has the default multiplicity in the source model.
Shall be fixed: MultiplicityUpperBoundOwningMembership_Mapping and MultiplicityLowerBoundOwningMembership_Mapping
Shall be removed : DefaultLowerBound_Mapping and DefaultUpperBound_Mapping
Factories for LiteralInteger, LiteralInfinity are required
Duplicated operations can be removed by adding a common abstract root class. This will simplify the model and ease the maintenance
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.
Duplicated operations can be removed by adding a common abstract root class. This will simplify the model and ease the maintenance
ownedRelationship() operation. There is the following code:
else if from.oclIsTypeOf(UML::FlowFinalNode) then ObjectFlowItemFlowEndRedefinition_Factory.create(ElementMain_Mapping.getMapped(SysMLv2::ActionUsage.allInstances()->any(e | e.qualifiedName = 'Actions::Action::done')))
The point is that the parameter of a getMapped operation shall be an element form the source model, while the code above povide a SysMLv2 element from a library. This makes the MIWIG test case #27 failing
The multiplicities that the transformation specifies are wrong when the source element has the default multiplicity in the source model.
Shall be fixed: MultiplicityUpperBoundOwningMembership_Mapping and MultiplicityLowerBoundOwningMembership_Mapping
Shall be removed : DefaultLowerBound_Mapping and DefaultUpperBound_Mapping
Factories for LiteralInteger, LiteralInfinity are required
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.
The MIWIG test case #11 fails because it assumes that the client of a SysML::Satisfy relationship, that is a Block, is owned by something that is mapped to a SysMLv2 Type.
This is unlikely to happen since in most cases (like in this test case) Blocks are owned by Packages
The filter operations defined for the mapping specified from an OpaqueBehavior prevent those owned by another kind of element to be transformed, like in MWIG test cases 7 and 35
The MWIG test case #8 fails because it contains a property that is typed by an Actor while the transformatiosn currently defined do not support it
The MIWIG test case #11 fails because it assumes that the client of a SysML::Satisfy relationship, that is a Block, is owned by something that is mapped to a SysMLv2 Type.
This is unlikely to happen since in most cases (like in this test case) Blocks are owned by Packages
The filter operations defined for the mapping specified from an OpaqueBehavior prevent those owned by another kind of element to be transformed, like in MWIG test cases 7 and 35
The MWIG test case #8 fails because it contains a property that is typed by an Actor while the transformatiosn currently defined do not support it
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.
Clause 8.3.9.5 (OccurrenceUsage), Constraints, says
checkOccurrenceUsageTypeFeaturing
If the portionKind of an OccurrenceUsage is not empty, then, for each occurrenceDefinition of the OccurrenceUsage, there must be a featuringType of the OccurrenceUsage which either is the occurrenceDefinition or directly or indirectly specializes it.portionKind <> null implies occurrenceDefinition->forAll(occ | featuringType->exists(specializes(occ)))
For example, adapted from 7.13.5 (Successions as Usages):
occurrence def Flight {
timeslice preflight : Preflight [1];
then timeslice inflight : Inflight [1];
then timeslice postflight : Postflight[1];
checkOccurrenceUsageTypeFeaturing requires Flight to specialize each of Pre/In/Postflight, even though these would typically be disjoint with Flight, leading to:
which probably aren't intended in this exampe.
Clause 8.3.9.5 (OccurrenceUsage), Constraints, says
checkOccurrenceUsageTypeFeaturing
If the portionKind of an OccurrenceUsage is not empty, then, for each occurrenceDefinition of the OccurrenceUsage, there must be a featuringType of the OccurrenceUsage which either is the occurrenceDefinition or directly or indirectly specializes it.portionKind <> null implies occurrenceDefinition->forAll(occ | featuringType->exists(specializes(occ)))
For example, adapted from 7.13.5 (Successions as Usages):
occurrence def Flight {
timeslice preflight : Preflight [1];
then timeslice inflight : Inflight [1];
then timeslice postflight : Postflight[1];
checkOccurrenceUsageTypeFeaturing requires Flight to specialize each of Pre/In/Postflight, even though these would typically be disjoint with Flight, leading to:
which probably aren't intended in this exampe.
GenericToElement_Mapping is missing default rules for:
GenericToStateUsage_Mapping is missing a default rule for isParallel
A Namespace shall own the relationships that defined its members (either owned or not) and its import relationships.
Instead the ownedImport() operation is useless since Namespace::ownedImport is a derived property
The body condition specified for this operation is wrong. It should be an empty set.
Comment_Mapping is missing a default rule locale
The body condition specified for this operation is wrong. It should be an empty set.
GenericToStateUsage_Mapping is missing a default rule for isParallel
GenericToElement_Mapping is missing default rules for:
A Namespace shall own the relationships that defined its members (either owned or not) and its import relationships.
Instead the ownedImport() operation is useless since Namespace::ownedImport is a derived property
Comment_Mapping is missing a default rule locale
GenericToRelationship_Mapping should provide default rules for
GenericToRequirementUsage_Mapping is missing a default rule for reqId
A graphical BNF production should be added that specifies that it is mandatory to include the applicable user-defined keyword in the notation for a library extension element.
Currently it is not possible to use action control nodes (Fork/Join/Decision/Merge) as sources/targets of a transition in a state definition or usage.
A graphical BNF production should be added that specifies that keywords may optionally be included on edges.
A graphical BNF production should be added that specifies that it is mandatory to include the applicable user-defined keyword in the notation for a library extension element.
GenericToRequirementUsage_Mapping is missing a default rule for reqId
GenericToRelationship_Mapping should provide default rules for
A graphical BNF production should be added that specifies that keywords may optionally be included on edges.
Currently it is not possible to use action control nodes (Fork/Join/Decision/Merge) as sources/targets of a transition in a state definition or usage.
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.
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.
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.
Documentation should be added that bolding of keywords in the graphical notation is optional, and may be used for visual prominence. For example, in representative notation table 16 in subclause 7.17.1 in the actions compartment of a state the keywords entry, do and exit are bolded.
Right now use-case nodes cannot be associated with actors and subjects. They need to be made subject/actor stakeholders
Notation table shows item flows on interface connections. This is not enabled by the graphical BNF
Documentation should be added that bolding of keywords in the graphical notation is optional, and may be used for visual prominence. For example, in representative notation table 16 in subclause 7.17.1 in the actions compartment of a state the keywords entry, do and exit are bolded.
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.
Right now use-case nodes cannot be associated with actors and subjects. They need to be made subject/actor stakeholders
Notation table shows item flows on interface connections. This is not enabled by the graphical BNF
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
Graphical BNF specifies a flow connection. It is not clearly mapped to a semantic language concept. Should it be merged with a message specified as part of occurences?
Events and event occurrences are supported by the textual syntax, but not by the graphical syntax.
It is also not mentioned in the representative notation tables
The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect
The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect
Graphical BNF specifies a flow connection. It is not clearly mapped to a semantic language concept. Should it be merged with a message specified as part of occurences?
Events and event occurrences are supported by the textual syntax, but not by the graphical syntax.
It is also not mentioned in the representative notation tables
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
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.
To provide guidance for users on common formatting
example:
requirement def SomeRequirement
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.
The transformation ignores the entry, do, and exit behavior of a state.
Sub-clause 8.2.3.3 (dependencies) uses element-node as the source and target of a dependency.
element-node is not defined anywhere
The transformation ignores the entry, do, and exit behavior of a state.
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.
To provide guidance for users on common formatting
example:
requirement def SomeRequirement
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.
Sub-clause 8.2.3.3 (dependencies) uses element-node as the source and target of a dependency.
element-node is not defined anywhere
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.
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;
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;
Subclause 8.2.3.13, specifies the productions for connections. Ballot 3 added a production for n-ary connection usage, but n-ary connection definition (graphical) is still missing
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.
A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.
Subclause 8.2.3.13, specifies the productions for connections. Ballot 3 added a production for n-ary connection usage, but n-ary connection definition (graphical) is still missing
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.
A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.
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.
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;
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;
Any execution of the CommentAnnotation_Mapping transformation rule shall result in the same instance of SysMLv2 Annotation for a given (Comment, annotatedElement) pair provided. I.e. it should specialize the Foundations::UniqueMapping class.
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.
Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.
Any execution of the CommentAnnotation_Mapping transformation rule shall result in the same instance of SysMLv2 Annotation for a given (Comment, annotatedElement) pair provided. I.e. it should specialize the Foundations::UniqueMapping class.
Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.
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.
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".
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".
Actor and subject are parameters of a use case (and also requirement in case of subject). The current notation suggests symbols completely outside the contour of the use case/requirements linked by a line segment. This is different from V1 where actors and subjects were not parameters. Ultimately the modeler is interested to see the binding of those parameters being the concrete occurrences standing for them. The parameter bindings can be graphically represented by binding connections to those external symbols. Would be more effective to treat those predefined parameters using on contour symbols like ports and parameters and bind to those.
Actor and subject are parameters of a use case (and also requirement in case of subject). The current notation suggests symbols completely outside the contour of the use case/requirements linked by a line segment. This is different from V1 where actors and subjects were not parameters. Ultimately the modeler is interested to see the binding of those parameters being the concrete occurrences standing for them. The parameter bindings can be graphically represented by binding connections to those external symbols. Would be more effective to treat those predefined parameters using on contour symbols like ports and parameters and bind to those.
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.
In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».
Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline
Add import qualifier text (* or **) to upper right corner of imported Package
Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.
Add import qualifier text (* or **) to upper right corner of imported Package
Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline
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.
In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».
Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.
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.
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.
In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.
Clarify that the identifier for the metadata declaration is the metadata definition name.
In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.
Clarify that the identifier for the metadata declaration is the metadata definition name.
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.
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.
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.)
The mapping of ObjectFlow in combination with JoinNodes is not covered yet by the transformation.
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.)
The mapping of ObjectFlow in combination with JoinNodes is not covered yet by the transformation.
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.
The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.
The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.
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.
Since Relationship is now an abstract class, ElementOwnership_Mapping has been made abstract as well. A consequence of this, because it is not a "MainMapping", is that it is not possible to invoke the getMapped operation directly on this mapping class.
However there are many body conditions that still that. They have to be fixed.
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.
The mapping of a Unit and a QuantityKind is not covered by the transformation yet.
The transformation does not map the Parameter::isStreaming.
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.
Since Relationship is now an abstract class, ElementOwnership_Mapping has been made abstract as well. A consequence of this, because it is not a "MainMapping", is that it is not possible to invoke the getMapped operation directly on this mapping class.
However there are many body conditions that still that. They have to be fixed.
The transformation does not map the Parameter::isStreaming.
The mapping of a Unit and a QuantityKind is not covered by the transformation yet.
The way SysML libraries are provided relies on textual notation files on which element declarations do not include the specification of their elementId property.
As consequence, if the elementId is actually generated by the tool, as written in the KerML specification (p226), it is very likely to have a different value from one computer to another and even from one loading to another on the same computer.
Hence, it is impossible to make sure it will "not change during the lifetime of the Element", as required by in the same paragraph of that specification.
Linked to a similar issue raised on KerML
The way SysML libraries are provided relies on textual notation files on which element declarations do not include the specification of their elementId property.
As consequence, if the elementId is actually generated by the tool, as written in the KerML specification (p226), it is very likely to have a different value from one computer to another and even from one loading to another on the same computer.
Hence, it is impossible to make sure it will "not change during the lifetime of the Element", as required by in the same paragraph of that specification.
Linked to a similar issue raised on KerML
Currently, the transformation supports only AcceptEventActions with one trigger, but it could be many.
The transformation does not specify mapping rules for UML4SysML::DestroyLinkAction.
The transformation does not specify mapping rules for UML4SysML::FunctionBehavior.
The transformation does not specify mapping rules for UML4SysML::CreateLinkAction.
The transformation does not specify mapping rules for UML4SysML::ReadLinkAction.
The transformation does not specify mapping rules for UML4SysML::CreateLinkAction.
Currently, the transformation supports only AcceptEventActions with one trigger, but it could be many.
The transformation does not specify mapping rules for UML4SysML::DestroyLinkAction.
The transformation does not specify mapping rules for UML4SysML::ReadLinkAction.
The transformation does not specify mapping rules for UML4SysML::SignalEvent.
The transformation does not specify mapping rules for UML4SysML::FunctionBehavior.
The mapping of a UML4SysML::InterruptibleActivityRegion is not covered by the transformation rules.
The transformation generally maps a PseudoState, but does not distinguish between the different kinds of pseudostates.
Some Standard View Definitions, like Case View, are not a self-standing view, but are effectively a General View with a specific filter applied.
Add filtered views as specializations of General View into the first table "Standard View Definitions" of clause 9.2.19.1, in particular Case View, with an explicit filter declaration.
The transformation does not specify mapping rules for UML4SysML::SignalEvent.
Some Standard View Definitions, like Case View, are not a self-standing view, but are effectively a General View with a specific filter applied.
Add filtered views as specializations of General View into the first table "Standard View Definitions" of clause 9.2.19.1, in particular Case View, with an explicit filter declaration.
The transformation generally maps a PseudoState, but does not distinguish between the different kinds of pseudostates.
The mapping of a UML4SysML::InterruptibleActivityRegion is not covered by the transformation rules.
There are different implementations of the SysML v2 graphical notation in the various release documents
Documents checked:
2-OMG_Systems_Modeling_Language.pdf Version 2.0 Release 2023-02
Intro to the SysML v2 Language-Graphical Notation.pdf (2023 03 07)
Intro to the SysML v2 Language-Textual Notation.pdf Release: 2023-02
Example of difference, on page 218 of "2-OMG_Systems_Modeling_Language.pdf", the stereotype identifier (<<state>>) is not displayed for State1 and State2, in the "Intro to the SysML v2 Language-Graphical Notation.pdf", the "<<state>>" is displayed.
If you then take a look at the "Intro to the SysML v2 Language-Textual Notation.pdf" document, there is again a different graphical notation.
What is the correct standard notation? Does the "2-OMG_Systems_Modeling_Language.pdf" take precedence here?
There are different implementations of the SysML v2 graphical notation in the various release documents
Documents checked:
2-OMG_Systems_Modeling_Language.pdf Version 2.0 Release 2023-02
Intro to the SysML v2 Language-Graphical Notation.pdf (2023 03 07)
Intro to the SysML v2 Language-Textual Notation.pdf Release: 2023-02
Example of difference, on page 218 of "2-OMG_Systems_Modeling_Language.pdf", the stereotype identifier (<<state>>) is not displayed for State1 and State2, in the "Intro to the SysML v2 Language-Graphical Notation.pdf", the "<<state>>" is displayed.
If you then take a look at the "Intro to the SysML v2 Language-Textual Notation.pdf" document, there is again a different graphical notation.
What is the correct standard notation? Does the "2-OMG_Systems_Modeling_Language.pdf" take precedence here?
Package-level features do not give featuring types, and some have lower multiplicity greater than zero, meaning everything in the universe (instances of Anything), including every data value, is required to give at least that number of values to them (see KERML-56). For example, the libraries include:
Time::universalClock[1] {...}
Observation::defaultMonitor[1] : ChangeMonitor[1] {...}
SpatialFrames::defaultFrame : SpatialFrame[1] {...}
Might be others.
Clause 7 Language Description includes a large number of example models and snippets, in textual and graphical notation. However, no machine-readable interchange file was submitted for these models. Project interchange files should be provided for them, including textual notation, XMI and JSON versions.
There is a machine-readable file containing the example model described in Annex A, but only in the textual notation. There should also be machine-readable versions of this model represented in XMI and JSON.
In SysML 1.7, Clause 10.1 (Overview, Constraint Blocks) and 10.3.2.1 (ConstraintBlock) say:
Constraint blocks define generic forms of constraints that can be used in multiple contexts. For example, a definition for Newton’s Laws may be used to specify these constraints in many different contexts. Constraint blocks can be used to specify a network of constraints that represent mathematical expressions such as {F=m*a} and {a=dv/dt}, which constrain the physical properties of a system.
A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used.
enabling an equation to "calculate" any of its variables (constraint parameters), to the extent it's reversible, depending on its usage. For example a constraint block for F=m*a can calculate any on of its variables given the other two by where it's used. But in SysML v1 to SysML v2 Transformation, 7.8.5.2.1 (ConstraintBlock_Mapping) says
A SysML::ConstraintBlocks::ConstraintBlock is mapped to a SysML v2 ConstraintDefinition. The following shows an example of what the textual SysML v2 syntax of the result of the transformation may look like.
onstraint def SysMLv1ConstraintBlock { in attribute a : ScalarValues::Integer; in attribute b : ScalarValues::Integer; in attribute c : ScalarValues::Integer; constraint constraintExpression { language "OCL2.0" /* c == a + b */ } }
suggests constraint parameters are mapped to attributes with direction in, preventing them from being "calculated" from within the constraint (see KERML-10).
Not sure if the above is encoded in the mapping rules, but perhaps related is 7.8.5.2.2 (ConstraintParameter_Mapping), under Mapping Rules, says
The mapping class only has inherited rules. See the mapping classes in the general mapping section for details.
which means nothing specific is required for mapping constraint parameters. I couldn't find a "general mapping section".
There is a machine-readable file containing the example model described in Annex A, but only in the textual notation. There should also be machine-readable versions of this model represented in XMI and JSON.
In SysML 1.7, Clause 10.1 (Overview, Constraint Blocks) and 10.3.2.1 (ConstraintBlock) say:
Constraint blocks define generic forms of constraints that can be used in multiple contexts. For example, a definition for Newton’s Laws may be used to specify these constraints in many different contexts. Constraint blocks can be used to specify a network of constraints that represent mathematical expressions such as {F=m*a} and {a=dv/dt}, which constrain the physical properties of a system.
A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used.
enabling an equation to "calculate" any of its variables (constraint parameters), to the extent it's reversible, depending on its usage. For example a constraint block for F=m*a can calculate any on of its variables given the other two by where it's used. But in SysML v1 to SysML v2 Transformation, 7.8.5.2.1 (ConstraintBlock_Mapping) says
A SysML::ConstraintBlocks::ConstraintBlock is mapped to a SysML v2 ConstraintDefinition. The following shows an example of what the textual SysML v2 syntax of the result of the transformation may look like.
onstraint def SysMLv1ConstraintBlock { in attribute a : ScalarValues::Integer; in attribute b : ScalarValues::Integer; in attribute c : ScalarValues::Integer; constraint constraintExpression { language "OCL2.0" /* c == a + b */ } }
suggests constraint parameters are mapped to attributes with direction in, preventing them from being "calculated" from within the constraint (see KERML-10).
Not sure if the above is encoded in the mapping rules, but perhaps related is 7.8.5.2.2 (ConstraintParameter_Mapping), under Mapping Rules, says
The mapping class only has inherited rules. See the mapping classes in the general mapping section for details.
which means nothing specific is required for mapping constraint parameters. I couldn't find a "general mapping section".
Package-level features do not give featuring types, and some have lower multiplicity greater than zero, meaning everything in the universe (instances of Anything), including every data value, is required to give at least that number of values to them (see KERML-56). For example, the libraries include:
Time::universalClock[1] {...}
Observation::defaultMonitor[1] : ChangeMonitor[1] {...}
SpatialFrames::defaultFrame : SpatialFrame[1] {...}
Might be others.
Clause 7 Language Description includes a large number of example models and snippets, in textual and graphical notation. However, no machine-readable interchange file was submitted for these models. Project interchange files should be provided for them, including textual notation, XMI and JSON versions.
Clause 8.3.16.5 (AssignmentActionUsage), Description, says:
An AssignmentActionUsage is an ActionUsage that is defined, directly or indirectly, by the ActionDefinition AssignmentAction from the Systems Model Library. It specifies that the value of the referent Feature, relative to the target given by the result of the targetArgument Expression, should be set to the result of the valueExpression.
but does not require the model to specify when the expression is evaluated (or its owner, AFAICT).
Clause 8.3.16.5 (AssignmentActionUsage), Description, says:
An AssignmentActionUsage is an ActionUsage that is defined, directly or indirectly, by the ActionDefinition AssignmentAction from the Systems Model Library. It specifies that the value of the referent Feature, relative to the target given by the result of the targetArgument Expression, should be set to the result of the valueExpression.
but does not require the model to specify when the expression is evaluated (or its owner, AFAICT).
In 7.24.1 Use Cases Overview, in the third paragraph, it states:
The subject of the included use case is the same as the subject of the containing use case...
In 7.24.3 Include Use Case Usages, in the third paragraph, it also states:
The subject of an included use case usage is bound by default to the subject of its containing use case definition or usage.
However, there is no semantic constraint in the abstract syntax to enforce this.
In 7.17.3 Transition Usages, in the fourth text paragraph, it states:
Transition usages from the entry action are not allowed to have accepters.
There is no validation constraint for this in the abstract syntax.
Is this constraint necessary? If so, a validation constraint should be added. If not, the statement in 7.17.3 should be removed.
The transformation does not specify mapping rules for SysMLv1::Overwrite.
The transformation does not specify mapping rules for SysMLv1::NoBuffer.
In 7.24.1 Use Cases Overview, in the third paragraph, it states:
The subject of the included use case is the same as the subject of the containing use case...
In 7.24.3 Include Use Case Usages, in the third paragraph, it also states:
The subject of an included use case usage is bound by default to the subject of its containing use case definition or usage.
However, there is no semantic constraint in the abstract syntax to enforce this.
In 7.17.3 Transition Usages, in the fourth text paragraph, it states:
Transition usages from the entry action are not allowed to have accepters.
There is no validation constraint for this in the abstract syntax.
Is this constraint necessary? If so, a validation constraint should be added. If not, the statement in 7.17.3 should be removed.
The transformation does not specify mapping rules for SysMLv1::NoBuffer.
The transformation does not specify mapping rules for SysMLv1::Overwrite.
The transformation does not specify mapping rules for SysMLv1::BoundReference.
The transformation does not specify mapping rules for SysMLv1::AllocateActivityPartition.
The transformation does not specify mapping rules for SysMLv1::EndPathMultiplicity.
The transformation does not specify mapping rules for SysMLv1::PropertySpecificType.
The transformation does not specify mapping rules for SysMLv1::ParticipantProperty.
The transformation does not specify mapping rules for SysMLv1::ParticipantProperty.
The transformation does not specify mapping rules for SysMLv1::BoundReference.
The transformation does not specify mapping rules for SysMLv1::PropertySpecificType.
The transformation does not specify mapping rules for SysMLv1::EndPathMultiplicity.
The transformation does not specify mapping rules for SysMLv1::AllocateActivityPartition.
The transformation does not specify mapping rules for SysMLv1::InvocationOnNestedPortAction.
The transformation does not specify mapping rules for SysMLv1::View.
The transformation does not specify mapping rules for SysMLv1::DistributedProperty.
The transformation does not specify mapping rules for SysMLv1::Conform.
The transformation does not specify mapping rules for SysMLv1::Expose.
The transformation does not specify mapping rules for SysMLv1::InvocationOnNestedPortAction.
The transformation does not specify mapping rules for SysMLv1::Expose.
The transformation does not specify mapping rules for SysMLv1::DistributedProperty.
The transformation does not specify mapping rules for SysMLv1::View.
The transformation does not specify mapping rules for SysMLv1::Conform.
The transformation does not specify mapping rules for SysMLv1::AddFlowPropertyValueOnNestedPortAction.
The transformation does not specify mapping rules for SysMLv1::ChangeStructuralFeatureEvent.
The transformation does not specify mapping rules for UML4SysML::UnmarshallAction.
The transformation does not specify mapping rules for SysMLv1::TriggerOnNestedPort.
The transformation does not specify mapping rules for SysMLv1::ChangeStructuralFeatureEvent.
The transformation does not specify mapping rules for UML4SysML::UnmarshallAction.
The transformation does not specify mapping rules for SysMLv1::AddFlowPropertyValueOnNestedPortAction.
The transformation does not specify mapping rules for SysMLv1::TriggerOnNestedPort.
The transformation does not specify mapping rules for SysMLv1::FlowProperty.
The transformation does not specify mapping rules for SysMLv1::FlowProperty.
The transformation does not specify mapping rules for UML4SysML::LinkEndDestructionData.
The transformation does not specify mapping rules for UML4SysML::LinkEndCreationData.
The transformation does not specify mapping rules for UML4SysML::ConditionalNode.
The transformation does not specify mapping rules for UML4SysML::Clause.
The transformation does not specify mapping rules for UML4SysML::LinkEndData.
The transformation does not specify mapping rules for UML4SysML::LinkEndDestructionData.
The transformation does not specify mapping rules for UML4SysML::ActivityPartition.
The transformation does not specify mapping rules for UML4SysML::ConditionalNode.
The transformation does not specify mapping rules for UML4SysML::LinkEndCreationData.
The transformation does not specify mapping rules for UML4SysML::Clause.
The transformation does not specify mapping rules for UML4SysML::ActivityPartition.
The transformation does not specify mapping rules for UML4SysML::LinkEndData.
The transformation does not specify mapping rules for UML4SysML::ExecutionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::InteractionConstraint.
The transformation does not specify mapping rules for UML4SysML::OccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::Gate.
The transformation does not specify mapping rules for UML4SysML::OccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::InteractionConstraint.
The transformation does not specify mapping rules for UML4SysML::ExecutionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::Gate.
The transformation does not specify mapping rules for UML4SysML::Continuation.
The transformation does not specify mapping rules for UML4SysML::ConsiderIgnoreFragment.
The transformation does not specify mapping rules for UML4SysML::GeneralOrdering.
The transformation does not specify mapping rules for UML4SysML::PartDecomposition.
The transformation does not specify mapping rules for UML4SysML::PartDecomposition.
The transformation does not specify mapping rules for UML4SysML::Continuation.
The transformation does not specify mapping rules for UML4SysML::ConsiderIgnoreFragment.
The transformation does not specify mapping rules for UML4SysML::GeneralOrdering.
The transformation does not specify mapping rules for UML4SysML::DestructionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::Interval.
The transformation does not specify mapping rules for UML4SysML::Image.
The transformation does not specify mapping rules for UML4SysML::DurationInterval.
The transformation does not specify mapping rules for UML4SysML::TimeConstraint.
The transformation does not specify mapping rules for UML4SysML::DurationInterval.
The transformation does not specify mapping rules for UML4SysML::Image.
The transformation does not specify mapping rules for UML4SysML::TimeConstraint.
The transformation does not specify mapping rules for UML4SysML::Interval.
The transformation does not specify mapping rules for UML4SysML::DestructionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::IntervalConstraint.
The transformation does not specify mapping rules for UML4SysML::TimeObservation.
The transformation does not specify mapping rules for UML4SysML::Duration.
The transformation does not specify mapping rules for UML4SysML::DurationObservation.
The transformation does not specify mapping rules for UML4SysML::StringExpression.
The transformation does not specify mapping rules for UML4SysML::Duration.
The transformation does not specify mapping rules for UML4SysML::DurationObservation.
The transformation does not specify mapping rules for UML4SysML::StringExpression.
The transformation does not specify mapping rules for UML4SysML::TimeObservation.
The transformation does not specify mapping rules for UML4SysML::IntervalConstraint.
The transformation does not specify mapping rules for UML4SysML::DurationConstraint.
The details of the mapping of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode are not specified.
The mapping of a UML4SysML::ActivityFinalNode is not covered by the transformation rules.
The extend relationship between use cases is not covered by the transformation.
The transformation does not specify mapping rules for UML4SysML::TimeInterval.
The extend relationship between use cases is not covered by the transformation.
The transformation does not specify mapping rules for UML4SysML::DurationConstraint.
The details of the mapping of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode are not specified.
The transformation does not specify mapping rules for UML4SysML::TimeInterval.
In 7.16.5 Conditional Successions, in the second paragraph, it states:
Further, the keyword else may be used in place of a guard expression to indicate a succession to be taken if the guards evaluate to false on all of an immediately preceding set of conditional successions.
In 8.2.2.16.7, a conditional succession with the else keyword is parsed as a TransitionUsage that simply does not have a guard condition:
DefaultTargetSuccession : TransitionUsage =
'else' ownedRelationship += TransitionSuccessionMember
However, the semantics of such a TransitionUsage would seem to be that it can be taken unconditionally, not that it can only be taken if preceding conditional successions have guards that evaluate to false. The else case is not mentioned at all in 8.4.12.3 Decision Transition Usages, which covers the semantics of conditional successions.
In 7.16.1 Actions Overview, in the "Bindings and Flows Between Actions" section, it states in the last paragraph (italics added):
A send action usage includes an expression that is evaluated to provide the values to be transferred, and it specifies the destination to which those values are to be sent (possibly delegated through a port and across one or more interfaces – see also 7.12 and 7.14 on interfaces between ports).
However, the semantics of "delagation across an interface", per the italicized part above, are not described in 7.12 or 7.14, nor are they specified in 8.4.10 Interfaces Semantics.
The transformation does not include a mapping for UML4SysML::GeneralizationSet.
The transformation does not include a mapping for UML4SysML::GeneralizationSet.
In 7.16.5 Conditional Successions, in the second paragraph, it states:
Further, the keyword else may be used in place of a guard expression to indicate a succession to be taken if the guards evaluate to false on all of an immediately preceding set of conditional successions.
In 8.2.2.16.7, a conditional succession with the else keyword is parsed as a TransitionUsage that simply does not have a guard condition:
DefaultTargetSuccession : TransitionUsage =
'else' ownedRelationship += TransitionSuccessionMember
However, the semantics of such a TransitionUsage would seem to be that it can be taken unconditionally, not that it can only be taken if preceding conditional successions have guards that evaluate to false. The else case is not mentioned at all in 8.4.12.3 Decision Transition Usages, which covers the semantics of conditional successions.
In 7.16.1 Actions Overview, in the "Bindings and Flows Between Actions" section, it states in the last paragraph (italics added):
A send action usage includes an expression that is evaluated to provide the values to be transferred, and it specifies the destination to which those values are to be sent (possibly delegated through a port and across one or more interfaces – see also 7.12 and 7.14 on interfaces between ports).
However, the semantics of "delagation across an interface", per the italicized part above, are not described in 7.12 or 7.14, nor are they specified in 8.4.10 Interfaces Semantics.
In 7.12.1 Ports Overview, at the end of the third paragraph, it states
A transfer can occur from the out features of one port usage to the matching in features of connected port usages. Transfers can occur in both directions between matching inout features.
It is unclear whether this is intended to mean that such transfers happen automatically in some way, or if it just means that it is possible to have such transfers by adding explicit flows to the model. If the former is intended, then this does not seem to be currently supported by port semantics (8.4.8). If the latter is intended, this should be made more clear.
In 7.12.1 Ports Overview, at the end of the third paragraph, it states
A transfer can occur from the out features of one port usage to the matching in features of connected port usages. Transfers can occur in both directions between matching inout features.
It is unclear whether this is intended to mean that such transfers happen automatically in some way, or if it just means that it is possible to have such transfers by adding explicit flows to the model. If the former is intended, then this does not seem to be currently supported by port semantics (8.4.8). If the latter is intended, this should be made more clear.
There should be a Constants Domain Library that capture all mathematical and CODATA Fundamental Physical Constants as published on https://pml.nist.gov/cuu/Constants/, in particular from the ASCII list of all constants at https://pml.nist.gov/cuu/Constants/Table/allascii.txt. Each constant should include a specification of whether its real number value is exact or not and, if not, what the uncertainty is.
Multiplicities and bound values of redefining features don't seem to show up in the specification. For example, Clause 9.7.3.2.40 (Toroid) redefines edges, faces, and genus, but does not show the redefining multiplicities or bound values that appear in ShapeItems.kerml and the repository from which this part of the spec was generated. Might be other kinds of information missing on other redefining features.
Project interchange files (.kpar) were submitted for all model libraries. However, in all cases, these archives only included textual notation model interchange files (.sysml). There should also be normative model library project interchange files in which the models are formatted in XMI and JSON.
In 7.15.1 Allocations Overview, Table 17, entry for "Allocation (with sub allocation)", the name acton1 in the graphical notation should be action1.
Multiplicities and bound values of redefining features don't seem to show up in the specification. For example, Clause 9.7.3.2.40 (Toroid) redefines edges, faces, and genus, but does not show the redefining multiplicities or bound values that appear in ShapeItems.kerml and the repository from which this part of the spec was generated. Might be other kinds of information missing on other redefining features.
In 7.15.1 Allocations Overview, Table 17, entry for "Allocation (with sub allocation)", the name acton1 in the graphical notation should be action1.
Project interchange files (.kpar) were submitted for all model libraries. However, in all cases, these archives only included textual notation model interchange files (.sysml). There should also be normative model library project interchange files in which the models are formatted in XMI and JSON.
There should be a Constants Domain Library that capture all mathematical and CODATA Fundamental Physical Constants as published on https://pml.nist.gov/cuu/Constants/, in particular from the ASCII list of all constants at https://pml.nist.gov/cuu/Constants/Table/allascii.txt. Each constant should include a specification of whether its real number value is exact or not and, if not, what the uncertainty is.
The SysML v2 RFP included Requirement PRP 1.15 “Probabilistic Value Distributions", which stated:
Proposals for SysML v2 shall include a capability to represent the value of a quantity with a probabilistic value distribution, including an extensible mechanism to detail the kind of distribution, i.e. the probability density function for continuous random variables, or the probability mass function for discrete random variables.
This requirement was not satisfied in the SysML specification as submitted. A capability should be added that covers this requirement. It should at least be possible to represent a numerical value as a symmetric or asymmetric accuracy, uncertainty or tolerance, with a uniform (i.e., rectangular) distribution.
The SysML v2 RFP included Requirement PRP 1.15 “Probabilistic Value Distributions", which stated:
Proposals for SysML v2 shall include a capability to represent the value of a quantity with a probabilistic value distribution, including an extensible mechanism to detail the kind of distribution, i.e. the probability density function for continuous random variables, or the probability mass function for discrete random variables.
This requirement was not satisfied in the SysML specification as submitted. A capability should be added that covers this requirement. It should at least be possible to represent a numerical value as a symmetric or asymmetric accuracy, uncertainty or tolerance, with a uniform (i.e., rectangular) distribution.
A variant is an owned member of its variation and is also a specialization of its variation. As a result, the variant inherits the owned member relationships from its variation.
This appears in the diagram in the attached example (file name: variant_inheritance_from_variation_issue_sf_2023-04-12). The transmissionAutomatic has an inherited ownedMembership to the transmissionManual and to itself. This applies to the transmissionManual as well.
Refer to the spec clauses as 8.2.3.5 Namespaces and Packages Graphical Notation and 8.2.3.6 for Definition and Usage Graphical Notation (where variation is introduced).
The US Customary Units as specified in NIST SP811 Annex B include a number of units for which the corresponding quantity is not defined in ISO/IEC 80000, the International System of Quantities (ISQ). These units are currently commented out in Quantities and Units Domain Library USCustomaryUnits. Examples are:
//attribute <'Btu_IT/ft³'> 'British thermal unit (IT) per cubic foot' : EnergyDensityUnit = Btu_IT/ft^3; //attribute <'gal/(hp⋅h)'> 'gallon (US) per horsepower hour' : EnergySpecificVolumeUnit = gal/(hp*h); //attribute <'mi/gal'> 'mile per gallon (US)' : FuelEconomyUnit = mi/gal; //attribute <'lb/(hp⋅h)'> 'pound per horsepower hour' : FuelConsumptionUnit = lb/(hp*h);
An additional extension package for ISQ is needed that declares the attribute definitions for the missing quantity and measurement unit types, e.g.:
It should be considered whether or not to include the new library package inside ISQ, as formally these quantity and unit types are not part of ISO/IEC 800000.
There is no Graphical BNF for grid rendering, required by the Grid View Standard View Definition.
This should be added.
A variant is an owned member of its variation and is also a specialization of its variation. As a result, the variant inherits the owned member relationships from its variation.
This appears in the diagram in the attached example (file name: variant_inheritance_from_variation_issue_sf_2023-04-12). The transmissionAutomatic has an inherited ownedMembership to the transmissionManual and to itself. This applies to the transmissionManual as well.
Refer to the spec clauses as 8.2.3.5 Namespaces and Packages Graphical Notation and 8.2.3.6 for Definition and Usage Graphical Notation (where variation is introduced).
There is no Graphical BNF for grid rendering, required by the Grid View Standard View Definition.
This should be added.
The US Customary Units as specified in NIST SP811 Annex B include a number of units for which the corresponding quantity is not defined in ISO/IEC 80000, the International System of Quantities (ISQ). These units are currently commented out in Quantities and Units Domain Library USCustomaryUnits. Examples are:
//attribute <'Btu_IT/ft³'> 'British thermal unit (IT) per cubic foot' : EnergyDensityUnit = Btu_IT/ft^3; //attribute <'gal/(hp⋅h)'> 'gallon (US) per horsepower hour' : EnergySpecificVolumeUnit = gal/(hp*h); //attribute <'mi/gal'> 'mile per gallon (US)' : FuelEconomyUnit = mi/gal; //attribute <'lb/(hp⋅h)'> 'pound per horsepower hour' : FuelConsumptionUnit = lb/(hp*h);
An additional extension package for ISQ is needed that declares the attribute definitions for the missing quantity and measurement unit types, e.g.:
It should be considered whether or not to include the new library package inside ISQ, as formally these quantity and unit types are not part of ISO/IEC 800000.
The declaration of attribute def Iso860DateTimeEncoding in the Quantities and Units Domain Library model Time.sysml still has a TODO comment (line 199):
* TODO: Add constraint to verify ISO 8691 extended string encoding.
The declaration of attribute def Iso860DateTimeEncoding in the Quantities and Units Domain Library model Time.sysml still has a TODO comment (line 199):
* TODO: Add constraint to verify ISO 8691 extended string encoding.
In subclause 7.13.1, Table 15, in example "Flows Compartment" the graphical notation is missing. Graphical notation corresponding to the example expressed in textual notation should be added. Also, the corresponding graphical BNF production for flows-compartment is missing in subclause 8.2.3.13, so that should be added too.
A mapping of the Graphical BNF productions to the abstract syntax has not been addressed.
If no specific proposal is considered by the FTF, it may be worth including some discussion notes in the spec in place of any detailed mapping.
Lifeline elements need to be included within the lifeline itself, with connector segments above and below, and occurrences of * within the lifeline, similar to boundary elements.
Currently, distinguished parameters like subject, actor, stakeholder, do not stand out in the graphical notation for symbols that use them.
Consider allowing distinguished parameters in the name compartment of elements that use them, such as RequirementDefinition, RequirementUsage, UseCaseDefinition, UseCaseUsage, etc.
The graphical BNF for binary ConnectionDefinition does not clearly indicate the source and target ends.
The graphical BNF should provide the optional ability to include source and target notation, with arrow head or source and target keywords.
Lifeline elements need to be included within the lifeline itself, with connector segments above and below, and occurrences of * within the lifeline, similar to boundary elements.
Currently, distinguished parameters like subject, actor, stakeholder, do not stand out in the graphical notation for symbols that use them.
Consider allowing distinguished parameters in the name compartment of elements that use them, such as RequirementDefinition, RequirementUsage, UseCaseDefinition, UseCaseUsage, etc.
In subclause 7.13.1, Table 15, in example "Flows Compartment" the graphical notation is missing. Graphical notation corresponding to the example expressed in textual notation should be added. Also, the corresponding graphical BNF production for flows-compartment is missing in subclause 8.2.3.13, so that should be added too.
A mapping of the Graphical BNF productions to the abstract syntax has not been addressed.
If no specific proposal is considered by the FTF, it may be worth including some discussion notes in the spec in place of any detailed mapping.
The graphical BNF for binary ConnectionDefinition does not clearly indicate the source and target ends.
The graphical BNF should provide the optional ability to include source and target notation, with arrow head or source and target keywords.
Explicit concepts for ratio, RatioValue and RatioUnit are missing from ISQ and SI, although they are highly relevant and often used.
Similarly fraction, FractionValue and FractionUnit would be useful.
Add these concepts as specializations of DimensionOneValue and DimensionOneUnit.
Also add units <'%'> percent, <ppm> 'parts per million', <pbm> 'parts per billion'. For parts per billion it is important to explicitly chose the US or UK billion (10^9 vs 10^12).
BNF production is missing for n-ary connection def and connection usage as in examples shown in the representative notation table in 7.13.1 Connections Overview. Must be fixed in 8.2.3.13.
Check all examples of n-ary connections (including causation and requirements derivation) to replace arrowheads with bolded end names. Connections of 3 or more ends only have target ends, no source ends, see KerML spec clause 7.4.5.
The line-arrows in the current graphical notation for ports with directional features are badly readable in large, busy diagrams.
The same solid triangular arrow symbols as for parameters should be used on ports with directional features.
BNF production is missing for n-ary connection def and connection usage as in examples shown in the representative notation table in 7.13.1 Connections Overview. Must be fixed in 8.2.3.13.
Check all examples of n-ary connections (including causation and requirements derivation) to replace arrowheads with bolded end names. Connections of 3 or more ends only have target ends, no source ends, see KerML spec clause 7.4.5.
Explicit concepts for ratio, RatioValue and RatioUnit are missing from ISQ and SI, although they are highly relevant and often used.
Similarly fraction, FractionValue and FractionUnit would be useful.
Add these concepts as specializations of DimensionOneValue and DimensionOneUnit.
Also add units <'%'> percent, <ppm> 'parts per million', <pbm> 'parts per billion'. For parts per billion it is important to explicitly chose the US or UK billion (10^9 vs 10^12).
The line-arrows in the current graphical notation for ports with directional features are badly readable in large, busy diagrams.
The same solid triangular arrow symbols as for parameters should be used on ports with directional features.
The current graphical notation for parameters is similar to SysML v1, i.e. a (rounded) square attached to outside of the border of an action symbol. A directional parameter has a line arrow indicating in, out or inout direction. The notation is inconsistently depicted: both full squares outside the border and half squares outside the border (like in SysML v1) are used. See e.g., Representative Notation Table in section 7.16.1 page 194.
There should be a single standard notation that is clearly differentiated from port symbols. Also, the direction arrows should be clearly readable in large and busy diagrams with many parameters (nested and non-nested).
Alternative parameter symbol notation has been developed that uses a circular shape that straddles the border of the owning action (definition or usage), and has solid triangular arrow symbols.
The current graphical notation for parameters is similar to SysML v1, i.e. a (rounded) square attached to outside of the border of an action symbol. A directional parameter has a line arrow indicating in, out or inout direction. The notation is inconsistently depicted: both full squares outside the border and half squares outside the border (like in SysML v1) are used. See e.g., Representative Notation Table in section 7.16.1 page 194.
There should be a single standard notation that is clearly differentiated from port symbols. Also, the direction arrows should be clearly readable in large and busy diagrams with many parameters (nested and non-nested).
Alternative parameter symbol notation has been developed that uses a circular shape that straddles the border of the owning action (definition or usage), and has solid triangular arrow symbols.
The loop examples in representative notation table for section 7.16 are incomplete, only two until-loops are shown.
Add while-loop and for-loop action examples in the representative notation table for Actions (after until-loops).
Requirement derivation, cause effect, and refinement are missing in the representative notation tables.
Add examples in both graphical and textual notation for requirement derivation, cause effect, and refinement.
proxy refers to proxy-label should be sq-proxy-label
The BNF attempted to reuse the proxy graphics and productions across all three contexts where a proxy may appear (lifeline, ports, and parameters), but all these need to be replaced by proxy graphics specific to each context, including connector line segments above and below, or left and right, in each specific graphic context where a proxy dot may appear.
The graphical notation is lacking support to express metadata
The graphical notation should be updated with support for specification of user defined keywords and use of the meta keyword as a shortcut for elementName.metadata as Metaclass.
See also the explanation in https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/releases/tag/2022-09 .
No productions for case view. All case-related productions were included in general view, since no specific subset was finalized during discussions. Consider defining as a subset view, like other general view subsets. Incorrect reference to 9.2.19.1.
Standard geometric view is identified, but contents are not specified yet. An initial description is given in the doc comment in 9.2.19 library element <gev> GeometricView.
Requirement derivation, cause effect, and refinement are missing in the representative notation tables.
Add examples in both graphical and textual notation for requirement derivation, cause effect, and refinement.
The loop examples in representative notation table for section 7.16 are incomplete, only two until-loops are shown.
Add while-loop and for-loop action examples in the representative notation table for Actions (after until-loops).
proxy refers to proxy-label should be sq-proxy-label
The BNF attempted to reuse the proxy graphics and productions across all three contexts where a proxy may appear (lifeline, ports, and parameters), but all these need to be replaced by proxy graphics specific to each context, including connector line segments above and below, or left and right, in each specific graphic context where a proxy dot may appear.
Standard geometric view is identified, but contents are not specified yet. An initial description is given in the doc comment in 9.2.19 library element <gev> GeometricView.
The graphical notation is lacking support to express metadata
The graphical notation should be updated with support for specification of user defined keywords and use of the meta keyword as a shortcut for elementName.metadata as Metaclass.
See also the explanation in https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/releases/tag/2022-09 .
No productions for case view. All case-related productions were included in general view, since no specific subset was finalized during discussions. Consider defining as a subset view, like other general view subsets. Incorrect reference to 9.2.19.1.
Currently sq-ev-occurrence is denoted as an "X", which is not used anywhere else. Should it be rather the proxy notation, i.e., a black dot?
Clarify how to show the owning context for a nested feature in a graphical view such as a state transition view (Proposed solution: consider 'exhibited by vehicle' for state transition view of vehicleStates).
The textual notation should be regularized between the until loop and while loop.
The proposed update is loop while action actionName where action and actionName are optional.
Clarify how to show the owning context for a nested feature in a graphical view such as a state transition view (Proposed solution: consider 'exhibited by vehicle' for state transition view of vehicleStates).
The textual notation should be regularized between the until loop and while loop.
The proposed update is loop while action actionName where action and actionName are optional.
Currently sq-ev-occurrence is denoted as an "X", which is not used anywhere else. Should it be rather the proxy notation, i.e., a black dot?
Identify the implications of views on the model organization and how to mitigate circular dependencies.
Approaches to representing nested views
Example (representing nested parts tree). The default case is to apply the same rendering method to each element. In effect, the rendering method and filter is inherited by all elements in the view.
Case 1. Specify view rendering for each element in the view (e.g., show nested parts as a tree view for some parts and interconnection view for others)
Case 2. View exposes packages with views
Case 3. View contains nested views
The graphical notation for allocating a flow to a connection, that is consistent with textual notation, is missing.
This should be added.
Add standardized element icons and standard view definition icons as they should appear in a browser or on diagrams.
How a view/query is performed when using a view as an input mode is unspecified.
This should be clarified and added.
There should be explicit specification and explanation, that a diagram and a compartment are views, as well as clarification on how the filter notation can be applied to a view compartment and to a diagram. Consider an extension to the filter notation.
Identify the implications of views on the model organization and how to mitigate circular dependencies.
Approaches to representing nested views
Example (representing nested parts tree). The default case is to apply the same rendering method to each element. In effect, the rendering method and filter is inherited by all elements in the view.
Case 1. Specify view rendering for each element in the view (e.g., show nested parts as a tree view for some parts and interconnection view for others)
Case 2. View exposes packages with views
Case 3. View contains nested views
There should be explicit specification and explanation, that a diagram and a compartment are views, as well as clarification on how the filter notation can be applied to a view compartment and to a diagram. Consider an extension to the filter notation.
The graphical notation for allocating a flow to a connection, that is consistent with textual notation, is missing.
This should be added.
Add standardized element icons and standard view definition icons as they should appear in a browser or on diagrams.
How a view/query is performed when using a view as an input mode is unspecified.
This should be clarified and added.
Specifications of the standard views in library StandardViewDefinitions.sysml are incomplete, i.e. they are not all formally specified with a filter expression.
Specify valid Definitions as a filter expression for each ViewDefinition. Initial specifications are in textual descriptions in clauses 9.2.19.2.x.
The section describing the mapping class TestCaseVerifyObjectiveMembership_Mapping is incomplete. The subsections Description, General Mappings, Mapping Source, Mapping Target, and Owned Mappings are missing.
The transformation does not consider the property UML4SysML::RemoveVariableValueAction::isRemoveDuplicates.
Specifications of the standard views in library StandardViewDefinitions.sysml are incomplete, i.e. they are not all formally specified with a filter expression.
Specify valid Definitions as a filter expression for each ViewDefinition. Initial specifications are in textual descriptions in clauses 9.2.19.2.x.
The section describing the mapping class TestCaseVerifyObjectiveMembership_Mapping is incomplete. The subsections Description, General Mappings, Mapping Source, Mapping Target, and Owned Mappings are missing.
The transformation does not consider the property UML4SysML::RemoveVariableValueAction::isRemoveDuplicates.
The spec says: "DataVersion.identity should be populated with the DataIdentity that will be deleted in the new commit. When a DataIdentity is deleted in a commit, all its versions (DataVersion) are also deleted,"
This sounds wrong - presumably DataVersions referenced by earlier Commits need to be maintained. This does seem to be the way that the reference implementation behaves.
The documentation for the constraint validateClassSpecializtion states:
A Class must not specialize a DataType and it can only specialize an Association if it is an AssociationStructure.
with the OCL
ownedSpecialization.general->
forAll(not oclIsKindOf(DataType)) and
not oclIsKindOf(AssociationStructure) implies
ownedSpecialization.general->
forAll(not oclIsKindOf(Association))
However, an Interaction is both a Behavior, which is a kind of Class, and an Association, and, for example, the library interaction Transfer specializes both Performance (a behavior) and BinaryLink (an association). But the above constraint disallows this specialization.
The validateClassSpecialization constraint needs to be updated to allow both AssociationStructures and Interactions to specialize Associations.
The Kernel Standard Library model for Transfers includes the following features, documented in subclauses of 9.2.7.2:
In all these cases, the "Element" kind is documented simply as "Feature". However, in the normative Transfers.kerml file, all of these features are actually declared as steps.
The interaction FlowTransferBefore in the Transfers library package specializes both FlowTransfer and TransferBefore. Both FlowTransfer and TransferBefore are binary, so FlowTransferBefore has to be, too. However, in the normative Transfers.kerml file from the Kernel Semantic Library project, FlowTransferBefore is currently declared without owned end features, so it inherits two ends each from FlowTransfer and TransferBefore, for a total of four, which is incorrect. Instead, it needs to declare two nested end features that redefine the corresponding ends from each of the interactions it specializes.
(Note that, in subclause 9.2.7.2.3 of the specification document, FlowTransferBefore is actually documented as properly having two owned ends.)
While reading through Release 2023-02 of the Systems Modeling Application Programming Interface (API) and Services.pdf i think the following is incorrect:
Project: missing property created:ISO8601DateTime
Branch: owningProject is the Project that owns the given Branch -> this property should not be described here as Branch is a subclass of CommitReference which already has a property called owningProject
Tag: owningProject is the Project that owns the given Tag-> this property should not be described here as Tag is a subclass of CommitReference which already has a property called owningProject
The src property in the filter condition should be from.
The src property in the filter condition should be from.
All sections in the specification that end with "elements not mapped" should list tables of elements that are not considered by the transformation including a rationale. The tables are listed in the List of Tables of the document.
As a table or in an alternative presentation form, the information about unmapped elements should be described in the appropriate sections of the specification.
Note: this is not an issue with the SysML v2 specification itself, but rather with the tooling to produce it.
Currently, the graphical notation in the representative notation tables (and for Graphical BNF) is created using an adapted version of the open source tool diagrams.net (https:// www.diagrams.net) in .drawio format. The production workflow is very labor-intensive, cumbersome and therefore error-prone.
A new, efficient and maintainable workflow using improved tooling should be considered. Preferably, the produced graphical artifacts should in SVG format. The workflow shall also be compatible with the KerML and SysML v2 specification authoring environment.
Clause 9.2.4.1 (Occurrences Overview), under Temporal and Spatial Associations, describes temporal/spatial relations between occurrences, such as HappensBefore/Outside and HappensDuring/InsideOf, then says:
The Links above to do not take up time or space, they are temporal and spatial relations between things that do (they are disjoint with LinkObject, see 9.2.5.1).
but
Specifications of the standard views in library `StandardViewDefinitions.sysml` are incomplete, i.e. they are not all formally specified with a filter expression.
Identify valid element kinds as filter expression for each ViewDefinition. Initial set is specified in clause 9.2.19. Elaborate remaining filter expressions from initial description in comments.
(Derived from GSWG ID#01).
The Model Interchange Project file in the Cause and Effect Domain Library Project Interchange File is named .proj.json. It should be .project.json.
In subclause 8.4.10.2, at the beginning of the second bullet, checkInterfaceDefinitionBinarySpecialization should be checkInterfaceUsageBinarySpecialization ("...Usage..." instead of "...Definition...").
In Figure 8. Definition and Usage (subclause 8.3.6.1), the opposite association end to Usage::directedUsage appears on the diagram as /usageWithDirectedUsage, where the slash indicates it is derived, and the property name is usageWithDirectedUsage. However, in the normative XMI for the abstract syntax, the property is not derived an it has the name /usageWithDirectedUsage (it starts with a space and a slash).
In 7.2.2 Elements, at the end of the last paragraph, in the sentence "In the graphical notation, owned elements may be shown in compartments within the symbol representing the owning element, particularly when the owning element is a definition or usage (see 7.6.1).", it should say "...when the owing element is a package, definition or usage (see 7.5 and 7.6.1)."
In the BNF production for RequirementDefinition in 8.2.2.20.1:
RequirementDefinition =
OccurrenceDefinitionPrefix 'requirement' 'def'
DefinitionDeclaration RequirementBody?
and the BNF production for ConcernDefinition in 8.2.2.20.3:
ConcernDefinition =
OccurrenceDefinitionPrefix 'concern' 'def'
DefinitionDeclaration RequirementBody?
the final ? after RequirementBody is incorrect and should be removed.
In 7.19.3 Assert Constraint Usages, in the last example, the assert constraint usage nested in the part usage alienObject is incorrect (and inconsistent with the preceding comment). The name of the constraint should be negativeMass, not nonNegativeMass, and the value bound to mass should be antiMass, not computeMass.
The transformation of UML4SysML::AddVariableValueAction contains several issues:
The subsetting of the ItemFlowEnd should be a ReferenceSubsetting instead of a Subsetting.
The value of the isEnd property of the ItemFlowEnd is false, but should be true.
It is misleading that the names of the mapping classes for the ItemFlowEnd mapping contain the string ItemFlow. It should be ItemFlowEnd.
The assignment of LiteralNull should include a ReturnParameterMembership element with a feature that is not there. It should be part of the mapping class CVAReferenceUsageFeatureValue_Mapping.
In 7.16.11 Loop Action Usages, in the section on "While Loops", in the last paragraph, in the first sentence, "true" should be bold.
The mapping of an allocation relationship between usage elements is not specified yet (see section 7.8.3.3.8).
The separation of typed and untyped pin mapping classes leads to the same separation for each specialized mapping class for InputPin and OutputPin and for further specializations. This leads to many mapping classes and thus redundancies in the operations.
It can be simplified if the distinction of whether the pin has a type or not is not implemented via specialized mapping classes but within the rules.
The subsections for mapping specification in the document are ordered alphabetically. The alphabetically order is not fully followed in section 7.7.2.3.9.
The mapping class ValueSpecificationAction_Mapping uses a mapping class for the output pin that only considers typed pins.
The mapping class REAOutputPin_Mapping should specialize OutputPin_Mapping instead of Pin_Mapping. The result pin of a ReadExtentAction is always an output pin with a defined type.
The description of mapping classes creating a subsetting element states: "Creates a subsetting relationship for the subsettingFeature() and the subsettedFeature()."
The operation subsettingFeature() is not defined in the mapping class. Sometimes also the subsettedFeature() operation is also not specified.
The description should be simply:
"Creates a subsetting relationship."
The mapping class ClassifierBehaviorFeatureMembership_Mapping is used in several operations, but it does not exist. It seems that the class was renamed to BehavioredClassifierFeatureMembership_Mapping.
The wrong name is used in sections 7.3.1, 7.7.13.3.4, 7.8.4.3.4, 7.8.6.3.25, and 7.8.6.3.33
Section 7.7.2.3.9.22 RVVAVariableFeatureReferenceExpression_Mapping and section 7.7.14.3.23 OpaqueExpressionFeatureValueExpression_Mapping use the mapping class EmptyReturnParameterFeatureMembership_Mapping, but it does not exist.
Instead, it should be ReturnParameterFeatureMembership_Factory.
The ownedRelationship() operation of ControlFlowSuccessionAsUsage_Mapping uses the mapping class ActivityEdgeInitialNodeSourceEndFeatureMembership_Mapping which is not defined.
The ownedRelationship() operation of ControlFlowSuccessionAsUsage_Mapping uses the mapping class ControlFlowTargetEndFeatureMembership_Mapping, which is not defined.
The to property of GenericToEndFeatureMembership_Mapping redefines itself, but should redefine the inherited to property from GenericToFeatureMembership_Mapping.
The end features of the the UML4SysML::ControlFlow target element SuccessionAsUsage should have end feature with reference subsetting instead of a subsetting.
The BehavioredClassifier_Mapping::ownedRelationship() operation creates a OwningMembership relationship for ConnectionUsages, but should be a FeatureMembership relationship
Several mapping classes map to a transition usage. A GenericToTransitionUsage_Mapping class could be introduced to simplify the mapping model and reduce redundancies.
The filter condition of the mapping class Behavior_Mapping is just "true". The filter can be removed.
The ends of a control flow mapping target have a subsetting relationship, but it should be a reference subsetting relationship.
The mapping of ItemFlow does not consider the itemProperty. For the case that the itemProperty is not used, it could reuse the mapping of InformationFlow.
sq-message refers to message-label instead of sq-message-label
Resolution:
Change the production rule
sq-message = &sq-l-node message-label &sq-l-node
------------------->
to:
sq-message = &sq-l-node sq-message-label &sq-l-node
------------------->
sq-proxy-label refers to Usage from textual grammar - needs to be corrected
interconnection view production missing interfaces
"sq-part refers to portNode* instead of sq-port
Replace portNode by sq-port but also update sq-port graphics to show horizontal connector segments like other boundary elements"
The descriptions of all mapping classes in sections 7.6.3 and 7.6.4 contain the text "mappingsto" which should be "mappings to".
In 7.25.2 View Definitions and Usages, the third paragraph includes the parenthetical comment:
(Note that, in the textual notation, it is only possible to specify a view rendering using reference subsetting.)
This correctly reflects the following textual notation BNF in 8.2.2.25.1 View Definitions:
ViewRenderingMember : ViewRenderingMembership =
MemberPrefix 'render'
ownedRelatedElement += ViewRenderingUsage
ViewRenderingUsage : RenderingUsage =
ownedRelationship += OwnedReferenceSubsetting
FeatureSpecializationPart?
UsageBody
However, neither the abstract syntax (see 8.3.25) nor the semantics (see 8.4.21) of view rendering require this restriction. The textual notation should be updated to allow a more general declaration of a view rendering usage, consistent with what is representable in the abstract syntax.
The second line of the following does not parse:
abstract connection c1; abstract connection c2 = c3; // Error: No viable alternative at input '='
The reason for this is that the ConnectionUsage production uses UsageDeclaration (see subclause 8.2.2.13.1):
ConnectionUsage =
OccurrenceUsagePrefix
( 'connection' UsageDeclaration
( 'connect' ConnectorPart )?
| 'connect' ConnectorPart )
UsageBody
However, UsageDeclaration does not include ValuePart, which provides the syntax for feature values (see 8.2.2.6.2):
Usage =
UsageDeclaration UsageCompletion
UsageDeclaration : Usage =
Identification FeatureSpecializationPart?
UsageCompletion : Usage =
ValuePart? UsageBody
On the other hand, 7.13.2 states that “A connection definition or usage (that is not of a more specialized kind) is declared as a kind of occurrence definition or usage (see 7.9.2), using the kind keyword connection”, and an occurrence declaration (in the informal sense) can, in general, include a feature value, so it would be expected to be allowable for a connection, too.
Note that this is also a problem for interactions, but not for messages or flow connections, which explicitly allow a ValuePart (see 8.2.2.13.4):
MessageDeclaration : FlowConnectionUsage =
UsageDeclaration ValuePart?
( 'of' ownedRelationship += ItemFeatureMember )?
( 'from' ownedRelationship += MessageEventMember
'to' ownedRelationship += MessageEventMember
)?
| ownedRelationship += MessageEventMember 'to'
ownedRelationship += MessageEventMember
FlowConnectionDeclaration : FlowConnectionUsage =
UsageDeclaration ValuePart?
( 'of' ownedRelationship += FlowPayloadFeatureMember )?
( 'from' ownedRelationship += FlowEndMember
'to' ownedRelationship += FlowEndMember )?
| ownedRelationship += FlowEndMember 'to'
ownedRelationship += FlowEndMember
The production for attributes-compartment-element is incorrectly referencing "UsagePrefix UsageDeclaration".
It should reference "UsagePrefix Usage".
sq-message-label uses Usage from textual production, needs to be corrected
The Graphical BNF flow-label and interface-label productions are missing and should be added.
Remove existing Table 38 "Standard View Definitions", as well as the immediately preceding paragraph, from subclause 9.2.19.1, since this information is redundant and potentially inconsistent with the graphical BNF in subclause 8.2.3.
The first table in clause 9.2.19.1 that lists the Standard View Definitions does not have a number nor a caption. Table number 38 and caption should be added.
The textual BNF production for MessageDeclaration includes a reference to ItemFeatureMember, which does not exist. This reference should instead be to FlowPayloadFeatureMember.
The Case View that is listed in the first table in clause 9.2.19.1 and defined in clause 9.2.19.2.3 is not one of the standard views and should be removed.
Note: The intent is to respecify the Case View as a specialization of the (standard) General View with a suitable filter.
The textual BNF production for the TargetSuccession is missing the keyword then.
The mapping of UML4SysML::InformationFlow and therefore also SysMLv1::ItemFlow between definition elements is not supported yet.
The Helper operation activityOwnedRelationships calls the mapping class FlowFinalNode_Mapping with a set of final nodes including activity final nodes, but should only be final nodes.
Activity final nodes are currently excluded from the transformation (see SYSML2-106).
The operation TIAOperatorExpression_Mapping::ownedRelationship() uses mapping class EqualOperatorExpressionOperand_Mapping, but it does not exist.
The SysMLv1::ItemFlow mapping supports the flow with a realizing connector. Move this capability to the mapping of UML4SysML::InformationFlow and reuse it to map an ItemFlow. The ItemFlow mapping must only add the special handling of an itemProperty.
The mapping of ItemFlow only covers the flow of classifiers, but not of items specified by ItemFlow::itemProperty.
All target nodes of object flows are handled the same, but activity final nodes are not covered yet, flow final nodes are mapped to a library element, and activity parameter nodes are ignored by the transformation and replaced by the parameter. The object flow mapping must consider the handling of these cases.
TestCaseActivity_Mapping::ownedRelationships() uses the mapping classes CaseSubjectMembership_Mapping and CaseObjectiveMembership_Mapping, which do not exist.
They existed in a previous version but were removed without updating TestCaseActivity_Mapping.
The resolution forgot to update two usages of the mapping class ObjectFlowItemFlowEndRedefinition_Mapping which is now a factory ObjectFlowItemFlowEndRedefinition_Factory class.
The error is in the OCL code of ObjectFlowItemFlowEndReferenceUsage_Mapping::ownedRelationships().
RVVAVariable_Mapping uses CommonAssignmentActionOwningMembership_Mapping, but it should be the factory class AssignmentActionUsageOwningMembership_Factory.
The resolution SYSML2-4 changed CommonAssignmentActionOwningMembership_Mapping to AssignmentActionUsageOwningMembership_Factory, but oversaw the usages of the mapping class in RVVAVariable_Mapping.
RSFAReferenceUsageFeatureMembership_Mapping uses the non-existing mapping class ReadStructuralFeatureActionReferenceUsage_Mapping, but it should be RSFAReferenceUsage_Mapping
ownedRelationship() calls the mapping class ControlFlowFinalNodeTargetEndFeatureMembership_Mapping, but it does exist. Instead it should be ControlFlowFinalNodeFeatureMembership_Mapping.
The mapping of the allocation relationship only considers allocations from definition to definition and usage to usage elements, but not a mixed allocation.
OpaqueBehavior not owned by a package is mapped to a ActionUsage. Since a UML4SysML::OpaqueBehavior is also a type it should be mapped to a conforming element in SysML v2, i.e., only to ActiobDefinition.
The ownedMemberParameter must return an element and not OclUndefined. The case where the if-statement leads to OclUndefined must be checked before AEAParameterMembership_Mapping::ownedMemberParameter is called.
The UML4SysML::CreateLinkObjectAction is a specialization of UML4SysML::CreateLinkAction. Accordingly, the CreateLinkObjectAction_Mapping should specialize CreateLinkAction_Mapping.
ACAReceiverFeatureReferenceExpression_Mapping should be AEAReceiverFeatureReferenceExpression_Mapping
Activities owned by blocks are mapped to ActionUsage, but should be ActionDefinition. Same for StateMachines
Most of the text of the description of AttributeUsage (8.3.7.2) and TransitionUsage (8.3.17.9) is incorrectly in the "code" font, probably due to a missing HTML tag.
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.
Connections is missing connection production with end names and multiplicities.
Table 19, Requirement, compartment for require constraints:
Typo in compartment headline should be "require constraints" => "requirre"
UntypedPin_Mapping (SYSML2-171 renamed it to Pin_Mapping) redefines ownedRelationship(), but does not change anything. Remove the redefined operation.
In 8.2.3.9, the sq-port-port-label and sq-ev-occurrence-label use Usage from the textual BNF. But Usage includes UsageBody, which was not intended to be included in this graphical notation.
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.
The nesting parameter symbol productions (for actions) must have rounded corners, since they are (parameter) usages.
The nesting port symbol productions must have rounded corners, since they are (port) usages.
Example "Package with imported packages (nested packages)" should have «private» enclosed by guillemets
Example "Usage Definition" should be labeled "Part defined by Part Definition"
In example "Relationships Compartment" add textual notation that matches the graphical notation. Also "connect part3" in second symbol should be removed.
In example "Variant Membership" the variants should be defined by Part1a and Part1b respectively. Currently they are both defined by Part1.
In example "Occurrences Compartment" add abstract occurrence feature for completeness.
In example "Attributes Compartment" textual notation should use nonunique instead of unique.
Remove nested features (textual) notation from compartments in graphical symbols in all Representative Notation tables where they occur. This capability was discarded.
Simplify examples "Timeslices Compartment" and "Snapshots Compartment" by putting the compartments into a «part» context, and add e.g. phase1 and phase2 timeslices, and e.g. snapshot1 and snapshot2.
In example "Part with Graphical Compartment with perform actions and flows between them." add «perform action» to both action2 and action3.
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.
In examples "Timeslices Compartment" and "Snapshots Compartment" remove state state1 feature, since it is confusing, and potentially incorrect.
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.
In example "Part with Ports" remove "Nested" from NestedPortDef0.
In 7.16.2 Action Definitions, the action definition example TakePicture contains two declarations with incorrect textual notation:
action focus : Focus (in scene, out image);
and
action shoot : Shoot (in image, out picture);
These should be
action focus : Focus {in scene; out image;}
and
action shoot : Shoot {in image; out picture;}
In 7.16.10 If Action Usages, the nested action declarations in the last example all have incorrect textual notation:
if threat.level == high then {
action soundAlarm(threat);
} else if threat.level == medium then {
action sendNotification(threat);
} else {
action beginMonitoring(threat);
}
This should instead be something like:
if threat.level == high then {
action soundAlarm {in cause=threat;}
} else if threat.level == medium then {
action sendNotification {in cause = threat;}
} else {
action beginMonitoring {in cause = threat;}
}
The description of ForLoopActionUsage::seqArgument is (see 8.3.16.9 ForLoopActionUsage):
The Expression whose result provides the sequence of values to which the loopVariable is set for each iterative performance of the bodyAction. It is the owned parameter that redefines ForLoopAction::body.
The second sentence is clearly wrong. It should instead be
It is the Expression whose result is bound to the seq input parameter of this ForLoopActionUsage.
Similarly, the description of the constraint deriveForLoopActionUsageSeqArgument should be
The seqArgument of a ForLoopActionUsage is its first argument Expression.
and with the OCL
seqArgument = argument(1)
In 7.16.8 Accept Action Usages, it states that the "current time" for time triggers is "relative to the defaultClock". This is incorrect, the time used for triggers is actually the localClock, which defaults to the defaultClock, but can be overridden locally.
In example "Documentation Compartment", the documentation keyword should read doc
In example "Message" the arrow head should be moved to the end of the line, and should be adorned "message of item1:Item1".
In 7.4.1 Annotation Overview, Table 7, in the "Documentation Component" entry, the keyword in the graphical symbol should be doc, not documentation.
The constraints validateDefinitionVariationMembership and validationUsageVariationMembership require that all the owned members of a variation definition or usage be variant members. This is too strong:
There are errors in the specification of the following constraints for TransitionUsage:
checkTransitionUsageSpecialization
checkTransitionUsageActionSpecialization
Toward the end of subclause 7.6.3 Usage of the SysML v2 specification, there is a numbered list describing additional keywords that can be used in a usage declaration. However, this list is repeated twice (sequentially, one right after the other). The two lists are consistent, but the second one is more complete, so the first list is redundant.
The constraint validateFramedConcernUsageConstraintKind is owned by FramedConcernMembership, not FramedConcernUsage (which doesn't exist). Therefore, the constraint should be named validateFramedConcernMembershipConstraintKind.
The constraint deriveForLoopActionUsageBodyAction is owned by LoopAction, not ForLoopActionUsage, and, so, should be called deriveLoopActionUsageBodyAction.
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.
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.
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.
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.
The body OCL for the namingFeature operation of ConstraintUsage references ownedFeatureMembership. This should instead be owningFeatureMembership.
The OCL for the constraints validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization both use ownedGeneralization (which doesn't exist) instead of ownedSpecialization.
Section 8.2.3.13 Connections is missing productions for n-ary connections.
They should be added.
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.
In Clause 8.3.17.9 (TransitionUsage), the Attributes section says effectAction are expressions:
Attributes
/effectAction : ActionUsage [0..*] {subsets feature}
The ActionUsages that define the effects of this TransitionUsage, which are the ownedFeatures of the TransitionUsage related to it by TransitionFeatureMemberships with kind = effect, which must all be Expressions.
but a constraint says they're action usages
deriveTransitionUsageEffectAction
The effectActions of a TransitionUsage are the transitionFeatures of the ownedFeatureMemberships of the TransitionUsage with kind = effect, which must all be ActionUsages.
triggerAction = ownedFeatureMembership->
selectByKind(TransitionFeatureMembership)->
select(kind = TransitionFeatureKind::trigger).transitionFeatures->
selectByKind(AcceptActionUsage)
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)))
In 8.3.16.10 (IfActionUsage), the OCL for checkIfActionUsageSpecialization refers to specifiesFromLibrary instead of specializesFromLibrary.
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
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.
The description of the TimeEvent_Mapping class is a note from the development team instead of a description text.
The description of the ChangeEvent_Mapping class is a note from the development team instead of a description text.
Part properties with AggregationKind::none or shared are mapped to Feature, but should be a PartUsage with isComposite=false.
UML4SysML::Class is currently mapped to OccurrenceDefinition, but should be ItemDefinition.
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.
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.
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.
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.
In the graphical BNF there is a set of textual productions related to compartments that are currently mapped to a "text block" placeholder. They need to be replaced with concrete textual productions.
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.
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".
The Graphical BNF productions in section 8.2.3 contain a number of minor mistakes
In order to be efficient, the mistakes and corrections are recorded as an enumerated list hereafter.
The mapping class RSAOutputPin_Mapping should specialize OutputPin_Mapping instead of Pin_Mapping. The result pin of a ReadExtentAction is always an output pin with a defined type.
ElementMain_Mapping::ownedRelationship deals with owned comments and tries to create an ownership relationship thanks to ElementOwnership_Mapping.
Instead, this is an Annotation relationship that shall be used here. We can get it thanks to the CommentAnnotation_Mapping.
However, CommentAnnotation_Mapping misses the computation of ownedRelatedElement that is left to its default value, meaning that the ownership of a comment is never set.
The transformation does not specify mapping rules for SysMLv1::~InterfaceBlock.
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".
Representative notation table, in 7.13 Connections, uses the deprecated «equal» notation instead of the standard "=" notation for a binding connector.
All «equal» notations should be replaced with = notation.
In 7.13.1 Connections Overview, Table 15, entry for "Flows Compartment", the graphical notation is missing.
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.
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.
In example "Binding Connection" «ref part» part4R should use the graphical notation as specified in the graphical BNF in subclause 8.2.3.11.
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.
In example "Variants Compartment" textual notation should include part def PartDef1, and item def ItemDef1, and also part1 : PartDef1 and item1 : ItemDef1.
In example "Flow as Node" check whether flow from source :> action1.item1 should be reference subsetting? Add keyword from to the nested flows.
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
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>
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
The option for <PrefixComment> has been deprecated, but is still an option for AnnotatingElement. Remove PrefixComment.
AnnotatingElement = Comment | PrefixComment | Documentation | TextualRepresentation | MetadataUsage
In the production:
FeatureTyping = OwnedFeatureTyping | ConjugatePortTyping
There is no corresponding production for the non-terminal <ConjugatePortTyping>.
<ConjugatedPortDefinitionMember> or <ConjugatedPortDefinition> may be correct for <FeatureTyping>.
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.
In the Views::View model as submitted, viewpointSatisfactions was accidentally declared as redefining viewpointChecks. This should be changed to subsetting, so that there can be (non-composite) viewpoint references within a view that subset viewpointChecks but not viewpointSatisfactions.
Further, because View is a kind of Part, viewpointSatisfactions also has an implied specialization of Item::checkedConstraints. It would be better if this was explicit, to make it clear that any declaration in a View subsetting viewpointSatisfactions automatically satisfies the requirement to subset checkedConstraints, so that this does not require an additional implied specialization.
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.
TestCaseVerifyRequirementUsage_Mapping ::ownedRelationships() uses the mapping classes CaseSubjectMembership_Mapping, which do not exist.
It existed in a previous version but was removed without updating TestCaseVerifyRequirementUsage_Mapping .
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.
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.
The connection definition Causation in the CausationConnections library package has two ends that redefine the non-end features causes and effects from Multicausation.
However, in the normative CausationConnections.sysml file from the Cause and Effect Domain Library project, these ends are declared to only subset the source and target ends inherited from BinaryConnection. As a result, the connection definition ends up having four ends rather than two, which is incorrect. Its ends need to redefine source and target, rather than just subsetting them.
In subclause 9.5.2.2.1 of the specification document, on the other hand, Causation is not shown as specializing BinaryConnection at all, and the ends are shown as only redefining the non-end features from Multicausation.
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.
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
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.
Currently, in the Geometry Domain Library model SpatialItems, the calculation definitions PositionOf and CurrentPositionOf return vectors defined by the generic definition VectorQuantityValue. These should be specialized more narrowly to ISQ::Position3dVector.
The following validation constraints are implied by textual descriptions in the specification, but are missing in the abstract syntax. They should be added, along with appropriate OCL.
8.3.16.5 AssignmentActionUsage
validateAssignmentActionUsageArguments – An AssignmentActionUsage must have two argument Expressions.
validateAssignmentActionUsageReferent – An AssignmentActionUsage must have an ownedMembership that is not an OwningMembership whose memberElement is a Feature.
8.3.16.9 ForLoopActionUsage
validateForLoopActionUsageLoopVariable – The first ownedFeature of a ForLoopActionUsage must be a ReferenceUsage.
validateForLoopActionUsageParameters – A ForLoopActionUsage must have two owned input parameters.
8.3.16.10 IfActionUsage
validateIfActionUsageParameters – An IfActionUsage must have at least two owned input parameters.
8.3.16.16 TriggerInvocationExpression
validateTriggerInvocationExpressionAfterArgument – If a TriggerInvocationExpression has kind = after, then it must have an argument Expression with a result that conforms to the type ISQ::DurationValue.
validateTriggerInvocationExpressionAtArgument – If a TriggerInvocationExpression has kind = at, then it must have an argument Expression with a result that conforms to the type Time::TimeInstantValue.
validateTriggerInvocationExpressionWhenArgument – If a TriggerInvocationExpression has kind = when, then it must have an argument Expression with a result that conforms to the type ScalarValues::Boolean.
8.3.16.18 WhileLoopActionUsage
validateWhileLoopActionUsageParameters – A WhileLoopActionUsage must have at least two owned input parameters.
8.3.17.2 ExhibitStateUsage
validateExhibitStateUsageReference – If an ExhibitStateUsage has an ownedReferenceSubsetting, then its referencedFeature must be a StateUsage.
8.3.19.2 AssertConstraintUsage
validateAssertConstraintUsageReference – If an AssertConstraintUsage has an ownedReferenceSubsetting, then its referencedFeature must be a ConstraintUsage.
8.3.20.10 SatisfyRequirementUsage
validateSatisfyRequirementUsageReference – If a SatisfyRequirementUsage has an ownedReferenceSubsetting, then its referencedFeature must be a RequirementUsage.
8.3.24.2 IncludeUseCaseUsage
validateIncludeUseCaseUsageReference – If an IncludeUseCaseUsage has an ownedReferenceSubsetting, then its referencedFeature must be a UseCaseUsage.
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.
The following statements are made in Clause 7 (Language Description) of the SysML v2 specification:
However, there are currently no constraints on the Usage class in the abstract syntax to enforce these rules (see 8.3.6.4).
In addition, a usage that is not explicitly declared as a feature of a type is, by default, considered to be a feature of the base type Anything. However, since Anything is not a kind of Occurrence, its features cannot be composite. Therefore, such usages should be always referential.
In the Systems Model Library, the features Actions::Action::acceptSubactions and Actions::Action::sendSubactions should subset Actions::acceptActions and Actions::sendActions, respectively.
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.
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.
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.
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.
Currently binding connector graphical production overly constraining the possible permutations to two specific cases. it needs to be generalized to bind usage-nodes in general where they have to be of consistent types.
Current Graphical BNF needs to have a production for a keyword notation with and without the base class enabled for all name compartments.
According to the Graphical BNF, the notation for a nested reference usage is now a white diamond in the upper-right hand corner of the usage shape (or optionally a black diamond for a non-reference usage, which is the default). In the Graphical BNF productions this is represented by rd = (reference-diamond)? as defined in clause 8.2.3.6. This is a change from the previous dashed-outline shape as also used in SysML v1.
There are arguments pro and con for which notation might be the more usable, including the affinity of the white diamond with a feature membership, but also continuity with SysML v1 and its visibility of the distinction around the whole shape.
The new notation was proposed primarily to avoid the practical difficulties providing dashed-outline versions of every usage shape in the BNF, but the notation should be properly decided on its own merits, not to make things easier for the BNF. An informal comment could be provided in the BNF simply stating that a dashed-outline version is available for each shape according to whether it is a reference usage. An additional alternative is to use dotted-outline, with the advantage that it more closely follows non-right-angled shapes, such as rounded rectangles used for usages.
After discussion the Graphical Specification WG recommends to replace the upper-right-hand corner reference-diamond notation with a dotted-outline for reference usage, and stay with a solid-outline for composite usage.
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." There are a number of cases of models in the Domain Libraries that violate this constraint.
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.
Graphical BNF should allow for graphical relationships such as causation connection from a state (i.e. cause) to a transition (i.e. effect) or from one transition (i.e., cause) to another transition (i.e., effect). These should be supported in the general view.
The reflective SysML model in the SysML Systems Library has the following inconsistencies with the normative SysML abstract syntax:
1. The feature AnalysisCaseUsage::analysisAction should subset usage, not feature.
2. The features of Definition, RequirementDefinition and Usage should have the same order as the properties of the corresponding metaclasses in the abstract syntax.
3. The feature ViewDefinition::satisfiedViewpoint should subset ownedRequirement, not ownedUsage.
4. The feature ViewDefinition::viewRendering should not subset ownedUsage.
5. The feature ViewUsage::satisfiedViewpoint should subset ownedRequirement, not ownedUsage.
6. The feature ViewUsage::viewRendering should not subset ownedUsage.
In 7.16.9 Assignment Action Usages, at the beginning of the second text paragraph, it states
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 to enforce this (see 8.3.16.5).
Example "Individual Occurrence" should include individual def from preceding example, and rename occurrence1 to occurrence1-1.
Clarify the various textual notations and corresponding graphical notations for representing a flow on a connection.
The subsections of section 7.7.2.3.7 should be ordered alphabetically.
In 7.9.1 Occurrences Overview, Table 11, entry for Individual Occurrence, the subsetted occurrence and the subsetting individual are both named occurrence1. It would be better to give the individual occurrence a different name.
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.
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.
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.
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".
The issue SYSML2-241 is merged into SYSML2-240. Both issues are approved. The resolution of SYSML2-240 does not consider the issue SYSML2-241.
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.
TestCaseVerifyRequirementUsage_Mapping.ownedRelationship() contains the following code:
CaseSubjectMembership_Mapping.getMapped(from.client),
Since from.client is a collection the code specified cannot work. This makes MIWIG test case #37 failing
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.
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.
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.
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.
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.
The graphical notation lacks clear differentiation between the various types of flows in the language: flow, succession flows, and message flow (see also SYSML2-59).
In addition, the BNF was overly restrictive and did not allow flow connections on structural diagrams, except for flows on connections.
Flows on connections also need to include messages and succession flows.
It needs to be corrected in the BNF in the relevant clauses
8.2.3.9 - Occurrences (SD notation)
8.2.3.13 - Connections
8.2.3.14 - Interfaces
8.2.3.16 - Actions
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.
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.
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.
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.
The description indicates that this should be FlowConnectionUsage.
Clause 6.1 Document Overview contains an incorrect reference to the SysML v1 to SysML v2 Transformation Specification. The last line of the second paragraph refers to Annex C, which is no longer a correct reference.
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.
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.
In the SysML specification document, in 9.2.9.2.4 Action, the feature decisionActions is stated as subsetting transitions. However, in the normative Actions.sysml library model, Action::decisionTransitions currently subsets transitionActions. It should instead subset Action::transitions, as given in the specification.
The description indicates that it should be FlowConnectionUsage
Right now use-case nodes cannot be associated with actors and subjects. They need to be made subject/actor stakeholders
In subclause 8.2.3.17 - states gbnf definition-node is being augmented with action-def instead of state-def
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.
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.)
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.
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.
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.
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.
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.)
Clause 9.8.8.2.13 (universalClock), Description, says
universalClock is a single Clock that can be used as a default universal time reference.
but the Time library shows it as a package-level feature, enabling everything in the universe (instances of Anything) to identify its own universal clock (see KERML-56).
The phrase "universalClock is a single Clock" above is worded as if universalClock were a part def, rather than a part usage, giving the impression of exactly one value for universalClock across all things, but there is no constraint for this. Similarly, Clause 8.4.12.6 (Accept Action Usages) says
In particular, the Occurrences::Occurrence::localClock itself defaults to the singleton universalClock (see 9.8.8.2.13 and [KerML, 9.2.12]).
and 9.7.2.2.5 (SpatialItem) says its localClock is
A local Clock to be used as the corresponding time reference within this SpatialItem. By default this is the singleton Time::universalClock.
The term "singleton" usually refers to instances of a class, rather than values of a feature, giving the impression of exactly one value for universalClock across all things.
Might be other features like this. For example, from the library:
ISQSpaceTime::universalCartesianSpatial3dCoordinateFrame : CartesianSpatial3dCoordinateFrame[1] {
/* A singleton CartesianSpatial3dCoordinateFrame that can be used as a default universal Cartesian 3D coordinate frame. */ }
This is also a top-level feature that seems intended to be "universal" in the sense above.
Subclause 8.1 defines typographical conventions to be used in the KerML metamodel. However, these are not being followed consistently throughout Clause 8 and Clause 9.
Also, subclause 6.3 is inconsistent with 8.1 and should be removed.
MOF constraints require that all associations be named. But none of the associations in the SysML abstract syntax model are currently named. They should all be given generated names.
In A.9 Analysis, in the diagram in Figure 70 Analysis Case fuelEconomyAnalysis, the following need to be addressed:
In A.3 Definitions, in the diagram in Figure 58, the feature FrontAxle::steeringAngle is shown subsetting ISQSpaceTime::angularMeasure. However, in the corresponding textual notation representation, steeringAngle is shown as subsetting ISQ::planeAngle. Now, ISQ::planeAngle is actually an alias for ISQSpaceTime::angularMeasure, so the representations as shown are technically correct. But the difference will be likely be confusing to the reader. Perhaps, at least, the ISQ::planeAngle should be changed to ISQ::angularMeasure in the textual representation.
The arguments for specializesFromLibrary are sometimes single quoted and sometimes double quoted. Search on specializesFromLibrary(' and specializesFromLibrary(" to find them.
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.
In Table 2, example "Annotation-Textual Representation", the textual notation incorrectly uses "rep about" syntax, while any textual representation element should be owned by, and therefore inside the body of, the element being represented. The upper textual notation fragment must be removed, and the lower fragment kept as is.
The 2023-10 version of SysML2 still not include the XMI version of the standard libraries but only the textual syntax version.
Because of this, model elements from those libraries have no stable identifiers
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.
*/
}
Some entries in the mapping overview tables show duplicate entries in the SysML v2 column.
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.
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.
The tilde character is not accepted in a name by most of the progarmming languages. So, it's not convenient to use it in a mapping name that is intended for software implementation
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.
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.
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.
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.
package x View and Viewpoint TBD should not be included in the SysML.xmi file.
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.)
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.
For example, comparing Clause 9.8.4 (ISQ) to ISQSpaceTime library,
Might be others.
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.
The PerformActionUsage::namingFeature operation documentation states that "The naming Feature of a PerformActionUsage is its performedAction." However the body of the operation is specified as exhibitedState. This should instead be performedAction.
Further, this specification means that that, if a PerformActionUsage redefines another ActionUsage and doesn't have a reference usage, then it will not have any effective name. One would instead expect that its effective name in this case be the same as the name of the action it is redefining, as for a regular ActionUsage.
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.
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.
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.
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
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).
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.)
The graphical notation is specified in the graphical BNF in subclause 8.2.3 and the view model libraries in subclause 9.2.18 and 9.2.19. Its use is illustrated in the representative notation tables in the overview sections of Clause 7.
The overarching need is for the specification of the graphical notation to result in a clear and unambiguous human interpretable representation that is consistent within and across views, and that is consistent with the abstract syntax and the textual notation. A further goal is to achieve, as much as possible, compatibility with or smooth transition from SysML v1 notation.
To facilitate discussion a legend of different arrowheads is given below.
The following issues with the graphical notation relate to successions, messages, flows, and succession flows as they appear in the action flow view, sequence view, and interconnection view.
