The description of the PropertySpecificType states:

The PropertySpecificType stereotype can be applied to classifiers that type exactly one property and that are owned by the owner of that property. Classifiers with this stereotype applied shall be generalized by at most one
other classifier.

The constraint section covers only "can be applied to classifiers that type exactly one property". The other constraints

"that are owned by the owner of that property."
and
"Classifiers with this stereotype applied shall be generalized by at most one
other classifier."

are missing.

Defer

Issue deferred

This issue is dedicated to collect all typos and editorials we find in the SysML1.6 specification document. See linked annotated PDF for the list.

-------------------------------------------------------------------------------------------------------
>>> Note to RTF Chairs: do not schedule this issue for voting before the last ballot of the RTF; until then we update the list in the issue description if we find new typos <<<
-------------------------------------------------------------------------------------------------------

Proposal: Fixed typos/editorials in SysML 1.6

This resolution fixes all typos summarized in the issue.

Clarify the executable semantics of SysML Stereotypes

Add an Annex to the SysML specification

The ViewEditor present an informative annex (Annex H) that we propose as a resolution to this issue.

The operations and constraints in section E.5.2.15 SystemOfQuantities are not consistent with the definition in the XMI.

Sync section 5.2.15 with XMI

The XMI is based on the QUDV model, which is the single source of truth. Therefore, the documentation of the operations and constraints in section 5.2.15 must be updated to be in sync with the XMI. This will be achieved thanks to the document generation.

Figure E-5 and E-6 are identical. Replace figure E-6 with the figure E-6 from the SysML 1.5 specification.

Figure E-6 contains some issues:

• Should be a bdd instead of pkg
• Unit::dependsOnUnits is a reference property and should be displayed in a separate compartment with headline "references"
• Multiplicity at ends of associations between Unit and SystemOfUnits are 0..1 in figure E-5, but 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
• Multiplicity quantityKind (association between Unit and QuantityKind) is 1..* in figure E-5, and 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5

Update figures E-5 and E-6

Figure E-5 and E-6 are identical. Replace figure E-6 with the figure E-6 from the SysML 1.5 specification.

Figure E-6 contains some issues:

• Should be a bdd instead of pkg
• Unit::dependsOnUnits is a reference property and should be displayed in a separate compartment with headline "references"
• Multiplicity at ends of associations between Unit and SystemOfUnits are 0..1 in figure E-5, but 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
• Multiplicity quantityKind (association between Unit and QuantityKind) is 1..* in figure E-5, and 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5

The units shown in figure E.15 to E.18 don't have a link to the SystemOfUnits shown in the same diagram. There has been a link in SysML 1.5, albeit erronously, because there is no direct link. An indirect link exists along the included SystemOfUnits. I think it makes sense to show these indirect links. Otherwise the unconnected SystemOfUnits shown makes no sense in the diagram.
Suggestion: Add the intermediary SystemOfUnits.

Change the diagrams

Replace diagrams

The illustration given as part of the description of the Overwrite stereotype does not match the semantics defined by fUML.

Indeed, and except in very specific situation input pins never "store" tokens. So, applying the Overwrite stereotype to an input pin does not have practical effect in most cases.

Fix the illustration given in the SysML specification

In the sentence referred by the issue, just replace "input pin" by "output pin"

Name of constraint 8 is "8_callAction_composite_and_consitent_type",
but should be "8_callAction_composite_and_consistent_type".

Proposal: Typo: Constraint name 8 of Adjunct Property

Fix the typo as proposed.

The sentence that says: “When the stereotype is not applied, the semantics are as in UML, specifically, tokens arriving at an object node that are refused by outgoing edges, or action for input pins, are held until they can leave the object node” is false. This is not the semantics UML specifies. Buffering is provided only for token satisfying the guard but that are not numerous enough to satisfy the “weight” condition.

The sentence is correct, but restates UML semantics.

The sentence is correct. Buffering of tokens in Pins is possible in UML. The weight is not the only reason, why the outgoing ObjectFlow might refuse to accept tokens. If the guard is not satisfied, tokens are not discarded but buffered.

However, the second part of the sentence restates UML semantics. In terms of a clean separation of the specifications UML and SysML, the second part is removed and the sentence is changed to "When the stereotype is not applied, the semantics are as in UML."

Figure E-5 QUDV Concepts Diagram has several minor issues:

