SYSML2_-403 change semantics and the class hierarchy for FlowConnectionUsage and therefor impact the specification of the transformation that is related to that class
There is no rule that maps a property typed by a Signal. It should be mapped to an item usage.
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.
After resolution SYSML2_-403 to issue SYSML2_-173, FlowConnectionDefinition no longer specializes ConnectionDefinition (now specializing only ActionDefinition and KerML Interaction), and FlowConnectionUsage no longer specializes ConnectionUsage (now only specializing ActionUsage, ConnectorAsUsage and KerML ItemFlow. As a result of SYSML2_-403, having "Connection" in the name of the "Flow" classes causesconfusion among users that don't see the distinction between structure and behavior.
Renaming FlowConnectionDefinition to FlowDefinition and FlowConnectionUsage to FlowUsage would avoid confusion going forward. Not making this change prior to finalization of SysML v2 runs the risk of having confusion that would require complex deprecation steps to correct later.
Similarly for SuccessionFlowConnectionUsage, which specializes FlowConnectionUsage.
Resolution KERML_-87 to issue KERML_-18, which has been approved by the KerML FTF, adds a new `CrossSubsetting` relationship and introduces the concept of cross features for end features of associations and connectors. These changes in KerML require corresponding updates to the concrete syntax, abstract syntax and semantics of connections and connection definitions in SysML, which are based on KerML associations and connectors.
Current spec mandates that messages are implemented as flow connectors without ends.
>> (8.4.9.6, page 389, "A message declaration of the form ....
>> is parsed as an abstract FlowConnectionUsage, but without any connectionEnds (see 8.2.2.13.4 ),")
Instead, the connectivity information (what this connector is attached to) is implemented as
sourceEvent and targetEvent parameters that need to be redefined.
This is problematic from implementation standpoint as now we need two different codes for drawing/displaying conectors -
one for all connectors except messages and another one for messages.
There seems to be no strong reason why it should be so. Even the very abstract, non-structural,
purely-behavioral connectors, such as Successions do have ends.
It would be better to make message connectors as connectors with ends, as all other connectors.
The only reason to implement them this way seems to be - to make messages "more" distinguishable from flows.
As there is no special metaclass for messages, the same FlowConnectionUsage is reused.
So flow connection with no ends => message, flow connection with ends =>flow seems to be distinguishing criterion.
Now, if user creates connector ends explicitly/forcefully (using the extended syntax of {<connectorbodydetails>}),
the message connection ceases to be distinguishable from flow connection.
But this is a problem, since users do want to specify message connection ends - namely to indicate the sending and receiving parts.
The spec vaguely says (in chapter 7.13.6) that messages should be abstract, while flows (supposedly) should not be so.
The reasoning for no ends for messages seems to be that connectors without bound ends are abstract connectors (there is such a rule elsewhere in the spec),
thus guarranteeing that connector is abstract; but that is a resoning in the opposite direction
(binding of connector ends should not/does not prevent the connector from being abstract).
A better rule to distinguish messages and flows perhaps could be devised.
Heavyweight approach would be to have a dedicated metaclass for messages, but we understand that this would be a signifficant spec change.
Criterion of inheritance from appropriate library class seems to be sufficient?
To summarise:
a) we propose that messages could also have normal connector ends bound to parts.
Perhaps this could be analogous to the arrangement that flow connectors currently have:
when specifying flow connector as being from a.b.c to d.e.f,
the connector ends are filled as a.b and d.e, while the last steps in the chain - c and f go into special flow-specific features.
In the same manner when message is specified as being from a.b.c to d.e.f, the connector ends could be filled as
as a.b and d.e, while the last steps in the chain - c and f (EventOccurrences) go into message-specific features .
b) The rule to distinguish messages and flows should be revised.
In subclause 7.20.1, Table 19, example "Requirement" the compartment labels "require constraints" and "assume constraints" and their content are misleading and inconsistent. Besides pure "require ConstraintUsage" statements a "require constraints" compartment may also contain "require RequirementUsage" statements. A "require RequirementUsage" has the same semantics as a RequirementUsage contained (isComposite==true) by a containing RequirementUsage (see explanation in subclause 7.20.2). Therefore a better compartment name is possibly "requires".
The same problem applies to other compartments for shorthand textual notation for particular reference-subsetted usages following a similar pattern. The full list of patterns to be made consistent is:
In addition a mix of verb forms are used: some use the infinitive (exhibit states, satisfy requirements), some use third person singular form (exhibits, satisfies). This is confusing and should be regularized in a consistent way, following a single rule.
Finally, graphical edges that represent the above reference-subsetted relationships between usage nodes are inconsistently specified in the representative notation tables in clause 7, and the graphical BNF in subclause 8.2.3.
The description of message declarations in 7.13.6 Flow Connection Usages and Messages is incorrect. It states that a message declaration "may or may not include identification of source and target related features. If they are included, then they follow the payload specification (if any), with the source related feature identified after the keyword from, followed by the target related feature after the keyword to." However, the from and to features of a message are not the related features of the message as a flow connection usage. Rather, they are the values of the sourceEvent and targetEvent parameters of the MessageConnection (see parsing in 8.2.2.13.4 Message and Flow Connections and semantics in 8.4.9.6 Flow Connection Usages).
In light of this, the message declaration example in 7.13.6 is also incorrect, as is the textual notation for the first "Messages" example in Table 11 Connections – Representative Notation (showing a message between ports). However, the graphical notation in this example seems to be acceptable, as are both the graphical and textual notations in the second "Message" example (showing a message on a sequence diagram).
In 7.13.6 Flow Connection Usages and Messages, a message declaration is described as identifying the "source and target related features", and the associated example shows a message declared as being between controller and engine parts. This is not correct. Messages are actually declared between source and target events that are within the source and target related features, with the actual ends of the transfer remaining implicit.
As for other flow connection usages, the syntax for a message declaration allows for explicit typing by flow connection definitions. However:
In 8.3.10.3 ItemUsage, under "Attributes", the type of the attribute itemDefinition is Structure and the attribute description states
The Structures that are the definitions of this ItemUsage. Nominally, these are ItemDefinitions, but other kinds of Kernel Structures are also allowed, to permit use of Structures from the Kernel Library.
However, under "Constraints" the constraint deriveItemUsageItemDefinition has the following description and OCL:
The itemDefinitions of an ItemUsage are those occurrenceDefinitions that are ItemDefinitions.
itemDefinition = occurrenceDefinition->selectByKind(ItemDefinition)
This only allows itemDefinitions that are ItemDefinitions, filtering out all other kinds of Structures.
Each mapping class needs at least one general mapping. There is none defined for TestCaseVerifyObjectiveRequirementUsage_Mapping.
The section describing the mapping class TestCaseVerifyObjectiveMembership_Mapping is incomplete. The subsections Description, General Mappings, Mapping Source, Mapping Target, and Owned Mappings are missing.
In subclause 8.2.3.10 the production item-name-compartment is out-of-date. In line with other usage name-compartment productions it should read:
item-name-compartment =
'«' OccurrenceUsagePrefix 'item' '»'
usage-name-with-alias
Operation RICOAOutputPin_Mapping::filter() does not redefine Pin_Mapping::filter(). The issue is not visible in the specification document but in the model resp. XMI.
The subclause 7.7.5.3.7 Trigger_Mapping contains no text.
In subclause 7.13.1, Table 11, example "Flow as node" in the «flow» elaboration symbol the subItems of source.item1 and target.item2 are depicted with parameter symbols. This is incorrect because the subItems are undirected features and therefore should be depicted as parameters, but rather as nested items inside the containing item1 and item2 rounded rectangles.
In subclause 7.13.1, Table 11, example "Flow as Node" the subitems of parameters item1 and item2 of the flow between action1 and action2 are depicted in the elaborated flow node with parameter symbols subItem1, subItem2, subItem3. The current graphical notation is as follows:
Currently parameter nodes can only show nested parameters and direction. They need to be able to show owned features such as item usages.
In subclause 7.17.1, Table 16, example row "State with entry, do and exit actions", the compartment label is "actions".
In subclause 8.2.3.17 in production state-actions-compartment the compartment label is "states".
To be explicit and unambiguous, in both places the label should be "state actions".
The specification of Helper::getScalarValueType() uses the unknown OCL String function includes:
t.qualifiedName.includes('PrimitiveTypes::UnlimitedNatural')
To check if a string is part of another string, the function indexOf() should be used instead.
The issue was accidentally introduced by SYSML2_-300 in ballot #3.
The COAPin_Mapping class should specialize directly or indirectly a mapping class from the mapping framework. Very likely, it should specialize Pin_Mapping.
The ValuePin_Mapping class should specialize directly or indirectly a mapping class from the mapping framework. Very likely, it should specialize Pin_Mapping.
The mapping class AEAChangeParameterFeatureMembership_Mapping is in the transformation model, i.e., the XMI and is referenced by the mapping class AEAChangeParameterTrigger_Mapping, but the description is missing in the document.
In subclause 7.9.1., Table 7, examples "Individual Occurrence" and "Portion Membership" the graphical notations incorrectly show «individual» as a separate keyword in guillemets. In line with the Graphical BNF specification, they should be put together with the main element keyword, i.e. «individual occurrence» and «individual part» respectively.
The first example also contains a typo: 'OccurenceDef1-1' should read 'OccurrenceDef1-1'. The second contains typo: indvidual1 should read individual1.
In subclause 7.9.1, Table 7, example "Individual Occurrence Definition", in the graphical notation, the name 'OccurenceDef1-1' is an UNRESTRICTED_NAME and should be written between two single quotation marks as it contains a character (the hyphen) outside the valid character set for BASIC_NAME (see KerML clause 8.2.2.3).
There are also many typos in the spelling of "occurrence":
The graphical BNF and representative notation do not support an else branch originating from a decision node.
Some graphical symbols used in state machine diagrams and activity diagrams in SysML v1 have been informally carried over to SysML v2. However, there are inconsistencies in how the symbols are used in SysML v2 actions and states. The intent is to align the symbols shown in the attachment that include the graphical SysML v2 symbols in action flow views that correspond to the initial node, flow final, and activity final with the SysML v2 graphical symbols in state transition views that correspond to the initial pseudo state, final state, and terminal node pseudo state. This will also require addressing the symbols for entry action which is currently informally depicted in SysML v2 with a solid filled circle like the initial pseudo state.
Graphical notation uses a caret symbol "^" to show inherited properties. This is currently only possible for textual compartments, it also needs to be enabled for name compartments.
general-view is used but not specified. The definition should probably be
general-view =
definition-node* definition-edge * usage-node* usage-edge*
Also, need to add a production for definition-edge and account for namespace symbols (e.g., packages)
While there is a production for a diagram frame, it is not used by the graphical BNF, other than by "usage-node".
There is a need to specify how diagram frames are integrated into the various view productions, such as general-view, interconnection-view etc
In clause 7.16.1, the examples provided for send action are confusing and erratic. 5 alternative graphical examples for a single textual reference shown all of them have issues.
In subclause 7.16.1 Table 14 examples "Actions Compartment" and "Perform Actions Compartment" have outdated notation using parentheses for parameter notation in actions compartments.
It is suggested to remove those parameter declarations.
Clause 7.16.1 (rep. notation for actions) shows a graphical notation example of an accept action corresponding to the following textual notation:
action trigger1 : Trigger accept scene : Scene via viewPort;
It shows 3 alternative graphical notations which are confusing and inconsistent.
That graphical representative example needs to be corrected. Here are few issues:
Current GBNF uses the textual notation to represent state entry/do/exit actions within a "state actions" compartment.
This does not allow to describe state actions in a graphical way and also requires the graphical modeler to use more extended textual syntax.
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.
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.
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.
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?
When metadata is defined with keyword textual notation allows short syntax of metadata application with #keyword. Example from the spec:
occurrence def Situation;
occurrence situations : Situation[0..*] nonunique;
metadata def <situation> SituationMetadata :> SemanticMetadata {
:>> baseType = situations meta SysML::Usage;
}
// batteryLow is an OccurrenceUsage that implicitly subsets situations.
#situation occurrence batteryLow;
Unfortunately, the end user still needs to know underlying model element flavor (occurrence in the example above). This knowledge is difficult to learn for the users of the particular specialized domain. It could be considered an "implementation detail" of the domain specific modeling provider.
Ideally, when metadata is defined 1) with keyword 2) with annotatedElement fixed to a single variant, the end user should not need to specify the model element flavor ("metaclass") in the textual notation and just state the keyword; like this:
#situation batteryLow;
This would be very handy for UAF and other domains.
Unfortunately, a small error has crept into the resolution of SYSML2_-203.
The mapping class InitialStateMembership_Mapping should be named InitialStateSubactionMembership_Mapping and the general mapping of the mapping class should be GenericToSubactionMembership_Mapping.
Accordingly, change InitialStateMembership_Mapping in Helper::stateOwnedRelationship() to InitialStateSubactionMembership_Mapping.
All feature redefinitions specified in the transformation model, whether they affect properties or operations, should appear in the specification document
Each section describing a particular thing e.g. Usage needs a notation subsection which should show all new possible notation relevant to that section where not described elsewhere and how it ties in with abstract syntax in terms of which properties, item types and values are involved.
Graphical lines which connect items should be described in terms what attributes of what item should refer to which other items.
Such information should not be buried in a sea of descriptive text, it should be clear and concise.
An example: 7.10 deals with Items and only lists a couple of symbols and one compartment (displayable property) called 'items'.
There is no specification of what this compartment is presenting in terms of a) the property or properties to be checked or b) what is referenced.
Point a can sometimes be answered where they have property name = ... but not in this case.
Point b can sometimes be answered by following the chain of notation specifications because they sometimes have notationname : type of element = ... - this does point to Usage types.
I guessed that the nestedItem attribute should be the source of this information.
The Graphical syntax section identifies another symbol, an item reference, which I guess is the presentation to be used when the Usage is a ReferenceUsage. I say guess because again there is no specification.
Trying to understand 18: Connections with respect to abstract syntax when each pictured symbol's abstract type is not named is very difficult.
View usage is restricted to have at most one definition which must be a view definition:
/viewDefinition : ViewDefinition [0..1] {redefines partDefinition}
With this passage viewDefinition field redefines partDefinition field - this makes constraints on what partDefinition field values can be - namely (at most) one definition which must be a view definition.
This is too restrictive and precludes some valid use cases; For example, additional "instrumentation" of the view with additional properties to implement diagram properties
e.g.:
part def VendorSpecificDiagramProperties {
attribute showGrid:Boolean;
//other diagram style attributes here
}
//.......
view usage usersDiagram: InterconnectionView, VendorSpecificDiagramProperties {
:>>showGrid = true;
}
This restriction could be relaxed to e.g. viewDefinition subsetting partDefinition instead of redefining, allowing more flexible use of views (just like partDefinition only subsets itemDefinition).
The specification states in 7.17.3:
"The accepter action for a transition usage is placed after the guard expression and notated using the accept keyword..."
The examples in 7.17.3 also show "accept" after the "if' statement.
However, the implementation (specifically, Eclipse) will not instantiate a transition that has the accept after the guard. It will recognize the accept before the guard.
For example:
item def TurnOn;
state def OffOn {
state off;
state on;
in attribute enabled;
transition off_on3 first off accept TurnOn if enabled then on;//This declaration parses
transition off_on4 first off if enabled accept TurnOn then on;//This declaration does not parse.
}
I think these specifications in section 8 are too generic.
a-subsetting =
'«subsets»' ownedRelationship (',' ownedRelationship)*
a-redefinition =
'«redefines»' ownedRelationship (',' ownedRelationship)*
There is no single ownedRelationship = or ownedRelationship : but several ownedRelationship += which I interpret to mean that this is the property that would be added to when parsing.
The first of these would surely be OwnedSubsetting which has a OwnedSubsetting : specification.
typo in OCL, also on page 184
Definition is given as
flow-label =
UsageDeclaration? ('«of»' FlowPayloadFeatureMember)? | FlowPayloadF
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).
On one hand abstract syntax chapters for the transitions between states stipulate (Figure 32 in 8.3.17.1@page316, text in 8.3.17.9@page325)
that transition can have multiple triggers, multiple guards and multiple effects
by specifying multiplicities [0..*] for TransitionUsage::triggerAction, TransitionUsage::guardExpression, TransitionUsage::effectAction
On the other hand, semantics and textual syntax chapters for the transitions between states stipulate (8.4.13.3@page424, 8.2.2.17.3@page178)
that transition can have at most one of each trigger, guard and effect
by stating:
"A TransitionUsage is parsed as having the following ownedMemberships
....
Zero to three TransitionFeatureMemberships for up to one each of a triggerAction, guardExpression, and effectAction."
and by using "?" marks (which has a meaning of [0..1] multiplicity) in the BNF
"TransitionUsage =
...
ownedRelationship += TriggerActionMember )?
( ownedRelationship += GuardExpressionMember )?
( ownedRelationship += EffectBehaviorMember )?"
-----------------------
This contradiction should be resolved in one direction or another - by stipulating either [0..1] or [0..*] everywhere.
We suggest that the variant with singular multiplicity be adopted as this seems to be closer to the original intent of standard builders.
This was also the convention of previous standards (UML)
Therefore the abstract syntax chapters - Figure 32 in chapter 8.3.17.1@page316, and specification in chapter 8.3.17.9@page325 -
should be updated with multiplicity [0..1] for the aforementioned 3 fields.
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;
The mapping of a UML4SysML::ActivityFinalNode is not covered by the transformation rules.
In current implementation each FlowConnectionUsage owned by PartUsage subsets (automatically) 3 features:
This could be optimized for the sake of model size. Maybe it would be better idea to introduce
Part::Part::ownedFlows :> ownedActions, subparts, flowConections
and define something like CheckFlowConnectionSubFlowSpecialization constraint?
proxy connection in sequence views should be contextualized on lifelines.
Right now they just float as nodes.
It is possible to define flow connection usage in several ways.
One - use the simple/nice notation where syntactic sugar hides the underlying complexity:
flow of SomeItemDefinition from firstEndCon to secondEndCon;
Second- use full available detailed notation allowing precise definition of the characteristics of the payload
flow {
:>>payload: SomeItemDef; //note more characteristics for payload can be modeled here - especially useful when flows are inherited
end ::> firstEndCon;
end ::> secondEndCon;
}
Sometimes the second, detailed way is the only way to define characteristics of the payload in the more complex cases (especially when the flows are inherited/specialized in the hierarcy).
Now the problem is that two different models are created for these two cases. ItemFeature is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case.
It seems that ItemFeature (meta)type is mostly a syntactic marker. So perhaps it would be possible to get rid of it entirely and make the two cases equivalent from the abstract syntax/model standpoint?
This non-uniformity causes several technical problems down the line.
The second problem could perhaps be solved by e.g. changing the definition of the itemFeature property in the abstract syntax to be the feature that specializes `Transfer::item`, whether or not it is owned or inherited, and whether or not it is an ItemFeature. The derivation would not be as simple as the current one, but it would be a reasonable suggestion.
Currently, the only way to create payload for flow def is to redefine it explicitly:
flow def SomeFD {
:>>payload: SomeData;
end :FirstEndType;
end :SecondEndType;
}
it would be nice for the same syntactic sugar "of TypeOfPayload" to be available for flow defs as is now available for flow usages:
flow def SomeFD of SomeData {
end :FirstEndType;
end :SecondEndType;
}
It is possible to define flow connection usage in several ways.
One - use the simple/nice notation where syntactic sugar hides the underlying complexity:
flow of SomeItemDefinition from firstEndCon to secondEndCon;
Second- use full available detailed notation allowing precise definition of the characteristics of the flow ends:
flow of SomeItemDefinition {
end ::> firstEndCon {
//more end characteristics can be specified here:
:>>sourceOutput, someFlowPropertyofEnd1;
}
end ::> secondEndCon {
:>>targetInput, someFlowPropertyofEnd2;
}
}
Sometimes the second, detailed way is the only way to define characteristics of the ends in the more complex cases. Now the problem is that two different models are created for these two cases. ItemFlowEnd is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case
It seems that ItemFlowEnd (meta)type is mostly a syntactic marker.So perhaps it would be possible to get rid of it entirely and make the two cases equivalent from the abstract syntax/model standpoint (by using just ReferenceUsage)?
The description in clause 9.8.8.2.4 is missing the three words at the end of the sentence.
'its start snapshot.'
The above description in the SysML specification should align with corresponding clause 9.2.12.2.5 in the KerML specification to read as follows:
DurationOf returns the duration of a given Occurrence relative to a given Clock, which is equal to the TimeOf the end snapshot of the Occurrence minus the TimeOf its start snapshot.
The following row headers describe unowned elements, but the textual notation illustrates that the elements are owned.
Package with alias member (unowned)
Package with alias member (unowned)
Membership (unowned member with alias name)
The simplest resolution, if the desire to emphasize "unowned" is maintained, may be to use textual notation for each which declare the packages to be aliased in the next higher namespaces.
The SysML v1 stereotype Stakeholder is applied to Classifiers. Therefore, it could also be other model elements than Class which represent stakeholders. The usage of Actor is quite common.
Actors are mapped to PartDefinition. Therefore, Stakeholders should also be mapped to PartDefinition which makes it more consistent. Stakeholders and Actors are different concepts, but there seems to be no reason to map them differently to parts and items.
Readers should expect that the textual notation and graphical notation should match as much as possible, including element names.
The attributes compartment row should at least align on the attribute1 declaration (the definition is different between the graphical and textual notations. I would like to make the case that all of the graphical notation examples should be shown in textual notation, too. If it is worth it to show the graphical notation expectation in the table, it is worth it to show the corresponding textual notation.
Example of minimum correction in textual notation:
change:
attribute attribute1 : Attribute1Def
to:
attribute attribute1 : AttributeDef1
I suspect that there are two errors near the top of page 30 in the P8 namespace textual notation:
1. Import Annotations::*; should be import ApprovalMetadata::*;
import Annotations::* does not seem to serve a purpose here, and ApprovalMetadata elements would be needed to support the following code (when corrected).
2. import NA::*[@Approved]; should be import NA::*[@Approval and approved]; or import NA::*[@approved]; or another version of this depending on interpretation of preceding commentary.
According to the SysML abstract syntax (8.3.17.9 TransitionUsage), the source and target of a TransitionUsage must be ActionUsages. However, the textual notation (8.2.2.17.3 Transition Usages) allows sources and targets to be feature chains, which are parsed as a KerML Feature with FeatureChaining relationships to the chained Features, which are not ActionUsages.
Issue 1: the following notation found in the middle of the page has a comma instead of a semicolon for the declaration of an "in".
action def B { in b1, out b2; }
should be
action def B { in b1; out b2; }
Issue 2: The following notation found in the middle of the page has the wrong kind of closing bracket, followed by a semi-colon, following the declaration of an action definition. I.e., a closed parenthesis and semi-colon should be replaced by a closed curly bracket.
action def B1 :> B { in b1; out b2; inout b3); // Redefinitions are implicit.
should be
action def B1 :> B { in b1; out b2; inout b3} // Redefinitions are implicit.
In 9.1 Model Libraries Overview, in the last paragraph, it states that "the prefix https://www.omg.org/SysML/" should be used "when constructing the URL for a standard library package" as part of the generation of model library element UUIDs. The URL used here should instead be the standard OMG base URI https://www.omg.org/spec/SysML/ (which was what was actually used when generating the UUIDs in the normative XMI for the library models).
The chapter 7.8.7.3.4 has no content.
The chapter 7.8.7.3.3 has no content.
The phrase "As such, any directed usages declared in the body of a calculation definition or usage are considered to be owned parameters of the calculation."
Should be corrected to say "As such, any directed usages declared in the body of a constraint definition or usage are considered to be owned parameters of the constraint."
An Actor is mapped to an ItemDefinition, but it should be a PartDefinition.
The temporary mapping classes
_InitialState_Mapping and _InitialStateMembership_Mapping
should be removed from the SysMLv1Tov2.xmi.
They are not part of the specification document.
Helper::getScalarValueType checks only the name of the input parameter and does not consider the fully qualified name to check if it is part of the SysML v1 library. Any DataType of name "UnlimitedNatural" is mapped to ScalarValues::Natural.
"A RenderingDefinition is a kind of PartDefinition. As such, all the general semantic constraints for a PartDefinition (see 8.4.7.1) also apply to a ViewDefinition."
Should be "RenderingDefinition" not "ViewDefinition"
spec: "A view definition or usage is declared as a kind of part definition or usage (see 7.11.2 ), using the kind keyword view. A view usage must be defined by a single view."
Should this be "single view definition"?
Issue 1: textual notation does not include a state definition, but the graphical notation does. Change to match.
Issue 2: textual notation has an assumed spelling error, also causing a mismatch to graphical notation. In the following notation, "actio1" should likely be "action1".
state state1
{ entry actio1; do action2; exit action3; }There is an error in the last example on this page and in this section. One line calls out "comment Comment 2", which is likely intended to be "comment Comment2".
Suggest change from original: comment Comment 2
to: comment Comment2
A sentence is missing a word indicating that an owned comment is implicitly about the element owning the namespace, if it is about nothing else:
Original: "If the comment is an owned member of a namespace (see 7.5 ), then the explicit identification of annotated elements can be omitted, in which case the annotated element is implicitly the containing namespace."
Should be:"...the annotated element is implicitly about the containing namespace."
In two SysML textual notation example snippets, (1) clause 7.16.4 third snippet, (2) clause 7.16.5 last snippet, a merge node is named loop. This is not allowed as loop is a keyword.
Suggest to rename the merge node to something like loopBegin, beginLoop or loopEntry.
The coexistence of both the "GenericTo*_Mapping" classes and the Initializer classes generates a significant number of redundancies in the model, and make it harder to understand and to maintain.
More specifically it makes the management of redefinitions much more complex with a very negative impact on the clarity of the specification.
In order to fix that, all the GenericTo*_Mapping classes shall be removed and replaced par their Initializer class equivalent in an appropriate way.
The current algorithm crashes if the data type provided has no name defined or if the type is not defined
If permitted, the transformation must also enable the mapping of SysML stereotypes that extend specialized metaclasses. For example, Satisfy based on Realization or Block based on Activity.
These issues reported by Dovile.ZIAUKIENE from Dassault.
See 2 attachments.
1. Name compartment of a package does not support guilements modifiers
2. Unowned member alias notation
The specification does not describe the else-condition for an outgoing succession of a decision node.
An Operation should not be mapped to perform action, but an owned action.
In clause 8.2.3.5 graphical BNF production relationship-name has an incorrect body of comma-separated terminals.
It should use the pipe symbol as a separator instead of comma, i.e.:
relationship-name = 'defines' | 'defined by' | 'specializes' | 'specialized by' | 'connect to'
| 'subsets' | 'subsetted by' | 'performs' | 'performed by' | 'allocated' | 'allocated to'
| 'satisfy' | 'satisfied by'
There are a number of compartments in graphical notation that have misleading labels. For example, a "require constraints" compartment may contain besides pure "require ConstraintUsage" also "require RequirementUsage" statements. Similary, a "assume constraints" compartment may contain besides "assume ConstraintUsage" also "assume RequirementUsage". A "require RequirementUsage" has the same semantics as a RequirementUsage contained (isComposite==true) by a containing RequirementUsage (see explanation in subclause 7.20.2).
This is a wider problem that potentially also applies to other qualified compartment labels. The full list of affected compartment label qualifiers is:
In addition a mix of verb forms are used in compartment labels, some use the infinitive (satisfy requirements), some use third person singular form (satisfies). This is confusing and should be regularized in a consistent way, following a single rule.
Certain primitive data types have have specified extents of values
two "have"s remove one
To be more consistent across the section 7 tables in the specification, make the row headers of table 2 unique. From:
Comment
Comment
Documentation
Documentation
to something like:
Comment (stereotype hidden)
Comment (stereotype, name shown)
Documentation
Documentation with Name
There are two row headers which says "Interface". One of these showed more of a general/compartment view (no declared connection), while another shows more of an interfaces view (including a declared connection). Please make the headers more clear regarding what the reader should find.
E.g.:
Interface Usage
Interface with connection
This seems an odd choice and at least needs more explanation of how the various features of part definitions, like ports, are used
The spec says "A view definition includes filter conditions on what kinds of elements can be included in a view" here but elsewhere in 7.25.1 says "view conditions". are these the same?
For example, here "A view definition includes filter conditions on what kinds of elements can be included in a view". can this be interpreted as view usage?
The term view is used a lot and I'm wondering whether it always means "view usage".
Didn't know quite where to put this so filed against examples.
There are no examples of nested view usages, either within view usages or view definitions. As such it is not clear how view usage hierarchies work – in particular, how do nested view usages in view definitions establish their set of exposed elements.
I can't see anything in the syntax pages that shed any light on this either, and without more guidance I don't understand how to build view usage hierarchies.
In 7.25.2 the spec says "A view artifact is an individual view usage where the model content is rendered in a compartment of the view usage"
View artifact is italicized so it is presumably significant but I don’t understand the sentence.
In section 7.25.1 on page 137, view artifact is defined thus: “A view artifact is a rendering of information that addresses some aspect of a system or domain of
interest of concern to one or more stakeholders”
Currently proxy connection points are supported by GBNF only for interconnection, action-flow, and sequence views. They should also be applicable in state-flow and possibly other views such as case and general views for additional usage nodes.
The UML specifies that a use case yields a
"result that is of value for Actors or other stakeholders".
In SysML 2 it now says
"The objective is to yield an observable result that is of value to one or more of the actors".
Stakeholders are no longer allowed. I think this would be necessary.
There are use cases, whose result is not of value for any of the actors. For example a prison cell. The inmate interacts with the cell, observes the result, but is most likely not seeing a value in it. The result is of value for the society, which is not an actor of the prison cell.
I suggest to add stakeholderParameter to the properties of UseCaseDefinition and UseCaseUsage.
Additionally, it should be possible to identify the actors or stakeholders, for whom the result is of value. It is from their view, that the objective is to be described. This information whould guide the documentation of the objective.
Comment_Mapping is missing a default rule locale
The Mappings overview tables presented in the specification document of the v1 to v2 transformations includes many consistency errors with regard to the mappings actually specified in other parts of the document. This in particular true for the overview tables in the "UML4SYSML" part.
The content of those tables is generated, so there are obviously issues in the corresponding algorithm.
Note that, since, the specification of the transformation itself is not the point here, and then will not be modified by the resolution, this issue can be considered editorial.
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.)
Although deprecated, FlowSpecifications are still part of SysML v1 and there should be a defined mapping for the element.
Although deprecated, FlowPorts are still part of SysML v1 and there should be a defined mapping for the element.
Table 13 shows an example of a composite allocation. Part allocation owns an allocation between performed actions.
The graphical notation shows an allocation edge between perform edges, owned by an allocation edge between parts.
It is for sure confusing, and not sure if the textual notation that says
allocate part1.action1 to part2.action2;
is correct, provided that action1 and action2 are performed but not owned actions.
Even if technically correct, it would be better to present a clearer and simpler example of composite allocations.
The transformation ignores the entry, do, and exit behavior of a state.
The graphical notation makes use of enclosing guillemets to mark up presentation of the metaclass as well as possible metaproperties and metamodel extensions of a model element (i.e., their mapping to the SysML abstract syntax or metamodel). However, there are inconsistencies in their application. The following graphical BNF productions are affected:
Currently, metaproperties of a metaclass are treated in different ways. E.g. in a -name-compartment the isAbstract metaproperty is presented as a leading '«abstract»' literal with its own guillemets, while the isReference metaproperty is included in the main metaclass presentation, e.g., '«ref part»'.
A single, consistent rule should be established for all graphical BNF productions that concern presentation of metamodel information.
1. The GBNF production for a transition is wrong, it does not account for nodes which are not states (e.g. control nodes)
2. The production for states actions compartment is incorrect, the compartment name is currently named "states" while it should be named "state actions".
Name textual expressions in GBNF for definition and usage names,exclude various characteristics such as specializations, redefinitions multiplicity etc. Name expressions denoted definition-name-with-alias and usage-name-with-alias in the graphical BNF should reuse the textual syntax productions DefinitionDeclaration and UsageDeclaration.
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.
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.
GBNF and notation tables only cover a generic "loop action" which is not aligned with the textual syntax that has 3 specific structured actions:
Each one of the above has a specific textual syntax, that the graphical syntax should align with, to enable proper graphical modeling of actions.
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.
The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.
There are 94 uses of the word 'however' in the specification, usually starting a sentence. In many cases, the word injects unnecessary text that further confuses and obfuscates the intent. In most cases, what follows is not an exception, rather just another option of the language. In many cases the word can be replaced with ‘if’ or ‘when’ but I also found many cases where a rewrite is necessary.
Here are the first 45ish specific examples and rewrites. I stopped at page 119 as there is enough evidence to show simple rewriting of the offending test can greatly improved the text. I have also added comments to point to the issue and any further wordsmithing that seems to be required.
This seems like a minor or even a style issue, ‘however’ the point of this issue is that the use of the word muddles the descriptive intent of the text when it should be precise as possible.
2. conformance:
Original:
However, a tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.
Replacement:
A tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.
6.2 Document Organization
Original:
However, this clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
Replacement:
This clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
Comment:
Optionally delete the sentence as it is already assumed that KerML is where the reader finds the details of the details.
6.3 Acknowlegements
Original:
However, work on the specification was also supported by over 200 people in over 80 organizations that participated in the SysML v2 Submission Team (SST), by contributing use cases, providing critical review and comment, and validating the language design.
Replacement:
Over 200 people from over 80 organizations participated in the SysML v2 Submission Team (SST), contributing to the specifics and providing reviews and comments.
7.2.1 Elements and Relationships Overview
Original:
However, in some cases, additional shapes may be attached to relationship lines in order to present additional information.
Replacement:
Additional shapes may be attached to relationship lines in order to present additional information.
7.2.2 Elements
Original:
Various specific kinds of model elements in SysML are described in subsequent subclauses. However, there are certain concepts that apply to all model elements.
eplacement:
Key model elements in SysML are described in subsequent subclauses. Some of the concepts apply to all model elements.
comments: The opening statement like this are without value to the spec.
Original:
The SysML notation does not have any provision for specifying element or alias IDs, since these are expected to be managed by the underlying modeling tooling. Instead, an element can be given a name and/or a short name, and it can also have any number of alias names relative to one or more namespaces (see 7.5).
Replacement:
The SysML notation does not have any provision for specifying element or alias IDs because these are expected to be managed by the underlying modeling tooling. Instead of using an ID, an element has a given name and/or a short name that can also have any number of alias names relative to one or more namespaces (see 7.5).
Original:
However, unless at least one of these is given, it is not possible to reference the element using the textual notation (though it is still possible to show it in relationships on graphical diagrams).
Replacement:
It is not possible to reference the element using the textual notation unless a name or short name is given, though it is still possible to show it in relationships on graphical diagrams.
Original:
However, a reserved word may not be used as a name, even though it has the form of a basic name (see 8.2.2.1.2 for the list of the reserved words in SysML).
Replacement:
A reserved word may not be used as a name (see 8.2.2.1.2 for the list of the reserved words in SysML).
Original:
However, these characters may be included as part of the name itself through use of an escape sequence.
Replacement:
Non-printable characters may be included as part of the name itself through use of an escape sequence.
7.4.2 Comments and Documentation
Original:
However, marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
Replacement:
Marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
Original:
However, for any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented
Replacement:
For any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented
7.5.4 Import Filtering
Original:
comments. Namespaces other than packages cannot have filter conditions (except for their special use in view definitions and usages – see 7.25). However, any kind of namespaces may have filtered imports.
Replacement:
Namespaces other than packages cannot have filter conditions, except for their special use in view definitions and usages – see 7.25. All kinds of namespaces may have filtered imports.
comments: It is strange that this is a note as these are very specific semantics rather than an aside as would be described in a note.
7.6.1 Definition and Usage Overview
Original:
However, truck can instead redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
Replacement:
Alternatively the Truck could redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
comments: The paragraphs are rather confusing without a textual language or graphical examples. At least you could refer to an example in the annex. It is also odd to get into alternatives without an example of the alternative.
Original:
However, it is expected that if Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.
Replacement:
If Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.
7.6.3 Usages
Original:
However, a tighter default of [1..1] is implicitly declared for the usage if all of the following conditions hold
Replacement:
A tighter default of [1..1] is implicitly declared for the usage if all of the following conditions are true:
Comment: Is there a reference to where this is described in the standard?
7.6.4 Reference Usages
Original:
However, a reference usage is always, by definition, referential. A reference usage is otherwise declared like any other usage, as given above.
Replacement:
Reference usages are always referential. A reference usage is declared like any other usage, as given above.
Comment:
Once the ‘however’ was removed, the changes to the following sentence is also required to improve the explanation of the concept.
7.6.5 Effective Names
Original:
However, if neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
Replacement:
When neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
Comment:
The use of ‘however’ muddled the original explanation. Imagine Java or some other computer language with ‘however’ as a key word.
7.6.6 Feature Chains
Original:
However, their use is particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)
Replacement:
Feature chains are particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)
7.6.8 Implicit Specialization
Comment:
This may be a good use of however, but look at it anyway and see if it can be avoided,
7.7.1 Attributes Overview
Original:
However, the owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). In this case, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
Replacement:
The owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). When the attribute owner is a usage is an occurrence definition or usage, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
Comment:
This is still confusing. It again screams out for a textual/graphical language example.
7.8.1 Enumerations Overview
Original:
However, if the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
Replacement:
If the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
Original:
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.
Replacement:
The reason for this constraint is that enumerated values defined in an enumeration definition would add to the set of enumerated values, which is inconsistent with the semantics of specialization.
Comment:
This is a definite improvement over the original text, which is very confusing. It is very strange that given you are creating a new language to get around issues with UML you have not fixed this glaring issue of the inability to specialize enumerations.
7.8.2 Enumeration Definitions and Usages
Original:
However, an enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
Replacement:
An enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
Comment:
This paragraph seems like a repeat of the previous change request. Suggest choosing one and deleting the other to reduce confusion and need to maintain both statements.
7.9.1 Occurrences Overview
Original:
However, if a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
Replacement:
If a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
Original:
However, if the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)
Replacement:
If the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)
Original:
However, it could also be realized as the start and end of an explicitly modeled flow connection (see 7.13 on flow connections and messages).
Replacement:
These events can also be realized as a modeled flow connection (see 7.13 on flow connections and messages).
Comment:
This is another statement that becomes more muddled when treating it as an exception when in fact this is not an exeption, but just realkized by another possible construct.
7.9.3 Time Slices and Snapshots
Original:
However, if such an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.
Replacement:
If an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.
7.10.1 Items Overview
Original:
However, once the engine assembly is completed, the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. But later it may be removed from the car and again be considered only an inactive item in a junkyard.
Replacement:
Once the engine assembly is completed (e.g. the engine has completed manufacturing and exists as a whole), the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. Later in time, the engine may be removed from the car and again be considered only an inactive item in a junkyard.
Comment:
This is a weird example. There are many parts to an engine that are added and removed. For example, spark plugs. A spark plug could be a better example as these are assembled of pieces that are not individually replaceable and junked as a whole.
7.13.1 Connections Overview
Original:
However, the values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
Replacement:
The values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
Original:
However, a message does not specify how the payload is to be obtained from the source or delivered to the target.
Replacement:
A message does not specify how the payload is to be obtained from the source or delivered to the target.
Comment:
So how do we specify how it obtained? This needs further clarification.
7.13.2 Connection Definitions and Usages
Original:
However, if it declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.
Replacement:
If a connection definition declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.
7.13.4 Feature Values
Original:
However, for a default, bound feature value, the symbol = may be elided.
Replacement:
Optionally. a default, bound feature value, the symbol = may be elided (as shown in the default ‘mass’ in the following example).
Comment:
This a capricious and confusing option. Please choose one and delete the other. This adds a complication to the reading of the language that is unnecessary.
7.13.6 Flow Connection Usages and Messages
Original:
A streaming flow is declared similarly to a message, but with the kind keyword flow. However, instead of identifying the source and target features of the flow, such a flow declaration must identify (after the keyword from) the output feature of the source from which the flow receives its payload and (after the keyword to) the input feature of the target to which the flow delivers the payload.
Replacement:
A streaming flow has the kind keyword flow and must identify, after the keyword from, the output feature of the source from which the flow receives its payload and, after the keyword to, the input feature of the target to which the flow delivers the payload.
Comment:
The use of ‘however’ has created language of no value. The streaming flow is totally different than a message in its form. The rewrite hopefully fixes the first mistake, however the sentence is still rather obtuse and still needs some wordsmithing.
7.14.2 Interface Definitions and Usages
Original:
However, if the declaration part of an interface usage is empty, then the interface keyword is still included, but the connect keyword may be omitted.
Replacement:
If the declaration part of an interface usage is empty, then the connect keyword may be omitted.
7.16.1 Actions Overview
Original:
However, if the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.
Replacement:
If the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.
Original:
However, a succession between action usages may, additionally, have a guard condition, represented as a Boolean expression (see 7.18).
Replacement:
A succession between action usages may have an additional guard condition, represented as a Boolean expression (see 7.18).
7.16.5 Conditional Successions
Original:
However, the target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.
Replacement:
The target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.
7.17.1 States Overview
Original:
However, if the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.
Replacement:
If the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.
7.17.2 State Definitions and Usages
Original:
However, if the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. (However, no transitions are allowed between concurrent states; see 7.17.3.)
Replacement:
If the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. In this case, no transitions are allowed between concurrent states; see 7.17.3.
Original:
(However, no transitions are allowed between concurrent states; see 7.17.3.)
Replacement:
No transitions are allowed between concurrent states; see 7.17.3.
7.19.1 Constraints Overview
Original:
In general, a constraint may be satisfied sometimes and violated other times. However, an assert constraint usage asserts that the result of a given constraint must be always true at all times.
Replacement:
When an assert constraint usage asserts exists, the result of that constraint must be always true at all times. This is compared to a simple constraint may be satisfied sometimes and violated other times.
Comment:
This another example of the ‘however’ causing a confusion in the semantics. The spec should say what is true before saying what is true is an exception. In this case, there is no exception, just a differing kind of constraint than one already discussed.
The transformation maps a constraint to a constraint definition and a constraint usage. The ConstraintDefinition should be defined as ConstraintUsage and the previously generated ConstraintUsage can be removed.
The mapping of a ProfileApplication is not covered by the transformation.
ConnectorProperty is deprecated but still part of SysML v1.7. So, the transformation should provide a mapping for it.
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.
An object flow with a guard is mapped to a conditional succession and a succession flow. Conditional succession targets the succession flow. Both have the decision node as the source element. However, only one succession outgoing decision node can be taken.
Change the mapping to:
first sourceNode if guardCondition.result then objectFlow { constraint guardCondition { bind result = guardCondition.result; calc guardCondition { language "English" /* * guard says ok */ } } flow objectFlow from sourceNode to targetNode; first source then target;
The source and target of the flow succession are parameters (the target elements of the corresponding SysML v1 ObjectNodes). The source and target of the succession are the owner of the object nodes. Exceptional cases are control nodes.
The pins of a CallBehaviorAction are not mapped. Although the parameters of the action usage are inherited from the action definition, the pins must be mapped since they can have different names than the behavior parameters, different types, etc.
An ObjectFlow is mapped to a succession flow including the specification of the payload: "...of <type>".
The type of the flowing objects cannot be precisely determined (for example, if the source of the object flow is a merge node). Additionally, the ObjectFlow in SysML v1 also has no relationship to the type of the flowing objects.
Currently, ActivityParameterNodes are not mapped to v2. Instead, only the Parameter of the Activity is mapped to a parameter of the ActionDefinition. However, it is not possible to connect the parameter by a succession flow with a parameter of an action usage, for example.
Instead, map an ActivityParameterNode to an ActionUsage with corresponding input and output parameters and bind the ActionDefinition parameter with the corresponding ActionUsage parameter. For example:
action def {
in inputParameter: Integer;
bind inputParameter = __inputParameter.outbound;
action __inputParameter {
in ref outbound;
out ref inbound: Integer;
}
}
A ConnectionPointReference is mapped to a StateUsage. In addition, the state usage shoud redefine the corresponding pseudostate.
In subclause 7.26.1, Table 25, two typos appear in examples "Metadata" and "Metadata Compartment". In the graphical notation for both, AttributeDef1 should be replaced with MetadataDef1, in line with the textual notation.
The mapping class RICOAOutputPin_Mapping has no general mappings but should have Pin_Mapping
In clause 8.2.3.25 view-frame is specified as a box with sharp corners and a UML / SysML v1 style name compartment.
Since views are usages, their notation should use rounded corners. Also, the '«view»' metaclass name is missing from the graphical symbol.
Affected view examples in the representative graphical notation tables in clause 7.25.5 table 24 should be made consistent with the graphical BNF specification.
A state with several regions should be mapped to a parallel state.
The InitialState should be mapped to an empty ActionUsage owned by a StateSubactionMembership relationship.
A SysMLv1::InterfaceBlock is mapped to a SysMLv2::PortDefinition, but the owned SysMLv2::ConjugatedPortDefinition is not generated.
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.
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 chapter 7.7.5.3.7 Trigger_Mapping is empty.
The specification incorrectly mentions that CallEvent is not part of the SysML v1.7 specification, which is why no transformation is offered for either CallEvent or AcceptCallAction.
According to Table 4.2 about the included UML metaclasses in the SysML v1.7 specification, CallEvent and AcceptCallAction are part of SysML v1.7. A mapping must be specified accordingly.
Terminate node is about to be introduced to the language, need to assure it is covered by the graphical bnf
name compartment productions for send and accept actions are not reusing the textual productions for usage declarations and misaligned with the rest of the graphical BNF
A use case can have many subjects. The transformation considers only one. If there are more subjects specified, it only takes the first one in the list.
The transformation does not consider the mapping of a property typed by an Actor. It should be mapped to a usage defined by the target element of the Actor.
The mapping creates a calc inside a constraint definition. The result parameter of the calc should be bound to the result parameter of the constraint.
Allow flows to connect ControlNodes because, currently, this limitation makes it impossible to pass payloads from one ActionUsage to another ActionUsage if a DecisionNode is in between.
This issue is a showstopper for the UAF v2 development.
Currently two conventions are used for graphical action names e.g. send action vs. assign, so issue is whether the action postfix is used or not. Note that the textual notation does not use the postfix action. Regardless, this needs to be aligned along the GBNF and representative notation tables.
The resolutions by the KerML FTF to the following issues make restrictions to the functionality of imports in KerML and hence, by reference, in SysML, also:
The discussion of imports in Clause 7 Language Description need to be updated to reflect these changes (particularly in 7.5.3 Imports). In addition, adopting the requirement to always show visibility of imports in the concrete syntax, consistent with KERML_-74, requires changes in
The Systems Library model AnalysisCases includes a declaration for AnalysisAction as a specialization of Actions::Action. In the abstract syntax, ActionDefinition::analysisSteps and ActionUsage::analysisSteps are derived to be the subactions that are AnalysisActions.
However, no special semantics are specified for AnalysisActions and no special concrete syntax for defining analysisSteps. So they are never used in practice within user models of analysis caes, so they seem pointless.
There is a bunch of mapping defined in the "GenericMappings::Common" package. However, they are not used very much in by other mappings while multiple more specific versions of them have been created without a good rationale. Defining reusable mappings is a good idea and could greatly simplify the specification of the transformation by reducing the number of classes it contains... Assuming they are actually used!
I do think it deserves a global review and optimization.
Note that some of those "common" mappings shall be fixed with regard to either their source type, the body condition of some of their rules or both.
In case the client of the client of the Satisfy relationship is a block, a ReferenceUsage will have to be generated. The type of that ReferenceUsage shall be the Definition corresponding to that block.
It is necessary to create a reference usage if and only if the client of the Satisfy relationship is a block. Instead, the current version of the Satisfy_Mapping create it if and only if the client is a property
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.
Clause 7.7.3.3.17 (CommonActivityEdgeSuccessionAsUsage_Mapping), Description says
The mapping class provides a common mapping of a UML4SysML::ActivityEdge to a SysMLv2 SucessionAsUsage.
Clause 7.7.3.3.35 (ObjectFlow_Mapping), Description, says
A UML4SysML::ObjectFlowFlow without a guard condition is mapped to a SysMLv2SuccessionFlowConnectionUsage.
This seems to say all ActivityEdges, including ObjectFlows are mapped to v2 Successions, is that right? This prevents mapping of object flows from/to streaming parameters, which enable actions to provide output and take input while they are executing, with object flows between the respective pins potentially defining guards to filter which items move across which object flows, per UML 2.5, Clause 15.2.3.3 (Activity Edges), second paragraph.
The above isn't mentioned, AFAICT, in the various "not mapped" tables, and the term "stream" doesn't appear anywhere in the Transformation specification.
SatisfyRequirementUsage subsets Requirements::notSatisfiedRequirementChecks or Requirements::satisfiedRequirementChecks in pilot implementation.
checkSatisfyRequirementUsageSpecialization constraint should be defined in the specification.
In the Systems Library model Parts, the base part definition Part is declared to have the features ownedPorts, ownedActions and ownedStates. These features are described in 8.4.7 Parts Semantics, noting that the are covered further in 8.4.8 Ports Semantics, 8.4.12 Actions Semantics and 8.4.13 States Semantics, respectively. More specifically, 8.4.8.2 Port Usages, 8.4.12.2 Action Usages and 8.4.13.2 State Usages state that the semantic constraints checkPortUsageOwnedPortSpecialization, checkActionUsageOwnedActionSpecialization and checkStateUsageOwnedStateSpecialization determine the required specialization of the relevant Part features. However, of these, checkActionUsageOwnedActionSpecialization is defined in the abstract syntax, but the other two are not.
For some reason, the textual syntax for interface usage limits the set of elements allowed in its body (see InterfaceBody in clause 8.2.2.14.1). This prevents users from redefining inherited attributes in the usage:
interface myInterface : MyInterfaceDef // MyInterfaceDef defines attribute x
connect end1 ::> end1InOuterScope
to end2 ::> end2InOuterScope {
redefines x = 5; // syntax error
}
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 7.16.1 (Actions Overview), under Sequencing of Actions, 7.16.3 (Control Nodes), and 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 binding 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".
Expose relationship is used to map a view usage element to a model element. In case of elements such as featureTyping, Subsetting and others, since they are not namespaces and not memberships, it is not possible to use it for views of such elements.
That creates a problem for consistency using expose for graphical view representations, and requires a "workaround" to capture the relationship between view usages and such elements.
Test. [Conrad] I can edit this.
In clause 7.16.1, Table 14, example "Action with Parameters", the name "param2 : ItemDef2" of the out parameter on the righthand side should be placed outside the action1 rectangle.
In the SysML Specification, in non-normative Language Description subclause 7.6.3 Usages, it describes several conditions that, if met, require a usage to have default multiplicity 1..1. However, there is no formal specification of this in the normative Clause 8 Metamodel.
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 exampie.
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.
As mentioned in section "7.7.2.3.7.20 ClearStructuralFeatureAction_Mapping": The details of the mapping are not defined yet.
As mentioned in section "7.7.2.3.7.34 RemoveStructuralFeatureValueAction_Mapping": The details of
the mapping are not defined yet.
The mapping AddStructuralFeatureValueAction ignores the names of the input and output pins and uses the names defined in the SysMLv1Library::AddStructuralFeatureValueAction element.
The fourth and sixth rows of "Table 16. States – Representative Notation" each give an example of a transition statement that contains both an if statement and an accept statement, with the accept before the if.
... transition first state1 accept trigger1 if guard1 ...
However, page 110 and the subsequent examples seem to contradict this:
A transition usage can also have an accepter, which is an accept action usage use to trigger the transition. The accepter action for a transition usage is placed after the guard expression and notated using the accept keyword, with its payload and receiver parameters specified exactly as discussed in 7.16.8 .
If an accept before an if has a different meaning than an if before accept, the specification document does not make this obvious.
The Jupyter Kernel in release 2024-05 of the SysML-v2-Release repository treats an if before an accept as a syntax error.
The Analysis Domain Library model TradeStudies includes the following definition:
requirement def MinimizeObjective :> TradeStudyObjective {
doc
/*
* A MinimizeObjective is a TradeStudyObjective that requires that the
* selectedAlternative have the minimum ObjectiveFunction value of all the
* given alternatives.
*/
subject :>> selectedAlternative;
in ref :>> alternatives;
in calc :>>fn;
out attribute :>> best = alternatives->minimize {
doc
/*
* For a MinimizeObjective, the best value is the minimum one.
*/
in x; fn(x)
};
}
(and there is a similar definition for MaximizeObjective that uses maximize instead of minimize). Unfortunately, in the definition minimize in the Kernel Function Library model ControlFunctions, the functional argument to minimized is named fn, and, in the expression fn(x), the name fn gets bound to this parameter, instead of to MinimizeObjective::fn. This means that an evaluation of the invocation of minimize as given will result in an infinite recursion (and similarly for the call to maximize in MaximizeObjective).
In subclause 8.2.3.13 productions for n-ary ConnectionDefinition should be added, similar to the existing production n-ary-connection for n-ary ConnectionUsage.
An n-ary ConnectionDefinition example is given in 7.13.1 Table 11 in row "Connection Definition (n-ary with 3 ends)", like so:
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.
According to the constraint checkStateUsageExclusiveStateSpecialization (in 8.3.17.6), a substate of a non-parallel owning state definition or usage must specialize StateAction::exclusiveStates (at least according to the description of the constraint; the OCL is wrong, see SYSML2_-183). However, the feature StateAction::substates actually meets the requirements for the application of checkStateUsageExclusiveSpecialization, which means that it has an implied specialization of exclusiveStates. But exclusiveStates already subsets substates (at least according to the library model in States.sysml; the feature exclusiveStates seems to be missing from subclause 9.2.10.2.1 StateAction), so this would mean that all substates are exclusiveStates, which is, of course, incorrect for the semantics of parallel states.
This table has two rows where the Element Column states Enums Compartment. Recommend adding information to the row titles to indicate what aspect of the compartment is important. E.g., Enums Compartment (enumeration usage names) and Enums Compartment (enumeration values). Alternatively, combine these into one row.
"State with entry, do and exit actions." - code shows "entry actio1" instead of "entry action1"
"State with entry, do and exit actions": image showns definition by StateDef1, textual notation does not show this.
in SysML v1 there is a concept of Complete in terms of Specialization of a GeneralizationSet... that concept seems to be missing in SysML v2
a classifier in SysML v1 can have isFinalSpecialization:Boolean ... that concept is missing in SysML v2
in SysML v1 a RedefinableElement can have a isLeaf:Boolean... this concept seems to be missing in SysMLv2
in SysMLv1 for an ElementImport one can supply an Alias... That seems to be missing in SysMLv2
In the Geometry Domain Library model ShapeItems, in the item definitions CircularDisc, Sphere, CircularCone and CircularCylinder, the radius feature is bound to semiMajorAxis (or semiAxis1 for Sphere). However, because of the constraint featureValueOverriding, this means that the radius features cannot be re-bound to specific values in user-model usages of these definitions, as would be expected. (Note that this can only be seen in the ShapeItems.sysml file, not in the description in the specification document.)
The transformation does not specify mapping rules for SysMLv1::FlowProperty.
In the following example:
enum def Enum2 :> ScalarValues::Integer {a=1; b=2;} attribute x1 : Enum2 = Enum2::a; attribute x2 : Enum2 = 1; attribute x3 : Enum2 = 42;
x3 is invalid, but currently, there is no validation for it.
Mr. Ed Seidewitz wrote:
x3 is semantically invalid, since 42 is not a legal value for Enum2, but there is currently no static validation check for it. This cannot be checked statically in general, because the bound value could be any expression returning an Integer, the value of which may not be determinable without doing a complete execution/evaluation of the model (we don’t currently have a general way to report “runtime” semantic errors like this, other than that the model will be formally “unsatisfiable”). It might be possible to add a validation constraint for the case in which the both the enumerated values and the bound value in the attribute usage are model-level evaluable expressions (which would catch the case of your x3), though the OCL could be a bit complicated. If you think it is worth it, you could file a SysML v2 Jira issue for this, though it probably not be addressed in the FTF (though we could possibly address it on the KerML side when resolving KERML_-245 to add enumeration syntax to KerML).
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.
The mapping given in 9.2.21 from the MOF abstract syntax model to the reflective SysML abstract syntax model is missing instructions for what to do if a property is ordered or non-unique. Therefore, appropriate annotations for these are missing from the normative SysML.sysml file.
The KerML specification contains guidance for tooling to highlight keywords in concrete textual notation. KerML subclause 8.2.2.6 specifically says:
Tooling for the KerML textual notation should generally highlight keywords relative to other text, for example by using boldface and/or distinctive coloring. However, while keywords are shown in boldface in this specification, the specification does not require any specific highlighting (or any highlighting at all), and KerML textual notation documents are expected to be interchanged as plain text (see also Clause 10 on Model Interchange).
A similar statement, modified for SysML, should be added, probably as a last paragraph under subclause 8.2.2.1.2, including a cross-reference to KerML. For SysML the same guidance applies to textual snippets used in the Graphical Notation.
In the SysML Specification, 9.2.6.2.4 connections, the base connection usage connections is specified as being a ConcernUsage under "Elements". This should, instead, be ConnectionUsage. (Note that this error is only in the document, and connections is declared correctly in the Connections.sysml model file.
The following example appears in 7.8.2 Enumeration Definitions and Usages:
enum def ConditionColor { red; green; yellow; }
attribute def ConditionLevel {
attribute color : ConditionColor;
}
enum def RiskLevel :> ConditionLevel {
enum low { color = ConditionColor::green; }
enum medium { color = ConditionColor::yellow; }
enum high { color = ConditionColor::red; }
}
This is example is not valid, because the color features defined in the enumerated values will have name conflicts with the color feature inherited from ConditionLevel. The intent was probably to have the color features in the enumerated values redefine ConditionLevel::color, but that is currently missing from the example.
In 8.3.17.6 StateUsage:
A StateUsage that is a substate usage with a non-parallel owning StateDefinition or StateUsage must directly or indirectly specialize the StateUsage States::State::exclusiveStates from the Systems Model Library.
However, the OCL for the constraint actually checks for the owning state being parallel (rather than non-parallel) and requires specialization of substates rather than exclusiveStates.
A StateUsage that is a substate usage with a owning StateDefinition or StateUsage that is parallel must directly or indirectly specialize the StateUsage States::State::substates from the Systems Model Library.
However, the OCL for the constraint actually checks for the owning state being non-parallel (rather than parallel).
Check if this StateUsage is composite and has an owningType that is an StateDefinition or StateUsage with the given value of isParallel, but is not an entryAction or exitAction. If so, then it represents a StateAction that is a substate or exclusiveState (for isParallel = false) of another StateAction.
However, the OCL for the operation actually does not check if the state usage is composite and also excludes do actions (in addition to entry and exit actions).
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.
Right now use-case nodes cannot be associated with actors and subjects. They need to be made subject/actor stakeholders
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?
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 graphical representation of metadata definition and semantic metadata definition is missing from the specification. The resolution should include the addition of one or more entries in the representative notation tables of metadata definition, for both regular and semantic metadata definition, and the graphical BNF should be updated to support this capability.
See also the explanation in https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/releases/tag/2022-09 .
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 notation tables show various permutations of send/receive actions with various parameter options. They are all shown against a single simple textual example. It is unclear what is the purpose of rationale each permutation.
Graphical Examples need to align with corresponding text examples.
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.)
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; }
State shall be able to have proxy nodes on their boundaries. Currently not covered by the GBNF
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.
Both Enumeration and ValueType have main mappings and their specified filters do prevent a double match
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
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
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.
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 body condition specified for this operation is wrong. It should be an empty set.
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
GenericToElement_Mapping is missing default rules for:
A graphical BNF production should be added that specifies that keywords may optionally be included on edges.
GenericToRelationship_Mapping should provide default rules for
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
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.
Notation table shows item flows on interface connections. This is not enabled by the graphical BNF
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.
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
The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect
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.
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
Sub-clause 8.2.3.3 (dependencies) uses element-node as the source and target of a dependency.
element-node is not defined anywhere
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 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.
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.
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.
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.
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.
Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline
Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.
In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».
Add import qualifier text (* or **) to upper right corner of imported Package
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.
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.
Clarify that the identifier for the metadata declaration is the metadata definition name.
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.
The transformation does not map the Parameter::isStreaming.
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 mapping of a Unit and a QuantityKind is not covered by the transformation yet.
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 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.
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::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 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.
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?
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.
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 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.
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.
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.
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::ParticipantProperty.
The transformation does not specify mapping rules for SysMLv1::PropertySpecificType.
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::BoundReference.
The transformation does not specify mapping rules for SysMLv1::View.
The transformation does not specify mapping rules for SysMLv1::InvocationOnNestedPortAction.
The transformation does not specify mapping rules for SysMLv1::Conform.
The transformation does not specify mapping rules for SysMLv1::DistributedProperty.
The transformation does not specify mapping rules for SysMLv1::Expose.
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 UML4SysML::UnmarshallAction.
The transformation does not specify mapping rules for SysMLv1::ChangeStructuralFeatureEvent.
The transformation does not specify mapping rules for UML4SysML::LinkEndData.
The transformation does not specify mapping rules for UML4SysML::ActivityPartition.
The transformation does not specify mapping rules for UML4SysML::Clause.
The transformation does not specify mapping rules for UML4SysML::LinkEndDestructionData.
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::InteractionConstraint.
The transformation does not specify mapping rules for UML4SysML::Gate.
The transformation does not specify mapping rules for UML4SysML::ExecutionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::OccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::Continuation.
The transformation does not specify mapping rules for UML4SysML::PartDecomposition.
The transformation does not specify mapping rules for UML4SysML::GeneralOrdering.
The transformation does not specify mapping rules for UML4SysML::ConsiderIgnoreFragment.
The transformation does not specify mapping rules for UML4SysML::TimeConstraint.
The transformation does not specify mapping rules for UML4SysML::Image.
The transformation does not specify mapping rules for UML4SysML::DestructionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::DurationInterval.
The transformation does not specify mapping rules for UML4SysML::Interval.
The transformation does not specify mapping rules for UML4SysML::StringExpression.
The transformation does not specify mapping rules for UML4SysML::DurationObservation.
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::Duration.
The details of the mapping of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode are not specified.
The transformation does not specify mapping rules for UML4SysML::DurationConstraint.
The extend relationship between use cases is not covered by the transformation.
The transformation does not specify mapping rules for UML4SysML::TimeInterval.
The transformation does not include a mapping for UML4SysML::GeneralizationSet.
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.
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.
There is no Graphical BNF for grid rendering, required by the Grid View Standard View Definition.
This should be added.
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 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.
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.
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.
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 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.
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).
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.
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 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).
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.
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).
Add standardized element icons and standard view definition icons as they should appear in a browser or on diagrams.
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.
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 transformation does not consider the property UML4SysML::RemoveVariableValueAction::isRemoveDuplicates.
