OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML2_-259 Operation should not be mapped to perform action SysML 2.0b2 open
SYSML2_-326 Use Cases should have stakeholderParameters SysML 2.0b2 open
SYSML2_-327 Transformation does not cover the deprecated elements FlowSpecification SysML 2.0b2 open
SYSML2_-325 Transformation does not cover the deprecated elements FlowPort SysML 2.0b2 open
SYSML2_-324 Representative notation example for allocation confusing/wrong? SysML 2.0b2 open
SYSML2_-197 Inconsistent use of guillemets in graphical notation for metamodel aspects SysML 2.0b2 open
SYSML2_-323 There is no production for general-view SysML 2.0b2 open
SYSML2_-321 state-flow GBNF issues SysML 2.0b2 open
SYSML2_-227 Name expressions in GBNF are too constraining SysML 2.0b2 open
SYSML2_-200 Structured actions not properly covered by GBNF and notation tables SysML 2.0b2 open
SYSML2_-320 Specification lacks precision in multiple sentences that begin with the word 'however' SysML 2.0b2 open
SYSML2_-274 Map UML4SysML::Constraint to ConstraintUsage only SysML 2.0b2 open
SYSML2_-220 Replace Generic mapping classes by Initializers SysML 2.0b2 open
SYSML2_-318 Transformation does not cover UML4SysML::ProfileApplication SysML 2.0b2 open
SYSML2_-317 Transformation does not cover SysMLv1::ConnectorProperty SysML 2.0b2 open
SYSML2_-294 Send action examples in representative notation tables wrong SysML 2.0b2 open
SYSML2_-314 Actor should be mapped to a PartDefinition SysML 2.0b2 open
SYSML2_-310 ObjectFlow with guards outgoing from DecisionNodes are not mapped correctly SysML 2.0b2 open
SYSML2_-311 Fix errors in resolution of issue SYSML2_-203 (InitialState mapping) SysML 2.0b2 open
SYSML2_-309 CallBehaviorAction mapping does not consider the pins SysML 2.0b2 open
SYSML2_-308 Mapping of ObjectFlow should not consider the type of the objects that flow SysML 2.0b2 open
SYSML2_-307 ActivityParameterNodes should be mapped SysML 2.0b2 open
SYSML2_-304 Diagram frame production not properly integrated into graphical BNF SysML 2.0b2 open
SYSML2_-297 proxy connection points should be applicable more broadly then currently supported by the GBNF SysML 2.0b2 open
SYSML2_-305 SysMLv1Tov2.xmi contains temporary mapping classes SysML 2.0b2 open
SYSML2_-303 ConnectionPointReference_Mapping should create a Redefinition SysML 2.0b2 open
SYSML2_-272 Typos in graphical metadata representative notation SysML 2.0b2 open
SYSML2_-249 RICOAOutputPin_Mapping should specialized Pin_Mapping SysML 2.0b2 open
SYSML2_-230 Inconsistent graphical notation for view frame SysML 2.0b2 open
SYSML2_-214 Mapping of State does not consider orthogonal states SysML 2.0b2 open
SYSML2_-203 InitialState is mapped to StateUsage, but should be an empty ActionUsage SysML 2.0b2 open
SYSML2_-199 InterfaceBlock mapped to PortDefinition, but ConjugatedPortDefinition is not generated SysML 2.0b2 open
SYSML2_-224 State machine graphical notation for entry/exit/do actions inconsistent SysML 2.0b2 open
SYSML2_-302 Chapter Trigger_Mapping is empty SysML 2.0b2 open
SYSML2_-301 Mapping for UML4SysML::CallEvent and UML4SysML::AcceptCallAction are missing SysML 2.0b2 open
SYSML2_-300 Weak check of input parameter in Helper::getScalarValueType SysML 2.0b2 open
SYSML2_-296 Need to add terminate action node to action flow and state flow views SysML 2.0b2 open
SYSML2_-295 send and accept actions name compartment productions inconsistent SysML 2.0b2 open
SYSML2_-293 Definition of view artifact SysML 2.0b2 open
SYSML2_-292 Examples of Nested View Usages SysML 2.0b2 open
SYSML2_-291 Typo in definition of RenderingDefinition SysML 2.0b2 open
SYSML2_-290 is view the same as view usage? SysML 2.0b2 open
SYSML2_-289 filter condition or view condition SysML 2.0b2 open
SYSML2_-288 Missing word in description of view usage SysML 2.0b2 open
SYSML2_-287 Why does View Definition specialise Part Definition? SysML 2.0b2 open
SYSML2_-286 Misspelling in Table 16 / graphical and textual notation do not match SysML 2.0b2 open
SYSML2_-285 Multiple textual notation issues SysML 2.0b2 open
SYSML2_-284 Differentiate Row Headers that say "Interface" SysML 2.0b2 open
SYSML2_-283 Table 5 Attributes Compartment Graphical Notation and Textual Notation does not match SysML 2.0b2 open
SYSML2_-282 P8 import textual notation may have errors SysML 2.0b2 open
SYSML2_-281 Error in textual notation on this page ("comment Comment 2") SysML 2.0b2 open
SYSML2_-280 Header description of unowned elements does not align with textual notation SysML 2.0b2 open
SYSML2_-279 Presuming missing word in sentence describing implicit annotation. SysML 2.0b2 open
SYSML2_-278 Row headers not descriptive enough SysML 2.0b2 open
SYSML2_-277 Mapping of UseCase does not consider more than one subject SysML 2.0b2 open
SYSML2_-276 Property typed by an Actor should be mapped to a PartUsage SysML 2.0b2 open
SYSML2_-275 Mapping of UML4SysML::Constraint: Bind the result parameter SysML 2.0b2 open
SYSML2_-262 Flows cannot connect ControlNodes SysML 2.0b2 open
SYSML2_-260 Accept action in representative notation tables is confusing and needs cleanup SysML 2.0b2 open
SYSML2_-261 Graphical notation action names need to be aligned SysML 2.0b2 open
SYSML2_-207 Update language description and concrete syntax related to imports SysML 2.0b2 open
SYSML2_-187 There is no need for AnalysisAction SysML 2.0b2 open
SYSML2_-271 Mappings from the "Common" package SysML 2.0b2 open
SYSML2_-270 Type of the ReferenceUsage created for the client of a Satisfy relationship SysML 2.0b2 open
SYSML2_-269 ReferenceUsage creation in case of a Satisfy relationship transformation SysML 2.0b2 open
SYSML2_-267 Invalid use of "loop" as merge action name SysML 2.0b2 open
SYSML2_-268 Incorrect declaration of parameters on actions SysML 2.0b2 open
SYSML2_-266 ObjectFlow mappings limited to non-streaming parameters SysML 2.0b2 open
SYSML2_-263 There is no checkSatisfyRequirementUsageSpecialization constraint SysML 2.0b2 open
SYSML2_-265 Missing semantic constraints related to features of Part SysML 2.0b2 open
SYSML2_-264 Interface usage cannot redefine inherited attributes in textual syntax SysML 2.0b2 open
SYSML2_-254 No way to expose non-membership and non-namespace elements SysML 2.0b2 open
SYSML2_-256 Inconsistent compartment labels SysML 2.0b2 open
SYSML2_-255 Name misplaced on action symbol parameter SysML 2.0b2 open
SYSML2_-221 Default multiplicities are not formally specified SysML 2.0b2 open
SYSML2_-253 Mapping of ClearStructuralFeatureAction is not defined yet SysML 2.0b2 open
SYSML2_-252 Mapping of RemoveStructuralFeatureValueAction is not defined yet SysML 2.0b2 open
SYSML2_-251 AddStructuralFeatureValueAction Mapping does not consider the names of the input and output pins SysML 2.0b2 open
SYSML2_-245 Multiple vs Single Trigger/Guard/Effect for State Transitions Contradiction SysML 2.0b2 open
SYSML2_-246 Ordering of guards and accepts in transitions is inconsistent SysML 2.0b2 open
SYSML2_-248 Evaluation problem with TradeStudyObjectives SysML 2.0b2 open
SYSML2_-247 Graphical BNF for n-ary ConnectionDefinition is missing SysML 2.0b2 open
SYSML2_-184 StateAction::substates has an implied subsetting of exclusiveStates SysML 2.0b2 open
SYSML2_-236 Missing Complete concept SysML 2.0b2 open
SYSML2_-237 Missing Final concept SysML 2.0b2 open
SYSML2_-238 Missing isLeaf concept SysML 2.0b2 open
SYSML2_-239 Missing Element Import Alias SysML 2.0b2 open
SYSML2_-240 ShapeItems have radius feature bound SysML 2.0b2 open
SYSML2_-229 Invalid values can be assigned to an enum SysML 2.0b2 open
SYSML2_-226 Description and examples for message notation are wrong SysML 2.0b2 open
SYSML2_-212 Inconsistencies in the graphical notation for "expose" SysML 2.0b2 open
SYSML2_-209 isOrdered and isUnique are missing from the reflective abstract mapping SysML 2.0b2 open
SYSML2_-202 Missing guidance on highlighting keywords SysML 2.0b2 open
SYSML2_-191 Error in the specification of "connections" SysML 2.0b2 open
SYSML2_-189 Incorrect enumeration example SysML 2.0b2 open
SYSML2_-183 checkStateUsageExclusiveStateSpecialization and checkStateUsageSubstateSpecialization have problems SysML 2.0b2 open
SYSML2_-222 TransitionUsage source and target properties do not support feature chains SysML 2.0b2 open
SYSML2_-206 Editorial errors in constraints SysML 2.0b2 open
SYSML2_-201 Confusing send/accept examples in notation tables SysML 2.0b2 open

