The specification does not specify a graphical notation for the cross-subsetting. The textual notation is specified with keyword "crosses" and short-hand syntax "=>".
checkInvocationExpressionDefaultValueBindingConnector has no OCL
checkConstructorExpressionResultDefaultValueBindingConnector has no OCL
An example that also show successions and time constraints.
in clause 7.16 table 14, the example sequence diagram does not match the textual model across as it does not refer to the events.
The graphical notation needs to add the event references using proxy connection points on the lifelines.
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.
This is done with cross subsetting, which is a special kind of subsetting
relationship specified using the keyword crossing or the symbol =>.
replace the work crossing with crosses
No Abstracts shown in Metamodel... I am assuming one cannot create an Element... yet it is not shown as italicized in the
metamodel... that would be helpful if you had that in the metamodels
Performed By
Compartment is empty
checkCalculationUsageSubcalculationSpecialization has no definition
it says "Further, the keyword else may be used in place of a guard expression" but it needs to add
that may be used in palce of a guard and following then
because the else replaces the then... and nowhere in the spec does it say you can remove the then.... yet that is in the examples
The current SysML metamodel defines use cases as specializations of behavioral elements—effectively treating them as calculations or executable functions. This characterization is semantically inconsistent with the foundational role of use cases in systems modeling. Use cases are not behaviors the system performs internally; rather, they represent contracts or agreements between external actors and the system, specifying what the system is expected to do in response to a stimulus. Modeling use cases as executable behaviors introduces a category error into the metamodel and risks conflating external interactions with internal mechanisms.
Use cases, by their very nature, are interaction scenarios. They do not define how a result is computed or executed, but instead describe what result is expected when a particular actor engages the system in a defined way. Their semantics are declarative and externally visible; they are about outcomes, not procedures. As such, the current inheritance from computational behavior types (such as Function or Behavior) is conceptually incorrect. This structural alignment misleads modelers and tool developers into treating use cases as execution artifacts, which they are not.
If the metamodel insists that use cases must derive from a parent behavioral concept, a more accurate—though still imperfect—choice would be to inherit from a construct akin to a state transition. This would at least preserve the idea that use cases mark a change in the system’s externally observable state as a result of actor interaction. Even so, this remains a second-best solution, as it still imposes a behavioral framing on what should be a scenario-based modeling construct.
The preferred and semantically coherent approach is to model use cases as a distinct first-class metamodel element, such as a Scenario. This new metaclass should stand apart from behavioral execution elements and focus solely on external intent, interaction structure, and resulting system obligations. Two clear examples of such Scenario constructs would be Use Cases and Acceptance Test Scripts. Doing so would reinforce the modeling clarity that use cases are not descriptions of how the system behaves internally, but agreements about what the system must do when engaged from the outside.
Separating use cases from procedural behavior elements also promotes stronger model validation and traceability. It enables more accurate conformance checking between actor expectations and system behavior without enforcing implementation-specific logic. This adjustment to the metamodel aligns better with the practical and pedagogical use of use cases in systems engineering and eliminates the conceptual mismatch that currently exists.
In summary, the treatment of use cases as calculations within the SysML metamodel introduces a fundamental misalignment between semantics and structure. Reframing use cases as scenario-based constructs—independent from executable behaviors—restores conceptual clarity and reinforces the integrity of the modeling language. This change would provide immediate benefit to the precision, usability, and future extensibility of SysML.
subject vehicle : Vehicle {
...
then event occurrence startsDrive [1];
then event occurrence endsDrive [1];
should be
subject vehicle : Vehicle {
...
then event occurrence drives [1];
to make
then message of Drive from vehicle.drives to environment.vehicleDrives;
correct
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 doc descriptions of MergeAction, DecisionAction, JoinAction and ForkAction use "succession connector". This should be replaced with "succession connection" (4 times).
Standard library ISQMechanics.sysml contains a declaration of torque as a scalar quantity to represent torque magnitude, but the related torque vector quantity is missing.
A torque vector quantity and associated coordinate frame should be added using the same pattern as for other vector quantities.
Note: This issue was flagged in "SysML v2 Release" Google Group at https://groups.google.com/g/sysml-v2-release/c/w7ZbFZ9d-e0/m/yTF8oyb6AwAJ .
Tables 25 and 34 in clauses 7.26.5 and 9.2.20.1 respectively have inconsistent descriptions of standard views. Table 34 is the authoritative source for the standard view definitions. The first column of Table 25 will need to be updated to be consistent with Table 34.
As part of the Users WG in coordination with Execution WG, we have determined that successions from the "start" of a state or the "entryAction" of the state can cause confusion for many users. As such, we want to "deprecate" this usage in favor of requiring an explicit state transition from "start" to the first subState.
We will need to update all of our relevant graphical and textual examples shown in the spec to demonstrate this preferred approach and remove the previous approach.
Models using successions from "start" or "entryAction" will remain valid but will not be the preferred method. We will want to indicate that support for such may be removed in some future version, subject to a discussion around what the deprecation policy should be.
In 'Table 3. Packages - Representative Notation', there is a 'Package with owned package' graphical example where the owned package is displayed but as text rather than as a node.
Should this example be removed, or should the 'general-view' element be updated to include node representation in text?
There is an inconsistency between Table 3. Packages - Representative Notation (specifically the Package with imported package (nested notation) element) and the Graphical BNF. In section 8.2.3.5 Namespaces and Packages Graphical Notation, it is specified that the Package shape should not display any keywords above its name when it is imported. However, in the table example, the visibility indicator keyword is visible.
The following cosmetic changes are needed for some graphical examples displayed in the tables:
There is an inconsistency in the Table 4. Definition and Usage - Representative Notation table (specifically the Name Compartment - Definition element).
In this example, the abstract keyword is omitted from the symbol keyword («part def»), whereas in other examples, the abstract keyword is displayed when usage/definition is shown as a shape.
Does this imply that additional property keywords are optional for display in the shape?
In section 8.2.3 of the Graphical Notation for packages, it is stated that no keyword should be displayed before the name.
Our concern is that without a keyword, it will not be possible to differentiate a library package from a standard package within the diagram.
There is an inconsistency between the examples in the following tables and the Graphical BNF:
In these examples:
There is an inconsistency between the examples in the following tables and the Graphical BNF:
In these examples, some shapes are missing the symbol keyword within «». According to the Graphical BNF, these keywords do not appear to be optional.
There are inconsistencies between table examples and the Graphical BNF due to compartments being displayed that are not specified in the BNF:
There is an inconsistency between Table 19. Requirements - Representative Notation (specifically the 'Requirement' element) and the Graphical BNF (section 8.2.3.4).
In the table example, the 'doc' compartment is labeled as 'documentation,' which is incorrect according to the BNF. The label should be 'doc.'
In the following tables, examples display port/parameter labels on the border as being inside the context:
However, according to the BNF specification (8.2.3.12; 8.2.3.16), labels for ports and parameters on the border should be positioned outside the context.
In Table 4. Definition and Usage - Representative Notation, the 'Name Compartment - Definition (abstract)' element displays the usage as abstract, with its name in italic font. However, other examples with abstract usages/definitions, such as 'Name Compartment - Definition' and 'Name Compartment - Usage (abstract)', do not display their names in italic font.
In Table 16. States - Representative Notation, the "State with entry, do, and exit actions" element includes an 'actions' compartment, where the entry, do, and exit actions are displayed.
However, in the 8.2.3.17 States Graphical Notation section, it is specified that the only compartment permitted to display the entry, do, and exit keywords is named 'states', creating a discrepancy between the table and the section.
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.
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”
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
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
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.
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.
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 representative notation example "Package with members compartment" shows the members compartment which is the default compartment and does not require a compartment label. Change members compartment label to the requirements compartment label and adjust the package content and textual notation accordingly, i.e. with requirement elements.
Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.
Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.
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 import qualifier text (* or **) to upper right corner of imported Package
In 7.15.1 Allocations Overview, Table 17, entry for "Allocation (with sub allocation)", the name acton1 in the graphical notation should be action1.
Verified
Requirements
Compartment
is empty need to be filled or removed
Performed By Compartment is empty needs to be removed or filled
In subclause 7.8.1, Table 6 "Enumerations", first example row "Enumeration Definition", the graphical notation has two mistakes: in both enumeration definition symbols the label within guillemets should read «enum def» instead of «enumeration def», as specified in the Graphical BNF per subclause 8.2.3.8.
Add to the row names more detail that indicates that one is part def - part feature membership and one is part - part feature membership.
SysML2 should support both graphical and textual syntax for guards on flows. The graphical and textual syntax should be like the syntax for successions. Ideally, the abstract syntax created by parsing the graphical and textual syntax for guards on flows should be more direct than the approach suggested for translating SysML1 object flows into SysML2 (proposed in Section 7.7.3.3.50 of the SysML v1 to SysML v2 Transformation specification).
In subclause 8.2.3.8 three corrections on graphical BNF productions are needed:
Need to add recursive production of swimlanes as part of the swimlane graphical production.
Currently the graphical BNF only allows a flat sequence of swimlanes.
However in case of a hierarchical parts structure, for example, it is desired to represent the parts containment hierarchy using a hierarchy of nested swimlanes. For example a swimlane that represents a vehicle is partitioned into two nested swimlanes for the engine and the transmission.
Clause 9.3.5 describes icon metadata, with the objectives to attach icons to model elements in a graphical/tabular view,
There are two issues here
(1) It is not practical too attach an icon to each individual usage, it is expected that assigning such a metdata to a semantic metadata would imply the icons also on elements referring to the semantic metadata. For example, if a semantic metadata defined for "assembly", any definition or usage "tagged" as assembly is expected to have this icon. The current specification does not address this practical issue.
(2) The graphical notation representative tables anf BNF do not cover how an icon is represented in case an icon is defined
In Table 15 of the Representative Notation Tables, the row labeled Accept and Send Action Flow includes a model fragment that uses a combination of a succession and a binding connection to connect to the input payload parameter of a send action and from the output payload parameter of an accept action. This issue recommends adding another example of a common pattern that replaces the succession and the binding connection with a succession flow.
The current specification presents two issues with compartment definitions:
• The same elements may appear in multiple compartments, even when a more specific compartment is defined (e.g., action and perform action).
• Because keywords are hidden, compartment element keywords cannot be clearly distinguished (for example, perform action looks the same as action).
To address these issues, the following adjustments are proposed. Specific compartments should explicitly exclude overlapping contents:
actions-compartment-contents (page 227)
• exclude perform-actions-compartment-contents (page 227)
use-cases-compartment-contents (page 255)
• exclude include-use-cases-compartment-contents (page 255)
states-compartment-contents (page 238)
• exclude exhibit-states-compartment-contents (page 239)
constraints-compartment-contents (page 243)
• exclude require-constraints-compartment-contents (page 246)
• exclude assume-constraints-compartment-contents (page 246)
• exclude assert-constraints-compartment-contents (page 244)
requirements-compartment-contents (page 246)
• exclude satisfy-requirements-compartment-contents (page 247)
• exclude verifies-compartment-contents (page 253)
Currently, the usage appearance in the ‘parameters’ compartment is defined in the “8.2.3.17 Actions Graphical Notation” chapter as follows:
parameters-compartment-element = el-prefix? FeatureDirection UsageDeclaration ValueOrFlowPart? DefinitionBodyItem*
This is not consistent with other compartments that represent elements which can declare a direction (it includes only the ‘direction’ modifier but omits others), such as items, parts, and attributes:
items-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
attributes-compartment-element = el-prefix? UsagePrefix usage-cp
Currently, the usage appearance in end compartment are declared in “8.2.3.14 Interfaces Graphical Notation” chapter like that:
ends-compartment-element = QualifiedName (’:’ QualifiedName)?
It is not consistent with all other compartments, e.g. parts, ports:
parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
ports-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
Currently the BNF requires a separate flow symbol for every flow that transpires over a connection (or an interface).
It is requested to also support a more compact notation, that each flow symbol can represent multiple flow usages specified in a comma separated list.
Subclause 7.27 shows a metadata node attached to a usage with a dotted connector. This is not supported by the GBNF. metadata-feature-annotation-node defined in subclause 8.2.3.27 should be included with the annotation-node production in subclause 8.2.3.4.
Graphical BNF does not allow a metadata compartment.
Annotations and successions are consistently represented with short dashes in both the graphical examples in Clause 7 and the graphical BNF. However, the specification does not consistently depict the dashed lines that are used in dependencies and related relationships.
DEPENDENCIES:
Table 1 "Dependency" - long dashes
Table 1 "Dependency - nary" - medium dashes
8.2.3.3 binary-dependency - short dashes
8.2.3.3 n-ary-dependency-*-link - short dashes
IMPORTS:
Table 3 "Import (recursive) - short dashes
8.2.3.5 import - long dashes
EXPOSE:
Table 24 "Expose" - long dashes
8.2.3.26 expose_r and *-expose-r - short dashes
Recommend the graphical BNF and graphical examples in the tables be made consistent in showing these relationships as having long dashes. This will help users to distinguish these types of relationships from those having short dashes, e.g., successions and annotations, and would be more familiar to users having experience with UML, SysML v1, etc.
1. The perform-actions-swimlanes production does not appear to be used anywhere.
2. The swimlane production only appears to support vertical swimlanes. i.e., with the action flow displayed below the head rather than to the right of it. Horizontal swimlanes should also be supported.
3. There is no production for the <<performer>> keyword in the head of a swimlane. The appropriate production appears to be Usage-name-compartment (which is missing, as was noted in SYSML21-251), but this name should probably be changed to be more specific to this usage, e.g., swimlane-name-compartment or performer-name-compartment to be consistent with the names of other similar productions.
4. The note "Note. All swimlanes are attached to each other on vertical edges and aligned along the top and bottom horizontal edges." in 8.2.3.17 does not appear to be followed by the examples of swimlanes that appear in Table 15.
5. The swimlanes production have squared (right-angled) corners, but rounded corners appear in the examples in Table 15.
The specification does not define how to show filter conditions at an import relationship, and it also does not define a compartment for packages for owned filter conditions.
In the Graphical BNF, the only usages that lack the 'compartment-stack' section are the send and accept action usages. Is this intentional, meaning these actions cannot have compartments?
In section 8.2.3.12 of the Ports Graphical Notation, ports displayed as shapes have only a solid border, whereas ports on the border of another shape may also have a dashed border, as noted:
"Dotted line port productions (references) are only possible for nested ports."
This implies that a nested port can be displayed on another port with a dashed border. However, based on the BNF, the same nested port cannot be displayed with a dashed border when shown as a regular shape.
There is an inconsistency between Table 14. Actions - Representative Notation (specifically the Actions with Control Nodes element) and the Graphical BNF.
In this example, the control nodes (join, fork, decision, and merge nodes) have names displayed in the diagram. However, the Graphical BNF (section 8.2.3.16 Actions Graphical Notation) does not specify that names can be displayed for these nodes.
There is an inconsistency between the table examples and the Graphical BNF (section 8.2.3.13):
In these examples, the line connecting the connector as a path and as a shape is represented with dashes. However, in the BNF, this line is specified as dotted.
There are inconsistencies between the examples in Table 12. Interfaces - Representative Notation (specifically the 'Interface as Node' and 'Interface as Node (with flow)' elements) and the Graphical BNF (section 8.2.3.14).
In these examples, nested shapes are displayed without a compartment. However, the BNF does not specify that a general view or interconnection view is applicable for interface usage.
There is an inconsistency between Table 14. Actions - Representative Notation (specifically the 'Parameters Compartment' element) and the Graphical BNF.
In the table, the 'return' keyword is displayed before the name of the 'param4' feature. However, the 'return' keyword is specified under the 'ReturnParameterMember' element, which is not included in the 'parameters-compartment-element' specification. As a result, based on the BNF, the 'return' keyword should not appear in the parameters compartment.
There is an inconsistency between Table 18. Constraints - Representative Notation (specifically the 'Constraints Compartment' element) and the Graphical BNF (section 8.2.3.19).
In the example, the keywords 'require', 'assume', and 'assert' are displayed before the constraint name. These keywords are only defined under 'AssertConstraintUsage' (for 'assert') and 'RequirementKind' (for 'assume' and 'require'). However, these elements are not included within the 'constraints-usage-compartment-element' specification.
There are several examples where the 'doc' keyword is displayed in the 'objective' compartment:
However, upon reviewing the specification for the 'objective' compartment, neither the 'doc' keyword nor the documentation text body is visible in any of the specified elements.
There is an inconsistency between Table 23. Views and Viewpoints - Representative Notation (specifically the 'Frame' element) and the Graphical BNF in section 8.2.3.20.
In the table, the 'frame' relationship connects a viewpoint to concern usages. However, the BNF specification for the 'frame' relationship does not include viewpoint usage as one of the possible relationship ends, as it has 'subject-actors-stakeholders-node' for one end and 'concern' for another.
The 'subject-actors-stakeholders-node' includes:
Additional properties that are specified under UsagePrefix/OccurrencePrefix element are missing for these usages inside the «» :
The Swimlane element is described in the specification as containing two elements: Usage-name-compartment and action-flow-node. However, several issues arise with this definition:
The issues regarding the Swimlane:
action-flow-node = start-node | done-node | fork-node | join-node | decision-node | merge-node | send-action-node | accept-action-node | while-loop-action-node | for-loop-action-node | if-else-action-node | assign-action-node
In the Table 19. Requirements - Representative Notation table in the Satisfy Requirements Compartment element a lot of information is displayed:
satisfy-requirements-compartment-contents = text-block
In the graphical BNF the short usage name notations are not specified as well duplicated usage keywords are possible. For these usages, the issues occurs:
In the Table 25. Metadata - Representative Notation (Chapter 7.26.1 , page 151) table there is an element that specifies the metadata compartment, however, this compartment is not specified in the Graphical BNF.
For ports and parameters on border, connectors and transitions name label there is no indication to display an inheritance symbol.
The el-prefix is not indicated in none of these element specifications.
proxy connection in sequence views should be contextualized on lifelines.
Right now they just float as nodes.
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
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'
In subclause 7.20.1, Table 19, example "Requirement" the compartment labels "require constraints" and "assume constraints" and their content are misleading and inconsistent.
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".
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.
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
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.
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!
State shall be able to have proxy nodes on their boundaries. Currently not covered by the GBNF
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.
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.
A graphical BNF production should be added that specifies that keywords may optionally be included on edges.
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.
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
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.
In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.
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.
Clarify that the identifier for the metadata declaration is the metadata definition name.
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.
There is no Graphical BNF for grid rendering, required by the Grid View Standard View Definition.
This should be added.
A variant is an owned member of its variation and is also a specialization of its variation. As a result, the variant inherits the owned member relationships from its variation.
This appears in the diagram in the attached example (file name: variant_inheritance_from_variation_issue_sf_2023-04-12). The transmissionAutomatic has an inherited ownedMembership to the transmissionManual and to itself. This applies to the transmissionManual as well.
Refer to the spec clauses as 8.2.3.5 Namespaces and Packages Graphical Notation and 8.2.3.6 for Definition and Usage Graphical Notation (where variation is introduced).
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.
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.
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.
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.
Clarify how to show the owning context for a nested feature in a graphical view such as a state transition view (Proposed solution: consider 'exhibited by vehicle' for state transition view of vehicleStates).
The graphical notation for allocating a flow to a connection, that is consistent with textual notation, is missing.
This should be added.
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
How a view/query is performed when using a view as an input mode is unspecified.
This should be clarified and added.
Add standardized element icons and standard view definition icons as they should appear in a browser or on diagrams.
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.
Compartment in Table 13 says "allocated"...
allocations-compartment has the marker called "allocations"
I think one of these need to be changed
Cases can be used "in its own right"... there needs to be a graphical notation for Cases
confirm state-actions-compartment is "states" not "state actions"
in the graphical notation for states the compartment name is "exhibit states" ... yet in the example in table 17 there is exhibits and exhibitedBy
is this a mistake?
action-def-name-compartment =
'«' DefinitionPrefix 'action' 'def' '»'
definition-name-with-alias<
don't think the ending < should be there
Currently flow connections can be connected to control nodes such as decision/merge/fork/join using parameters, and the behavior needs to be explicitly specified like in any action. This is a limitation comparing to UML that allowed flows to be seamlessly connected to control nodes with proper semantics to cover such connections. In SysML V2 the current approach is to specify parameters on control nodes to handle this. There are two main issues here:
The expectation is to provide proper semantics to connect flow connections similar to UML/V1, and keep the graphical symbols "atomic" without having to add compartments or parameters, at least for "default" use cases
Currently, the compartment names for While Loop, For Loop and If-Else actions differ slightly from their corresponding action names:
• Loop Body is used for the body action in While and For loop actions.
• Then Body is used for the thenClause action in If-Else actions.
• Else Body is used for the elseClause action in If-Else actions.
We understand that these names are intended to enhance user-friendliness. However, since body, thenClause, and elseClause actions can also be visible in the feature chain, aligning the compartment names with their exact action names could improve clarity and maintain consistency across the model.
Currently name compartment keywords are pulled via DefinitionPrefix, which does not include 'variant'. Textual syntax introduces variant via a special VariantUsageMember production.
GBNF needs to explicitly add ability to use 'variant' keyword for all usage nodes
There are two productions for calc-name-compartment, not labeled as partial.
Also, there is no specific production for the result of a calculation other than in a compartment. Should the result parameter of a calculation be graphically depicted in the same manner as an out parameter on an action would?
Recommend adding an example to Table 18 to clarify the expected notation for in and result parameters.
The production for usage-node appears to have a typo: "occurrence-refxfx" should probably be "occurrence-ref"
SpatialItem in standard library SpatialItems.sysml is defined by ThreeDCoordinateFrame[1]. However, this is too wide as it may not be any ThreeDCoordinateFrame but should be narrowed to ISQSpaceAndTime::Spatial3dCoordinateFrame[1] since it must be a spatial coordinate frame that is a measurement reference for 3D position or displacement vectors.
Furthermore, in subclause 9.7.2.2.5, SpatialItem::coordinateFrame is defined by the even wider VectorMeasurementReference and misses the default value. This should be corrected in line with the above, i.e., ISQSpaceAndTime::Spatial3dCoordinateFrame[1] , and adding the default value.
Documentation of Clock in standard library Time.sysml and subclause 9.8.8.2.1 has typo "montonically", should be "monotonically".
In the Systems Library model Actions, the action definition AssignmentAction has two parameters, target and replacementValues, in that order. The action usage assignmentActions, which is defined by AssignmentAction, redefines the target parameter, but inherits replacementValues.
The action usage Action::assignments is also defined by AssignmentAction and it subsets assignmentActions. This means that it has two parameters from AssignmentAction and two parameters from assignmentActions as potentially inheritable members. However, assignmentActions::target redefines AssignmentAction::target so the latter is not inherited. And assignmentActions::replacementValues is the same as AssignmentAction::replacementValues, so the former is not inherited again.
The result of this is that the inherited parameters of Action::assignments are AssignmentAction::replacementValues and assignmentActions::target in that order. That is, the parameters of assignments have effectively switched their order relative to how they are defined in AssignmentActions. This is a problem, because an AssignmentActionUsage has an implied specialization of assignments, and it is parsed assuming the parameters inherited from assignments are in the same order as in AssignmentAction.
In the Systems Library model Flows, the flow usage flows explicitly subsets messages. However, messages is also a flow usage, and it has owned end features. So, according to the constraint checkFlowUsageFlowSpecialization, messages is required to subset flows. This means messages and flows subset each other and are, therefore, semantically equivalent. As a result, all message flow usages with implied subsetting of messages end up having the same semantics as non-message flow usages with implied subsetting of flows.
The following library models include the declaration of types that have inherited members with the same name, because of diamond inheritance of redefined features.
Systems Library
Analysis Domain Library
Cause and Effect Domain Library
Geometry Domain Library
Metadata Domain Library
Quantities and Units Domain Library
Requirement Derivation Domain Library
The analysis case definition TradeStudy from the Analysis Domain Library model TradeStudies.sysml is intended to be used by redefining the objective tradeStudyObjective to use a concrete specialization of TradeStudyObjective, e.g., MinimizeObjective or MaximizeObjective. For example:
analysis tradeStudy : TradeStudy {
objective minimize :>> tradeStudyObjective : MinimizeObjective;
...
}
However, MinimizeObjective and MaximizeObjective redefine the parameters from TradeStudyObjective, and TradeStudy::tradeStudyObjective also redefines the first three of these parameters (selectedAlternative, alternatives and eval). But this means that both sets of redefinitions are inherited by the objective minimize in the analysis case usage above, which is semantically inconsistent. Currently, the only way to avoid this is for the modeler to include nested redefinitions of selectedAlternative, alternatives and eval when redefining tradeStudyObjective, which is inconvenient and unintended.
Due to the problem identified in KERML11-72, a state usage that is a substate may end up inheriting two different redefinitions of Occurrence::Occurrence::this, but both with the name this, resulting in a violation of the constraint validateNamespaceDistinguishibility.
The namingFeature of a RenderingUsage that is a viewRendering (i.e., owned via a ViewRenderingMembership) should be the referencedRendering of the owning ViewRenderingMembership.
The constraint checkRequirementUsageSubrequirementSpecialization requires that a composite RequirementUsage whose ownedType is a RequirementDefinition or RequirementUsage specialize RequirementCheck::subrequirements. However, RequirementCheck::subrequirements subsets RequirementCheck::constraints, which is the set of required constraints of the requirement. So it doesn't make sense for a RequirementUsage to specialize subrequirements if it is owned as an assumed constraint.
The constraints validateAttributeDefinitionFeatures and validateAttributeUsageFeatures require that all the features of an attribute definition or usage be referential (non-composite). However, there are a number of models in Domain Libraries that declare attribute definitions or usages with composite features.
The resolution of SYSML2_-159, approved in SysML v2 FTF2 Ballot #5, included the following abstract syntax changes that were not actually made in the specification:
An AcceptUsageAction must have at least one input parameter, corresponding to its payload (even if it has no FeatureValue). (Note that the payloadParameter is an input as well as an output.)
inputParameters()->notEmpty()
validateSendActionUsagePayloadArgument
If a SendActionUsage is owned via a StateSubactionMembership or a TransitionFeatureMembership, then it must have a payloadArgument.
owningFeatureMembership <> null and (owningFeatureMembership.oclIsKindOf(StateSubactionMembership) or owningFeatureMembership.oclIsKindOf(TransitionFeatureMembership)) implies payloadArgument <> null
There is no textual syntax to use fork, join, merge, and decision in statemachines textual syntax.
It is supported by the graphical notation which is also a misalignment issue
In KerML clause 8.2.5.8.2 Primary Expressions, operator '[' is declared as an abstract function in BaseFunctions.kerml, as an Undefined placeholder. As such the operator does not have a precedence position in Table 6 Operator Precedence (in 8.2.5.8.1 Operator Expressions).
In SysML the operator '[' is redefined as a concrete calc def to construct quantity and measurement reference value tuples (defined by ScalarQuantityValue, VectorQuantityValue or TensorQuantityValue).
When used in quantity expressions that contain also other (arithmetic) operators it is currently undefined what the evaluation order is.
Examples:
The precedence of the '[' operator should be defined relative to the other binary operators.
In 8.2.2.21.1 Requirement Definitions, the production FramedConcernUsage references CalculationUsageDefinition. However, there is no CalculationUsageDefinition defined in the grammar.
In commercial practice, many variation points are optional meaning that its variants are present or not. A SysML v2 variation currently only allows its members to be its variants which are always identified with multiplicity 0 or 1 for an optional variation. It is desired that a variation that is optional receive special treatment to facilitate its use by PLE methods and tools. In particular, it is desired to provide a unique way to identify an optional variation and to enable it to include its features instead of its variant members.
The MWIG test case #8 fails because it contains a property that is typed by an Actor while the transformations currently defined do not support it
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.
There is no rule that maps a property typed by a Signal. It should be mapped to an item usage.
All feature redefinitions specified in the transformation model, whether they affect properties or operations, should appear in the specification document
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.
ConnectorProperty is deprecated but still part of SysML v1.7. So, the transformation should provide a mapping for it.
The mapping of a ProfileApplication is not covered by the transformation.
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.
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.
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;
}
}
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.
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.
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.
Both Enumeration and ValueType have main mappings and their specified filters do prevent a double match
The current specification is not computable in some cases (where the "any" OCL iterator find no value). E.g. : MIWG Test Case#27
As a consequence SysMLv literals generated by the transformation have no value defined
Duplicated operations can be removed by adding a common abstract root class. This will simplify the model and ease the maintenance
A Namespace shall own the relationships that defined its members (either owned or not) and its import relationships.
Instead the ownedImport() operation is useless since Namespace::ownedImport is a derived property
The body condition specified for this operation is wrong. It should be an empty set.
Comment_Mapping is missing a default rule locale
GenericToElement_Mapping is missing default rules for:
GenericToStateUsage_Mapping is missing a default rule for isParallel
GenericToRequirementUsage_Mapping is missing a default rule for reqId
GenericToRelationship_Mapping should provide default rules for
The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect
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
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.
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.
Since Relationship is now an abstract class, ElementOwnership_Mapping has been made abstract as well. A consequence of this, because it is not a "MainMapping", is that it is not possible to invoke the getMapped operation directly on this mapping class.
However there are many body conditions that still that. They have to be fixed.
The transformation does not specify mapping rules for UML4SysML::FunctionBehavior.
The transformation does not specify mapping rules for SysMLv1::ParticipantProperty.
The transformation does not specify mapping rules for UML4SysML::ConditionalNode.
The transformation does not specify mapping rules for UML4SysML::Clause.
The transformation does not specify mapping rules for UML4SysML::GeneralOrdering.
checkRenderingUsageSpecialization requires that a RenderingUsage specialize the base
RenderingUsage Views::rendering (see 9.2.19.2.7 ).
need Views::renderings (with an "s")
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.
The constraint checkIncludeUseCaseSpecialization should be named checkIncludeUseCaseUsageSpecialization.
In current implementation each FlowUsage 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, flows
and define something like CheckFlowConnectionSubFlowSpecialization constraint?
The following calc defs are missing nonunique in the declaration of the num input parameter:
Both the specification and the standard libraries must be updated.
The following calc defs should include redefinitions of their parameters wrt the x and y parameters in general function BaseFunctions::'[' :
The Vector and Tensor calc defs also must include nonunique in the redefined declarations of the input parameters.
Within this definition:
FilterPackage : Package =
ownedRelationship += FilterPackageImport
FilterPackageImport is not defined within the metamodel. According to Ed Seidewitz, this is a mistake in the specification and FilterPackageImport should have been ImportDeclaration.
A binary ConnectionDefinition must directly or indirectly specialize the ConnectionDefinition
Connections::BinaryConnection from the Systems Model Library.
ownedEndFeature->size() = 2 implies
specializesFromLibrary('Connections::BinaryConnections')
should be
specializesFromLibrary('Connections::BinaryConnection')
In 8.3.20.2 AssertConstraintUsage, in the OCL for the constraint validateAssertConstraintUsageReference, the invocation referencedFeaure() should be referencedFeature().
In 8.4.1 Semantics Overview, the tables contain the following errors.
In 8.3.17.15 SendActionUsage, in the OCL for the constraint checkSendActionUsageSubactionSpecialization, the reference to Actions::Action::acceptSubactions should be Actions::Action::sendSubactions.
includes the the keyword
an occurrence isage
should be
usage is
PrefixMetadataMember : OwningMembership =
'#' ownedRelatedEleemnt = PrefixMetadataUsage
Element is not spelled correctly
PackageMember : OwningMembership
MemberPrefix
( ownedRelatedElement += DefinitionElement
| ownedRelatedElement = UsageElement )
there is no equal sign here
In the section for /stakeholderParameter within 8.3.21.8 RequirementsDefinition:
"The parameters of this RequirementDefinition that represent stakeholders for th requirement"
"the" missing the "e" at the end of the sentence.
On page 630 and 634 in the table under the section for ScalarQuantityValue Operations on the 3rd row, 1st column, the text is:
fs1+fs2
for the Description:
Addition of a bound and a free scalar quantity returns a bound scalar quantity.
Text should be:
bs1+fs2
In 8.3.17.5 AssignmentActionUsage, under "Constraints":
The textual notation production AnnotatingMember in 8.2.2.4.1 Annotations is used in the special syntax for EnumerationBody to allow the bodies of EnumerationDefinitions included AnnotatingElements as members. However, AnnotatingMember does not include the MemberPrefix that allows for visibility to be specified for a normal DefinitionMember. This means that AnnotatingElements in EnumerationBodies cannot currently have any visibility other than public, even though there is no such restriction in the abstract syntax.
When discussing verdicts "The result of the validation case is a verdict..." should this be "The result of the verification case is a verdict..."?
It's likely that OrderedContainer is supposed to specialized Container, such that orderedContent can redefine content.
abstract part def Container {
abstract ref content : Base::Anything;
}
part def OrderedContainer {
// By default, the following is a reference usage.
orderedContent ordered :>> content;
}
In the following sentence, the word "enumerationDefinition" should be "EnumerationDefinition".
"However, other than when nested in an EnumerationDefinition, an EnumerationUsage is semantically just an AttributeUsage that is required to be typed by exactly one EnumerationDefinition (syntactically enforced by the 1..1 multiplicity of EnumerationUsage::enumerationDefinition, see 8.3.8 )."
The semantic constraint checkRequirementUsageObjectiveRedefinition requires that
A RequirementUsage whose owningFeatureMembership is a ObjectiveMembership must redefine the objectiveRequirement of each CaseDefinition or CaseUsage that is specialized by the owningType of the RequirementUsage.
But this doesn't handle the case in which the owningType may be specialized by a feature chain whose featureTarget is a CaseUsage.
The OCL for the constraint checkDecisionNodeOutgoingSuccessionSpecialization references the library element ControlPerformances::MergePerformance::outgoingHBLink, but the correct qualified name is ControlPerformances::DecisionPerformance::outgoingHBLink
The constraint checkActionUsageSubactionSpecialization checks that the operation isSubactionUsage is true before requiring that an ActionUsage specialize Actions::Action::subactions. The operation isSubactionUsage not only checks the ActionUsage is composite and has an owningType that is an ActionDefinition or ActionUsage, but also ensures that the ActionUsage is not an entry or exit action. Various subclasses of ActionUsage have semantic constraints that require more specific specializations of subactions but do not include the condition that the usage is not an entry or exit action:
In SysML section 7.17.9 (BETA 4) - Assignment Action Usages, the code comment in the textual example is inconsistent with the language in the English.
The English says:
"An AssignmentAction sets a referent feature of a target occurrence to a new assigned value."
But the code comment says:
action def UpdateVehiclePosition {
in part sim : Simulation;
in attribute deltaT : TimeDurationValue;
// The target of the assignment below is "sim".
// The referent feature chain is "vehicle.position".
assign sim.vehicle.position :=
sim.vehicle.position + sim.vehicle.velocity * deltaT;
// After the above assignment "sim.vehicle.position" has the
// value of the result of the assigned value expression,
// evaluated at the time of the assignment.
}
The comment should probably identify "position" as the referent (not "vehicle.position" ! ) and "sim.vehicle" as the target, since "vehicle" features "position" ("sim" does NOT feature "position" and therefore "sim" cannot be the target).
Consistent with the 'var' feature being featured by "vehicle" and not "sim", I would expect "sim.vehicle" to declare the occurrence for the purposes of the assignment. Otherwise, using "sim" as the occurrence would require more complex semantics involving the 'var' behavior of an intermediate occurrence as part of the assignment action, which is unnecessary.
In the description and OCL for the constraint checkViewpointDefinitionSpecialization, Views::Viewpoint should be replaced with Views::ViewpointCheck. In the description and OCL for the constraint checkViewpointUsageSpecialization, Views::viewpoints should be replaced with Views::viewpointChecks.
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.
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)?
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".
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 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
}
on a EnumerationDefinition we want isVariation=true and readonly (should not be allowed to be changed
Change ItemUsage is a ItemUsage to ItemUsage is an OccurenceUsage
checkItemUsageSubitemSpecialization should have description
An ItemUsage that is composite and has an owningType that is an ItemDefinition or ItemUsage must specialize the System model Library ItemUsage Items::Item::subitems
checkPartUsageStakeholderSpecialization wording should be
If a PartUsage is owned via a StakeholderMembership, then it must directly or indirectly specialize Requirements::RequirementCheck::stakeholders.
i.e. remove the word "either"
checkPartUsageStakeholderSpecialization wording should be
If a PartUsage is owned via a StakeholderMembership, then it must directly or indirectly specialize Requirements::RequirementCheck::stakeholders.
i.e. remove the word "either"
/conjugatedPortDefinition : ConjugatedPortDefinition [0..1]
{subsets ownedMember}The that is conjugate to this PortDefinition.
should be
The ConjugatedPortDefinition that is conjugate to this PortDefinition.
the standard alludes to validatePortDefinitionNestedUsagesNotComposite requires that all nestedUsages of the PortDefinition that are not PortUsages are referential (non-composite).
but no OCL definition of validatePortDefinitionNestedUsagesNotComposite is in the standard
the standard alludes to
validatePortDefinitionNestedUsagesNotComposite requires that all nestedUsages of the PortDefinition that are not PortUsages are referential (non-composite).
but no OCL definition of validatePortDefinitionNestedUsagesNotComposite is in the standard
in interfaces.sysml
end port source: Port :>> BinaryConnection::source;
end port target: Port :>> BinaryConnection::target;
but 9.2.7.2.1 BinaryInterface has
source : Port [0..*]
{redefines source}target : Port
{redefines target}so one of these sources is wrong
Don't think we need
validateObjectiveMembershipIsComposite
it is composite in the metamodel
Actions::SendAction descriptions not the same as in the Library file
Actions::AcceptMessageAction has different descriptions than in the library
Actions::TerminateAction documentation is not coordinated between section 9.2.10.2.24 and the library files
Actions::MergeAction descriptions are different than in the system library file
Actions::DecisionAction descriptions are different are different than in their library files
Actions::DecisionTransitionAction has different descriptions
"has a single guard" in standard vs "has a guard" in standard file
Actions::AcceptAction descriptions differ between Standard and Standard Library
Actions::acceptActions descriptions are different between Standard and Standard Library File
acceptActions is the base feature for all SendActionUsages.
vs
acceptActions is the base feature for standalone AcceptActionUsages
The OCL for thee validateAssignmentActionUsage constraint is
referent <> null implies referent.featureTarget.mayTimeVary
However, referent.featureTarget has the type Feature, not Usage, so mayTimeVary is not defined for it. Instead, isVariable should be used.
The constraint validateAssignmentActionUsageReferent is described as
An AssignmentActionUsage must have an ownedMembership that is not an OwningMembership and whose memberElement is a Feature.
This is intended to support the derivation of AssignmentActionUsage::referent, however, the constraint deriveAssignmentActionUsageReferent is
The referent of an AssignmentActionUsage is the first Feature that is the memberElement of a ownedMembership that is not a FeatureMembership.
Note that the derivation only excludes FeatureMembershps, not all OwningMemberships. Indead, a referent that is a feature chain will be owned by the AssignmentActionUsage using an OwningMembership.
The resolution to SYSML2_-417 was supposed to change all uses of "FlowConnection" in names to "Flow". However some changes were missed.
In the constraint deriveSatisfyRequirementUsageSatisfyingFeature, in the if condition, the subexpression
bindings->first().relatedElement->exits(r | r <> subjectParameter)
should be
not bindings->first().relatedElement->exists(r | r <> subjectParameter)
The constraint checkSatisfyRequirementUsageBindingConnector requires that "A SatisfyRequirementUsage must have exactly one ownedMember that is a BindingConnector between its subjectParameter and some Feature other than the subjectParameter." However, in the textual notation for a SatisfyRequirementUsage, a *by* is parsed as a FeatureValue binding from the owned subject of the SatisfyRequirementUsage to the *by* clause Expression (see 8.2.2.21.2 Requirement Usages). But the implied BindingConnector for a FeatureValue will then be owned by the subject parameter, not by the SatisfyRequirementUsage, so the checkSatisfyRequirementUsageBindingConnector constraint will be violated.
1. The reserved keywords of SysML are the following.
The following keywords (in the Beta 3 document I have downloaded) I believe are missing: constant, effect, feature, locale, meta, and new.
The resolution to SYSML2_-248 changed the name of the fn parameter of TradeStudies::TradeStudyObjective and its specializations to eval. However, invocations of this parameter in the bodies of MaximizeObjective and MinimizeObjective where not correspondingly updated in the full textual notation in file TradeStudies.sysml.
According to 8.4.16.2 Constraint Usages, "checkConstraintUsageCheckedConstraintSpecialization requires that a composite ConstraintUsage whose owningType is an ItemDefinition or an ItemUsage...specialize the ConstraintUsage Items::Item::checkedConstraints...". However, the definition of checkConstraintUsageCheckedConstraintSpecialization in 8.3.20.4 does not actually test if the ConstraintUsage is composite.
This issue is with v2 Beta 4.
In the following textual notation, vehicle does not have a drives occurrence. Later in the notation, the message sequence references a vehicle.drives feature, which is erroneous.
use case def 'Provide Transportation' {
subject vehicle : Vehicle {
event occurrence driverEnters [1];
then event occurrence passengerEnters [0..*];
then event occurrence startsDrive [1];
then event occurrence endsDrive [1];
then event occurrence passengerExits [0..*];
then event occurrence driverExits [1];
}
actor driver : Person {
event occurrence entersVehicle [1];
then event occurrence exitsVehicle [1];
}
actor passengers : Person[0..4] {
event occurrence entersVehicle [1];
then event occurrence exitsVehicle [1];
}
actor environment : Environment {
event occurrence vehicleDrives [1];
}
objective {
doc
/* Transport driver and passengers from starting location
* to ending location.
*/
}
message of Enter from driver.entersVehicle to vehicle.driverEnters;
then message of Enter from passengers.entersVehicle to vehicle.passengerEnters;
then message of Drive from vehicle.drives to environment.vehicleDrives;
then message of Exit from passengers.exitsVehicle to vehicle.passengerExits;
then message of Exit from driver.exitsVehicle to vehicle.driverExits;
}
We need to update the defaults for owned non-abstract Actions to ensure expected interpretations of when and how Actions will start when executing their parent (owning Action, Part, or Occurrence).
Background:
Modelers creating SysML would like good defaults to make modeling Action sequences simple, easy to declare, and easy to interpret. The main discussion stems around potential confusion in the case where some owned Actions have zero incoming successions (but are possibly expected to "start automatically").
In UML, Actions that did not require any incoming control or flow tokens would "start automatically" without requiring a control token. Essentially, they would not be blocked from starting by requiring them to wait for a control token. In SysMLv2, we no longer have control tokens and instead rely on Successions (HappensBefore connectors) to constrain the relative time ordering of behaviors. While it's clear (pending other RTF issues around end multiplicities) that the intent of a succession is to ensure that a target Occurrence occurs for every instance of a source Occurrence, it is less clear what would happen in the absense of any such succession.
Currently, the default multiplicity of Actions in SysML is inherited from KerML as [0..*]. As part of execution, there is some major question around whether there is any indication that such an action would occur at all with a lower bound multiplicity of zero. So, a model where the action does NOT execute is valid!
See attached for reference models. Consider the following textual models:
Explicit (All actions have successions from start)
action a0{
action a1{
out x1;
}
action a2{
in x1;
}
first start then a1;
first start then a2;
flow from a1.x1 to a2.x1;
}
Implicit (No actions have incoming successions)
action a0{
action a1{
out x1;
}
action a2{
in x1;
}
flow from a1.x1 to a2.x1;
}
Mixed (Some actions may have successions from starts but others do not)
action a0{
action a1{
out x1;
}
action a2{
in x1;
}
first start then a1;
flow from a1.x1 to a2.x1;
}
The open question is: when and how do actions 'a1' and 'a2' start in the context of 'a0' for these different models?
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".
PrefixMetadataMember : OwningMembership =
'#' ownedRelatedEleemnt = PrefixMetadataUsage
Element is not spelled correctly
There are errors in the example model that need to be corrected to align with the latest release.
This includes the following errors on pg 662.
From: variation part transmission:TransmissionChoices;
To: part transmission:TransmissionChoices;
From: variation part sunroof:Sunroof;
To: variation part sunroof:Sunroof [0..1];
It is also recommended to add the subset of the part vehicleFamily to model a specific vehicle configuration.
In 8.3.21.7 RequirementConstraintMembership, the constraint validateRequirementConstraintMembershipIsComposite requires that the ownedConstraint of a RequirementConstraintMembership be composite. However, consider the following:
part p {
constraint c;
}
requirement r {
subject :> p;
require p.c;
}
In this case, the constraint c is composite in p, but the required constraint referencing p.c is composite in r. Further, checkConstraintUsageCheckedConstraintSpecialization requires that c subset Part::checkedConstraints, which indirectly specializes Object::ownedPerformances, and, therefore, so does the required constraint referencing p.c. But checkConstraintUsageRequirementConstraintSpecialization requires the required constraint to specialize RequirementCheck::constraints, which (as a composite constraint usage) indirectly specializes Performance::subperformances. Thus, the required constraint inherits from both ownedPerformances and subperformances, which is inconsistent (in particular, this is bound differently in the two features).
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 definition of 'pi' provided in TrigFunctions::pi (KerML) also includes an invariant that specifies PI to 20 significant digits.
However, in SI.sysml where we define 'degree', the conversion factor is listed as:
attribute <'°'> degree : AngularMeasureUnit { :>> unitConversion: ConversionByConvention { :>> referenceUnit = rad; :>> conversionFactor = 1.745329E-02; :>> isExact = false; } } // conversionFactor should become pi/180
It appears that this was intended to be a "TODO" that was never addressed!
Having the conversion factor from degrees to radians only listed to "single precision" will be a severe problem for many engineering applications. We should instead depend on the actual "pi/180" expression as stated in the trailing comment
According to the specification, items can own actions and parts can perform actions.
However, the feature "ownedActions" is owned by the library element Part and not Item. The feature "performedActions" is also owned by Part which is correct.
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.
viewpointConformance is not defined in the standard library
should be stubbed out...
abstract view def View :> Part {
...
viewpoint viewpointSatisfactions : ViewpointCheck[0..*] :> viewpointChecks, checkedConstraints
satisfy requirement viewpointConformance by that
}
An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages
I agree items should be able to have states (e.g. Document has states "underReview", "Reviewed")...
but
exhibitedStates : StateAction [0..*]
ownedStates : StateAction [0..*]
{subsets ownedActions}are in Parts (not in Item) ... is this wrong??
An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages
I agree items should be able to have states (e.g. Document has states "underReview", "Reviewed")...
but
exhibitedStates : StateAction [0..*]
ownedStates : StateAction [0..*]
{subsets ownedActions}are in Parts (not in Item) ... is this wrong??
validateUsageVariationMembership is missing a OCL statement
should sunroof be multiplicity 0..1? for optional?... or is this another way to show optional (but not stated in the standard)..
sunroof does not have any variants... that simply means model is not yet concrete?
In 8.2.2.17.4 Send and Accept Action Usages, the payload parameter of an AcceptActionUsage is parsed as being owned by a ParameterMembership. This requires that the parameter have the direction in (see 8.3.4.6.4). However, the payload parameter of the base library definition Actions::Action has the direction inout. While it is valid to redefine an inout parameter with an in parameter, it is generally the output payload value that is desired from an accept action. Therefore, the payload parameter of an AcceptActionUsage should also have direction inout.
It is possible to define flow 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. PayloadFeature is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case.
It seems that PayloadFeature (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 payloadFeature property in the abstract syntax to be the feature that specializes `Transfer::payload`, whether or not it is owned or inherited, and whether or not it is a PayloadFeature. The derivation would not be as simple as the current one, but it would be a reasonable suggestion.
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).
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.
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.
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.
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.
A ConnectionPointReference is mapped to a StateUsage. In addition, the state usage shoud redefine the corresponding pseudostate.
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.
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.
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
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.
An Operation should not be mapped to perform action, but an owned action.
In some cases (e.g. MIWG test case #11) it is unable to compute the requested type.
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
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 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
A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.
The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.
The mapping of a Unit and a QuantityKind is not covered by the transformation yet.
The transformation does not map the Parameter::isStreaming.
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::CreateLinkAction.
The transformation does not specify mapping rules for UML4SysML::ReadLinkAction.
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.
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".
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::AllocateActivityPartition.
The transformation does not specify mapping rules for SysMLv1::PropertySpecificType.
The transformation does not specify mapping rules for SysMLv1::EndPathMultiplicity.
The transformation does not specify mapping rules for SysMLv1::BoundReference.
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::Conform.
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::AddFlowPropertyValueOnNestedPortAction.
The transformation does not specify mapping rules for SysMLv1::ChangeStructuralFeatureEvent.
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 UML4SysML::LinkEndData.
The transformation does not specify mapping rules for UML4SysML::LinkEndDestructionData.
The transformation does not specify mapping rules for UML4SysML::LinkEndCreationData.
The transformation does not specify mapping rules for UML4SysML::ActivityPartition.
The transformation does not specify mapping rules for UML4SysML::InteractionConstraint.
The transformation does not specify mapping rules for UML4SysML::OccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::Gate.
The transformation does not specify mapping rules for UML4SysML::ExecutionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::ConsiderIgnoreFragment.
The transformation does not specify mapping rules for UML4SysML::PartDecomposition.
The transformation does not specify mapping rules for UML4SysML::Continuation.
The transformation does not specify mapping rules for UML4SysML::DestructionOccurrenceSpecification.
The transformation does not specify mapping rules for UML4SysML::Image.
The transformation does not specify mapping rules for UML4SysML::Interval.
The transformation does not specify mapping rules for UML4SysML::TimeConstraint.
The transformation does not specify mapping rules for UML4SysML::DurationInterval.
The transformation does not specify mapping rules for UML4SysML::StringExpression.
The transformation does not specify mapping rules for UML4SysML::DurationObservation.
The transformation does not specify mapping rules for UML4SysML::IntervalConstraint.
The transformation does not specify mapping rules for UML4SysML::TimeObservation.
The transformation does not specify mapping rules for UML4SysML::Duration.
The transformation does not specify mapping rules for UML4SysML::DurationConstraint.
The transformation does not specify mapping rules for UML4SysML::TimeInterval.
The extend relationship between use cases is not covered by the transformation.
The details of the mapping of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode are not specified.
The transformation does not include a mapping for UML4SysML::GeneralizationSet.
The transformation does not consider the property UML4SysML::RemoveVariableValueAction::isRemoveDuplicates.
In section 7.3.2.3 of the KerML specification, the statement is made that, "Specializations are relationships between types, identified as specific and general, indicating that all instances of the specific type are instances of the general one...." This statement, or a similar one conveying the same idea, is absent from the SysML v2 specification. Instead, the treatment of specialization in section 7.6.1 of the SysML v2 specification focuses entirely on inheritance of features. The SysML v2 specification should clarify that specialization also conveys the semantics of subtyping, as is described in the KerML specification. This concept is really foundational to object oriented modeling (and ontology), even more essential in modeling than it is in object oriented programming.
The specification also would be strengthened by including explicit examples of the implications of subtyping within a model, e.g.,
1. In 7.12.1, the statement is made that "Two features match if they have conforming definitions and either both have no direction or they have conjugate directions," but there is no explanation in the SysML v2 specification as to what it means to conform. If A specializes B, then would an in port defined by B match with an out port defined by A? It should, since an in port defined by B, which therefore expects to receive payloads having a specification compatible with the specification of B, should be able to accept a payload defined by A.
2. In 7.21.1, the statement is made that, "A requirement usage can only be satisfied by an entity that conforms to the definition of its subject," but there is no explanation in the SysML v2 specification as to what it means to conform. If the requirement usage specifies a subject defined by B, and A specializes B, then would a subject defined by A be sufficient to satisfy that requirement for satisfaction? It should, since any A is also a B.
These are two examples, among many, where such clarifications of the semantics of subtyping and their implications on SysML v2 models should be addressed in Clause 7 of the SysML v2 specification to ensure model users and modeling tool developers have consistent expectations of the semantics of specialization.
In the Systems Library model States, in the body of StateAction, the usages entryAction, doAction and exitAction are respectively declared as entry, do and exit action usages. However, according to constraint validateActionUsageStateActionRedefinition, this means that these usages a required to directly redefine themselves, which doesn't make sense.
The textual notation of single-line (//) and multiline (/** */) notes does not appear to be documented in either the SysML v2 or KerML specifications. These are described in the Intro to the SysML v2 Language - Textual Notation slide deck, are used extensively in example models throughout both specs, and appear in the BNF in 8.2.2.2 of the KerML Spec Beta 2.4. However, their intended use and semantics are not described anywhere in either spec. It should be important to state in the spec(s) that these notes are intended to not be part of the model, if this is still true.
The Quantities and Units Domain Library model Time.sysml contains attribute definitions for ISO 8601 date/time string encodings and structures. However, the model could be improved by adding additional constraints to ensure these definitions are used properly:
[From Dr. Charles Manion] Item::iSSolid cannot be specified by redefinition because it is given a bound value. It's common in my applications to specify that an item is solid or not (in that typical terminology) without specifying how many voids are present or not.
scalarQuantities is defined as nonunique. However some of its subsets are not. They probably should be nonunique.
Examples:
width, height or gaugePressure
Also many don't have multiplicity [*]. As far as I know, this would not be necessary, because it is the default for attributes defined at package level anyway. However, length and scalarQuantities itself do have an explicit multiplicity. I guess it should be consistent.
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).
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;
}
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.
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.
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.
This seems an odd choice and at least needs more explanation of how the various features of part definitions, like ports, are used
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.
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.
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 SysML v1 a RedefinableElement can have a isLeaf:Boolean... this concept seems to be missing in SysMLv2
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).
a classifier in SysML v1 can have isFinalSpecialization:Boolean ... that concept is missing in SysML v2
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
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.
The reuse of KerML BNF productions in the SysML textual notation grammar is not described sufficiently. It is not clear which productions are reused and which not. Reused productions are simply missing from the SysML definitions.
(This issue was originally reported as part of SYSML2-635.)
The general 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.)
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.
[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;
}
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.
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
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.
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 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.
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.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 US Customary Units as specified in NIST SP811 Annex B include a number of units for which the corresponding quantity is not defined in ISO/IEC 80000, the International System of Quantities (ISQ). These units are currently commented out in Quantities and Units Domain Library USCustomaryUnits. Examples are:
//attribute <'Btu_IT/ft³'> 'British thermal unit (IT) per cubic foot' : EnergyDensityUnit = Btu_IT/ft^3; //attribute <'gal/(hp⋅h)'> 'gallon (US) per horsepower hour' : EnergySpecificVolumeUnit = gal/(hp*h); //attribute <'mi/gal'> 'mile per gallon (US)' : FuelEconomyUnit = mi/gal; //attribute <'lb/(hp⋅h)'> 'pound per horsepower hour' : FuelConsumptionUnit = lb/(hp*h);
An additional extension package for ISQ is needed that declares the attribute definitions for the missing quantity and measurement unit types, e.g.:
It should be considered whether or not to include the new library package inside ISQ, as formally these quantity and unit types are not part of ISO/IEC 800000.
The 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.
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).
SysML v2 includes syntax for enumeration definitions and usages. The semantics for enumerations are based on the general variation/variant semantics in SysML v2, which is itself based on KerML semantics. However, there currently is no syntax for enumerations in KerML. In particular, this leads to an awkward mapping in 9.2.17 KerML of MOF enumerations to KerML data types without specific syntax for enumeration.
Enumerations are the only modeling element in the CMOF subset of UML that does not have a clear mapping to a KerML element. Especially as KerML is considered further for use as the basis of other languages, including their reflective abstract syntaxes, it would be better if enumeration syntax was codified in KerML. This would also make it easier to incorporate enumerations consistently into SysML v2 and future KerML-based languages themselves.
In the Systems Library model Interfaces, the Interface::participant feature is declared as a port usage. However, the semantic constraint checkPortUsageOwnedPortSpecialization then requires that the feature subset ownedPorts. But ownedPorts is unique, will participant has to be non-unique, which violates the constraint validateSubsettingUniquenessConformance.
The feature Interface::participant should thus not subset ownedPorts. Indeed, an Interface is supposed to be a Connection between the ownedPorts of other parts, so its participants shouldn't be considered ownedPorts of the Interface itself, anyway.