Issues for OMG SysML Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 9763: Page 16
Issue 9771: Section 16.4.2
Issue 9779: Section 16.3.1.1
Issue 10020: Section: Blocks - BOM properties
Issue 10033: Section: Ports and Flows - Behavioral flow ports
Issue 10042: Section: Requirements - Figure 16.1
Issue 10057: SysML: Use Cases
Issue 10060: SysML: Missing arrow on figure 16.8
Issue 10073: SysML:Architecture
Issue 10097: Table 14.1 Use Case Diagram
Issue 10098: constraints on viewpoint, 7.3.2.5
Issue 10343: Section: 16.3.2.4 RequirementRelated (from Requirements)
Issue 10374: Section: Appendix B.4.5
Issue 10380: Section: Annex G
Issue 10427: Section: 7.3.2.5 Viewpoint
Issue 10446: SysML: nout-->inout
Issue 10471: Section: 9, 16, C
Issue 10473: Chapter 8, Blocks, instance specifications for default values
Issue 10501: Section: 11 Actibities
Issue 10502: Section: 11 Activities
Issue 10509: Section: 17.4.2
Issue 10510: Section: Annex A
Issue 10511: Section: figure 17.6
Issue 10517: Figure 17.4.2
Issue 10524: Constraint parameter stereotype
Issue 10538: 7.1 Overview
Issue 10539: 15.2.1Representing Allocation on Diagrams
Issue 10540: Section 16.3.2.3
Issue 10587: SysML doesn't explicitly support the modeling of alternative models
Issue 10602: Section: Appendix B
Issue 10641: Section: 11.3.2.2
Issue 11066: Namespace compartment for blocks
Issue 11091: Section: Chapter 7-17
Issue 11118: Section: 11.3.1.1
Issue 11267: Section: 11.3.2.2 ControlOperator
Issue 11269: Section: 16 Requirements
Issue 11270: Section: 8.3.2.8 ValueType
Issue 11271: Section: 16 Requirements
Issue 11274: Section: Annex A: Diagrams
Issue 11275: Section: 8.3.2 Unit/Dimension Notation
Issue 11308: Question on PropertySpecificType
Issue 11490: Requirements are abstract
Issue 11491: <<satisfy>> is displayed as dependency (in examples)
Issue 11492: Uppercase/lowercase problems
Issue 11494: Association branching is not defined in UML
Issue 11497: Mixed action and activity concepts
Issue 11500: View as Package extension is very bad idea
Issue 11501: Wrong ends of Allocate relationship used in Allocated definition
Issue 11502: PropertySpecificType concept is highly ineffective and suboptimal
Issue 11523: optional parameter section
Issue 11591: 8.3.1.3 UML Diagram Elements not Included in SysML Block Definition Diagram
Issue 11599: SysML -- Fix for Fig 9.4 p70.
Issue 11600: SysML dimensions
Issue 11612: SysML specification for containment relationship
Issue 11622: Section: 8/3
Issue 11626: Section: Appendix E
Issue 11629: Section: 5.1
Issue 11650: Section: 9.4
Issue 11651: Section: 9.3.2.
Issue 11652: Section: 16.3.2.7
Issue 11654: Section: 11.4
Issue 11655: Section: 8.3.2.2
Issue 11656: Section: 16.2.1
Issue 11691: Rate stereotype attribute
Issue 11814: Section 7.1
Issue 11819: Section: 8.3.1.2 Internal Block Diagram Extensions
Issue 11823: Stakeholder and Concern
Issue 11895: Chapter Blocks/Section 8.3.2.6
Issue 11961: Section: 9.3.2
Issue 12124: Allocation Callout to Item Flow is Ambiguous
Issue 12126: 8 Blocks, 8.3.1.2 Internal Block Diagram, 8.3.2.2 Block
Issue 12127: 8.3.1.2 Internal Block Diagram
Issue 12128: 08 Blocks, 8.3.2.9 Unit, 8.3.2.10 ValueType
Issue 12129: 10.3.2.2 ConstraintProperty
Issue 12133: 11 Activities, 11.2.1 Activity Diagram
Issue 12134: 11.Activities/11.3.2.8 Rate/Figure 11.8
Issue 12135: 11 Activities, Figure 11.10
Issue 12136: 11.Activities, Figure11.10
Issue 12137: 11 Activities, Figure 11.10
Issue 12138: 11. Activities
Issue 12139: 15.3.2.3 AllocateActivityPartition
Issue 12140: Annex B/B.4.1.2 Package Diagram
Issue 12141: Annex B, B.4.4.3 Requirement Diagram
Issue 12142: Annex B / B.4.5.4 Block Definition Diagram
Issue 12143: Annex B / B.4.8.3 Activity Diagram
Issue 12148: Annex B / Figure B.36
Issue 12149: Annex B / Figure B36
Issue 12150: Annex B / Figure B.36
Issue 12151: Annex B / Figure B36
Issue 12153: Annex / Figure B.37
Issue 12155: Annex B, Figure B.18, Figure B.19
Issue 12157: Section: 8.3.2.1
Issue 12159: 10.Constraint, Figure 10.3
Issue 12163: Suggest permit UML2.1.1 Component for use as parasitic element wrapper Comp
Issue 12219: Section: 08 Blocks: suggest need Quantity stereotype and definition
Issue 12239: Section: Chapter 7: Viewpoint
Issue 12253: Section: annex A.1, Activities
Issue 12254: Section: Chapter 2: UML version
Issue 12256: Icons for FlowPort
Issue 12257: remove homemade stereotypes
Issue 12258: moe should be removed from section 7.4 or added to the standard
Issue 12270: SysML unnecessarily restricts aggregation of datatypes
Issue 12277: SysML needs instance specs
Issue 12361: 08.Blocks: compartment for property-specific defaultValue should be renamed
Issue 12363: 08. Blocks: The 'values' compartment for a part Property in an IBD
Issue 12364: DistributedProperty
Issue 12377: NestedConnectorEnd multiplicity typo in Fig 8.5
Issue 12560: Section: 11.3.1.1 Activity in bdd
Issue 12576: 11.4 Activity Usage Sample: ControlOperator has regular pins
Issue 13155: Section: 11.3.1.1, 11.3.1.4, 11.4
Issue 13156: Section: 4.2, 11.2.1
Issue 13157: Section: 11.3.2 Inability to name interruptible activity regions
Issue 13190: Ambigous line crossings
Issue 13262: Use cases in SysML are more similar to Requiremetns than Behavioral diagrams
Issue 13328: Lack of Structured Activity Node and other Activity features Discussion
Issue 13345: Merge UML DataType into SysML ValueType
Issue 13465: "trigger[guard]\activity" should be "trigger[guard]/activity"
Issue 13503: Fig. 11.10: Pin of ControlOperator
Issue 13666: Participant Property constraint #6 not correct.
Issue 13667: Connector Property value text.
Issue 13854: Chapter 7.3.1.1 Update comment stereotype diagram extension
Issue 13924: Using composite association between activities
Issue 13945: Notation for multiple item flows
Issue 13976: Example figures in chapters are redundant with Annex B sample problem
Issue 14032: The information in Annex D regarding AP233 needs to be updated
Issue 14033: Representing multiple item flows on the same connector
Issue 14041: SysML Issue based on UML Issue 10044: Profile Structure Diagrams are missing from Annex A
Issue 14042: SysML issue based on UML Issue 11160: Namespace URI for Standard Profile(s)
Issue 14043: SysML Issues based on UML 13080 New proposal for conjugate types for port
Issue 14056: UML4SysML: Architecture & Compliance with UML subset
Issue 14085: Overly restrictive statement regarding ports in blocks chapter

Issue 9763: Page 16 (sysml-rtf)

"This section is very difficult to understand, in particular for non-OMG
people. Please add a clarifying paragraph here.
"

Unable to resolve. Left for RTF to decide.
Disposition:	Deferred

Redraw visio to improve look. FTF Issue - General issue of style of uniform diagrams

. 

Discussion:
Diagrams are fairly uniform in the chapter. Issue is deferred for the next major release of the spec.
Disposition:	Deferred

Add more precision to table spec in terms of what rows, columns mean (refer to SP spec). Also, enlarge table elements so they are readable.

Unable to be addressed in time.
Disposition:	Deferred

BOM properties. In Blocks, BlockProperty, 8.3.2.2, Description, third paragraph, seems to be trying to address the request for bill of material properties. If so, these are properties whose values are all the objects in the composite of a given type. They are derived from all the other block properties of that type. Eg, all the resistors needed to assemble an circuit board. 

Discussion:
It was felt that there is a need for experience in SysML prior to making such a change or extension. Deferred for future consideration.
.
Disposition:	Deferred

Behavioral flow ports. In Ports and Flows, FlowPort 9.3.2.5, Description, the fourth and sixth paragraph seem to give contradictory defintions of behavioral flow ports. The second refers to the UML isBehavior semantics. The fourth refers to "relaying" to properties or parameters, but doesn't explain what that means. If the two paragraphs are referring to the same thing, then presumably a block behavior is a classifier behavior, and since that behavior executes while the block instance exists, relaying to the parameters requires those parameter to be streaming, in the sense of CompleteActivities. The semantics of relaying properties is unrelated to UML behavior ports. 

Clarify the meaning of isBehavioral to indicate if the item is relayed to the owning block or to on of its parts over an internal connector.
Add a constraint that states that isBehavioral must be set to True if the port is not connected to an internal connector