Issues Descriptions

Operation should not be mapped to perform action

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

    An Operation should not be mapped to perform action, but an owned action.

  • Reported: SysML 2.0b2 — Fri, 26 Jul 2024 18:02 GMT
  • Updated: Fri, 4 Oct 2024 16:36 GMT
  • Attachments:

Use Cases should have stakeholderParameters

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    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.

  • Reported: SysML 2.0b2 — Tue, 17 Sep 2024 16:47 GMT
  • Updated: Mon, 30 Sep 2024 15:47 GMT

Transformation does not cover the deprecated elements FlowSpecification

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

    Although deprecated, FlowSpecifications are still part of SysML v1 and there should be a defined mapping for the element.

  • Reported: SysML 2.0b2 — Sat, 28 Sep 2024 06:42 GMT
  • Updated: Sat, 28 Sep 2024 06:42 GMT

Transformation does not cover the deprecated elements FlowPort

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

    Although deprecated, FlowPorts are still part of SysML v1 and there should be a defined mapping for the element.

  • Reported: SysML 2.0b2 — Thu, 26 Sep 2024 10:48 GMT
  • Updated: Thu, 26 Sep 2024 10:48 GMT

Representative notation example for allocation confusing/wrong?

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    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.

  • Reported: SysML 2.0b2 — Mon, 23 Sep 2024 08:54 GMT
  • Updated: Mon, 23 Sep 2024 09:36 GMT

Inconsistent use of guillemets in graphical notation for metamodel aspects


There is no production for general-view

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    general-view is used but not specified. The definition should probably be

    general-view = 
        definition-node*  definition-edge * usage-node* usage-edge*
    

    Also, need to add a production for definition-edge and account for namespace symbols (e.g., packages)

  • Reported: SysML 2.0b2 — Wed, 18 Sep 2024 13:49 GMT
  • Updated: Wed, 18 Sep 2024 15:24 GMT

state-flow GBNF issues

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    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".

  • Reported: SysML 2.0b2 — Tue, 17 Sep 2024 09:57 GMT
  • Updated: Tue, 17 Sep 2024 09:57 GMT

Name expressions in GBNF are too constraining

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Name textual expressions in GBNF for definition and usage names,exclude various characteristics such as specializations, redefinitions multiplicity etc. Name expressions denoted definition-name-with-alias and usage-name-with-alias in the graphical BNF should reuse the textual syntax productions DefinitionDeclaration and UsageDeclaration.

  • Reported: SysML 2.0b2 — Mon, 24 Jun 2024 13:59 GMT
  • Updated: Sun, 15 Sep 2024 10:08 GMT

Structured actions not properly covered by GBNF and notation tables