• Should be a bdd instead of pkg diagram
• Diagram name should not include the diagram number E-5
• The notation of the owner in the block rectangle is not SysML conform
• Diagram is not a vector graphic
• Block QuantityKind has additional unknown stereotype <<Migration>>

Fixed figure E-5

Editorial fixes: change diagram type from package to bdd; remove diagram number from diagram name; assure that final graphic in the PDF is a vector graphic

The stereotype "Migration" seems to be a forgotten part of the work on the QUDV elements. It can be removed.

The information about the owner of the blocks is less important and would cost a lot of diagram space, if the package frames were included or the blocks had full qualified names. Therefore, that information is removed from the diagram.

In figure E-9, the prefixed unit kilogram has two quantity kinds mass.

However, PrefixedUnit redefines the quantityKind property and sets the multiplicity to 0. It should not have a quantityKind.

Remove quantityKind links for kilogram in Figure E-9

A PrefixedUnit has not quantity kinds. The slots respectively links from kilogram to mass should be removed.

According to the UML semantics for Activities execution, token will be placed on input pins of an action only when this action accept them. So there will be no case where token in a input pin will be "refused".

As a consequence, applying the "NoBuffer" stereotype on an input pin will not have any effect, conversely to what the description sub clause of that stereotype suggests (in section 11.3.2.4).

Proposal: clarify that "NoBuffer" should not be applied on input pins.

No change

No Buffer may actually has an effect on an input pin if that one is part of a structured node.

The operations and constraints in section E.5.2.16 SystemOfUnits are not consistent with the definition in the XMI.

Sync section 5.2.16 with XMI

The XMI is based on the QUDV model, which is the single source of truth. Therefore, the documentation of the operations and constraints in section 5.2.16 must be updated to be in sync with the XMI. This will be achieved thanks to the document generator.

The title of the section is:

15.4.1 Behavior Allocation of Actions to Parts and Activities to Blocks

There is in fact no allocation of an Activity to a Block, there is an allocation of an Activity6 to a Part7.

From p. 177:

Specific behavior allocation of Actions to Parts are depicted in Figure 15-4.

But the diagram includes an allocation from an Activity6 to a Part7 (that it is a part is confirmed by the «part» keyword in the allocatedTo callout).

The allocation to Activity6 comes from a nested part ..

The allocation is from the Activity6 to a part ...

The use of part names 'Part5', 'Part7' with Capitals is confusing. It is much clearer to have property names that are lowerCase. If they must have names with Capitals then the Blocks that type them should be shown (see attached image).

The use of the part name 'Block1' as the allocation target for Action1 is beyond confusing when there is a block Block1 in the same diagram.

ASIDE: I wish the RTF diagram contributors would adopt a policy across the entire specfication of using lowerCamelCase (no spaces) for all block properties and UpperPascalCase (no spaces) for all Blocks

The diagram figure is low resolution and needs to be replaced.

The following may be in part MagicDraw/Cameo 19SP3 tool issues:

• The path callout in the Note for the allocatedTo on Activity6 in the tool is '«part» Block4::Block7::part7'; the spec has '«part» Block4.Part5.Part7'

• The tool could not (as far as I can tell) display the qualified name corresponding to Part:Block1 for the header in a swimlane

Behavior Allocation

Correct the text in following way:

Specific behavior allocation+s+ of Actions to Parts and Activities to Blocks are depicted in Figure 15-4.

The allocation to Activity6 from action1 comes from goes to a nested part, and uses the attributes of DirectedRelationshipPropertyPath to specify the path of properties to reach that part. The sourceContext targetContext of the allocation is Block4 Block 0 and the sourcePropertyPath targetPropertyPath is (Part5) part1. Note that the AllocateActivityPartition, if used in this manner, is unambiguously associated with behavior allocation.

Replace the diagram with this one:

This diagram can be found in the specification model in the teamwork cloud under Element ID
mdel://_19_0_4_58401de_1632821659221_739603_774

Figure E.8 depicts instance specifications with a slot "name". None of the classifiers of the instance specification define the appropriate structural feature for the slot.

Remove invalid slots or replace them with another one

The types of the instance specifications in figure E-8 and E-9 have no property "name". It seems that the author mixed it up with the name of the instance specification.

An exception are the instance specifications SI and ISQ in figure E-8. The name slot should be replaced by "description" which is a property of SystemOfUnits and SystemOfQuantities.