In Requirements, Figure 16.1, Requirement has properties with Requirement as type. But instances of stereotypes are not property values. Perhaps this is supported in UML as part of stereotypes with associations to stereotypes. If not, the type should be UML4SysML::Class, with the constraint that the values of the properties are stereotyped by Requirement. 

Discussion:
Unable to be addressed in time
Disposition:	Deferred

The text in 14.1 should briefly discuss that for System Engineers, run-time optionality is not the typical distinction for indentifying extensions. If we wanted to draw a flow chart, we would use an activity diagram.

 

It is usually more relevant to identify as extensions those use cases that not are needed to reach the goal of the base use case. This allows the System Engineers to use the dependency graph among the use cases to help determine production/test/delivery order. 


This also makes it clear to the reviewer which features are considered optional and which are not. At the SE level, this is more important that than flagging those features that sometimes invoked and sometimes not invoked. 

 

Please clarify with this use at the SE level

Discussion:
Unable to be addressed in time
Disposition:	Deferred    This issue was previously deferred by the FTF with the following discussion comment:
Unable to be addressed in time.
No additional resolution was reached by the current RTF.
Disposition:	Deferred 

On figure 16.8 there should be up-arrow pointing to the Accelerate state from the decision node

Unable to be addressed in time.
Disposition:	Deferred

For an SE to specify an Architecture, it is often necessary to specify reusable architectural patterns.  SysML as currently formed does not appear to support the reusable definition of architecture tied to particular systems. It may be necessary to include some of UML 2.1 Template and Collaboration packages to support this capability.

 

A full resolution of this issue is beyond the scope of an RTF. The issue is being deferred, however, so that additional explanatory material could be considered in a future RTF to clarify the scope of modeling supported by SysML or to suggest possible workarounds.  A full resolution of this issue could be considered in an RFP for SysML 2.0.
Disposition:	Deferred

In Table 14.1 Use Case Diagram, the abstract syntax reference for the Subject notation is given as “Role name on Qualifier”.  This does not appear correct

In the constraints on viewpoint, 7.3.2.5, the plural form of the prosperities is used. I believe they should be in the singular. 

Constraints

…

[2]The property ownedOperations must be empty.



[3]The property ownedAttributes must be empty.

…

The names of tracedTo and tracedFrom appear counter-intuitive. On a <<requirement>> (p144)... /tracedTo: NamedElement[*] Derived from all elements that are the client of a <<trace>> relationship for which this requirement is a supplier. On a <<requirementRelated>> (p145)... \tracedFrom: Requirement[*] Derived from all requirements that are the supplier of a <<trace>> relationship for which this element is a client. If a trace dependency ends at a requirement therefore, it would be listed on the <<requirement>> with the property name 'tracedTo'. It is thought that most users wouldexpect this property to be called 'tracedFrom' instead. Should we swap the names of these properties around to avoid this confusion? 

Unable to be addressed in time.
Disposition:	Deferred

The CAN_Bus shown in the ibd B.22 is missing in figure B.18.

Unable to be addressed in time.
Disposition:	Deferred

Update Annex G to accurately specify the graphical and textual notations supported by the current SysML specification. Currently, an editorial note at the top of Annex G notes that the Annex contents are to be updated for specific diagram types during the finalization phase of the specification. Resolve the diagram types for which BNF syntax productions will be provided, and make sure that these match the notations documented in the corresponding SysML chapters.

Discussion:
Completion and detailed verification of Annex G exceeds the scope of work that is feasible during the SysML FTF.  Because the scope of SysML is defined by its concrete syntax, a more formal version of concrete syntax definition should be considered for future versions of the SysML specification.
Disposition:	Deferred

Viewpoint.Purpose[1] should probably be Purpose[*] to be consistent with the other attributes of Viewpoint. Perhaps [1..*] if needs to be mandatory. 

The viewpoint element can specify more than one stakeholder (multiplicity *). Each of the stakeholder has it's own concerns (multiplicity *). However the view has only one purpose that covers all concerns of all stakeholders.
Disposition:	Closed, no change

In SysML 9.3.2.4, the possible flow directions include 

 

nout

 

 

based on later usage, this is incorrect for

 

            inout.

This misspelling was already fixed in the 1.0 Available Specification.
Disposition:	Closed, no change

Inconsistent use of "sub-type" and "subtype". UML2 and SysML spec in general use subtype, there are a few instances of "sub-type" in the SysML spec (chapters 9, 16, and C), should be replaced with subtype.

The exclusion of UML concrete syntax for Instance Specifications has resulted in the inability to assign default values to properties of blocks using anything other than simple text strings for value properties. Consider reintroducing UML concrete syntax for UML InstanceSpecification into one or more SysML diagram types so that more complex default values can be assigned.

Discussion:
The defaultValue compartment on an internal block diagram does provide at least one available option for assigning default values to structured values, as discussed in the subsection "Default value compartment" under 8.3.1.3 Internal Block Diagram. Creating a graphical compartment on an internal block diagram to assign values to properties defined on a block definition diagram may be more cumbersome than a textual syntax, but tools may be able to streamline the  linkage to the default value  for usability. In particular, the use of a "structure" compartment on a block definition would allow the default value to be shown next to a properties compartment where a property is defined.
Other work in OMG is currently underway that may define a standardized form of textual syntax for value specifications.  SysML could consider such a textual syntax for property values in future versions.
Disposition:	Deferred

Brake is spelled Break twice on this page, once in the paragraph between the figures and once in figure 11.141

This is fixed in the current version of the specification.
Disposition:	Closed No Change

Several places in the spec, it is indicated that behaviors can be shown on block and class diagrams. As SysML does not support class diagrams, it should be changed to block diagrams only. See text on 11.1.1.1; 11.3.1.1(3x);11.3.1.4

In the explanation for Fig 17.4.2, the Block stereotype is described as having no properties. While the diagram does not show any properties, the block stereotype has an "isEncapsulated" property, described elsewhere in the specification (p. 46) This is very confusing. The text should be corrected to indicate that the property isEncapsulated of the Block Stereotype is inherited by the stereotype system and concept

In Annex A, the bdd is indicated that it can only be for blocks, pkgs, and constraint blocks. [A previous issue was raised that this list should include activities]. This list is incomplete; it should probably include all SysML-allowed stereotypes (and extensions) of class (perhaps classifier), including signal, actor, interface, etc. Even if such elements are not allowed to be model elements _for_ the diagram, they should be explicitly allowed as elements on a bdd. Similarly the allowed elements for and on an ibd should be clarified.

Unable to be addressed in time.
Disposition:	Deferred

It is unclear in this diagram what the element that this bdd is for (a package?) However, the elements on this diagram are metaclass and stereotype elements, which I believe are the wrong metalevel for bdd diagrams. This is really a notional metaclass diagram indicating how SysML might be extended, but it is not a SysML diagram itself

In Figure 17.4.2’s explanation, the Block stereotype is described as having no properties. While the diagram does not show any properties, the block stereotype has an “isEncapsulated” property (defined elsewhere in the spec). 

 

This is very confusing. The text should be corrected to indicate that all properties of the Block stereotype (e.g., “isEncapsultated), even if not indicated on the diagram, would be inherited by the stereotypes «system» and «context»  An alternative fix that also corrected the diagram would perhaps be better but more effort.

Can anybody clarify the definition of a constraint parameter for me?


To quote the SysML spec:
[1]The type of a constraint property must be a constraint block.


So a constraint parameter is not a constraint property typed by a value type or something like that...


To quote again:


"A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block define the parameters of the constraint."


So does this mean that a parameter is a block property (or an ordinary property)?  


Would it make sense to add a <<constraint parameter>> stereotype to constraint blocks? Has this been suggested or does it make sense?

The constraint referenced was quoted from the SysML Final Adopted Specification (ptc/06-05-04).  The FTF replaced this constraint by two new constraints by two new ones that clarify that the stereotype must be applied to properties of a SysML Block that are typed by a ConstraintBlock.
Because the ConstraintProperty must be applied to any property typed by a ConstraintBlock, it could be removed with no loss of information, or additional stereotypes could be defined for other cases, such as a constraint parameter. No additions or changes to the property stereotypes are being proposed in this version of SysML.
Disposition:	Closed, no change

As previously mentioned in our 2004 review; a rationale must be considered as a class, that has its own lifecycle and its own access rights.
It is not only a simple UML comment extension.

Additional requirements would need to be established to before defining Rationale as more than just the stereotype of Comment currently defined in SysML.  Such requirements and proposals to satisfy them could be considered in future revisions of SysML.
Disposition:	Deferred

Allocation arrows direction seems to be  opposite to UML dependency rules. We do ne think it is a good idea ?

Unable to be addressed in time.
Disposition:	Deferred

We do not agree with a systematic propagation rule of sub-requirements when copying requirements. That introduces useless constraints in contractual contexts that have their own rules.

Unable to be addressed in time.
Disposition:	Deferred