Specification lacks precision in multiple sentences that begin with the word 'however'

  • Status: open  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    There are 94 uses of the word 'however' in the specification, usually starting a sentence. In many cases, the word injects unnecessary text that further confuses and obfuscates the intent. In most cases, what follows is not an exception, rather just another option of the language. In many cases the word can be replaced with ‘if’ or ‘when’ but I also found many cases where a rewrite is necessary.

    Here are the first 45ish specific examples and rewrites. I stopped at page 119 as there is enough evidence to show simple rewriting of the offending test can greatly improved the text. I have also added comments to point to the issue and any further wordsmithing that seems to be required.
    This seems like a minor or even a style issue, ‘however’ the point of this issue is that the use of the word muddles the descriptive intent of the text when it should be precise as possible.

    2. conformance:
    Original:
    However, a tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.
    Replacement:
    A tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.

    6.2 Document Organization
    Original:
    However, this clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
    Replacement:
    This clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
    Comment:
    Optionally delete the sentence as it is already assumed that KerML is where the reader finds the details of the details.

    6.3 Acknowlegements
    Original:
    However, work on the specification was also supported by over 200 people in over 80 organizations that participated in the SysML v2 Submission Team (SST), by contributing use cases, providing critical review and comment, and validating the language design.
    Replacement:
    Over 200 people from over 80 organizations participated in the SysML v2 Submission Team (SST), contributing to the specifics and providing reviews and comments.

    7.2.1 Elements and Relationships Overview
    Original:
    However, in some cases, additional shapes may be attached to relationship lines in order to present additional information.
    Replacement:
    Additional shapes may be attached to relationship lines in order to present additional information.

    7.2.2 Elements
    Original:
    Various specific kinds of model elements in SysML are described in subsequent subclauses. However, there are certain concepts that apply to all model elements.
    eplacement:
    Key model elements in SysML are described in subsequent subclauses. Some of the concepts apply to all model elements.
    comments: The opening statement like this are without value to the spec.

    Original:
    The SysML notation does not have any provision for specifying element or alias IDs, since these are expected to be managed by the underlying modeling tooling. Instead, an element can be given a name and/or a short name, and it can also have any number of alias names relative to one or more namespaces (see 7.5).
    Replacement:
    The SysML notation does not have any provision for specifying element or alias IDs because these are expected to be managed by the underlying modeling tooling. Instead of using an ID, an element has a given name and/or a short name that can also have any number of alias names relative to one or more namespaces (see 7.5).

    Original:
    However, unless at least one of these is given, it is not possible to reference the element using the textual notation (though it is still possible to show it in relationships on graphical diagrams).
    Replacement:
    It is not possible to reference the element using the textual notation unless a name or short name is given, though it is still possible to show it in relationships on graphical diagrams.

    Original:
    However, a reserved word may not be used as a name, even though it has the form of a basic name (see 8.2.2.1.2 for the list of the reserved words in SysML).
    Replacement:
    A reserved word may not be used as a name (see 8.2.2.1.2 for the list of the reserved words in SysML).

    Original:
    However, these characters may be included as part of the name itself through use of an escape sequence.
    Replacement:
    Non-printable characters may be included as part of the name itself through use of an escape sequence.

    7.4.2 Comments and Documentation
    Original:
    However, marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
    Replacement:
    Marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
    Original:
    However, for any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented
    Replacement:
    For any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented

    7.5.4 Import Filtering
    Original:
    comments. Namespaces other than packages cannot have filter conditions (except for their special use in view definitions and usages – see 7.25). However, any kind of namespaces may have filtered imports.
    Replacement:
    Namespaces other than packages cannot have filter conditions, except for their special use in view definitions and usages – see 7.25. All kinds of namespaces may have filtered imports.
    comments: It is strange that this is a note as these are very specific semantics rather than an aside as would be described in a note.

    7.6.1 Definition and Usage Overview
    Original:
    However, truck can instead redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
    Replacement:
    Alternatively the Truck could redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
    comments: The paragraphs are rather confusing without a textual language or graphical examples. At least you could refer to an example in the annex. It is also odd to get into alternatives without an example of the alternative.
    Original:
    However, it is expected that if Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.
    Replacement:
    If Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.

    7.6.3 Usages
    Original:
    However, a tighter default of [1..1] is implicitly declared for the usage if all of the following conditions hold
    Replacement:
    A tighter default of [1..1] is implicitly declared for the usage if all of the following conditions are true:
    Comment: Is there a reference to where this is described in the standard?

    7.6.4 Reference Usages
    Original:
    However, a reference usage is always, by definition, referential. A reference usage is otherwise declared like any other usage, as given above.
    Replacement:
    Reference usages are always referential. A reference usage is declared like any other usage, as given above.
    Comment:
    Once the ‘however’ was removed, the changes to the following sentence is also required to improve the explanation of the concept.

    7.6.5 Effective Names
    Original:
    However, if neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
    Replacement:
    When neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
    Comment:
    The use of ‘however’ muddled the original explanation. Imagine Java or some other computer language with ‘however’ as a key word.

    7.6.6 Feature Chains
    Original:
    However, their use is particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)
    Replacement:
    Feature chains are particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)

    7.6.8 Implicit Specialization
    Comment:
    This may be a good use of however, but look at it anyway and see if it can be avoided,

    7.7.1 Attributes Overview
    Original:
    However, the owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). In this case, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
    Replacement:
    The owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). When the attribute owner is a usage is an occurrence definition or usage, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
    Comment:
    This is still confusing. It again screams out for a textual/graphical language example.

    7.8.1 Enumerations Overview
    Original:
    However, if the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
    Replacement:
    If the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
    Original:
    The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.
    Replacement:
    The reason for this constraint is that enumerated values defined in an enumeration definition would add to the set of enumerated values, which is inconsistent with the semantics of specialization.
    Comment:
    This is a definite improvement over the original text, which is very confusing. It is very strange that given you are creating a new language to get around issues with UML you have not fixed this glaring issue of the inability to specialize enumerations.

    7.8.2 Enumeration Definitions and Usages
    Original:
    However, an enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
    Replacement:
    An enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
    Comment:
    This paragraph seems like a repeat of the previous change request. Suggest choosing one and deleting the other to reduce confusion and need to maintain both statements.

    7.9.1 Occurrences Overview
    Original:
    However, if a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
    Replacement:
    If a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
    Original:
    However, if the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)
    Replacement:
    If the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)

    Original:
    However, it could also be realized as the start and end of an explicitly modeled flow connection (see 7.13 on flow connections and messages).
    Replacement:
    These events can also be realized as a modeled flow connection (see 7.13 on flow connections and messages).
    Comment:
    This is another statement that becomes more muddled when treating it as an exception when in fact this is not an exeption, but just realkized by another possible construct.

    7.9.3 Time Slices and Snapshots
    Original:
    However, if such an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.
    Replacement:
    If an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.

    7.10.1 Items Overview
    Original:
    However, once the engine assembly is completed, the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. But later it may be removed from the car and again be considered only an inactive item in a junkyard.
    Replacement:
    Once the engine assembly is completed (e.g. the engine has completed manufacturing and exists as a whole), the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. Later in time, the engine may be removed from the car and again be considered only an inactive item in a junkyard.
    Comment:
    This is a weird example. There are many parts to an engine that are added and removed. For example, spark plugs. A spark plug could be a better example as these are assembled of pieces that are not individually replaceable and junked as a whole.

    7.13.1 Connections Overview
    Original:
    However, the values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
    Replacement:
    The values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
    Original:
    However, a message does not specify how the payload is to be obtained from the source or delivered to the target.
    Replacement:
    A message does not specify how the payload is to be obtained from the source or delivered to the target.
    Comment:
    So how do we specify how it obtained? This needs further clarification.

    7.13.2 Connection Definitions and Usages
    Original:
    However, if it declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.
    Replacement:
    If a connection definition declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.

    7.13.4 Feature Values
    Original:
    However, for a default, bound feature value, the symbol = may be elided.
    Replacement:
    Optionally. a default, bound feature value, the symbol = may be elided (as shown in the default ‘mass’ in the following example).
    Comment:
    This a capricious and confusing option. Please choose one and delete the other. This adds a complication to the reading of the language that is unnecessary.

    7.13.6 Flow Connection Usages and Messages
    Original:
    A streaming flow is declared similarly to a message, but with the kind keyword flow. However, instead of identifying the source and target features of the flow, such a flow declaration must identify (after the keyword from) the output feature of the source from which the flow receives its payload and (after the keyword to) the input feature of the target to which the flow delivers the payload.
    Replacement:
    A streaming flow has the kind keyword flow and must identify, after the keyword from, the output feature of the source from which the flow receives its payload and, after the keyword to, the input feature of the target to which the flow delivers the payload.
    Comment:
    The use of ‘however’ has created language of no value. The streaming flow is totally different than a message in its form. The rewrite hopefully fixes the first mistake, however the sentence is still rather obtuse and still needs some wordsmithing.

    7.14.2 Interface Definitions and Usages
    Original:
    However, if the declaration part of an interface usage is empty, then the interface keyword is still included, but the connect keyword may be omitted.
    Replacement:
    If the declaration part of an interface usage is empty, then the connect keyword may be omitted.

    7.16.1 Actions Overview
    Original:
    However, if the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.
    Replacement:
    If the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.

    Original:
    However, a succession between action usages may, additionally, have a guard condition, represented as a Boolean expression (see 7.18).
    Replacement:
    A succession between action usages may have an additional guard condition, represented as a Boolean expression (see 7.18).

    7.16.5 Conditional Successions
    Original:
    However, the target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.
    Replacement:
    The target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.

    7.17.1 States Overview
    Original:
    However, if the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.
    Replacement:
    If the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.

    7.17.2 State Definitions and Usages
    Original:
    However, if the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. (However, no transitions are allowed between concurrent states; see 7.17.3.)
    Replacement:
    If the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. In this case, no transitions are allowed between concurrent states; see 7.17.3.

    Original:
    (However, no transitions are allowed between concurrent states; see 7.17.3.)
    Replacement:
    No transitions are allowed between concurrent states; see 7.17.3.

    7.19.1 Constraints Overview
    Original:
    In general, a constraint may be satisfied sometimes and violated other times. However, an assert constraint usage asserts that the result of a given constraint must be always true at all times.
    Replacement:
    When an assert constraint usage asserts exists, the result of that constraint must be always true at all times. This is compared to a simple constraint may be satisfied sometimes and violated other times.
    Comment:
    This another example of the ‘however’ causing a confusion in the semantics. The spec should say what is true before saying what is true is an exception. In this case, there is no exception, just a differing kind of constraint than one already discussed.

  • Reported: SysML 2.0b2 — Thu, 15 Aug 2024 23:57 GMT
  • Updated: Thu, 5 Sep 2024 20:56 GMT