The constraint SystemOfUnits::systemOfQuantitiesIncludesAllUnitsQuantityKinds is specified in the QUDV.xmi, but not mentioned in the PDF in section E.5.2.16.

Specify constraint SystemOfUnits::systemOfQuantitiesIncludesAllUnitsQuantityKinds in section E.5.2.16

It seems that the description of the constraint systemOfQuantitiesIncludesAllUnitsQuantityKinds has been overseen in section E.5.2.16 and should be added in the constraint subsection.

Figure E.11 should be a package diagram rather than a class diagram.

The URI's are old. Update them to SysML 1.6:

https://www.omg.org/spec/SysML/20181001/SysML
https://www.omg.org/spec/SysML/20181001/QUDV.xmi
https://www.omg.org/spec/SysML/20181001/ISO80000.xmi

Update figure E.11

The diagram depicts a package diagrams. Therefore, the header should be "pkg" according to UML 2.5.1, annex A.

The change of the URI's is an editorial fix. They will be updated to the appropriate URI's for SysML v1.7 as part of the specification generation process.

In section E.5.2.16, the constraint [1] specifies the body condition of operation isCoherent() and constraint [2] the body condition of operation isCoherent(du).

So, the specifications should be moved to the operation section and not be listed in the constraint section.

QUDV::SystemOfUnits: Move body conditions from constraint to operation section

The body conditions constraint [1] and constraint [2] for isCoherent() and isCoherent(du:DerivedUnit) should be moved to the operation section after the constraint section.

The operation SystemOfUnits::accessibleQuantityKinds() specified in section E.5.2.16 is not mentioned in the QUDV.xmi and is identical with the operation of same name in SystemOfQuantities in the previous section E.5.2.15.

Remove accessibleQuantityKinds() from SystemOfUnits

It seems that the documentation of SystemOfUnits::accessibleQuantityKinds() was added by accident to the description in section E.5.2.16. It is a copy of the operation in section E.5.2.15.

SimpleQuantityKind::dependsOnQuantityKinds() redefines the operation QuantityKind::dependsOnQuantityKinds(), but the redefinition is neither specified in the PDF nor in the QUDV.xmi.

SimpleQuantityKind::dependsOnQuantityKinds() redefines QuantityKind::dependsOnQuantityKinds()

The redefinition of the inherited operation dependsOnQuantityKinds() should be specified.

The operation SystemOfUnits::getUnit() in the QUDV.xmi in not mentioned in section E.5.2.16.

QUDV: Add documentation of SystemOfUnits::getUnit()

Add the documentation of SystemOfUnits::getUnit() specified in the QUDV.xmi in section E.5.2.16

The constant numbers in figure E.19 are not consistent with the ISO-80000.xmi

Update figure E.19

The elements depicted in figure E.19 are not part of the ISO-80000.xmi model anymore. The figure should be updated to depict the current content of the model.

Considering the purpose of the sample problem, it shall be adjusted so that it reflects a nominal usage of SysML. Usage of obsolete concept/stereotypes shall be replaced without further justification.
This includes, for instance, the replacement of "UML standard port"/Interfaces by proxy ports/InterfaceBlocks.

Hence, and even if we will try to keep the sample problem as close as possible to its previous version, some figures of even some parts of it will change, as appropriate with regard to the illustration objective.

The goal of this issue is to get a global RTF agreement on this.

Agree on this update principle

Per this resolution, and as requested by the issue, we allow the subgroup in charge of the Annex D "Sample problem" to apply changes on it in order to keep it in synchronization with the SysML specification it is part of and in order to make sure it provides an appropriate illustration of a common usage of it.

Changes related to this concerns will be gathered in a single resolution to a specific issue about "keeping the sample model up-to-date" so that the RTF will still be asked for a global approval of them.

There is no clear statement saying how the expression that specifies the constraint is managed, even if we can imagine that the intent was to use the ownedRule for that purpose it's not formally stated.

Assuming ownedRule is used, it's not specified either how to deal with ConstraintBlocks that would have more than one ownedRule (since the current specification only consider "one" constraint only)

Merge with SYSML17-252

The resolution to issue SYSML17-252 implies resolving this one first. For that reason its is convenient to merge them and to provide a common resolution that is specified as a resolution proposal for SYSML17-252

The return parameters of the operations in annex 5.2 have the parameter direction "in" in the QUDV.xmi, but should have parameter direction kind "return".

Set parameter direction kind of return parameters to "return"