SysML doesn't explicitly support the modeling of alternative models for example for trade studies as requested by the UML for Systems Engineering RFP. Models and Packages are not useful, because they don't allow to exclude elements. For example to specify a xor between requirements (if reqA is used, then don't use req B). Same for blocks and other model elements. 

A full resolution of this issue is beyond the scope of an RTF. The issue is being deferred, however, so that additional explanatory material could be considered in a future RTF to clarify the scope of modeling supported by SysML or to suggest possible workarounds.  A full resolution of this issue could be considered in an RFP for SysML 2.0.
Disposition:	Deferred

Figure B.16, B.18, and B.26 do not use white diamond notation for referenced properties. Please update these figures to use white diamond

Unable to be addressed in time.
Disposition:	Deferred

What happens if a control value disables an action within an activitz and no other actions are active and no more tokens are present?

The execution of the activity is complete.
Disposition:	Closed, no change

We build the structure of a system on the block definition level by composition
and not by namespace containment. We also use this approach in the sample problem.
Therefore I would like to use a block compartment to show a bdd of all owned elements
by composition and not by namespace containment. I don't know any good example where to 
use the namespace compartment or the namespace containment relationship. 


Should we change the namespace compartment to a owned element compartment?
Do you know good examples when to namespace containment vs. composition?


By the way the concrete syntax of the namespace containment in the sysml spec isn't 
defined in the uml specification

The namespace compartment is reserved for nested classifiers owned by a SysML Block, which is represented in the UML metamodel by elements contained in the "nestedClassifier" attribute of UML Class.  It can be used to define local classes which are referenced only in a local context.  Moreover, UML defines such nested classifiers as redefinable within an inheritance context, though specifics of how this would be done or shown on a diagram do not seem to be fully specified.
The issue is correct that the SysML specification does not currently contain any examples of such local namespace classifiers.  Adding such examples could be considered in future revisions of SysML, but the main request of this issue is to define a compartment to contain blocks owned by composition.  UML itself is relatively loose in its specification of classifier compartments and many details of concrete syntax, but some of its developers have shown such namespace compartments in their examples.  The closest prescription UML makes is in "Presentation Options" under 7.3.7 Class, "Additional compartments may be supplied to show other details, such as constraints, or to divide features." SysML makes the definition of this compartment explicit, to remove any ambiguity for the depiction of nested classifiers such as local blocks.
It would be good to establish usage examples for namespace compartments on a  Block, either within the SysML spec itself or within tutorial materials developed outside the spec.  Specific proposals for such examples could be raised as future issues.
This issue, however, requests a new block compartment to replace the namespace compartment currently in SysML.  SysML already provides the UML black diamond notation to show composition associations between blocks on a block definition diagram, which can include details such as multiplicities and ordering of the end roles carried by the composition. Internal block diagrams provide another means by which to show blocks owned by composition roles, which SysML defines as "parts."  While the issue is correct that more motivation could be provided for the namespace compartment already included in SysML, the specific request for a new kind of compartment for blocks on a bdd is beyond the scope of appropriate for an RTF.  It could be considered for an RFP for SysML 2.0, after more experience is gained with existing compartments to determine which ones might be added or dropped.
Disposition:	Closed, no change

Add clarification and precision to the specification by replacing the natural language constraints with OCL constraints. This is a general issue that applies to constraints on stereotypes within Chapters 7-17 of the specification. It is appropriate to address this on a priority basis to selected constraints that are ambigous due to their natural language representation, and where OCL can reduce their ambiguity.

Considerable work has been completed to draft initial OCL versions of constraints currently stated in the SysML spec by means of natural language statements. The RTF has agreed that both natural language and OCL forms of constraints should be included in future versions of the specification. Additional review will be needed before the current draft OCL constraints will be ready to be included in the specification.
Disposition:	Deferred

Using black-diamond composition for functional decomposion is confusing and misleading since the owner Activity does not contain other activity in the sense that they have the same life span and obvuisly since different CallVehavior are used to invoke the activities, these activites may actually be carries out one after the other. We propose that either another relationship is used to signify functional decomposition or a hierarchy of Activity Diagrams should be used.

The semantics of black diamond applies to CallBehaviorActions.  The semantics of black diamond is deletion of an instance of the class on the diamond end deletes instances of the class on the other end, when they are linked by the composite association (the life span semantics was removed in an early version of UML).  The instances of UML behaviors are executions of the behaviors.  When an activity execution starts another behavior execution through CallBehaviorAction, deleting the calling execution (terminating it) deletes the called executions (terminating them).  This is described in Section 11.1.4.
Disposition:	Closed, no change

What happens if a control value from a control operator stops the following action and there are no more tokens left and no actions are active? Does this terminates the execution of the activity? What if the control value suspends the action? Who can resume the action? There are no more tokens and running actions.

Yes, the execution of the activity is complete.  There is no control value defined in SysML for suspending and resuming actions.
Disposition:	Closed, no change

It is not explicitly mentioned that SysML changes the notation for the satisfy relationship. It is a stereotyped realization relationship and should be notated as a dashed line with a triangular arrowhead. But SysML uses a simple arrowhead.

The types of the attributes dimension and unit must be Dimension and Unit instead of ValueType according to Fig 8.4.

The nesting of requirements has the semantics that the upper requirement is fulfilled if all it's sub-requirements are fulfilled. In addition we need a mechanism to express a xor between sub-requirements sets to support variant modeling. If a requirement can be satisfied by different system components, these system components have different technically requirements. These requirements are sub-requirements, but a subset of them that relates to one of the system components is sufficient to fulfill the upper requirement. It is not necessary to fulfill all sub-requirements

Unable to be addressed in time.
Disposition:	Deferred

The list of diagram kinds and abbreviations should contain the non-normative table and matrix diagram kinds

I miss a explicit statement that SysML changes the standard notation for instance specifications. According to that the name of dimensions and units must be underlined

Can anybody elaborate on the following definition of PropertySpecificType : “The PropertySpecificType stereotype is automatically applied to a classifier created by the notation for a property-specific type for a property belonging to a SysML Block or ValueType. It identifies these classifiers so that they may be managed along with the property that they type.”

 

It is quite obscure to me to understand its meaning?

Disposition:	See Issue 11622  for resolution

Requirements are abstract (isAbstract must be true). However name of the requirement are not displayed in italic as defined in UML notation

<<satisfy>> is displayed as dependency (in examples), however it is extension of Realization (closed arrow notation shall be used) 

Uppercase/lowercase problems. Stereotype names are defined in upper case, but in diagrams are displayed in lower case (e.g. Block and <<block>>). Attributes(tags) are displayed in uppercase in diagrams, but are defined in lower case in the specification. 

Association branching is not defined in UML. Mapping is not clear. Composition tree is not defined in UML, mapping is not clear. 

The UML Superstructure specification, in the last paragraph under 7.3.3 Association, subsection "Presentation Options," states:
If there are two or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends into a single segment. Any adornments on that single segment apply to all of the aggregation ends.
SysML merely adopts this existing notation variant from UML.  Each separate branch is represented in the metamodel by a separate association, as in UML.  Branching is only supported for associations with composite or shared aggregation, which is consistent with the notations shown in the SysML Diagram Elements tables.
Disposition:	Closed, no change

Mixed action and activity concepts. B.35, B.36, B.37 - concepts of activity and action are mixed (action is allocated, but activity is in tabular notation)

Unable to be addressed in time.
Disposition:	Deferred

View as Package extension is very bad idea. Package is used for ownership, so it is not possible to show the same elements in different packages (as different point of view) 

The view is not the owner of the elements that are shown in the context of the view. As stated in constraint [1] the view is only allowed to own element import, package import, comments, and constraints. 
Disposition:	Closed, no change

Wrong ends of Allocate relationship used in Allocated definition. /allocatedTo is set of clients, but client is source of dependency (so "from"), /allocatedFrom is set of suppliers, but supplier is target of dependency (so "to")

PropertySpecificType concept is highly ineffective and suboptimal. It requires to redefine all structure from very root context if some deep nested part should use different configuration. So one should redefine all car internal structures if one bolt should be changed or color should be different

See the resolution for Issue 10473, Instance Specifications for Default Values, for a definition of an initialValues compartment on an internal block diagram and a corresponding metamodel to represent values within these compartments.  This compartment and metamodel now provide an alternative to property-specific types when all that is required is to specify context-specific values.  For example, if just the size of a bolt or the value of a color is changed, it is no longer necessary to redefine all the internal structures of a car.
With the definition of new capabilities for context-specific values, use of the property-specfic type mechanism can be reserved for cases in which new or redefined features are defined on a classifier which types a local property. Preserving this additional capability for cases in which additional or redefined features are of interest in a local context was agreed in meetings and discussions of the RTF to be worth preserving in SysML.
Issues 11308, "Question on PropertySpecificType" and 11622, "Mapping of PropertySpecificType to the UML metamodel," request further clarification of the metamodel used to represent a property-specific type.  Their resolution is consolidated under issue 11622. The resolution for Issue 11895, "Section 8.3.2.6: questions about PropertySpecificType" includes answers to the specific questions raised by that issue.
Disposition:	Closed, no change

Is it allowed to attach the optional stereotype to outgoing parameters? The definition mentions only ingoing parameters: "This means the parameter is not required to have a value for the activity or any behavior to begin execution." 

"An “X” on a single end of an association to indicate that an end is “not navigable” has similarly been dropped, as has the use of a small filled dot at the end of an association to indicate an owned end of an association."

 

In this text I see two mistakes:

1. "filled dot" notation is used for ends owned by associated classifier, not owned by association (an opposite situation).

2. "owned end of an association" does not mean it is not navigable. Association has "navigableOwnedEnds" property for navigable owned ends.

On Fig 9.4 p 70. the I_ICEData I/F has the following services defined on the cntrl (the engine)

 

getRPM():Integer 

getTemperature():Real 

isKnockSensor():Boolean

 

These names make sense if the interface was a provided interface on the engine. 

However, the I_ICEData interface on the engine is a REQUIRED interface.

 

The interface should be defined something more along the lines of…

 

hereIsRPM(:Integer)

hereIsTemperature(:Real)

hereIsKnockSensor(:Boolean)

 

as the engine is using this interface to tell the PowerControlUnit the current values of those properties.

 

This problem is duplicated later in Figure B.20 on p 194

This is a naming convention argument and there is no absolute right and wrong on this. The get* may make more sense than hereIs* since it means that the owner of the block requiring the services can call get* to get the values, while hereIs* is not a  common naming convention. Since this is just an example anybody can choose any naming convention they like. No specific naming convention is dictated by SysML.
Disposition:	Closed, no change

Inconsistency among valuetype/unit/dimension

 

In Figure 8.4 p 43, the following multiplicities are given

 

A valutype may (0..1) have a unit and may have a (0..1) dimension

A unit may (0..1) have a dimension.

 

On page 49. there is a constraint

 

Constraints

[1]If a value is present for the unit attribute, the dimension attribute must be equal to the dimension property of the referenced unit.

 

This would mean that if the unit’s dimension is null, then the valutype’s dimension must also be null. This seems overly constraining.

 

In 8.4.2, it says

Because a unit already identifies the type of quantity, or dimension, that the unit measures, a value type only needs to identify the unit to identify the dimension as well.

 

This statement seems to say the unit must have a dimension, and the valuetype’s dimension can be null even though the unit’s is not. This statement therefore disagrees with the Figure 8.4 and the constraint on page 49

This issue is being deferred as part of the same overall discussion and consideration noted under the resolution for Issue 12128, "8.3.2.9 Unit, 8.3.2.10 ValueType."  As noted there, the scope of any potential changes to the current ValueType, Unit, and Dimension metamodel has ended up beyond the workload that could be completed during this RTF. Relaxing the current constraints, as well as extensions or changes to the current model, should continue to be evaluated for future versions of SysML.  In the meantime, a workaround could be to define new units if necessary to carry different dimensions.
The statement in Section 8.4.2 is in a usage example for the definition of value types with SI units.  It is not intended to imply that a unit must have a dimension, just that if a unit does already identify a dimension, the dimension need not also be specified.  This language could be further clarified if needed in future updates of the specification.
Disposition:	Deferred

this about the interpretation of the the containment 
relationship and its
implementation on the tool side.

We are using MagicDraw 14.0 and SysML 1.1sp2.
 
As soon as a containment relationship is created between two
requirements the
contained requirement is automatically relocated to the package
of the container. This prevents distribution of requirements 
in different
packages, in particular if a contained requirement belongs to 
a subsystem.
I would like to properly distribute them.

We have a requirement A which contains requirement B and C.
A is a requirement on very high level of the system which is decomposed into
requirements B and C on a subsystem level.
To avoid to have all requirements together (because B and C 
belong to the
subsystems) we want to put A, B and C in different packages 
but still have
the containment relationship (as foreseen by the SysML spec.)
that's why I think it is different from a package containment. They
 are not the same. 

This issue points out that containment works precisely as designed with respect to requirements.  Containment for requirements should be no different than containment for packages.  The subsystem package can contain a copy of the original requirement.  This is the primary reason the copy relationship was added to SysML.
Disposition:	Closed, no change

Mapping of PropertySpecificType to the UML metamodel requires further explanation Chapter 8 introduces the notion of property-specific type to assign values to parts inside an ibd. Section 8.3.1.1 defines a notation for property-specific types. Section 8.3.2.8 provides a definition of the <<propertySpecificType>> stereotype and gives elements on how this concept maps to the UML metamodel. However, this section does not explicitly define: 1) where are stored the actual values? One may understand that a default value of a property owned by a class, which is stereotyped as <<propertySpecificType>>, is considered as a property-specific value. This property-specific value may be considered as an instance of a property owned by the refrenced block. It is not clearly stated though. 2) how does a property-specific type relate to the referenced block ? In other words, if a class is stereotyped as <<propertySpecificType>>, which feature of this class points to the referenced block? We may need to add a paragraph in section 8.3.2.8 that provides answers to questions.