Map UML4SysML::Constraint to ConstraintUsage only

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

    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.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 07:22 GMT
  • Updated: Mon, 2 Sep 2024 22:18 GMT

Replace Generic mapping classes by Initializers

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

    The coexistence of both the "GenericTo*_Mapping" classes and the Initializer classes generates a significant number of redundancies in the model, and make it harder to understand and to maintain.

    More specifically it makes the management of redefinitions much more complex with a very negative impact on the clarity of the specification.

    In order to fix that, all the GenericTo*_Mapping classes shall be removed and replaced par their Initializer class equivalent in an appropriate way.

  • Reported: SysML 2.0b2 — Sat, 15 Jun 2024 10:33 GMT
  • Updated: Sun, 1 Sep 2024 19:14 GMT

Transformation does not cover UML4SysML::ProfileApplication

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

    The mapping of a ProfileApplication is not covered by the transformation.

  • Reported: SysML 2.0b2 — Sat, 31 Aug 2024 06:11 GMT
  • Updated: Sat, 31 Aug 2024 06:11 GMT

Transformation does not cover SysMLv1::ConnectorProperty

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

    ConnectorProperty is deprecated but still part of SysML v1.7. So, the transformation should provide a mapping for it.

  • Reported: SysML 2.0b2 — Fri, 30 Aug 2024 16:05 GMT
  • Updated: Fri, 30 Aug 2024 16:05 GMT

Send action examples in representative notation tables wrong

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    In clause 7.16.1, the examples provided for send action are confusing and erratic. 5 alternative graphical examples for a single textual reference shown all of them have issues.

    • First example might be correct, if payload is indeed a parameter
    • Second example simply partial and lacks information such as picture
    • 3rd example use guiileimets in the textual expression and has redundant parameter symbols
    • 4th example Show(shoot.picture) misaligned with textual example
    • 5th example is partial and ot equivalent to the textual reference
  • Reported: SysML 2.0b2 — Wed, 14 Aug 2024 07:41 GMT
  • Updated: Wed, 28 Aug 2024 14:09 GMT

Actor should be mapped to a PartDefinition

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

    An Actor is mapped to an ItemDefinition, but it should be a PartDefinition.

  • Reported: SysML 2.0b2 — Tue, 27 Aug 2024 07:00 GMT
  • Updated: Tue, 27 Aug 2024 07:27 GMT

ObjectFlow with guards outgoing from DecisionNodes are not mapped correctly

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

    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.

  • Reported: SysML 2.0b2 — Sat, 24 Aug 2024 07:11 GMT
  • Updated: Sat, 24 Aug 2024 14:48 GMT

Fix errors in resolution of issue SYSML2_-203 (InitialState mapping)

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

    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.

  • Reported: SysML 2.0b2 — Sat, 24 Aug 2024 11:29 GMT
  • Updated: Sat, 24 Aug 2024 11:29 GMT

CallBehaviorAction mapping does not consider the pins

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

    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.

  • Reported: SysML 2.0b2 — Thu, 22 Aug 2024 06:56 GMT
  • Updated: Thu, 22 Aug 2024 06:56 GMT

Mapping of ObjectFlow should not consider the type of the objects that flow

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

    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.

  • Reported: SysML 2.0b2 — Wed, 21 Aug 2024 16:57 GMT
  • Updated: Wed, 21 Aug 2024 16:57 GMT

ActivityParameterNodes should be mapped

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

    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;
      }
    }
    
  • Reported: SysML 2.0b2 — Wed, 21 Aug 2024 15:48 GMT
  • Updated: Wed, 21 Aug 2024 15:48 GMT

Diagram frame production not properly integrated into graphical BNF

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    While there is a production for a diagram frame, it is not used by the graphical BNF, other than by "usage-node".
    There is a need to specify how diagram frames are integrated into the various view productions, such as general-view, interconnection-view etc

  • Reported: SysML 2.0b2 — Tue, 20 Aug 2024 10:07 GMT
  • Updated: Wed, 21 Aug 2024 14:44 GMT

proxy connection points should be applicable more broadly then currently supported by the GBNF

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    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.

  • Reported: SysML 2.0b2 — Wed, 14 Aug 2024 09:31 GMT
  • Updated: Wed, 21 Aug 2024 14:10 GMT

SysMLv1Tov2.xmi contains temporary mapping classes

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

    The temporary mapping classes

    _InitialState_Mapping and _InitialStateMembership_Mapping

    should be removed from the SysMLv1Tov2.xmi.

    They are not part of the specification document.

  • Reported: SysML 2.0b2 — Wed, 21 Aug 2024 09:57 GMT
  • Updated: Wed, 21 Aug 2024 09:57 GMT

ConnectionPointReference_Mapping should create a Redefinition

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

    A ConnectionPointReference is mapped to a StateUsage. In addition, the state usage shoud redefine the corresponding pseudostate.

  • Reported: SysML 2.0b2 — Tue, 20 Aug 2024 06:09 GMT
  • Updated: Tue, 20 Aug 2024 06:09 GMT

Typos in graphical metadata representative notation

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

    In subclause 7.26.1, Table 25, two typos appear in examples "Metadata" and "Metadata Compartment". In the graphical notation for both, AttributeDef1 should be replaced with MetadataDef1, in line with the textual notation.

  • Reported: SysML 2.0b2 — Fri, 2 Aug 2024 19:27 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT
  • Attachments:

RICOAOutputPin_Mapping should specialized Pin_Mapping

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

    The mapping class RICOAOutputPin_Mapping has no general mappings but should have Pin_Mapping

  • Reported: SysML 2.0b2 — Fri, 19 Jul 2024 17:06 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

Inconsistent graphical notation for view frame


Mapping of State does not consider orthogonal states

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

    A state with several regions should be mapped to a parallel state.

  • Reported: SysML 2.0b2 — Thu, 30 May 2024 16:07 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

InitialState is mapped to StateUsage, but should be an empty ActionUsage

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

    The InitialState should be mapped to an empty ActionUsage owned by a StateSubactionMembership relationship.

  • Reported: SysML 2.0b2 — Tue, 21 May 2024 05:40 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

InterfaceBlock mapped to PortDefinition, but ConjugatedPortDefinition is not generated

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

    A SysMLv1::InterfaceBlock is mapped to a SysMLv2::PortDefinition, but the owned SysMLv2::ConjugatedPortDefinition is not generated.

  • Reported: SysML 2.0b2 — Fri, 10 May 2024 16:26 GMT
  • Updated: Tue, 20 Aug 2024 00:22 GMT

State machine graphical notation for entry/exit/do actions inconsistent

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Current GBNF uses the textual notation to represent state entry/do/exit actions within a "state actions" compartment.
    This does not allow to describe state actions in a graphical way and also requires the graphical modeler to use more extended textual syntax.

  • Reported: SysML 2.0b2 — Thu, 20 Jun 2024 12:44 GMT
  • Updated: Mon, 19 Aug 2024 15:23 GMT