The specification PDF is correct, but not the QUDV.xmi.

The properties notation depicted in figure 8-1 is not correct. If the type is not shown, also the ':' is not shown according to the property notation BNF given in the UML specification in section 9.5.4:

<property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

’]

Figure 8-1: Updated property notation

If a property is depicted without a type, the ':' is not shown. The property syntax is defined in section 9.5.4 of the UML 2.5.1 specification:

<property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

’]

The QUDV model contains a constraint "invertible: isInvertible=true" for LinearConversionUnit, but is not mentioned in the specification document. I propose to add it to the description in section E.5.2.7.

Add constraint description to LinearConversionUnit

The constraint forces that the inherited property isInvertible is set to true. It is part of the QUDV.xmi, but not described in the specification document.

The QUDV model contains a constraint "invertible: isInvertible=true" for AffineConversionUnit, but is not mentioned in the specification document. I propose to add it to the description in section E.5.2.1.

Add constraint description to AffineConversionUnit

The constraint forces that the inherited property isInvertible is set to true. It is part of the QUDV.xmi, but not described in the specification document.

In appendix B, the description stereotype SysMLStructureDiagram in figure B.3 is missing in section B.2.

Added description for SysMLStructureDiagram

The description of the abstract stereotype SysMLStructureDiagram is missing and should be added.

Figures 11-13 and 11-14 are identical. According to the text figure 11-4 should show an example block definition diagram for object node types, but not object node types are in the diagram.

SYSML17-297 Resolution

Replace graphic

The figure 9-5 is identical with 9-4. It should be the attached figure.

Resolution: Replace with figure 9-5

Figure 9-5 is identical to figure 9-4.

The QUDV blocks DerivedUnit, ConversionBasedUnit, and SimpleUnit define each a dependsOnUnits() operation which should be a redefinition of the inherited Unit::dependsOnUnits() operation.

The redefinition is neither specified in PDF nor in the QUDV.xmi.

Redefine dependsOnUnits() operation

The QUDV blocks DerivedUnit, ConversionBasedUnit, and SimpleUnit define each a dependsOnUnits() operation and inherit the Unit::dependsOnUnits() operation. The definition of the redefinition is missing in the PDF and the QUDV.xmi.

Section 17.2 contains a subsection 17.2.1.1, but no subsection 17.2.1.

Section 17.2.1.1 as well as 17.2.2.1, 17.2.2.2, and 17.2.2.3 cover content from UML and does not add SysML specific information.

*Rearrangement of sections in chapter 17 *

The sections mentioned in the issue description repeat content from the UML specification. It is sufficient to repeat the notation in the diagram table. Therefore, the sections 17.2.1.1, 17.2.2.1 - 17.2.2.3 should be deleted.

The section 17.2.1 is missing. It got lost after SysML 1.4, and should be added again.

Section C.3.2.3 Semantic Variation Points should not be a section with its own numbering. It is just a headline like "Description" in section C.3.2.2.

The FlowPort was a stereotype of SysML 1.2. In the SysML 1.2 specification document, the section "Semantic Variation Point" was also only a unnumbered headline of the section about FlowPort.

Remove section numbering C.3.2.3

It seems that the numbering was introduced by accident in SysML v1.3 and should be removed.

In figure 13-1, the upper left state machine has two adjunct properties of the same name.

I propose to simply rename the properties to "submachine state name1" and "submachine state name2".

Rename identical adjunct properties

It is allowed to have two states with the same name, but not two adjunct properties. The adjunct property "submachine state name" must be renamed.

In figure 12-1, the upper left interaction has two adjunct properties of the same name.

I propose to simply rename the properties to "interaction use name1" and "interaction use name2".

Rename identical adjunct properties

It is not allowed to have two adjunct properties of the same name owned by a namespace.

The second constraint of the SysMLBehaviorDiagram is a copy of the second constraint of SysMLActivityDiagram.

Remove second constraint of SysMLBehaviorDiagram

Resolve the copy&paste error by removing the second constraint of SysMLBehaviorDiagram.

In the QUDV.xmi, the multiplicity of Prefix::symbol is 1 while the specification in section 5.2.8 defines a 0..1 multiplicity.

Fix multiplicity of Prefix::symbol in XMI

The multiplicity of Prefix::symbol in the XMI should be set to 0..1 as specified in the PDF.