The following text cites two OMG documents: "The OMG SysML requirements traceability matrix traces this specification to the original source requirements in the UML for Systems Engineering RFP (ad/2003-03-41). The traceability matrix is included by reference in a separate document (ptc/2007-03-09)." Someone unfamiliar with the OMG process has no way of knowing how to obtain these two documents. They should be cited by URL; e.g., http://doc.omg.org/ptc/2007-03-09 

Replace horrific long UML URL with short form: http://doc.omg.org/formal/2007-02-03

The outline indenture for the Atomic Flow Ports (9.4.1.1) and non Atomic Flow Ports (9.4.1.2)usage examples is incorrect. They should be 9.4.2 and 9.4.3 respectively.

In 9.3.2.7, the Standard Port is listed as a stereotype, yet it is not shown as an extension in Figure 9.1. The Standard Port should either be included in Figure 9.1 as a stereotype or removed from the list of stereotypes in 9.3.2.7. Since the only change is a change of name, I propose leaving it in as a stereotype, but clarifying that the only extension is a name change.

The verify relationship currently constraints one of its ends to be a test case. There have been several cases where this is too restrictive. In particular, sometimes it is useful to verify a requirement via analysis and leverage parametrics. In this case, it one may want to verify the reuqirement using a constraint block, block, or constraint property. The proposal is to delete the constraint that a requirement can only be verified with a test case which reads as follows: [2]The client must be an element stereotyped by «testCase» or one of the «testCase» subtypes. In addition, the description should be changed as follows: From: A Verify relationship is a dependency between a requirement and a test case that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) test case to the (supplier) requirement. To: A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) to the (supplier) requirement. There were two changes to the above description text. add 'or other model element', delete 'test case'

There is reference to timelines in 11.1.5. This is widely considered a critical capability for SysML, but there is not example in the spec. Add a usage example of an activity diagram with timing constraints and the corresponding timing diagram as referred to in 11.1.5.

A block stereotype should be applied to any subclass of a block. Add a constraint to the block stereotype in 8.3.2.2 to reflect this.

The callout notation used in the Diagram Elements tables in 16.2.1 of the Requirements Chapter (pg 144-146)is inconsistent with the callout noation in the Diagram Elements tables in 15.2.1 of the Allocation chapter (pg 130). The text in the callout in Requirements starts with a capital letter and the text in the callout in Allocations starts with lower case. Make them consistent.

Disposition:	See issue 11492 for disposition

Figure 11.8, page 98, defines a "rate" stereotype attribute typed as InstanceSpecification.
In section 11.3.2.8, page 101, one can read "The rate stereotype has a rate property of type ValueSpecification".
There seems to be an inconsistency here.


I assume the relevant type for the "rate" stereotype attribute is ValueSpecification. Please can you confirm?

Disposition:	See issue 12134 for disposition

The current paragraph describes comments as follows: "Comments can be associated with any model element and are quite useful as an informal means of documenting the model. The comment is not included in the model repository." If comments and their extensions (e.g., rationale, problem, etc) are not stored in the model repository, then they would not be retrievable when the model is next opened. This would make filling them out a waste of time. Please determine what is meant here and correct it. 

Please provide a notation variant that allows to show block stereotypes at property elements typed by those blocks in an ibd. Similar to the notation variant that CallBehaviorActions can show the stereotypes of the called Behavior element. For example a common approach is to define stereotypes for discipline specific elements like <<hardware>>, <<software>>, <<mechanic>>, and so on. It is important to see the information in a bdd and ibd. It is circumstantial and superfluous to define two stereotypes for blocks and properties. 

Stakeholder and Concern should be first class elements.
This is needed for UPDM modelers, that will likely will be reusing SysML View/Viewpoint structure.

Alignment with UPDM is premature, since UPDM has not completed finalization. This issue should be considered in the context of broader requirements for reuse of SysML Viewpoint. The initial version of SysML relies on informal documentation strings to define a viewpoint.  Any greater formalization of viewpoint should consider whether other supporting elements beyond just Stakeholder should also be promoted to first-class status.
Disposition:	Deferred

I am trying to support PropertySpecificType in our SysML Toolkit and I hit some road block while trying to implement the same. I have had some discussion with Sandy last week regarding the same but I quiet don’t get how this can be supported without some additional constructs to the PropertySpecificType stereotype. Below are the lists of questions I have: When a default value is provided for the property type, then a type derived from the original type should be created and its default value should be set as the new deafult value of the property. The property type should be displayed in square brackets which would indicated that the type is a specialized type. There can be more than one specialization of the same class, in such case there is no construct to store which specialization is associated with which property? This additional construct is very much needed because there is no way to know whether the specialization is created by SysML for PropertySpecificType or whether it is created by user? What happens in case of multi-level hierarchy? (If Class2 inherits Class1, and property1 is typed by Class2 & the default value at property1 is changed the resultant propertyspecifictype is Class3. Should the tool show property1:[Class2] or property1:[Class1]). Why is the PropertySpecificType extends UML2::Classifier and not UML2:Type? PropertySpecificType was introduced to provide specific default values to properties in Internal Block Diagram. Why not use the InstanceSpecification from UML2? Below Diagram shows how this is supported in UML2. 

In response to Question 1, a property-specific type results in a new classifier which specializes whatever classifier was referenced as the starting classifier of the property-specific type. At most one classifier can be specified as the starting classifier of a property-specific type.  While this classifier may itself specialize multiple other classifiers, the property-specific type specializes only the single classifier referenced by the property-specific type. In the example, if Class2 was referenced as the starting type (the name specified within square brackets) than that is the only classifier which the property-specific type specializes directly, regardless of any other classes such Class1 that Class2 may inherit from.
In response to Question 2, property-specific types are allowed only on properties of a SysML Block.  A block property may be typed only by a SysML Block, SysML ValueType, or UML DataType.  All of these are UML classifiers.  In the UML metamodel, Type is an abstract metaclass, and Classifier is its primary concrete metaclass.
In response to Question 3, one of the original purposes of PropertySpecificType was not to provide specific default values of properties, but also to permit local specialized types with customized features in a local usage context.  See the resolution for Issue 10473 for the definition of an initialValues compartment, including a metamodel representation based on UML InstanceValue and ValueSpecification, for a solution which can provide context-specific values for properties without property-specific types, as suggested.
Disposition:	Closed, no change