Chapter Trigger_Mapping is empty

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

    The chapter 7.7.5.3.7 Trigger_Mapping is empty.

  • Reported: SysML 2.0b2 — Mon, 19 Aug 2024 14:33 GMT
  • Updated: Mon, 19 Aug 2024 14:33 GMT

Mapping for UML4SysML::CallEvent and UML4SysML::AcceptCallAction are missing

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

    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.

  • Reported: SysML 2.0b2 — Mon, 19 Aug 2024 11:04 GMT
  • Updated: Mon, 19 Aug 2024 11:04 GMT

Weak check of input parameter in Helper::getScalarValueType

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

    Helper::getScalarValueType checks only the name of the input parameter and does not consider the fully qualified name to check if it is part of the SysML v1 library. Any DataType of name "UnlimitedNatural" is mapped to ScalarValues::Natural.

  • Reported: SysML 2.0b2 — Sat, 17 Aug 2024 11:54 GMT
  • Updated: Sat, 17 Aug 2024 11:54 GMT

Need to add terminate action node to action flow and state flow views

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Terminate node is about to be introduced to the language, need to assure it is covered by the graphical bnf

  • Reported: SysML 2.0b2 — Wed, 14 Aug 2024 09:18 GMT
  • Updated: Wed, 14 Aug 2024 09:18 GMT

send and accept actions name compartment productions inconsistent

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    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

  • Reported: SysML 2.0b2 — Wed, 14 Aug 2024 08:00 GMT
  • Updated: Wed, 14 Aug 2024 08:00 GMT

Definition of view artifact

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    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”

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:45 GMT
  • Updated: Tue, 13 Aug 2024 08:45 GMT

Examples of Nested View Usages

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    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.

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:20 GMT
  • Updated: Tue, 13 Aug 2024 08:20 GMT

Typo in definition of RenderingDefinition

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    "A RenderingDefinition is a kind of PartDefinition. As such, all the general semantic constraints for a
    PartDefinition (see 8.4.7.1 ) also apply to a ViewDefinition."

    Should be "RenderingDefinition" not "ViewDefinition"

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:14 GMT
  • Updated: Tue, 13 Aug 2024 08:14 GMT

is view the same as view usage?

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    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".

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:12 GMT
  • Updated: Tue, 13 Aug 2024 08:12 GMT

filter condition or view condition

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    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?

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:09 GMT
  • Updated: Tue, 13 Aug 2024 08:09 GMT

Missing word in description of view usage

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    spec: "A view definition or usage is declared as a kind of part definition or usage (see 7.11.2 ), using the kind keyword
    view. A view usage must be defined by a single view."

    Should this be "single view definition"?

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:07 GMT
  • Updated: Tue, 13 Aug 2024 08:07 GMT

Why does View Definition specialise Part Definition?

  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    This seems an odd choice and at least needs more explanation of how the various features of part definitions, like ports, are used

  • Reported: SysML 2.0b2 — Tue, 13 Aug 2024 08:04 GMT
  • Updated: Tue, 13 Aug 2024 08:04 GMT

Misspelling in Table 16 / graphical and textual notation do not match

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    Issue 1: textual notation does not include a state definition, but the graphical notation does. Change to match.
    Issue 2: textual notation has an assumed spelling error, also causing a mismatch to graphical notation. In the following notation, "actio1" should likely be "action1".

    state state1

    { entry actio1; do action2; exit action3; }
  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:47 GMT
  • Updated: Mon, 12 Aug 2024 19:17 GMT

Multiple textual notation issues

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    Issue 1: the following notation found in the middle of the page has a comma instead of a semicolon for the declaration of an "in".

    action def B

    { in b1, out b2; }

    should be
    action def B

    { in b1; out b2; }

    Issue 2: The following notation found in the middle of the page has the wrong kind of closing bracket, followed by a semi-colon, following the declaration of an action definition. I.e., a closed parenthesis and semi-colon should be replaced by a closed curly bracket.

    action def B1 :> B { in b1; out b2; inout b3); // Redefinitions are implicit.
    should be
    action def B1 :> B

    { in b1; out b2; inout b3}

    // Redefinitions are implicit.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:43 GMT
  • Updated: Mon, 12 Aug 2024 19:16 GMT

Differentiate Row Headers that say "Interface"

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    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

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:37 GMT
  • Updated: Mon, 12 Aug 2024 19:16 GMT

Table 5 Attributes Compartment Graphical Notation and Textual Notation does not match

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    Readers should expect that the textual notation and graphical notation should match as much as possible, including element names.
    The attributes compartment row should at least align on the attribute1 declaration (the definition is different between the graphical and textual notations. I would like to make the case that all of the graphical notation examples should be shown in textual notation, too. If it is worth it to show the graphical notation expectation in the table, it is worth it to show the corresponding textual notation.

    Example of minimum correction in textual notation:
    change:
    attribute attribute1 : Attribute1Def
    to:
    attribute attribute1 : AttributeDef1

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:31 GMT
  • Updated: Mon, 12 Aug 2024 19:15 GMT

P8 import textual notation may have errors

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    I suspect that there are two errors near the top of page 30 in the P8 namespace textual notation:
    1. Import Annotations::; should be import ApprovalMetadata::;
    import Annotations::* does not seem to serve a purpose here, and ApprovalMetadata elements would be needed to support the following code (when corrected).
    2. import NA::[@Approved]; should be import NA::[@Approval and approved]; or import NA:*[@approved]; or another version of this depending on interpretation of preceding commentary.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 19:21 GMT
  • Updated: Mon, 12 Aug 2024 19:15 GMT

Error in textual notation on this page ("comment Comment 2")

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    There is an error in the last example on this page and in this section. One line calls out "comment Comment 2", which is likely intended to be "comment Comment2".
    Suggest change from original: comment Comment 2
    to: comment Comment2

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 18:48 GMT
  • Updated: Mon, 12 Aug 2024 19:15 GMT

Header description of unowned elements does not align with textual notation

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    The following row headers describe unowned elements, but the textual notation illustrates that the elements are owned.

    Package with alias member (unowned)
    Package with alias member (unowned)
    Membership (unowned member with alias name)

    The simplest resolution, if the desire to emphasize "unowned" is maintained, may be to use textual notation for each which declare the packages to be aliased in the next higher namespaces.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 18:41 GMT
  • Updated: Mon, 12 Aug 2024 19:14 GMT

Presuming missing word in sentence describing implicit annotation.

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    A sentence is missing a word indicating that an owned comment is implicitly about the element owning the namespace, if it is about nothing else:

    Original: "If the comment is an owned member of a namespace (see 7.5 ), then the explicit identification of annotated elements can be omitted, in which case the annotated element is implicitly the containing namespace."
    Should be:"...the annotated element is implicitly about the containing namespace."

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 18:31 GMT
  • Updated: Mon, 12 Aug 2024 19:14 GMT

Row headers not descriptive enough

  • Status: open  
  • Source: outlook.com ( Mr. Matthew Johnson)
  • Summary:

    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

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 18:25 GMT
  • Updated: Mon, 12 Aug 2024 19:13 GMT

Mapping of UseCase does not consider more than one subject

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

    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.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 15:52 GMT
  • Updated: Sat, 10 Aug 2024 15:52 GMT

Property typed by an Actor should be mapped to a PartUsage

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

    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.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 07:33 GMT
  • Updated: Sat, 10 Aug 2024 07:33 GMT

Mapping of UML4SysML::Constraint: Bind the result parameter

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

    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.

  • Reported: SysML 2.0b2 — Sat, 10 Aug 2024 07:24 GMT
  • Updated: Sat, 10 Aug 2024 07:24 GMT

Flows cannot connect ControlNodes

  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Armonas)
  • Summary:

    Allow flows to connect ControlNodes because, currently, this limitation makes it impossible to pass payloads from one ActionUsage to another ActionUsage if a DecisionNode is in between.
    This issue is a showstopper for the UAF v2 development.

  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 13:03 GMT
  • Updated: Tue, 6 Aug 2024 05:41 GMT