Description mentions SysMLBlockDefinitionDiagram stereotype extends UMLPackageDiagram whereas it extends UMLClassDiagram according to Figure B.3 page 219.

Proposal: SysMLBlockDefinitionDiagram extends UMLClassDiagram

The SysML Diagram Interchange stereotype SysMLBlockDefinitionDiagram extends UMLClassDiagram (see figure B.3). Section B2.3 incorrectly states that SysMLBlockDefinitionDiagram extends UMLPackageDiagram.

The row ActorPart in table 8.3 should depict SysML::Blocks::PartProperty typed by UML4SysML::Actor, but it shows an Actor.

Resolution: Show properties typed by Actor in ActorPart row of table 8.3

The row ActorPart in table 8.3 shows Actor elements instead of properties typed by an Actor.

SYSML17-286 asks for removing the row ActorPart from the table.

Figure 9-5 (Item Flow Stereotype) is the same as Figure 9-4 (Provided and Required Features).

Proposal: Replace figure 9.5

The figure 9.5 is by accident identical with figure 9.4 and must be replaced.

The body condition of the Allocate::getAllocatedFrom()
getAllocatedFrom = Allocate.allInstances()->select(to = ref).from
should be
getAllocatedFrom = Allocate.allInstances()->select(supplier = ref).client

to and from are no stereotype or metaclass properties. The appropriate properties are client and supplier defined in the metaclass "Dependency".

Accordingly change the Allocate::getAllocatedTo() body condition as well as the name "getAllocatedFrom" to "getAllocatedTo":

getAllocatedTo = Allocate.allInstances()->select(supplier = ref).client.

Resolved: Error in operation body conditions of getAllocatedFrom() and getAllocatedTo()

The body condition of the Allocate::getAllocatedFrom() and Allocate::getAllocatedTo() operations are not correct. Fix them as proposed in the issue description.

According to chapter 4.1 of the SysML 1.6 specification document, RaiseExceptionAction is part of SysML, but the ExceptionHandler is not part of UML4SysML.

It makes sense to have a complete exception mechanism in SysML, for example, to model exceptional conditions like the violation of a constraint.

Throwing an exception is not restricted to software, but a useful logical concept of modeling flow behaviors. For instance, it is also included in BPMN.

Resolution: Add UML::ExceptionHandler to SysML

The UML::ExceptionHandler element is missing in SysML and must be added to UML4SysML.

The Stakeholder constraint 1_not_association is listed twice in the specification document and the XMI.

One constraint is named "1_not_association" the other one "not_association".

Remove the "not_association" constraint.

Proposal: Stakeholder constraint is listed twice

Remove the duplicated constraint "not_association".

At the end of section 4.2 is an unresolved reference:

"UnitAndQuantityKind, see Erreur : source de la référence non trouvée"

Replace it with

UnitAndQuantityKind, see 8.3.3.2

Proposal: Bad reference in section 4.2

Add the correct reference to the bullet point.

VerdictKind appears in a constraint on TestCase and in Table 4.3 (SysML stereotypes, blocks, valuetypes, and datatypes), but isn't defined in the spec. I should be in a model library, like ControlValueKind (see 11.3.3.1 Package ControlValues).

*Resolution: Add enumeration VerdictKind *

The enumeration VerdictKind is missing in the specification document. It used in the constraints of the TestCase and it is part of the SysML.xmi.

The second constraint of the stereotype AllocateActivityPartition references a section in the UML specification:

"To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic."

Subclause 12.3.10 does not exist. It is probably 15.6.3.1 in UML 2.5.1.

I propose to remove the subclause reference number.

AllocateActivityPartition: Reference to UML specification

The subclause number references an older version of the UML specification. It is hard to manage those links between separate specifications. Therefore, we follow the proposal of the issue author to remove the absolute reference.

Clause 16.1 (Requirements, Overview, search on "verdict") refers to "A verdict property of a test case", but verdicts are return parameters, which aren't properties (unless this means an adjunct).

Resolution: Describe verdict as return parameter

The verdict is not a property, but a return parameter of a test case. See 16.3.2.6 for the definition of a test case.

Would it be possible to create a special member in the RTF with no voting right (i.e. "assistant") , whose has the sysml-rtf@omg.org for email address?

By adding it to the "watch this issue" list it would then become possible to notify the whole RTF automatically.

Not a SysML issue

This is a JIRA feature request that was wrongly reported as a SysML issue. It is replaced by SUP-498