in Figure 9.1 Port Stereotypes,the Flow Specification that extends UML4SysML::Property should be a Flow Property and not a Flow Specification.

An allocation callout, when anchored to an Item Flow on an Internal Block Diagram, is unclear. If the Item Flow has an Item Property, then the allocation could be to the Item Flow itself, the Item Property, or the Item Property type (Conveyed Classifier). Recommendation: develop a compact graphical notation to distinguish the target of the allocation when a callout is used with any graphical depiction of an Item Flow.

There are at least 4 kinds of properties of blocks: parts, references, values, constraints Constraint properties do not take part in the assembly hierarchy of blocks. Although they are of type Block via ConstraintBlock and have AggregationKind 'composite' they should not be considered "parts". SysML1.0, 8 Blocks: 'A block can include properties to specify its values, parts, and references to other blocks.' Rewrite to include constraint properties: 'A block can include properties to specify its values, parts, references to other blocks, and constraint properties.' SysML1.0, 8.3.1.2 Internal Block Diagram, Property types: 'Three general categories of properties are recognized in SysML: parts, references, and value properties' Rewrite to include constraint properties: 'Four general categories of properties are recognized in SysML: parts, references, value properties, and constraint properties.' SysML1.0, 8.3.2.2 Block, Description: 'SysML establishes three standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classifed as a part property. A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a UML DataType or SysML ValueType is classified as a value property. Part, reference, and value properties may be shown in block definition compartments with the labels “parts,” “references,” and “values” respectively. Properties of any type may be shown in a “properties” compartment.' Rewrite to include constraint properties: 'SysML establishes four standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classified as a part property (excluding constraint properties, which are typed by a Constraint Block). A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a UML DataType or SysML ValueType is classified as a value property. Part, reference, value properties, and constraint properties, may be shown in block definition compartments with the labels “parts,” “references,” “values”, and "constraints" respectively. Properties of any type may be shown in a “properties” compartment.' Note also minor spelling correction: classifed -> classified. 

.3.1.2 Internal Block Diagram: p.40: assert that value properties must be owned with AggregationKind 'composite' This would be consistent with the following from 8.3.1.2 Internal Block Diagram, Property types: ".. A part or value property is always shown on an internal block diagram with a solid-outline box. A reference property is shown by a dashed-outline box, consistent with UML .." Rewrite to include assertion that value properties must always be owned with AggregationKind 'composite': ".. A part or value property has AggregationKind 'composite' and is always shown on an internal block diagram with a solid-outline box. A reference property has AggregationKind 'none' or 'shared' and is shown by a dashed-outline box, consistent with UML .." (Please note also that this case also illustrates why it would be useful to have a clear stereotypes like ValueProperty throughout the SysML specification, as it affords a canonical point of documentation for such assertions and constraints.)

Disposition:	See issue 12126 for disposition

Suggest Unit and ValueType both extend abstract DimensionedType, and inherit a 'dimension' attribute This strategy provides a compact and elegant metamodel for units and values, and expresses well the underlying physical and mathematical principles of a dimensioned quantity represented by a value subject to chosen units. Value properties can then be sensibly typed by either a Unit or a ValueType. In the case where a ValueType has a Unit, the constraint still applies that the dimension of the ValueType must be the same as the dimension of the Unit. See also analysis image and commentary at: http://school.nomagicasia.com/node/126 

they can be fully typed with units of measure and related concepts has occurred within the RTF. A variety of authoritative sources and comparison with practice by other communities including the related OMG MARTE profile have also contributed much to the discussion.
The scope of any potential new model, however, has ended up beyond the workload that could be completed during this RTF.  While much of the discussion has indicated a need for refinement or elaboration beyond the current Unit and DImension model of SysML, these initial elements of SysML 1.0 do provide an initial capability for SysML models. Issues 12128 and 12219 are both being deferred so that they can continue to be considered for future revisions of SysML.
Disposition:	Deferred

10.3.2.2 ConstraintProperty: add constraint that the AggregationKind must be 'composite' Add a constraint: [3] A property to which the ConstraintProperty stereotype is applied must have AggregationKind 'composite'

Table 11.1 and Table 11.2: appear to contradict constraint that <<discrete>> and <<continuous>> should not be both applied SysML 1.0, 11.3.2.3 Discrete: '[1] The «discrete» and «continuous» stereotypes cannot be applied to the same element at the same time.' However Table11.1 and Table 11.2 Rate examples appear to show both «discrete» and «continuous» applied to the same element at the same time, and Table 11.1 appears to show overloaded tagged values {rate=constant} and {rate=distribution}. Resolution: change Table11.1 and Table 11.2 to show dedicated examples of «discrete» and «continuous» stereotype usage. 

The tables show all the notations at once on the element they apply to, for example, one shows "rate = constant" and "rate = distribution" on the same object node.  The tables would get very large if all the cases were shown separately.
Disposition:	Closed, no change

The «rate» stereotype has a property 'rate' of type ValueSpecification 11.3.2.8 Rate yet InstanceSpecification in Figure 11.8 SysML1.0, 11.3.2.8 Rate: 'The «rate» stereotype has a rate property of type ValueSpecification.' However Figure 11.8 shows 'rate' with type InstanceSpecification. (Also, the 'rate' property should be clearly defined as an Attribute of <<rate>> in 11.3.2.8 Rate.) 

Figure 11.10: Suggest Actions better shown as clearly typed anonymous ClassBehaviorActions (rather than capital names and no type shown). See improved example at: http://school.nomagicasia.com/node/107 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png 

It is typical to show just the name of the behavior being called, because the distinction between action name and called behavior is more the advanced user.
Disposition:	Closed, no change

Figure11.10 suggest use anonymous, typed Pins for clear indication of flowing information type and to support {stream} Parameter t is difficult and/or inconsistent to show the {stream} indication of the Action ':Driving' without an output Pin corresponding to an underlying output Parameter of Behavior 'Driving' satisfying the 'isStream=true' condition. Indeed Table 11.1 - Graphical nodes included in activity diagrams shows only Actions with Pins and the {stream} indicator for UML4SysML::Parameter.isStream The following image shows Figure 11.10 adapted to use Pins throughout (except for ControlValue input to the controller Action 'Monitor Traction'): http://school.nomagicasia.com/node/108 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png NB: this issue submissions is marked as 'significant' because the I consider it extremely important that the SysML effort advertises the clear advantages of Pins whereever possible to the benefit of tool vendors and end users.

Eliding pins is a UML presentation option, see UML specification, Object Flow, Presentation Option.  Showing this option would make the graphical tables unnecessarily large.
Disposition:	Closed, no change

Figure 11.10 Suggest use output Pin from <<controlOperator>> 'Enable On Brake Pressure > 0' typed by ControlValue The <<controlOperator>> action ':Enable on Brake Pressure > 0' does not show an output Pin corresponding to an output Parameter of type ControlValue that must exist for the Behavior Enable on Brake Pressure > 0. From SysML1.0: '11.3.2.2 ControlOperator ,, Constraints [1] When the «controlOperator» stereotype is applied, the behavior or operation must have at least one parameter typed by ControlValue. If the stereotype is not applied, the behavior or operation may not have any parameter typed by ControlValue.' It would make sense (and be clearer) if the «controlOperator» had an output Pin typed by ControlValue. Below we see the diagram adapted to use an output Pin typed by ControlValue: http://school.nomagicasia.com/node/109 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png

I suggest general policy for SysML: prefer Pins over ObjectNodes in all possible cases Use of ObjectNodes is problematic for many reasons, including: - In UML2.1.1 ObjectNode is abstract ! Tool vendors are thus forced to choose an arbitrary concrete placeholder (like <<CentralBufferNode>>, which is invalid). Use of Pins avoid this problem. - ObjectNodes are graphically less stable than Pins, as on has to manage the placement of ObjectNodes between Actions and two paths. - It is easier to trace type compatibility of connections between between Pins representing typed Parameters than across two paths via an ObjectNode with no binding to Parameters. - The placement of ObjectNodes on swimlanes boundaries (like in Figure B.35) is contrived and graphically unstable. Experience has shown that Pins are far easier to read, verify, and manage, and they correspond well to the idioms of signal processing known to engineers. I recommend that they be used in ALL SysML diagrams wherever possible, and that this be adopted as SysML policy, to the advantage of systems engineers, educators, and tool vendors alike.

The object node notation is captured at M1 as instances of InputPin and OutputPin, rather than sObject Node.  The disadvantages of the object node notation should be compared to its advantages, for example, being more compact.  SysML should not demote the object node notation. 
Disposition:	Closed, no change

15.3.2.3 AllocateActivityPartition(from Allocations): /supplier (from) /client (to) wrong way round >From SysML1.0 15.3.2.3 AllocateActivityPartition(from Allocations): 'An Action appearing in an «AllocateActivityPartition» will be the /supplier (from) end of an «allocate» dependency. The element that represents the «AllocateActivityPartition» will be the /client (to) end of the same «allocate» dependency.' Should read: 'An Action appearing in an «AllocateActivityPartition» will be the /supplier (to) end of an «allocate» dependency. The element that represents the «AllocateActivityPartition» will be the /client (from) end of the same «allocate» dependency.' Note that a similar mixup was reported for 15.3.2.2 Allocated(from Allocations): 'Issue 11501: Wrong ends of Allocate relationship used in Allocated definition (sysml-rtf) Wrong ends of Allocate relationship used in Allocated definition. /allocatedTo is set of clients, but client is source of dependency (so "from"), /allocatedFrom is set of suppliers, but supplier is target of dependency (so "to")' 