Accept action in representative notation tables is confusing and needs cleanup

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    Clause 7.16.1 (rep. notation for actions) shows a graphical notation example of an accept action corresponding to the following textual notation:

    action trigger1 : Trigger 
    accept scene : Scene via viewPort;
    

    It shows 3 alternative graphical notations which are confusing and inconsistent.
    That graphical representative example needs to be corrected. Here are few issues:

    • it shows an unbound parameter "receiver" in 2nd and 3rd examples
    • first example uses the type Trigger instead of Trigger1
    • 3rd example uses guillemets in the wrong way
    • too many options instead of one "canonical" way to do this
    • it uses a parameter that in 2nd example called scene and in 3rd example called payload
  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 07:03 GMT
  • Updated: Tue, 6 Aug 2024 05:39 GMT

Graphical notation action names need to be aligned

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    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.

  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 07:30 GMT
  • Updated: Tue, 6 Aug 2024 05:37 GMT

Update language description and concrete syntax related to imports

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

    The resolutions by the KerML FTF to the following issues make restrictions to the functionality of imports in KerML and hence, by reference, in SysML, also:

    • KERML_-73 Disallow public imports at root level
    • KERML_-74 Make imports private by default
    • KERML_-75 Restrict the functionality of recursive import

    The discussion of imports in Clause 7 Language Description need to be updated to reflect these changes (particularly in 7.5.3 Imports). In addition, adopting the requirement to always show visibility of imports in the concrete syntax, consistent with KERML_-74, requires changes in

    • 8.2.2.5.1 Packages (textual notation)
    • 8.2.3.5 Namespaces and Packages Graphical Notation
    • 8.3.5 Namespaces and Packages Abstract Syntax, Figure 5 Namespaces
  • Reported: SysML 2.0b2 — Sun, 26 May 2024 21:27 GMT
  • Updated: Fri, 2 Aug 2024 05:18 GMT
  • Attachments:

There is no need for AnalysisAction

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

    The Systems Library model AnalysisCases includes a declaration for AnalysisAction as a specialization of Actions::Action. In the abstract syntax, ActionDefinition::analysisSteps and ActionUsage::analysisSteps are derived to be the subactions that are AnalysisActions.

    However, no special semantics are specified for AnalysisActions and no special concrete syntax for defining analysisSteps. So they are never used in practice within user models of analysis caes, so they seem pointless.

  • Reported: SysML 2.0b2 — Wed, 1 May 2024 22:44 GMT
  • Updated: Fri, 2 Aug 2024 05:11 GMT

Mappings from the "Common" package

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

    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.

  • Reported: SysML 2.0b2 — Thu, 1 Aug 2024 16:37 GMT
  • Updated: Thu, 1 Aug 2024 16:37 GMT

Type of the ReferenceUsage created for the client of a Satisfy relationship

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

    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.

  • Reported: SysML 2.0b2 — Thu, 1 Aug 2024 16:07 GMT
  • Updated: Thu, 1 Aug 2024 16:07 GMT

ReferenceUsage creation in case of a Satisfy relationship transformation

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

    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

  • Reported: SysML 2.0b2 — Thu, 1 Aug 2024 16:01 GMT
  • Updated: Thu, 1 Aug 2024 16:01 GMT

Invalid use of "loop" as merge action name

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

    In two SysML textual notation example snippets, (1) clause 7.16.4 third snippet, (2) clause 7.16.5 last snippet, a merge node is named loop. This is not allowed as loop is a keyword.

    Suggest to rename the merge node to something like loopBegin, beginLoop or loopEntry.

  • Reported: SysML 2.0b2 — Wed, 31 Jul 2024 08:48 GMT
  • Updated: Wed, 31 Jul 2024 16:10 GMT

Incorrect declaration of parameters on actions

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

    In clause 7.16.1 Table 14 examples "Actions Compartment" and "Perform Actions Compartment" have outdated notation using parentheses for parameter notation in actions compartments.

    It is suggested to remove those parameter declarations.

  • Reported: SysML 2.0b2 — Wed, 31 Jul 2024 14:03 GMT
  • Updated: Wed, 31 Jul 2024 14:03 GMT

ObjectFlow mappings limited to non-streaming parameters

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

    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.

  • Reported: SysML 2.0b2 — Tue, 30 Jul 2024 15:41 GMT
  • Updated: Tue, 30 Jul 2024 15:45 GMT

There is no checkSatisfyRequirementUsageSpecialization constraint

  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Armonas)
  • Summary:

    SatisfyRequirementUsage subsets Requirements::notSatisfiedRequirementChecks or Requirements::satisfiedRequirementChecks in pilot implementation.

    checkSatisfyRequirementUsageSpecialization constraint should be defined in the specification.

  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 13:14 GMT
  • Updated: Mon, 29 Jul 2024 19:01 GMT

Missing semantic constraints related to features of Part

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

    In the Systems Library model Parts, the base part definition Part is declared to have the features ownedPorts, ownedActions and ownedStates. These features are described in 8.4.7 Parts Semantics, noting that the are covered further in 8.4.8 Ports Semantics, 8.4.12 Actions Semantics and 8.4.13 States Semantics, respectively. More specifically, 8.4.8.2 Port Usages, 8.4.12.2 Action Usages and 8.4.13.2 State Usages state that the semantic constraints checkPortUsageOwnedPortSpecialization, checkActionUsageOwnedActionSpecialization and checkStateUsageOwnedStateSpecialization determine the required specialization of the relevant Part features. However, of these, checkActionUsageOwnedActionSpecialization is defined in the abstract syntax, but the other two are not.

  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 18:59 GMT
  • Updated: Mon, 29 Jul 2024 18:59 GMT

Interface usage cannot redefine inherited attributes in textual syntax

  • Status: open  
  • Source: Budapest University of Technology and Economics ( Dr. Vince Molnar)
  • Summary:

    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
      }
    
  • Reported: SysML 2.0b2 — Mon, 29 Jul 2024 14:39 GMT
  • Updated: Mon, 29 Jul 2024 17:31 GMT

No way to expose non-membership and non-namespace elements

  • Status: open  
  • Source: sodiuswillert.com ( Mr. Eran Gery)
  • Summary:

    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.

  • Reported: SysML 2.0b2 — Wed, 24 Jul 2024 11:34 GMT
  • Updated: Fri, 26 Jul 2024 22:17 GMT

Inconsistent compartment labels

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

    In subclause 7.20.1, Table 19, example "Requirement" the compartment labels "require constraints" and "assume constraints" and their content are misleading and inconsistent. Besides pure "require ConstraintUsage" statements a "require constraints" compartment may also contain "require RequirementUsage" statements. A "require RequirementUsage" has the same semantics as a RequirementUsage contained (isComposite==true) by a containing RequirementUsage (see explanation in subclause 7.20.2). Therefore a better compartment name is possibly "requires".

    The same problem applies to other compartment names for reference usages. The full list of compartments to be made consistent is:
    asserts, assumes, assert, exhibits, performs, requires, satisfies, verifies, include use cases. (Note: frames and frame concerns not included)

  • Reported: SysML 2.0b2 — Wed, 24 Jul 2024 14:06 GMT
  • Updated: Wed, 24 Jul 2024 14:06 GMT

Name misplaced on action symbol parameter

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

    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.

  • Reported: SysML 2.0b2 — Wed, 24 Jul 2024 13:50 GMT
  • Updated: Wed, 24 Jul 2024 13:50 GMT

Default multiplicities are not formally specified

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

    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.

  • Reported: SysML 2.0b2 — Sat, 15 Jun 2024 17:52 GMT
  • Updated: Tue, 23 Jul 2024 21:04 GMT

Mapping of ClearStructuralFeatureAction is not defined yet

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

    As mentioned in section "7.7.2.3.7.20 ClearStructuralFeatureAction_Mapping": The details of the mapping are not defined yet.

  • Reported: SysML 2.0b2 — Mon, 22 Jul 2024 14:34 GMT
  • Updated: Mon, 22 Jul 2024 14:34 GMT

Mapping of RemoveStructuralFeatureValueAction is not defined yet

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

    As mentioned in section "7.7.2.3.7.34 RemoveStructuralFeatureValueAction_Mapping": The details of
    the mapping are not defined yet.

  • Reported: SysML 2.0b2 — Mon, 22 Jul 2024 14:20 GMT
  • Updated: Mon, 22 Jul 2024 14:20 GMT

AddStructuralFeatureValueAction Mapping does not consider the names of the input and output pins

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

    The mapping AddStructuralFeatureValueAction ignores the names of the input and output pins and uses the names defined in the SysMLv1Library::AddStructuralFeatureValueAction element.

  • Reported: SysML 2.0b2 — Mon, 22 Jul 2024 13:39 GMT
  • Updated: Mon, 22 Jul 2024 13:39 GMT

Multiple vs Single Trigger/Guard/Effect for State Transitions Contradiction

  • Status: open   Implementation work Blocked
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    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.

  • Reported: SysML 2.0b2 — Wed, 10 Jul 2024 11:46 GMT
  • Updated: Wed, 17 Jul 2024 23:09 GMT

Ordering of guards and accepts in transitions is inconsistent

  • Status: open  
  • Source: Commonwealth Center for Advanced Manufacturing ( Nicholas Thompson)
  • Summary:

    The fourth and sixth rows of "Table 16. States – Representative Notation" each give an example of a transition statement that contains both an if statement and an accept statement, with the accept before the if.

    ...
    transition
       first state1
       accept trigger1
       if guard1
    ...
    

    However, page 110 and the subsequent examples seem to contradict this:

    A transition usage can also have an accepter, which is an accept action usage use to trigger the transition. The accepter action for a transition usage is placed after the guard expression and notated using the accept keyword, with its payload and receiver parameters specified exactly as discussed in 7.16.8 .

    If an accept before an if has a different meaning than an if before accept, the specification document does not make this obvious.
    The Jupyter Kernel in release 2024-05 of the SysML-v2-Release repository treats an if before an accept as a syntax error.

  • Reported: SysML 2.0b2 — Thu, 11 Jul 2024 14:42 GMT
  • Updated: Wed, 17 Jul 2024 23:07 GMT

Evaluation problem with TradeStudyObjectives

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

    The Analysis Domain Library model TradeStudies includes the following definition:

    	requirement def MinimizeObjective :> TradeStudyObjective {
    		doc
    		/*
    		 * A MinimizeObjective is a TradeStudyObjective that requires that the 
    		 * selectedAlternative have the minimum ObjectiveFunction value of all the
    		 * given alternatives.
    		 */
    		 
    		subject :>> selectedAlternative;
    		in ref :>> alternatives;
    		in calc :>>fn;
    	
    		out attribute :>> best = alternatives->minimize {
    			doc
    			/*
    			 * For a MinimizeObjective, the best value is the minimum one.
    			 */
    		
    			in x; fn(x)
    		};
    	}
    

    (and there is a similar definition for MaximizeObjective that uses maximize instead of minimize). Unfortunately, in the definition minimize in the Kernel Function Library model ControlFunctions, the functional argument to minimized is named fn, and, in the expression fn(x), the name fn gets bound to this parameter, instead of to MinimizeObjective::fn. This means that an evaluation of the invocation of minimize as given will result in an infinite recursion (and similarly for the call to maximize in MaximizeObjective).

  • Reported: SysML 2.0b2 — Wed, 17 Jul 2024 23:06 GMT
  • Updated: Wed, 17 Jul 2024 23:06 GMT

Graphical BNF for n-ary ConnectionDefinition is missing

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

    In subclause 8.2.3.13 productions for n-ary ConnectionDefinition should be added, similar to the existing production n-ary-connection for n-ary ConnectionUsage.

    An n-ary ConnectionDefinition example is given in 7.13.1 Table 11 in row "Connection Definition (n-ary with 3 ends)", like so:

  • Reported: SysML 2.0b2 — Fri, 12 Jul 2024 20:28 GMT
  • Updated: Fri, 12 Jul 2024 20:30 GMT
  • Attachments:

StateAction::substates has an implied subsetting of exclusiveStates

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

    According to the constraint checkStateUsageExclusiveStateSpecialization (in 8.3.17.6), a substate of a non-parallel owning state definition or usage must specialize StateAction::exclusiveStates (at least according to the description of the constraint; the OCL is wrong, see SYSML2_-183). However, the feature StateAction::substates actually meets the requirements for the application of checkStateUsageExclusiveSpecialization, which means that it has an implied specialization of exclusiveStates. But exclusiveStates already subsets substates (at least according to the library model in States.sysml; the feature exclusiveStates seems to be missing from subclause 9.2.10.2.1 StateAction), so this would mean that all substates are exclusiveStates, which is, of course, incorrect for the semantics of parallel states.

  • Reported: SysML 2.0b2 — Wed, 1 May 2024 20:57 GMT
  • Updated: Sun, 7 Jul 2024 23:19 GMT

Missing Complete concept

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    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

  • Reported: SysML 2.0b2 — Wed, 19 Jun 2024 16:26 GMT
  • Updated: Tue, 2 Jul 2024 11:33 GMT

Missing Final concept

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    a classifier in SysML v1 can have isFinalSpecialization:Boolean ... that concept is missing in SysML v2

  • Reported: SysML 2.0b2 — Wed, 19 Jun 2024 16:28 GMT
  • Updated: Tue, 2 Jul 2024 11:33 GMT

Missing isLeaf concept

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in SysML v1 a RedefinableElement can have a isLeaf:Boolean... this concept seems to be missing in SysMLv2

  • Reported: SysML 2.0b2 — Wed, 19 Jun 2024 16:29 GMT
  • Updated: Tue, 2 Jul 2024 11:32 GMT

Missing Element Import Alias

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in SysMLv1 for an ElementImport one can supply an Alias... That seems to be missing in SysMLv2

  • Reported: SysML 2.0b2 — Wed, 19 Jun 2024 16:31 GMT
  • Updated: Tue, 2 Jul 2024 11:32 GMT

ShapeItems have radius feature bound

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

    In the Geometry Domain Library model ShapeItems, in the item definitions CircularDisc, Sphere, CircularCone and CircularCylinder, the radius feature is bound to semiMajorAxis (or semiAxis1 for Sphere). However, because of the constraint featureValueOverriding, this means that the radius features cannot be re-bound to specific values in user-model usages of these definitions, as would be expected. (Note that this can only be seen in the ShapeItems.sysml file, not in the description in the specification document.)

  • Reported: SysML 2.0b2 — Tue, 2 Jul 2024 11:31 GMT
  • Updated: Tue, 2 Jul 2024 11:31 GMT