B.4.1.2 Package Diagram: <<access>> should be <<import>> SysML1.0: 'B.4.1.2 Package Diagram - Showing Package Structure of the Model .. The relationship between the views (OperationalView and PerformanceView) and the rest of the user model are explicitly expressed using the «access» relationship.' In fact Figure B.3 shows <<import>> relationships.

SysML1.0, p.188: 'B.4.4.3 Requirement Diagram - Acceleration Requirement Relationships Figure B.13 focuses on the Acceleration requirement, and relates it to other requirements and model elements. The “refineReqt” relation, introduced in Figure B.12, ..' Should read '"refine" relation'. 

B.4.5.4 Block Definition Diagram: Should say 'white diamond (shared AggregationKind)' not 'white diamond (composition)' SysML1.0: 'B.4.5.4 Block Definition Diagram - Power Subsystem .. Note how the of white diamond (composition) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.' The choice of the word 'composition' in combination with the white diamond is unfortunate, as it implies 'composite' AggregationKind. Rewrite to say 'white diamond (shared AggregationKind)' rather than 'white diamond (composition)': 'Note how the of white diamond (shared AggregationKind) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.' 

B.4.8.3 Activity Diagram (EFFBD): refers incorrectly to objectFlows in BDD Figure B.34 SysML1.0: 'B.4.8.3 Activity Diagram (EFFBD) - Acceleration (detail) Figure B.35 shows the ProvidePower activity, using the decomposed activities and objectFlows from Figure B.34' In fact Figure B.34 is a BDD, so it can't show 'objectFlows'. It shows the Blocks that type the ObjectFlows. 

Figure B.36 emg:ElectricalMotorGenerator should be allocated from a4:ProvideElectricPower not ConvertElectricToPower Figure B.36 shows 'emg:ElectricalMotorGenerator' allocated from <<activity>> ConvertElectricToPower Figure B.35 shows Action 'a4:ProvideElectricPower' allocated to '<<block>> ElectricalMotorGenerator'. The table in Figure B.37 shows 'a4:ProvideElectricPower' (incorrectly typed as an Activity) allocated to '<<block>> ElectricalMotorGenerator'. For consistency Figure B.36 should show 'emg:ElectricalMotorGenerator' allocated from Action 'a4:ProvideElectricPower'.

Figure B.36: shows allocations to part Properties, not to Blocks as in Figure B.35 Figure B.35 shows allocations of actions to swimlanes representing blocks. Figure B.36 shows allocations of activities to part properties. Figure B.35 should probably shows allocations of actions to part properties. Figure B.36 should probably show the same allocations of actions to part properties. 

Figure B36: ecu:PowerControlUnit should be allocated from ProportionPower, not ProportionPowerLoad Figure B36 shows 'ecu:PowerControlUnit' allocated from '<<activity>> ProportionPowerLoad'. Figure B.35 shows Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'. Figure B.37 table shows 'a1:ProportionPower ' allocated to part Property 'ecu:PowerControlUnit'. For consistency Figure B.36 should show Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'. 

Figure B36: ice:InternalCombustionEngine should be allocated from ProvideGasPower, not ConvertGasToPower Figure B36 shows 'ice:InternalCombustionEngine' allocated from '<<activity>> ConvertGasToPower'. Figure B35 shows Action 'a2:ProvideGasPower' allocated to '<<block>> InternalCombustionEngine'. The table in Figure B37 shows Action 'a2:ProvideGasPower' (incorrectly typed as an Activity) allocated to '<<block>> InternalCombustionEngine'. For consistency Figure B36 should show 'ice:InternalCombustionEngine' allocated from Action 'a2:ProvideGasPower'. 

Figure B.37: the elements allocated from are of type Action, not Activity In table Figure B.37 allocations are made from the following Actions (activity usages): a1:ProportionPower a2:ProvideGasPower a3:ControlElectricPower a4:ProvideElectricPower The 1st column shows them incorrectly as of type Activity. NB: this issue relates to and/or duplicates: Issue 11497: Mixed action and activity concepts (sysml-rtf) 

The composing owner of FrontWheel is never made clear It is clear from Figure B.18 - Defining Structure of Power Subsystem (Block Definition Diagram) and Figure B.19 - Internal Structure of the Power Subsystem (Internal Block Diagram) that ChassisSubsystem.FrontWheel is shared by PowerSubsystem, and that FrontWheel is a specialisation of WheelHubAssembly.. However nowhere is it made clear which block is the composing owner of FrontWheel (although we may guess that it is ChassisSubsystem). The polymorphic substitution of FrontWheel for WheelHubAssembly is never explained.

Clarify that a binding connector can have nested connector ends like a regular connector. In particular, clarify that a binding connector can bind to parameters of a nested constraint property, without having to bind to an intermediate parameter of the outer constraint property. A binding connector can clearly bind to a nested value property using the dot notation or directly to a value property nested within parts.

In Figure 10.3: 'delta-t' is shown with solid-line (AggregationKind 'composite'), is should be shown with a dashed line (AggregationKind 'none') to be consistent with Figure B.26 BDD for EconomyContext.

Suggest permit UML2.1.1 Component for use as parasitic element wrapper Component, for nested <<requirement>>s, and for <<view>>s There are at least three applications of the UML2 Component which I consider very beneficial to practical UML-based systems engineering: 1st: I make extremely heavy use of the technique of stereotyped <<composition>>, <<inhertance>>, <<specialisation>> "wrapper" Components to graphically and logically organise model elements in BDDs (and in class diagrams) "parastically", i.e. without stealing ownership of the contained elements. Especially the <<composition>> wrapper Component is very powerful for diagramming and organising hierarchical assemblies of complex systems. In such cases the wrapping Component has Realizations to the wrapped elements, which can be further leveraged to trace the logical groupings. The recipe is consistent with the UML2.1.1 superstructure (although it is not supported in all UML tools). I contend the wrapper Component strategy should be made officially available to those SysML users who wish to use it (at least as a permitted option). 2nd:If one permits the UML2.1.1 Component the SysML <<requirement>> stereotype can be applied to Components so that Requirements can be graphically nested, which is far more graphically stable than just diagramming Class <<requirement>> Dependencies, and can be consistently applied in combination with the existing relationship stereotypes between SysML requirements. 3rd: Components are far better suited to creating orthogonal, parasitic <<views>> of packaged elements than the Package or Model, which both steal ownership. 

 stereotype for a Quantity is required. The current Unit, Value, Dimension system in SysML is incomplete without the crucial concept of Quantity. A physical or industrial Quantity is independent of a choice of unit and value as measured or stated. A Quantity has a Dimension, which can be fundamental (as in the SI system), or derived (according to industrial needs). A Quantity DOES NOT have a Unit, and it DOES NOT have a relationship to a given unit systems, although it may be allocated a default unit within a given system. The statement/measurement of a Quantity is given as a value relative to a chosen Unit. A Quantity is represented in SysML by a value property (typed currently by a ValueType, although a strong case can be made for typing by a value property directly by a Unit).

Much useful discussion about underlying concepts of system quantities and how they can be fully typed with units of measure and related concepts has occurred within the RTF. A variety of authoritative sources and comparison with practice by other communities including the related OMG MARTE profile have also contributed much to the discussion.
The scope of any potential new model, however, has ended up beyond the workload that could be completed during this RTF.  While much of the discussion has indicated a need for refinement or elaboration beyond the current Unit and DImension model of SysML, these initial elements of SysML 1.0 do provide an initial capability for SysML models. Issues 12128 and 12219 are both being deferred so that they can continue to be considered for future revisions of SysML.
Disposition:	Deferred

The viewpoint should use a Behavior element to describe the construction of the view instead of methods and languages. Concrete behaviors could be SysML elements like Activity or Interaction. Or construction rules specified in any language using a OpaqueBehavior element

A Behavior element to formalize the elements in a view would apply the behavior in a metamodeling role unrelated to its use to express behavior in a user model.  It would also require establishing a whole new set of metaclass behaviors not currently defined in UML.  This level of formalization on methods and languages should be considered within the wider set of UML modeling specifications, not uniquely by SysML.
Disposition:	Closed, no change

Designating a Diagram Frame with a the name of a Stereotyped Model Element Type: Annex A (Diagrams) is not explicit on how to designate a diagram frame with a model element type that has a stereotype applied. If, for example, a diagram is intended to represent a package which has been stereotyped as a model library, one would expect the diagram header to reflect the model library as the designated model element type. The naming of diagram header is defined beginning on pg 173 in Annex A.1, and does not clarify this. The proposed resolution is to allow the name of the stereotype or the name of the base class to be used as the name of the model element type in the diagram header. For the previous example, the name of the model element type could either be [package] or [model library]. 

OMG SysML 1.0 is an extension of UML 2.1.1. The next version OMG SysML 1.1 should be an extension of UML 2.2 to avoid a gap between these two closely related standards. According to UML 2.2 SysML should support OMG XMI 2.2 instead of XMI 2.1.

I would suggest changing the icons you have chosen for FlowPort. Hence, in the following picture extracted from the spec., ac and dc are understood respectively as input and output flow port.

 



 