Invalid values can be assigned to an enum

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

    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).

  • Reported: SysML 2.0b2 — Wed, 26 Jun 2024 09:58 GMT
  • Updated: Wed, 26 Jun 2024 09:58 GMT

Description and examples for message notation are wrong

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

    The description of message declarations in 7.13.6 Flow Connection Usages and Messages is incorrect. It states that a message declaration "may or may not include identification of source and target related features. If they are included, then they follow the payload specification (if any), with the source related feature identified after the keyword from, followed by the target related feature after the keyword to." However, the from and to features of a message are not the related features of the message as a flow connection usage. Rather, they are the values of the sourceEvent and targetEvent parameters of the MessageConnection (see parsing in 8.2.2.13.4 Message and Flow Connections and semantics in 8.4.9.6 Flow Connection Usages).

    In light of this, the message declaration example in 7.13.6 is also incorrect, as is the textual notation for the first "Messages" example in Table 11 Connections – Representative Notation (showing a message between ports). However, the graphical notation in this example seems to be acceptable, as are both the graphical and textual notations in the second "Message" example (showing a message on a sequence diagram).

  • Reported: SysML 2.0b2 — Mon, 24 Jun 2024 04:43 GMT
  • Updated: Mon, 24 Jun 2024 04:43 GMT

Inconsistencies in the graphical notation for "expose"

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:
    1. In 7.25.1 Views and Viewpoints Overview, Table 23. Views and Viewpoints – Representative Notation, the example for "Expose" renders the expose relationship using a dashed arrow. However, in 8.2.3.25 Views and Viewpoints Graphical Notation, the graphical BNF production expose-relationship shows the arrow as being solid.
    2. An expose relationship is a kind of import and, as such, can expose a single membership or the content of a namespace, and can optionally be recursive. The textual BNF production Expose in 8.2.2.25.2 View Usages allows all these options, as does the graphical BNF production expose-compartment-element (for showing an expose declaration in a compartment) in 8.2.3.25 Views and Viewpoints Graphical Notation. However, the graphical graphical BNF production expose-relationship does not.
    3. The textual BNF production Expose allows a VisibilityIndicator on an expose declaration, as does the graphical BNF production expose-compartment-element. However, the graphical BNF production expose-relationship does not.
  • Reported: SysML 2.0b2 — Thu, 30 May 2024 14:46 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT
  • Attachments:

isOrdered and isUnique are missing from the reflective abstract mapping

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

    The mapping given in 9.2.21 from the MOF abstract syntax model to the reflective SysML abstract syntax model is missing instructions for what to do if a property is ordered or non-unique. Therefore, appropriate annotations for these are missing from the normative SysML.sysml file.

  • Reported: SysML 2.0b2 — Mon, 27 May 2024 19:34 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Missing guidance on highlighting keywords

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

    The KerML specification contains guidance for tooling to highlight keywords in concrete textual notation. KerML subclause 8.2.2.6 specifically says:

    Tooling for the KerML textual notation should generally highlight keywords relative to other text, for example by using boldface and/or distinctive coloring. However, while keywords are shown in boldface in this specification, the specification does not require any specific highlighting (or any highlighting at all), and KerML textual notation documents are expected to be interchanged as plain text (see also Clause 10 on Model Interchange).

    A similar statement, modified for SysML, should be added, probably as a last paragraph under subclause 8.2.2.1.2, including a cross-reference to KerML. For SysML the same guidance applies to textual snippets used in the Graphical Notation.

  • Reported: SysML 2.0b2 — Mon, 20 May 2024 09:37 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Error in the specification of "connections"

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

    In the SysML Specification, 9.2.6.2.4 connections, the base connection usage connections is specified as being a ConcernUsage under "Elements". This should, instead, be ConnectionUsage. (Note that this error is only in the document, and connections is declared correctly in the Connections.sysml model file.

  • Reported: SysML 2.0b2 — Sat, 4 May 2024 20:16 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

Incorrect enumeration example

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

    The following example appears in 7.8.2 Enumeration Definitions and Usages:

    enum def ConditionColor { red; green; yellow; } 
    attribute def ConditionLevel {
        attribute color : ConditionColor; 
    }
    enum def RiskLevel :> ConditionLevel {
        enum low { color = ConditionColor::green; } 
        enum medium { color = ConditionColor::yellow; } 
        enum high { color = ConditionColor::red; }
    }
    

    This is example is not valid, because the color features defined in the enumerated values will have name conflicts with the color feature inherited from ConditionLevel. The intent was probably to have the color features in the enumerated values redefine ConditionLevel::color, but that is currently missing from the example.

  • Reported: SysML 2.0b2 — Thu, 2 May 2024 21:34 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

checkStateUsageExclusiveStateSpecialization and checkStateUsageSubstateSpecialization have problems

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

    In 8.3.17.6 StateUsage:

    1. The constraint checkStateUsageExclusiveStateSpecialization has the description

      A StateUsage that is a substate usage with a non-parallel owning StateDefinition or StateUsage must directly or indirectly specialize the StateUsage States::State::exclusiveStates from the Systems Model Library.

      However, the OCL for the constraint actually checks for the owning state being parallel (rather than non-parallel) and requires specialization of substates rather than exclusiveStates.

    2. The constraint checkStateUsageSubstateSpecialization has the description

      A StateUsage that is a substate usage with a owning StateDefinition or StateUsage that is parallel must directly or indirectly specialize the StateUsage States::State::substates from the Systems Model Library.

      However, the OCL for the constraint actually checks for the owning state being non-parallel (rather than parallel).

    3. The operation isSubstateUsage used in the above constraints has the description

      Check if this StateUsage is composite and has an owningType that is an StateDefinition or StateUsage with the given value of isParallel, but is not an entryAction or exitAction. If so, then it represents a StateAction that is a substate or exclusiveState (for isParallel = false) of another StateAction.

      However, the OCL for the operation actually does not check if the state usage is composite and also excludes do actions (in addition to entry and exit actions).

  • Reported: SysML 2.0b2 — Wed, 1 May 2024 20:43 GMT
  • Updated: Tue, 18 Jun 2024 00:01 GMT

TransitionUsage source and target properties do not support feature chains

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

    According to the SysML abstract syntax (8.3.17.9 TransitionUsage), the source and target of a TransitionUsage must be ActionUsages. However, the textual notation (8.2.2.17.3 Transition Usages) allows sources and targets to be feature chains, which are parsed as a KerML Feature with FeatureChaining relationships to the chained Features, which are not ActionUsages.

  • Reported: SysML 2.0b2 — Sun, 16 Jun 2024 22:17 GMT
  • Updated: Sun, 16 Jun 2024 22:17 GMT

Editorial errors in constraints

  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:
    1. In 8.3.6.4 Usage, the name of valideaUsageVariationIsAbstract should be validateUsageVariationIsAbstract.
  • Reported: SysML 2.0b2 — Wed, 22 May 2024 19:31 GMT
  • Updated: Wed, 22 May 2024 19:36 GMT

Confusing send/accept examples in notation tables

  • Status: open  
  • Source: International Business Machines ( Mr. Eran Gery)
  • Summary:

    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.

  • Reported: SysML 2.0b2 — Mon, 13 May 2024 13:29 GMT
  • Updated: Wed, 22 May 2024 19:20 GMT