But, if I move dc on left hand side of the rectangle denoted Transformer, ac on the right, dc becomes an input and ac becomes an output. I suggest you to adopt the ones defined within MARTE (see following picture).

 



 

Having the arrows point out or in is definitely solvable by tools and there is no technical difficulty. The notation was accepted during SysML submission and was implemented by the tools.  There is no reason to change it as the tools definitely can handle maintaining the correct direction when moving the port.
Disposition:	Closed, no change

Don't the authors find it embarrassing that their solution to a sample problem isn't even compliant with their own specification? In section B.4.2.1, its states "The «system» and «external» stereotypes are user defined, not specified in SysML,...". I don't care what excuse the authors come up with, "user defined" stereotypes should not be used. The concept of "user defined" or just "making up" stereotypes is inconsistent with the concept of profiles. By standard, «system» and «external» must be in a profile since they are not standard UML keywords nor stereotypes. The authors need to remove homemade stereotypes from their example or add them to the profile. The removal of the homemade stereotypes will likely prove the current specification inadequate.

User-defined stereotypes are fully supported in SysML. Chapter 17 includes the UML-based mechanisms for users to define their own profiles. These profiles can define further stereotypes of the metaclasses and stereotypes already defined by  SysML. Profiles allow the general-purpose elements of SysML to be further customized to support specific classes of modeling needs. Examples of such user stereotypes are included in SysML usage examples to illustrate various ways such user extensions can be applied.  Reusable stereotypes can also be established for sharing across or within organizations.  Annex C of the SysML specification gives examples of stereotypes which are not defined as part of the SysML language itself, but which can help meet such shared modeling needs.
Disposition:	Closed, no change

Section 7.4, part of the standard, utilizes the <<moe>> stereotype. <<moe>> is not part of the standard. Annex C, where <<moe>> is defined, states "This annex describes useful non-normative extensions to SysML that may be considered for standardization in future versions of the language." The standard should not be infected with non-standardized stereotypes. <<moe>> should be removed from section 7.4 or added to the standard.

Disposition:	See issue 12257 for disposition

The 6th constraint on blocks is written as follows:

[6] If the aggregation attribute of a property owned by a SysML block is equal to “composite” or “shared,” then the type of the property must be a block

This constraint, as written, limits the use of solid or hollow diamond aggregation relationships from a block to "own" only other blocks. 

1) This is not what the original intent was. Apparently it was to prevent the use of aggregation relationships from a block to own dataTypes or valueTypes.
    As written, it is overly restrictive for its intent

2) Even the intent is overly restrictive. UML modelers have (for years) modeled the relationship between a class and its attributes as an aggregation relationship.True, software developers have occasionally used the distinction between composite/shared  as implementation clues which are unimportant to SysML concerns. However, even though the SysML distinction between an association, aggregation, or composition relationship to a property is irrelevant, the variation of notation allows modelers to use the style they are most familiar with. In addition, for models that move from SysML to UML and back, it allows the preservation of the software hints. It also leverages existing training and educational material on models.

I recommend dropping this constraint completely. At the most, add a sentence in the description section explaining that using the composite/shared relationship to properties has no implementation meaning. 

See proposed resolution for Issue 12126 for a replacement of this constraint as a result of cleanup of SysML property classifications.
The original intent of the constraint was to disallow value properties from having composite or shared aggregation.  The new constraint states this intent much more directly, but also changes the constraint on a value property to require composite aggregation, so that the solid-square-box notation of a value property on an internal block diagram is consistent with its aggregation.
Because SysML is in some respects a significantly different language than UML, preservation of software hints for models that move from to SysML to UML and back is not likely to be fully successful without further model mapping support. Definition of mappings from SysML to UML, beyond the subset of UML which SysML reuses directly, is not currently addressed by SysML.
Disposition:	Closed, no change

SysML needs instance specs capabilities for several reasons

1) compatibility with UML and many users' expectations
2) ability to do animation
3) ability to show particular values at a time
4) educational value / illustration value

No need for a new diagram type, instances can appear on block and sequence diagrams.

Much discussion occurred within the RTF on the possible roles of instance specifications and/or additional value compartments to show property values within blocks as they evolve during the lifetime of a system. As noted, such display could be useful for animation of a system, or to show particular valid states of blocks and all their properties.  Another issue, 12353, suggests additional forms of property compartments as another mechanism to display such values.  Both issues are being deferred and could be considered separately or together for future updates of SysML.
For the current RTF, the scope of support for property-specific values considered useful as a feasible scope and important initial step is better support for the "defaultValue" compartment as addressed in the resolution for Issue 10473.  This resolution renames the compartment to "initialValues" and specifies a metamodel that does not require use of property-specific types.
Disposition:	Deferred

As discussed at the OMG TM SysML RTF on Th 13Mar2008. The 'defaultValue' compartment should be renamed 'initialValue' (or perhaps 'initialValues'). The static (class level) default values of a given Block's properties may be overridden on instantiation and initialization of a part Property usage of that Block by the using context. The concept of "initial values" is more consistent with the programmatic practice, and it serves to highlight the difference between the UML2 defaultValue (of a Property within a class) and the (re)initialisation of a SysML value Property on usage of its Block as a part Property within a higher context, by assignment of a property-specific initial value. The label 'initial values' is also consistent with the UML2.1.1 specification description of the role of the defaultValue attribute of 7.2.44 Property: "If there is a default specified for a property, this default is evaluated when an instance of the property is created in the absence of a specific setting for the property or a constraint in the model that requires the property to have a specific value. The evaluated default then becomes the initial value (or values) of the property." Further, the concept of "initial values" emphasises the evolving value state of a system. The "initial value" is then merely a single value slice within a series of values states. Configuration is a special case of "initial value". Example: when a Car leaves a factory it is "initialised" to a luxury, sports, or family configuration. The concept of "initial value" compartment is complemented by the suggestion of a "current values" or simply "values" compartment for recording the value state of an evolving system. (See related issues submitted by Darren Kelly.) This suggestion promotes support of animation of SysML systems, and also encompasses aspects of static configuration consistently. 

Disposition:	See issue 10473 for disposition

There should be a definition of the role of the 'values' compartment for display of "current values" (for representing the entire value state of a system within a unique value context) and/or "deep configuration" values indepedendent of the PropertySpecificType concept, which may be seen as only one possible way of carrying values for assignment to the 'values' compartment in and IBD. Another strategy employing values in Slots of InstanceSpecifications that are related to targeted part Properties by a Property[*] path and then mapped to the targeted part Properties would achieve the same 'values' idiom in and IBD without indication of the implied subtype using [brackets]. When the 'values' are carried by redefined defaultValue : ValueSpecification[0.1] of redefined properties of an implied [PropertySpecificType] the bracket notation should still be used (inviting also indication of other redefinitions that can't be achieved using mapping of InstanceSpecifications, such as operation and constraint redefinitions). In particular, the following paragraph from p.53 (illustrated in Figure 8.11 - SUV EPA Fuel Economy Test) should be rewritten to admit other solutions: "In SysML, one approach is to capture system configurations by creating a context for a configuration in the form of a context block. The context block may capture a unique identity for the configuration, and utilizes parts and part-specific types to express property design values within the specification of a particular system configuration. Such a context block may contain a set of parts that represent the block instances in this system configuration, each containing specific values for each property. This technique also provides for configurations that reflect hierarchical system structures, where nested parts or other properties are assigned design values using property-specific types. The following example illustrates the approach.": While Figure 8.11 - SUV EPA Fuel Economy Test could remain with [PropertySpecificType] notation as an indication of that strategy, there should be an equivalent figure showing the same 'values' compartment and a similar top-level value context block, however without the [brackets] notation on part types, and without any reference to the PropertySpecificType solution. The title of Figure 8.11 should be clearly marked to indicated use of the PropertySpecificType solution and notation. Visit also: http://school.nomagic.com/node/331

Disposition:	See issue 10473 for disposition

On p.46 under 8.3.2.4 DistributedProperty it is stated that: '[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.' It does not however state whether a DistributedProperty [Property] may only be applied to a value property (a "block property" typed by a ValueType or DataType) or other Property variations. All examples of the application of DistributedProperty show it applied to a value property. This has implications for sorting into block compartments in BDDs; if a DistributedProperty [Property] may only be applied to a value property then it will always be sorted into the 'values' compartment. It also has implications for aggregation; since a value property must have AggregationKind 'composite', a DistributedProperty will also have AggregationKind 'composite'. 

There appears to be a typographical error in Fig 8.5 re: the multiplicity of a NestedConnectorEnd propertyPath. This figure says [2..*], whereas Section 8.3.2.6 says [1..*]. === Specifics: In the SysML 1.0 document (formal/2007-09-01), Fig 8.5 entitled "Abstract syntax extensions for SysML connector ends" shows this for NestedConnectorEnd: - propertyPath: Property [2..*] (ordered) However, Section 8.3.2.6 NestedConnectorEnd has a different multiplicity: - propertyPath: Property [1..*] (ordered) Section 8.3.2.6 seems to be the correct version, as it provides further explanation including stating "The connector end property is not included in the propertyPath list, but instead is held by the role property of the UML ConnectorEnd metaclass.", which is consistent with a multiplicity of [1..*]. The severity of this issue is deemed "Significant" because tool implementations that follow the figure versus ones that follow the section text (which has already occurred) will be incompatible. === Proposed Resolution: Change the multiplicity in Fig 8.5 from [2..*] to [1..*].

The semantics of composition between activities refers to synchronous calls. What happens if the activity is called asynchronously? Is it possible to show that activity in the bdd, too? What is the relationship to the calling activity? 

Output pin of a control operator is not a control pin as shown in fig. 11.10. It should be a regular pin typed by ControlValue.

Issue: Ability to capture performance properties of activities and bind to parameters in parametrics. Discussion. Need to clarify that performance properties of activities and other behaviors, such as the time, reliability, and accuracy associated with performing an activity, can be captured as part of the definition and use of an activity or the types of its object nodes in a way similar to value properties of blocks. Further clarification should be provided that these properties can be bound to parameters in parametric diagrams to support performance analysis. Activities (and other behaviors) can be captured on a bdd as shown in Figures 11.1, 11.5, 11-13 and 11-14. In section 11.3.1.1 and 11.3.1.4, the interpretation of activities and object nodes on bdd's is defined, and in section 11.3.1.4. Proposed resolution: Additional clarification should be provided in the above sections, that properties of activities and other behaviors can also be represented on their definitions on a bdd, and that the value properties are like any other value property, enabling them to be bound to parameters in parametric diagrams.

Issue: SysML support for Foundational UML to support execution of activities Discussion. Need to include the foundational subset of UML in the UML4SysML to support activity execution. This includes constructs suchas structured activity nodes in complete structured activities, which is a capability that is a useful addittion to SysML. Proposed Resolution. Update Figure 4.2 and Table 4.1 to included structured activities, extra structured activities and complete structured activities along with any other packages in UML4SysML needed to support the Foundational UML Subset. In addtion, update the diagram elements in Tables 11.1-11.3 to reflect the additional activity constructs including the structured activity node.

Issue: Inability to name interruptible activity regions. Discussion. Interruptible regions are useful constructs in SysML to enable termination of activity nodes. This is useful in a variety of cases, such as when one wants to terminate actions with streaming and continuous flows. In more complex behaviors with multiple interruptible regions, it is desired to be able to identify these regions by name. This may be useful when defining the owned behavior of a block with an activity that has multiple interruptible regions that represnt behavior in a similar way to state machines, where an accept event action may cause the behavior of the block to transition to another interruptible region of its behavior. Proposed resolution: An interruptible region in UML and SysML is currently an activity group which subclasses element. Create a stereotype of interruptible region called name interruptible region that subclasses Named Element (a similar approach is applied to activity partitions in UML

Issue: Ambigous line crossings Discussion: When two lines cross, there can be ambiguity associated with the line path. This applies to any line including flows, associations, and connectors and other relationships represented by edges. A solution to remove ambiguity that is used in various schematic diagrams to address the same issue is to add include a curve in the lline path at the intersection. Proposed Resolution: In the Diagram Appendix on pgs 175-176, and a diagram guideline to include the curve to a crossing line path to avoid ambiguity. Consider making this a normative requirement. This will require an additional clarification statement for the Non Normative annexes.

There is a non-normative diagram indicating a hierarchy of SysML diagram types. In this diagram we follow the UML convention of treating Use Cases as behavioral diagrams.  The exact reason for this is unclear, and appears to be tied up with collaborations.

 

However, in SysML system engineers (and many s/w eng in UML) treat use cases as a way of capturing goals, capabilities, purposes, and as a technique to organize (and find) requirements.   In this way, it is more understandable to the typical SysML user to treat both  Use case Diagrams and Requirements Diagrams as belonging to the same category. I have verified this by teaching SysML to students both ways – and the common UCD/REQ approach is thought to be more understandable.

 

One approach would be to consider the new category Requirement Diagrams, and Use Case and Text-base Requirements as the individual requirements. Another would be to make a new category of Specification Diagrams and use Use Case and Requirements as the individual types.

 Certain activity constructs were left out of UML4SysML to reduce complexitiy of the language, butBased on usage of activity diagrams, some of these constructs are now viewed as useful. One example is structured activity nodes. Others include the parameter affect. Proposed Resolution: Update Fig 4.2 andd Table 4.1 to include additional packages in UML4SysML that support the useful constructs such as structured activity node which is included in "CompleteStructuredActivities". Also, update the diagram element tables in Table 11.1 to reflect these new constructs.

Even though SysML ValueType includes all the capabilities of UML DataType, plus its own optional extensions, SysML currently both of these separately in its diagram elements and abstract syntax. This adds unnecessarily to the complexity of the specification (where both DataType and ValueType must be mentioned in multiple places) and to the language that the SysML user must learn. It's inconsistent with other renaming of UML elements by SysML, in which the neutral SysML term (e.g. Block) replaces the UML term (e.g. Class). Just as SysML Block replaces the UML term Class, there's no reason the SysML term ValueType can't replace the UML term DataType. Statement of OCL constraints and metamodel and diagram syntax specifications can be simplified as a result.

"trigger[guard]\activity" should be "trigger[guard]/activity"

The outpin of the control operator in fig. 11.10 is a control pin. But pins of control operators must be normal pins. The action Monitor Traction has no input pin.

Participant Property constraint #6 not correct. In Blocks, UML Extensions, Stereotypes, Participant Property, remove constraint 6 (the one resrtricting the upper multiplicity of the end property). End properties of associations can have any multiplicity. See example in Figures 8.13 and 8.14, where the deliveredTo end of a participant property has multiplicity 1..*. 

Connector Property value text. In Blocks, UML Extensions, Stereotypes, Connector Property, Description, first paragraph, last sentence, the current text implies all instances of association blocks will be values of the connector property. The value is actually the subset of those due to the connector. Suggestion: - remove "exactly those" - replace "that are instances" with "(instances)". 

UML 2.2 defines a presentation option for stereotypes for comments. There is no need to repeat that option in SysML. There is no need for a tool vendor to support a UML presentation option to be compliant with the specification. Since SysML depends on the presentation option the chapter 7.3.1.1 should be updated to state that the presentation option is required. 

Using composite association between activities. The actual nature of the properties corresponding to the association end is not clear. Either it is a CallBahaviorAction and then it is not an instance of associated activity, or it is an activity execution and then the association should be derived beacause it depends on the CallBehaviorActions owned by the activity. Proposed resolution: State that composite associations between activities are always derived from the CallBehaviorAction owned by the activity. 

Notation for multiple item flows. The UML specification provides a compact notation for multiple information items flowing in the same direction. A similar notation should be provided in SysML, but this is not explicitly called out. Recommendattion. Add a sentence at the end of section 9.3.1.4 which describes diagram extensions for item flows consistent with the UML approach that reads "When several item flows having the same direction are represented, only one triangle is shown, and the list of item flows, separated by a comma is presented." Also, include the multiple item flow notation in the Item Flow entry in Table 9.1. 

Example figures in chapters are redundant with Annex B sample problem. This creates document maintenance issues. Figures 7.3, 8.11, 9.5, 9.6, 10.2, 10.3, 12.1, 12.2, 12.3, 13.1, 14.1, 14.2, 15.9, and 15.10 are all duplicated in Annex B. It is recommended that these diagrams are removed from chapters in part II and IV of the spec, and instead specifically reference the appropriate diagrams out of Annex B, thus making the specification easier to maintain.

Out of Date Annex D.4: The information in Annex D regarding AP233 needs to be updated. AP233 to be released as DIS and this section needs to be revised to reflect changes to AP233. 

Representing multiple item flows on the same connector. The specification should clarify the notation for representing multiple item flows with the same direction on a connector. In particular, UML allows for multiple information items to be represented with a single triangle, along with the list of the information item names spearated by a comma (refer to Figure 17.6 of the Superstructure Spec). A similar notation should be provided to represent multiple items flows in SysML. Proposal resolution: Recommend adding the following sentence at the end of section 9.3.1.4. " When several item flows having the same direction are represented, one triangle can be shown, along with the list of item flows separated by a comma." Also, add a constraint to 9.3.1.4 as follows" 1. If the ItemFlow has an itemProperty, there must be one conveyed classifier which matches the type of the item property. 

UML 2.1 added a new structural diagram type, Profile Diagram for the purposes of containing the profile-defining elements. SysML either should be made consistent or should explicitly indicate that the diagram is not part of SysML

The SysML specification does not define the correct namespace URI for the standard profile(s) - it should.

The UML rtf’s response to this issue was to add an “isConjugated:Boolean” to the Port definition. This renders superfluous the SysML addition of the conjugated flag on flow ports. The SysML flag needs to be removed. In addition, the notation has changed to use a ~

The compliance levels defined for UML 2.1.1 and UML 2.2 merge UML::CommonBehaviors::Communications at L1 instead of at L2 in SysML 1.1 as specified in table 5.2 (Metamodel packages added in Level 2). With UML::CommonBehaviors::Communications  at L2, it is not possible to properly define UML::Actions::BasicActions at L1 because UML::Actions::BasicActions::SendSignalAction::signal :  UML::CommonBehaviors::Communications::Signal [1] becomes ill-formed at L1.
The UML::CommonBehaviors::Communications package is also absent from table 4.1 (Detail of UML Reuse) in SysML 1.1, clause 4.2 (Architecture).

Update clauses 4.2 (Architecture) and 5.1 (Compliance with UML subset) to reflect merging UML::CommonBehaviors::Communications at SysML's L1.
It is not clear what is the purpose of Figure 4.2 as it shows a combination of L2 and L3 content from Table 5.2 and 5.3.

Overly restrictive statement regarding ports in blocks chapter. The following statement in section 8.3.2.2 in the Blocks Chapter is overly restrictive. "A port that is typed by a Block is a special case of a part property, as further defined in Chapter 9, Ports and Flows.". A port is a special class of property that can be typed by classifiers other than blocks. The recommendation is to generalize the wording as follows: A port is another category of property, as further defined in Chapter 9, Ports and Flows.