Issues for Mailing list of the SysML Finalization Task Force

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

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

Issue 9620: chapter 11.3.2.6 Optional
Issue 9757: 7.3.1.2, last sentence
Issue 9758: Fig. 7.2:
Issue 9759: Fig. 7.3:
Issue 9761: Include subsections to sections 2.1 and 2.2
Issue 9762: Section 17.4.1 Fig. 17-5
Issue 9764: Section 10.3.2.1
Issue 9765: Section 1.4
Issue 9766: Section 8.4 - add figure
Issue 9767: XMI section
Issue 9768: Include index into the specification
Issue 9769: Appendix E, last column in table
Issue 9770: General - Stereotypes
Issue 9772: Editorial general issue
Issue 9773: Change UML 2.0 to UML 2.1
Issue 9774: "Change ""ISO AP233"" to ISO 10303-233 STEP AP233
Issue 9775: references
Issue 9776: What does <<moe>> mean?
Issue 9777: Page 36
Issue 9780: Add clarification of how to represent non-depletable stores in ibd as part
Issue 9781: General Diagram Elements
Issue 9782: Section 8.3.2.4
Issue 9783: Section 10.3.2.1 constraint block
Issue 9784: Blocks
Issue 9785: Section 7.3.2.4
Issue 9786: Section 7.3.2.5
Issue 9787: page 42, ist paragraph
Issue 9788: page 44
Issue 9789: page 86
Issue 9790: page 94
Issue 9791: page 137
Issue 9792: figure 11-14
Issue 9793: Section 15.3.2.3
Issue 9794: regarding the <<requirementRelated>> stereotype in the Requirements package
Issue 9804: Model Elements sub-profile depends only on UML4SYML Level 1, not 3.
Issue 9836: Invalid redefinition on stereotype extensions
Issue 9837: Freeform diagrams in SysML
Issue 9844: table 7.2, page 26, PublicPackageImport
Issue 9845: table 7.2, page 26, PrivatePackageImport
Issue 9846: table 7.2, page 26, PackageContainment
Issue 9847: §7.3.2, page 28
Issue 9848: §7.3.2, page 28, since View extends Package, it also extends Model
Issue 9849: table 14.2, page 117, Include should list UML4SysML::Include
Issue 9850: table 14.2, page 117, Exclude should list UML4SysML::Exclude
Issue 9851: table 14.2, page 117, ExtendWithCondition should list UML4SysML::Extend
Issue 9852: table 14.2, page 117, Subject should list UML4SysML::UseCase::subject
Issue 9853: §15.4.3, page 133
Issue 9854: §A.1, page 167
Issue 9876: Figure 9.2
Issue 9880: UML Profile-based conformance
Issue 10002: Section: Appendix B.4.5
Issue 10008: Section: Activities
Issue 10009: Section: Blocks - Internal block diagrams for associations
Issue 10010: Section: Blocks - Stereotype for binding connector
Issue 10011: Section: Blocks - Definition of binding connector
Issue 10012: Section: Activities - Timing diagram in Activities
Issue 10013: Section: Blocks - Unit base class.
Issue 10014: Section: Blocks - Unit base class (02)
Issue 10015: Section: Blocks - Dimension and Unit Base Class
Issue 10016: Section: Blocks - Block constraint [2].
Issue 10017: Section: Blocks - Definition of part properties
Issue 10021: Section: Blocks - Aggregation.
Issue 10022: Section: Blocks - DistributedProperty stereotype of stereotype
Issue 10023: Section: Blocks - propertyPath definition
Issue 10024: Section: Ports and Flows - the term "Standard Port" is a misnomer
Issue 10025: Section: Ports and Flows - Flow Ports overview 9.1.2
Issue 10026: Section: Ports and Flows - ItemFlow itemProperty type
Issue 10027: Section: Ports and Flows - FlowPort constraints [2] and [3].
Issue 10028: Section: Ports and Flows - ItemFlow constraint [5]
Issue 10029: Section: Ports and Flows - ItemFlow constraint [2].
Issue 10030: Section: Ports and Flows - ItemFlow constraint [4].
Issue 10031: Section: Ports and Flows - ItemFlow constraints [1] and [3].
Issue 10032: Section: Ports and Flows - Relaying instances.
Issue 10034: Section: Ports and Flows - Relaying to properties
Issue 10035: Section: Ports and Flows - Flow ports semantic variation
Issue 10036: Section: Ports and Flows - Flow ports direction for non-atomic ports
Issue 10037: Section: Ports and Flows - Flow port isAtomic derivation
Issue 10038: Section: Ports and Flows - Flow property values wording
Issue 10039: Section: Ports and Flows - Flow property constraint [3].
Issue 10040: Section: Constraint Blocks - Binding connectors in constraint blocks
Issue 10041: Section: Constraint Blocks - Parameters of constraint properties
Issue 10043: Section: Requirements - Backslash typos
Issue 10046: SysML: Remaining UML 2.0 references
Issue 10049: SysML: Section 8.3.1.4 Datatye
Issue 10050: SysML: Copyright page
Issue 10051: SysML:table 5.4
Issue 10052: SysML:Requirment-->Requirements
Issue 10053: SysML: Behavior or Behaviour
Issue 10054: SysML: of of
Issue 10055: SysML: The The
Issue 10056: SysML: USe Case Diagram
Issue 10062: SysML: Instance Diagrams
Issue 10063: Sysml: SST
Issue 10064: figure B.19
Issue 10065: Figure B.35
Issue 10066: SysML: Appendix G
Issue 10067: SysML: Unicode / Translations
Issue 10068: partial list of dependencies
Issue 10069: Sysml: Views can own Views
Issue 10070: SysML: Viewpoint and Actors
Issue 10071: SysML: SI units
Issue 10072: restriction on no more than 1 item property per item flow is unclear
Issue 10075: figure C2
Issue 10078: Section: 7.4
Issue 10085: Section: 8.2.1.1
Issue 10378: plug a gap wrt how to recognize diagrams that come with a default namespace
Issue 10381: Section: 8.2.1.1 Blocks Diagram Elements Table
Issue 10385: Part-specific type metamodel - Section: Blocks
Issue 10445: composition relationship between blocks
Issue 10447: SysML:Usiing a BDD for Activities
Issue 10514: Section: 9.3.2.8
Issue 10584: Section: Activities
Issue 10585: Figure 11.14 uses the value stereotype, which doesn't exist
Issue 10595: Issue – omission of join spec notation in activities diagram element table
Issue 10623: Section: Copyright page

Issue 9620: chapter 11.3.2.6 Optional (sysml-ftf)

The description mentions that "the parameter is not required to have a
value for the activity to begin execution."
Optional is a stereotype of Parameter. Therefore the statement should be
more general, e.g.
"the parameter is not required to have a value for the behavior to begin
execution."

Resolution:
Clarify that the optional stereotype applies parameters on all behaviors.

"Dependency subtypes that are imported from UML are defined in the
respective chapters where they are used."


better (?)


"Dependency subtypes that are imported from UML are defined in the
respective chapters 
in this specification where they are used, , e.g. Requirements."

The sentence makes no sense in the chapter "UML diagram elements not included in SysML" since dependency subtypes like abstraction (e.g. trace) are included in SysML.

Layout: The right extension relationship lines (Rationale/Problem)
are thinner than the other ones.

Update figure 7.2 in chapter 7.3.2: right extension lines should have same line thickness as the other ones.

The property values of the requirement Performance are not enclosed
in quotation marks.

The property values of the requirement Performance are not enclosed
in quotation marks.

Include subsections for both 2.1 Normative References AND 2.2 Non-Normative References under a general heading called References similar to SP

FTF issue - suggestion to retitle to Section 2 References Discussion:
Not clear why you would do this unless you also included non normative references which we do not. The UML specification only has a section on Normative References. Therefore this doesn't make any sense.
Disposition:	Closed, no change

Change diagram heading name from SysML metamodel to user defined profile.

FTF Issue - Change to "user profile definition". The submitter is correct. Change as proposed.

Clarify what happens with the semantics inherited from blocks (such as FlowPorts) that does not make sense for constraints. [SF] Recommend making a more general statement as part of blocks stereotype. 

FTF Issue - general issue of whether constraint blocks are equivalent to blocks or subtract from blocks.  Discussion:
Constraint 1 under 10.3.2.1 ConstraintBlock specifies a total exclusion of behavioral elements within a constraint block, which includes flow ports. Group discussion agreed that this exclusion matches the V1.0 intent for constraint blocks.  A regular block can always be used to model constraints that also entail other state or behavior, so there is no loss of modeling capability by keeping the definition of a constraint block limited to a pure constraint.
Disposition:	Closed, no change

Add usage example that shows how to constrain properties of flow ports. Refer to example in Rick's water distiller example.

FTF Issue - Consider adding an example in HSUV appenidx B   Discussion:
It is already specified. Many other examples available such as the SysML Tutorial available on OMG website (e.g. Heat Exchanger Flow ports)
Disposition:	Closed, no change

Show example of reference property for lugboltjoint in Fig 8-6.

FTF Issue - 8-8 mountingholes singular, connector should be unidirectional, add a version of 8-8 showing references properties inside joint  (Roger to supply) Discussion:
There are examples of reference properties, including connectors to reference properties, in the sample problems appendix.  (See, for example, Figure B.19.) The Usage Examples in Chapter 8 are not intended to show more than a few fragments of typical usage.  Further examples, especially of specialized topics such as the one raised by this issue, will no doubt be highly valuable, and can be included in tutorial or reference material external to the specificiation, but they are not appropriate within the editorial guidelines adopted for SysML specification chapters.
Disposition:	Closed, no change

Control value, real and complex seemed to be missing from the extensions

The submitter is correct, these three values (and the two libraries they exist in) are not present in the XMI. This can and will be addressed, but not until the end of the FTF when a new version of the XMI is create.

Include index into the specification

Index to be created

Update version number to clarify that the version represents when full compliance will be achieved. Otherwise it is assume to ve v1.0.

FTF Issue - Remove Appendix E from core document, use by reference not inclusion. Remove Annex E and Add Reference 

Separate definition from description

FTF Issue - Reference SysML partners  submission in parametrics (Thomas W)

 Discussion:
The separation of definition and description as used by SysML Partners in parametrics is not generally applicable to all sections of the submission. Therefore it was concluded that the current form is adequate and doesn't warrant rewriting all stereotype definitions / descriptions.
Disposition:	Closed, no Change

Apply paste special - metafile to all visio figures
Figures are all metafiles, Tables are embedded Visio still. General issue for upgrade to Visio 2003 and update the SysML template

Discussion:
Decided to leave as is. 
Disposition:	Closed, no change

Change UML 2.0 reference to UML 2.1 throughout the document

Issue was resolved prior to FTF. Change made by OMG editor.

"Change ""ISO AP233"" to ISO 10303-233 STEP AP233. This should be changed
in the whole document. Abbrevations to  ""AP233"" are fine within a
section provided it has been fully introduced at the beginning of
that section. In section headings and captions, it should never be
abbreviated
"

Change to be made in 7 locations

"Remove UML 2.0 Superstructure
Change UML Infrastructure to UML 2.1 Infrastructure Convenience Document 
(ptc/06-04-03)
"

Changes to be made

Please add a footnode explaining what <<moe>> is (just for readability)

Add a footnote below Figure 7.3 defining and point a reference to Appendix C Section 3.2

"In the table row for Actor, add some space between the two alternative
representation to make it obvious these are alternatives.
"

Added Space as requested

Add clarification of how to represent non-depletable stores in an ibd as a part. Consider including as a usage example.

Referenced Property is recommendation for depletable and non-depletable strores.  The blocks chapter covers Referenced Properties adequately.  An example of a non-depletable store will be included in the Appendix B sample problem.

Update diagram element tables to include requirements, allocations, packages, comments,ratinale, etc or include a statement where they are defined.
Diagram element tables should include cross cutting constructs such as allocations, requirements, and packages

FTF Issue -  Clarify in BNF and make general statements in cross cutting and model element chapters. Rather than adding many repeated copies of the same diagram elements to each SysML diagram type, add a general statement in the diagram elements table section of Chapter 7, Model Elements, and Chapter 15, Allocations, stating that the diagram elements defined in these diagram elements tables may also be shown on SysML diagram types defined in other chapters.

Constraint [1] is not very clear. Please clarify

The resolution for Issue 10015 replaces the metamodel for ValueType, Dimension, and Unit, which eliminates the need for this constraint.

Consider removing constraint. Delete Constraint [1]
Exclusion of all state or behavior within a constraint block may be too extreme for some potential uses.

Delete Constraint [1]
Exclusion of all state or behavior within a constraint block may be too extreme for some potential uses.
FTF Issue - general issue of whether constraint blocks are equivalent to blocks or subtract from blocks - close 49 as dup)   Discussion:
The rationale for this resolution is the same as for issue 9764.  This is the  same discussion text as for that issue:
Constraint 1 under 10.3.2.1 ConstraintBlock specifies a total exclusion of behavioral elements within a constraint block, which includes flow ports. Group discussion agreed that this exclusion matches the V1.0 intent for constraint blocks.  A regular block can always be used to model constraints that also entail other state or behavior, so there is no loss of modeling capability by keeping the definition of a constraint block limited to a pure constraint.
Disposition:	Closed, no change

How do you represent static properties of a block on a parametric diagram without imposting a usage, such as specific heat in the distiller example. The intent is to represent a value property for the specific heat of water that applies to all usages of water. One approach is to specify an anonymous type from a model library of ItemTypes with a value property as :ItemTypes::Water.specificHeat, where Water is specified as a block. 

Discussion:
Tutorial materials, external to the specification, show examples of such static properties. As indicated in the issue, multiple mechanisms are available to assign values to such static properties. A separate issue, 10381, has been raised to include the underline notation for static features in 8.2.1.1, Diagram Elements Table for the Blocks chapter.
Disposition:	Closed, no change

"Consider changing ""... of a whole system ..."" to ""... of a whole system 
or subsystem ...""
"

Since view is no longer a stereotype of model it is ok that the scope could differ from the whole system. However neither system nor subsystems are defined in SysML.
Change sentence as recommended.

"Consider other types than ""String"" for the ViewPoint attributes. This would
allow to refer to elements representing these concepts (like stakeholder).
"

Discussion:
Stakeholders are not explicitly defined in SysML as well as the other Viewpoint attributes like purpose or concerns. 
It's more part of a methodology than of a language to define which model elements represent those concepts.
I recommend to use already available SysML mechanisms like the dependency relationship to connect a viewpoint with other model elements. 

Disposition:	Closed, no change.

"Suggest to add a sentence explaining that the diagram frame sets an
unambiguous context for recognizing an unlabeled box as <<block>>
"

Discussion:
Issue refers to Section 8.3.1.2, "Default "block" stereotype on unlabeled box," which is now on Page 41 in ptc-06-05-04.
The use of the diagram frame to set the context for all notational elements, according to a particular diagram type, is fundamental in SysML. Explaining the role of the diagram frame to set the context for this particular notational element would be out of place. If more explanation is needed on the role of the diagram frame in setting the context for SysML notations, it should be provided in a more general way rather than for this particular element.
Disposition:	Closed, no change

Please add example(s) for NestedConnectorEnd

Discussion:
Issue refers to Section 8.3.1.3, "Nested Connector End" section, which is now on Page 43 in ptc-06-05-04.
Examples of connectors with nested connector ends appear in Section 8.4, "Usage Examples," Figure 8.8, "Internal Block Diagram for WheelHubAssembly," and within internal block and parametric diagrams in the Sample Problems Annex B.
Disposition:	Closed, no change

Clarify the line style for ControlFlow (last table row)

Discussion:
Unclear where what this referencing, it may have been an earlier draft (the row for Control Flow in the diagram elements table is not the last one, and is not on page 86).  The Control Flow entry in the diagram elements table has both line style notations.  Section 11.3.1.3 (ControlFlow) describes the additional style supported in SysML.
Disposition:	Closed, no change

"Remark: Be aware that the way it is defined, an optional attribute
has a physical slot in the instance, even though it has no value.
"

Discussion:
This is a software-specific fact is would not be appropriate in the SysML specification.
Disposition:	Closed, no change

"Two comment examples show still the old (wrong) notation with the
circle at the attach point.
"

The issue is actually more spread out because other elements that have a comment attached show a circle.

"If we use the pin notations for object flows does the user have to allocate both pins, bear in mind that two or more object flows may start or end at a given pin so in order to designate the precise object flow you need both ends.

-       From the item flow end does the user get a choice of pins (the actual elements in the model) or object node symbols (which may or may not exist on the activity diagram depending on whether pins are shown).

-       When the type name is shown in the allocatedFrom compartment, e.g. <<objectNode>>dirtywater, what should the typename be - either the tool derives it from the type of the allocated element (which is tricky because there are two elements with different type), or we explicitly list what the type name should be under which circumstances.
"

"Rick and I discussed adding an explicit objectNode, say a CentralBufferNode, for every object flow and this would be the thing that was allocatedFrom. We would stereotype it something (maybe even ObjectNode) and that would be the name shown as the typename. This could be related to the objectFlow (actually some stereotype thereof) by a stereotype property, similar to the itemProperty. Clearly this introduces redundancy, but has the benefit that the objectnode could be used in the parametric diagram to represent properties of the flow.

Another option is to actually allocate from the objectFlow, but name it from the name in the objectnode symbol - this seems simpler, and would be easier to maintain consistency, so the allocatedFrom compartment for an item flow might show <<objectFlow>>dirtywater. Doesn't solve the parametric problem though. Perhaps a hybrid approach is needed.

"  ActionPins represent ObjectNodes, not ObjectFlows.  
ActivityEdges, including ObjectFlows, are simple to allocate to ItemFlows or Connectors.  This is appropriate, since both kinds of "flow" represent connection and direction, and do not specify the thing that is flowing.  
ObjectNodes represent things flowing on ObjectFlows, and ItemProperties represent things flowing on ItemFlows.  ObjectNodes may NOT be cleanly allocated to ItemProperties, for reasons stated in the summary above.  The ObjectNode is in fact modeled by two ActionPins, one on each end of the ObjectFlow.  The "single box" notation for an ObjectNode is a display option, and does not supersede the ActionPins.  Since each ObjectNode is in fact two ActionPins, each of which is an embedded element of the associated Action, it is not straightforward to allocate them to a single ItemProperty, or any other element… especially if the Actions (and ActionPins) are re-used in a different activity diagram.  For this reason, any reference to ObjectNode allocation to ItemProperty should be deleted from the specification.

"Description paragraph for AllocateActivityPartition states that the relationship depicted is an allocation of definition (from Activity), but Constraints paragraph states that the relationship depicted is an allocation of usage (from Action).
"

"l- Change the Description paragraph to read:
AllocateActivityPartition is used to depict an <allocate> relationship on an Activity diagram. The AllocateActivityPartition is a standard UML2::ActivityPartition, with modified constraints as stated in the paragraph below.
- Change the Constraints paragraph to accommodate allocation of definition or allocation of usage, based on fully qualified names (with colons) of both the ActionNode in the partition, and the element representing the partition.  A non-normative example is shown below for illustration
purposes:

(Embedded image moved to file: pic29275.jpg)

This is consistent with our approach to allocation compartments and allocation callouts - the specificity of the allocation relationship can be expressed using fully qualified names.

" Allocations shown on diagrams of usage (act and ibd), must relate to the element shown on the diagram (Action, Part) and not the defining classifier (Activity, Block).  To do otherwise would be ambiguous.  Relating the allocation to a defining classifier can be shown on a diagram of definition (bdd).  
AllocateActivityPartitions can represent either Blocks or Parts.  Which of these is represented shall be distinguished as follows: Parts are designated by the use of a fully qualified name (including colon, e.g. "part_name:Block_Name"), and Blocks are designated by a simple name (no colons).  The allocation relation resulting from the use of this AllocateActivitiyPartition will be "from" (supplier) the Action depicted in the diagram, "to" (client) the Block or Part represented by the AllocateActivityPartition.
Words will also be added to this section to reference the UML 2.0 Superstructure Spec section 12.3.10 - Semantics, which describes implication of UML ActivityPartitions with respect to CallOperationActions and CallBehaviorActions.
Figure 15.4 needs to be replaced to show an appropriate use of Action and AllocateActivityPartition.  Table 15.1 needs to be updated to show an appropriate example of AllocateActivityPartition using an Action (rather than an Activity), and the diagram showing allocation compartment on ActionNodes needs to be clarified.

regarding the <<requirementRelated>> stereotype in the Requirements package of the SysML profile.  I have two questions:

 

Why is the “verifies” tag on requirementRelated instead of <<testcase>>? 
Why do you allow <<requirementRelated>> to be applied to <<testcase>> items? 
 

It makes more sense to me to put the “verifies” tag on <<testcase>> and have a constraint on <<requirementRelated>> that states it cannot be applied to items stereotyped as <<testcase>>.  As I understand it <<requirementRelated>> is basically a placeholder for the derived tags that can’t go anywhere else (e.g. “satisfies”, etc).  Since <<testcase>> is already a stereotype there’s no reason why it can’t hold the “verifies” tag.  

 

The submitter is right in the sense that only <<testcase>> can be used to verify requirement. The derived properties Verifies in the RequirementRelated Stereotype will never be filled unless the stereotype is applied to a testcase. Therefore, the Verifies property can be removed from the RequirementRelated stereotype.
Revise the text in section 16.3.2.4 to reflect that Verifies does not belong anymore to the stereotype RequirementRelated. Update 16.3.2.5 to reflect that a new derived property called Verifies is added to the stereotype. I disagree with the second part of the issue "have a constraint on <<RequirementRelated>>" because a test case can still be traced, satisfy or refine a requirement. Therefore no constrain should be added.

Update the Figures 16.1 and 16.2 accordingly.

Now that View extends Package instead of Model, the Model Elements sub-profile depends only on UML4SYML Level 1, not 3.

The submitter is correct. Remove the Level 3 compliance option for Model Elements.

In Figure 9-1, "Port Stereotypes"  ownedFlowProperty redefines ownedAttribute in FlowSpecification. 
You cannot redefine something that is not inherited - and extension is not inheritance.
 
Fortunately this seems to be a one-off: I could not find any other similar subsets or redefines in the spec.

the relationship between FlowSpecification and FlowProperty is removed from the spec. instead add a constraint that owned attribute of a FlowSpecification is a flowProperty

Section A.1 mentions a "freeform" version of package diagrams. If freeform diagrams are allowed (as they are), there does not seem to be any special benefit to restricting such diagrams to only the contents of a single package. Freeform diagrams are typically used to show relationships between elements that are normally shown in different diagrams. Experience with UML has shown that this is an extremely useful capability and is in high demand. I suggest moving this diagram from out of the package diagram restriction and make it a general diagram type that is not restricted to elements belonging to the same namespace.

Discussion:
The statement below in Appendix A.1 highlights the SysML philosophy regarding use of diagrams.
 
"Although the taxonomy provides a logical organization for the various major kinds of diagrams, it does not preclude the careful mixing of different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside a compartment of a block). However, it is critical that the types of diagram elements that can appear on a particular diagram kind be constrained and well specified. The diagram elements tables in each chapter describe what symbols can appear in the diagram, but do not specify the different combinations of symbols that can be used."

In SysML, most diagram types strictly control the kinds of diagram elements that may be present, but SysML allows diagram elements from other diagram types (including their own nested structure) to be present inside a package diagram context.  The only constraint on what can be shown on a package diagram is that the elements in the content section must be packageable elements. Since the diagram frame for a package diagram can designate the top level package, the content area of the diagram can include any packageable elements within the model. The elements shown may also be owned by other packages, as long as qualified names are used to distinguish them from elements owned directly by the package.

It is recognized that a free-form diagram is useful but it should not be part of the SysML specification which tries to promote modeling versus drawing. Instead, a free-form diagram could be an optional tool feature similar to other useful features such as providing HTML formats, etc.

In addition to the above, adding a free-form diagram to the SysML specification was deemed to have a significant impact on the tool implementation by some participating tool vendors, and was deemed outside the scope of the SysML FTF.

Disposition:	Closed, no change

In table 7.2, page 26, PublicPackageImport should list UML4SysML::PackageImport as the Abstract Syntax Reference

The submitter is correct. That raises another issue if PublicElementImport and PrivateElementImport are missing in table 7.2.

 In table 7.2, page 26, PrivatePackageImport should list UML4SysML::PackageImport as the Abstract Syntax Reference

The submitter is correct. That raises another issue if PublicElementImport and PrivateElementImport are missing in table 7.2.

In table 7.2, page 26, PackageContainment should list UML4SysML::Package::member as the Abstract Syntax Reference. (Or at the very least ownedMember.)

Resolution:
The abstract syntax UML4SysML::Package::ownedElement isn't wrong. All elements that are owned by the package can be refered by the package containment notation. The proposal to use member instead isn't correct. Member also includes elements that imported by the package, but not owned by it.

 
Disposition:	Closed, no change.

In §7.3.2, page 28, View should have a multiplicity of * (zero to many) on the derived viewpoint, since it is possible to have multiple conform-relationships between a view and different viewpoints. Also suggest to rename the derived attribute viewpoints (see next issue: to avoid confusion with Model::viewpoint).

Resolution:

A view is constructed by only one viewpoint. Unfortunately there is no constraint that clearly defines this. It is indirectly defined by the multiplicity 1 of the derived attribute viewpoint in the view and the definition of the view "…from the perspective of a single viewpoint.".
If multiple viewpoints specify a view, the modeler must define a new viewpoint that combines the other viewpoints. That's modeled with dependency relationships between viewpoints.

Since a view is no longer a stereotyped model, but a package, there is no confusion with the name viewpoint.


Disposition:	Closed, no change.

  In §7.3.2, page 28, since View extends Package, it also extends Model. This means that there is a potential for confusing Model::viewpoint with View::viewpoint.

Resolution:

The submitter is wrong: model extends package and not vice versa. The sysml view is a stereotype of a package has nothing to do with uml model. There is no potential for confusing.

Disposition:	Closed, no change.

In table 14.2, page 117, Include should list UML4SysML::Include as the Abstract Syntax Reference

Correct the abstract syntax reference

In table 14.2, page 117, Exclude should list UML4SysML::Exclude as the Abstract Syntax Reference

There is no Exclude relationship.  We assume that this issue is really about the Extend relationship and the proper resolution is to correct the abstract syntax reference for Extend.

In table 14.2, page 117, ExtendWithCondition should list UML4SysML::Extend as the Abstract Syntax Reference

Correct the abstract syntax reference for Extend With Condition.

In table 14.2, page 117, Subject should list UML4SysML::UseCase::subject as the Abstract Syntax Reference

Correct the abstract syntax reference

In §15.4.3, page 133, how are allocation tables represented in XMI if you want to interchange them (especially column headings)? The same issue applies to requirement tables as described in §16.3.1.5, on page 140.

Discussion:
This is an XMI issue, not a SysML issue.  Tabular representations are an important aspect of the XMI specification, but this issue needs to be raised with the XMI FTF/RTF.
Disposition:	Closed, no change

In §A.1, page 167, to what does the stereotype <<diagramUsage>> apply, and where is it defined (with properties and types)? Figure A.3 is incomplete: What is diagramKind? UseCaseDiagram is highlighted, but it is not mentioned where it is defined. Presumably, there are other diagrams, such as RequirementDiagram. Where and how is it defined?

Provide a clearer statement that <<diagramUsage>> is not a real stereotype. Also, use the proper stereotype notation in the text.

Figure 9.2. ItemFlow has a property itemProperty with a stereotype
   BlockProperty as type.  But instances of stereotypes are not
   properties.  The type should be Property, with the constraint that
   the values of itemProperty are stereotyped by BlockProperty.

The SysML specification should be clearer about the level of compliance that can be achieved by UML tools - that will be able to work with the SysML Profile but not support the extended diagrams required by SysML. There should be a separate level of compliance (e.g. called "UML Profile Compliance") for such tools, and the specification should more clearly indicate which parts of the specification require capabilities beyond UML

Discussion:
It was felt that the compliance levels were adequate for the purpose of determining compliance. Refer to Table 5.5 of the spec that already allows a vendor to state their level of conformance relative to concrete syntax
Disposition:	Closed, no change

Typo in title of fig. B.19: Change "Sybsystem" to "Subsystem"

Typo in title of fig. B.19: Change "Sybsystem" to "Subsystem

Activities model library. In Activities, 11.3.2.9 Model Library and 11.3.2.10 ControlValue are listed as stereotypes. They should be in a separate section (11.3.3) of Activities for the model library as (Blocks does, see 8.3.3). This is a normative model library for (Activities.

Create a new section model libraries section for activities, as there are for some of the other chapters, and move Control Value to it.

Internal block diagrams for associations. SysML currently cannot give the internal structure of an association class. For example, the association between engine and wheels has its own parts and connections between them, such as the clutch and differential. If an association class relating engine and wheels is stereotyped as a block currently, the clutch and differential parts can be specified, and the connections between them, but not the connections to the wheel and engine. This is because there are no standard properties on association classes that give the objects at end of the (instances of) the association. The Block model library should normatively define an association (instance of UML4SysML::AssociationClass) with standard names for properties that give the end objects. Since SysML resricts associations to have two ends, only two of these are needed. 

The filer is incorrect that association classes cannot have internal structure currently.  The Block stereotype extends Class, so can be applied to any specialization of Class, including Association Classes.  These will informally be called "association blocks" in this resolution.
However, modelers are not currently able to specify properties that identify the M0 instances linked by each instance of an association block.  This prevents modelers from defining connectors to the ends of an association block.  They are also not able to specify properties that identify instances of association blocks typing connectors.  This prevents modelers from defining connectors to internals of connectors typed by association blocks.
The resolution defines a stereotype (ParticpantProperty) to specify which properties of association block enable traversal from each M0 instance of an M1 association block (link objects) to M0 instances that are the ends of that link object.  It also defines a stereotype (ConnectorProperty) for properties with values that are the link objects of connectors typed by association blocks.
 

Stereotype for binding connector. The Blocks chapter should define a stereotype for binding connectors to distinguish them from those with UML semantics (SysML and UML semantics for associationless connectors is not the same). A stereotype can also specify the constraint that the types of the connected properties must be the same for binding connectors, which currently applies too generally to all associationless connectors with the same type at both ends (binding connectors are defined as any connector with no association). A stereotype would also enable them to be distinguished visually. Currently binding connectors appear in the concrete syntax table with no way to distinguish them from other connectors, and from connectors with UML semantics in particular. 

Add a BindingConnector stereotype and define an optional keyword "binding" that may be used to distinguish a binding connector on an ibd.

Definition of binding connector. In Blocks 8.3.2.1, the definition of binding connector includes this sentence: "If the two ends of a binding connector have the same type, the connector specifies that the properties at the end of the connector must have the same values, recursively through any nested properties within the connected properties." Clarify that the part after "same value" only applies to data/valuetypes. For objects/blocks, if it is the same instance, then it's the same all the way down. 

Issue 10010 establishes a new stereotype for BindingConnector.  The text that describes this new stereotype includes the requested clarification.

Timing diagram in Activities. In Activities, Overview 12.1 refers to timing diagrams, which are not related to activities. This should refer forward to the interaction chapter. 

Clarify the text to explain timelines on activity diagrams, and remove extraneous comment about simulation.

Unit base class. In Blocks, Unit 8.3.2.6, second paragraph, Unit is a stereotype of UML2SysML::Datatype, rather than ValueType. It is a specialization of ValueType. 

The resolution for Issue 10015 replaces the metamodel for ValueType, Dimension, and Unit, and also includes replacement wording for section 8.3.2.6.

Unit base class. In Blocks, Dimension 8.3.2.4, second paragraph, is inconsistent with Figure 8.4, which says Dimension is a stereotype of UML2SysML::Datatype, rather than ValueType. It is a specialization of ValueType. 

The resolution for Issue 10015 replaces the metamodel for ValueType, Dimension, and Unit, and also includes replacement wording for section 8.3.2.4.

Dimension and Unit Base Class. In Blocks, Dimension 8.3.2.4 and Unit 8.3.2.4, there are constraints that eliminate the use of the dimension and unit properties. This indicates that Dimension and Unit should not be specializations of ValueType. They should be based on Datatype without specializing from ValueType. They do not fit the definition of ValueType in 8.3.2.7. 

Specify new metamodel for Dimension and Unit as suggested. See pages 62 - 64 of ptc/2007-02-02

Block constraint [2]. In Blocks, Block, 8.3.2.1, constraint [2], presumably should be restricted to connectors owned by blocks. 

Change text to indicate this restriction.

Definition of part properties. In Blocks, BlockProperty, 8.3.2.2, Description, second paragraph, it says: "A property of a block may refer to another element of a system that is required to exist for the system to exist. Such properties are called part properties." This means the minimum multiplicity of the property is always greater than zero. I assume part properties can be optional, ie, not required to have a value. Was this sentence meant to say that part properties are strong compositional? That would be consistent with UML's definition of the term "part property". If so, the spec should read: "A property of a block may refer to another element of a system, and when instances of the block are destroyed, instances of the other element will be destroyed. Such properties are called part properties." Same comment on another sentence in the same paragraph: "While referenced by the part property, however, these instances cannot cease to exist unless the owning system also ceases to exist." This isn't UML destruction semantics (see above) or consistent with a multiplicity of 0..1, as indicated in the paragraph. Is this intended? 

Move the description of Block property types to the Block stereotype description, and remove the BlockProperty stereotype from the SysML metamodel.  The  BlockProperty stereotype was a holdover from earlier submissions in which separate stereotypes were defined for each property classification in a property taxonomy, and is no longer required.  Since a BlockProperty was defined as any property owned by a SysML Block, the Block stereotype is sufficient to define any constraints on all properties of a block.
Replace the current language defining part and reference properties to leave the specific semantics of composite and shared aggregation to be established by a particular model, as defined by operations that apply over the entire scope of a composite.  The deletion semantics suggested by UML can be adopted when it applies in a particular domain such as software, but other semantics can be established appropriate to other domains such as physical systems.
See the revised text below for the revised descriptions of the SysML property classifications.
Add a clarification that a property path name that contains a reference property anywhere within its path is shown with the notation for a reference property on an internal block diagram.

Aggregation. In Blocks, BlockProperty, 8.3.2.2, Description, furth paragraph, perhaps SysML should give more specific semantics than UML for aggregation. In particular, require acyclic graphs. 

Add a constraint to SysML Block to constrain their properties as suggested, but only for aggregation = composite.  The semantics of aggregation = shared (white-diamond aggregation) are deliberately left undefined, but acyclic constraints could be added to them on a case-by-case basis as part of the semantics of specific blocks.

DistributedProperty stereotype of stereotype. In Blocks, DistributedProperty, 8.3.2.3, first sentence, DistributedProperty is a subtype of BlockProperty, rather than a stereotype of BlockProperty

The resolution to issue 10017 replaces the metamodel for SysML properties to eliminate the BlockProperty stereotype altogether.  Change the text of Section 8.3.2.3 accordingly.  (Issues 10009, 10017, and 10022) all assume a an updated metamodel for Property in SysML.  See the resolution for Issue 10009 for an updated diagram which includes all the stereotypes of Property in SysML.)

propertyPath definition. In Blocks, NestedConnectorEnd 8.3.2.5, Attributes, propertyPath, at the end of the entry description, it says "not including the property which is directly connected.". I gather the property directly connected is identified by the UML ConnectorEnd.role metaproperty? If so, Constraint [1] isn't true, and the multiplicity of propertyPath should be 1..*, rather than 2..*. The entry should clarify if the intention to only use NestedConnector below ports (ie, use the UML ConnectorEnd.partWithPort metaproperty). I think the simplest solution is to just remove the quoted phrase above. The path will be from the Block owning the connector all the way down the connected property. These would need to be consistent with values of UML's ConnectorEnd.role and ConnectorEnd.partWithPort properties, if any (ie, the first two elements in the path would need to be the same as these, if they exist) 

Change the description of the attribute to make the ordering of the properties in propertyPath more clear, and to match the wording of Constraint [1].  Correct the multiplicity of propertyPath to 1..*.  Update the wording of Constraint [2] to allow properties of either blocks or value types to be contained in the propertyPath list.  Keep the definition of propertyPath to not include the leaf-level "property which is directly connected."  This means that the propertyPath list includes only the additional properties required when a connector end is deeply nested.  Add a constraint to indicate explicitly that the "role" property of ConnectorEnd be contained in the type of the last entry in the propertyPath list.  Add a constraint that the existing partWithPort property of ConnectorEnd must have the same value as the last entry in the propertyPath list.

In Ports and Flows, the term "Standard Port" is a misnomer. It won't be standard for many SE's presumably. How about "Interface Port"? 

Discussion:
Rejected. Already discussed and agreed on in the specification phase. 
Disposition:	Closed, no change

In Ports and Flows, Flow Ports overview 9.1.2, it is unclear if single / multiple is referring to item instances or types or something else. "This can include typing an atomic flow port with a single item that flows in our out, or typing a non-atomic flow port with a “flow specification” which lists multiple items that flow." Presumably it isn't referring instances, and not types either, because FlowSpecification supports multiple properties of the same type. Same common on FlowPort 9.3.2.5, second paragraph. 

Modify paragragh in 9.1.2 to be clearer. Should resolve confusion in 9.3.2.5

ItemFlow itemProperty type. In Ports and Flows, Figure 9.2. ItemFlow has a property itemProperty with a stereotype BlockProperty 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 should be UML4SysML::Property, with the constraint that the values of itemProperty are stereotyped by BlockProperty.

Disposition:	See issue 9876 for disposition

FlowPort constraints [2] and [3]. In Ports and Flows, FlowPort 9.3.2.5, constraints [2] and [3], constrains multiplicities of Direction and iConjugated, but it should be constraining the number of values of these properties in instances of the FlowPort metaclass. Multiplicities are in the metamodel and don't change in the instances. 

constraints wording shall be changed

ItemFlow constraint [5]. In Ports and Flows, ItemFlow 9.3.2.8, the attribute itemProperty and constraint [5] constrain multiplicities, but should constrain the number of values of instances of the ItemFlow metaclass (also see the text under Attributes just above). Multiplicities are in the metamodel and don't change in the instances. 

Disposition:	See issue 10031 for disposition

ItemFlow constraint [2]. In Ports and Flows, Figure 9.2 shows the itemProperty on ItemFlows restricted to block properties in (has BlockProperty as type), but ItemFlow 9.3.2.8, constraint [2] says "An ItemFlow itemProperty is typed by a Block or by a ValueType.", I assume values flow as well as blocks. For example, the ports by be typed by Number and the item flow in a particular usage could be integer

Discussion:
Conrads assumption is indeed what was meant by the text and no reason to change. Block Property can be typed by a value type.

. 
Disposition:	Closed, no change

ItemFlow constraint [4]. In Ports and Flows, ItemFlow 9.3.2.8, constraint [4] says The "type of itemProperty should be the same or a sub-type of the conveyedClassifier." Presumably this should be generalization: "The type of the itemProperty must be same or a generalization of the conveyedClassifier". If it were a subtype, then there could be instances of the conveyed classifier that could not be values of the item property. Or maybe the types should be required to be identical. 

Discussion:
The item-property signifies a specific usage of the flow, in which the item property may well be a specialized version of the conveyed classifier. If the conveyed classifier is liquid_, the item property can be water. 

Resolution: Closed No Change. 

Disposition:	Closed, no change

ItemFlow constraints [1] and [3]. In Ports and Flows, Item Flow, constraints [1] and [3] are worded without using the metamodel association ends names, so are difficult to interpret. For example, what do "assign" and "context" mean for the metamodel? 

Change the Constraints in Item Flow in Section 9.3.2.8 to:

Relaying instances. In Ports and Flow, FlowPort 9.3.2.5, Description, implies that type are relayed, but it is the instances of the types that are relayed: "Atomic Flow Ports relay a single usage of a Block, Value-Type, Data-Type or Signal." The term "usage" at least informally is a type-level notion, see fourth paragraph of 8.1. 

Modify paragragh in 9.3.2.5

Relaying to properties. In Ports and Flows, FlowPort 9.3.2.5, Description, sixth paragraph, the semantics relaying properties is very unclear. Are the values propogated from one end of the connector to the other and stored in properties? Do new values overwrite old ones? 

Ignore the isBehavior meta-attribute in FlowPort and rely implicitly relay the values based on the existence of internal links.

Remove the 4th paragraph in section 9.3.2.5:
(In addition, if the Flow Port is behavioral (in case the isBehavioral:Boolean meta-attribute from UML2.0 Port is set to True) then the port relays the item that flow through it to/from its owner. The relay of items of a behavioral FlowPort is bound only to its owner's classifier behavior.1 If the Flow Port is not behavioral then the items are relayed via internal Connectors to internal Parts (internal with respect to the port's owner).)

Change the beginning of the 6th paragraph in section 9.3.2.5 from:

Behavioral FlowPorts relay items to/from the associated connector to/from properties of the owning block or parameters of the block behavior. This means that every FlowProperty contained within a FlowPort is bound to a property owned by the block or a parameter of the block behavior.

To
FlowPorts relay items to/from the associated connector to/from properties of the owning block or parameters of the block behavior if the port is not connected to an internal link that may relay the items to an internal part of its owner. This means that every FlowProperty contained within a FlowPort is bound to a property owned by the block or a parameter of the block behavior. 

Change the last sentence of the 7th paragraph in section 9.3.2.5 from:
Outbound flow properties only declare the ability of the FlowPort to relay the Signal over external connectors attached to it and are not mapped to a property of the behavioral flow-port's owning Block.

To
Outbound flow properties only declare the ability of the FlowPort to relay the Signal over external connectors attached to it and are not mapped to a property of the flow-port's owning Block.

Flow ports semantic variation. In Ports and Flows, FlowPort 9.3.2.5, Description, the sixth paragraph introduced a semantic variation point, which means the models are not interchangeable. The sender will use one technique to bind flow properties and the receiver might another. At least enumerate and normalizes the techniques and put the enumeration in the model so the receiver knows which is being used

accept need to Enumerate the variation points following the way it's done in UML2.0.

Flow ports direction for non-atomic ports. In Ports and Flows, FlowPort 9.3.2.5, should explain why non-atomic ports cannot have direction. Multiple types of things can flow in a direction just as much as a single type of thing. If multiple types of things can flow in a direction, then the spec should be updated for that. 

1. Replace the description of direction and isConjugated with the following:

Flow port isAtomic derivation.In Ports and Flows, FlowPort 9.3.2.5, Attributes, /isAtomic, should explain this in terms of the flow specification, rather than circularly with "atomic". 

correct the text

Flow property values wording. In Ports and Flows, FlowProperty 9.3.2.6 refers to flow properties having values ("A Flow Property’s values are either received from or transmitted to an external Block."), but if a flow property is on an interface, it can't have values. A property of a block supporting the interface property will have the value. The wording could be "flow property" instead of "FlowProperty" which clarification of the relation of properties on a FlowProperty to those on a Block. 

Discussion:
Rejected, seems like a stylistic issue.
. 
Disposition:	Closed, no change

Flow property constraint [3]. In Ports and Flows, FlowProperty 9.3.2.6 constraint [3] says a block can't read its own properties if they have out direction. Why can't it? Every object can read its own properties, regardless of which object provides the values. 

Remove Contraint[3] in 9.3.2.6

Binding connectors in constraint blocks. In Constraint Blocks, ConstraintBlock 10.3.2.1, first paragraph, should say something about binding connectors. 

Add text to make clear that parameters of a constraint block are bound to other properties by binding connectors.

Parameters of constraint properties. In Constraint Blocks, ConstraintProperty 10.3.2.2, second sentence, "Parameters of the constraint property" should be "Parameters of the type of a constraint property". 

Reword as suggested to indicate that parameters belong to the ConstraintBlock that types the constraint property.  Also change capitalization and other minor text details to match the conventions in the preceding Section 10.3.2.1.

Backslash typos. In Requirements, RequirementRelated 16.3.2.4, Attributes, backslahses should be forward

Change 16.3.2.4 Attributes backslashes to forward slashes

The following 6 references to UML 2.0 should probably be converted to UML 2.1 (please review though). Also remember when the references are changed to UML 2.1, the OMG document numbers need to be updated also

 

Note I’m using the PDF page number (physical) not the page number on the bottom of the page

 

 

Page 4 – Use of specification – Terms, Conditions & Notices

 

The specification customizes the Unified Modeling Language (UML) specification of the Object Management Group (OMG) to address the requirements of Systems Engineering as specified in the UML for Systems Engineering RFP, OMG document number ad/2003-03-41. This document includes references to and excerpts from the UML 2.0 Superstructure Specification (OMG document number Formal/05-07-04) and UML 2.0 Infrastructure Specification (OMG document number ptc/04-10-14) with copyright holders and conditions as noted in those documents. 

 

Page 69 8.3.2.1 Block à Constraints     

[5]The following constraint under Section 9.3.6, “Connector” in the UML 2.0 Superstructure Specification (OMG document formal/05-07-04) is removed by SysML: “[3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier that owned the Connector, or they must be ports of such roles.”

 

P 99 Part III Behavioral Constructs

This Part specifies the dynamic, behavioral constructs used in SysML behavioral diagrams, including the activity diagram, sequence diagram, state machine diagram, and use case diagram. The behavioral constructs are defined in Chapter 11, “Activities,” Chapter 12, “Interactions,” Chapter 13, “State Machines,” and Chapter 14, “Use Cases.” The activities chapter defines the extensions to UML 2.0  activities, which represent the basic unit of behavior that is used in activity, sequence, and state machine diagrams.

 

 

Page 122. Table 12.1 

1. Table is compliant with UML 2.0  Superstructure source document dated 050704.

 

 

P 237. D.3 XMI Serialization of SysML 



UML 2.0  is formally defined using the OMG Meta Object Facility (MOF). MOF can be considered a language for specifying modeling languages. The

 

Change all references to 2, not 2.x to avoid having conflict with a specific revision except for those in the Normative References section

DataTyeàDataType

Fix spelling.

Insitute à Institute

 

Misspelling

Table 5.4 second line

 

probability -> probability

The submitter is correct. Change as proposed.

In several places, Requirement is spelled as Requirment

 

4 times in table 16.2 (right hand column)

And once in figure 8.10 (upper left)

Correct mispellings

Behaviour appears 4 times

Behavior appears 209 times.

 

Pick one

We choose Behavior

Duplicate “of of” in figure 11.11 (hmm)

In guard condition in upper right

There is a repeated “The The” in Appendix E table, row 6.5.1, 4th column

Delete one instance of the word "The"

In figure 14.2, the Start Vehicle use case is considered an extension to the Drive the vehicle Use Case.

 

By no means does it appear optional to start the vehicle to drive it. Certainly, it’s no less optional than Steer or Break. 

 

Most modelers, both software engineers and system engineers, would model, Start as an included Use Case not an extension.

 

Please find a better example.

Revise the text as defined below

Section G.5.3 Diagram Elements defined in Instance Diagram

What Instance Diagram?

Disposition:	See issue 10380 for disposition
(Issue 10380 now covers the general need to update Annex G so that it matches the finalized language in the areas that it covers.)

There is a reference to the SST on page 166. It’s the only one.

Replace the word "SST" with the words "submission team"

On figure B.19 on the middle of the diagram, the information flow arrowhead is not pointing along the line. This is confusing, does this mean “both” or something else, or is just a visio typo.

Resolution:
Revise diagram so that itemFlow arrow correctly positioned to show Torque flowing from ice:InternalCombustionEngine to trsm:Transmission.

Figure B.35 has the input signal block (the indented pentagon) facing backwards from your examples in the spec proper. Is this allowed? For non-left/right symmetric symbols, it needs to be explicitly said if the directionality is meaningful or ignored.

UML 2.0 Superstructure Specification, section 11.3.2, does not state explicitly which direction the AcceptEventAction symbol (concave pentagon) must be oriented.  The point of this issue is well taken, however, and the symbol should be changed on figure B.35.

In 6.2.2 Appendix G is referred to as more rigorously defining (some of) the notation. However, the text in Appendix G states that it is non-normative. This needs to be consistent

Update the text in Section 6.2.2 to clarify the role of the diagram elements tables in defining the scope of language notations included in SysML, and deleting the reference to Annex G. Because it is not yet sufficiently complete to define the concrete syntax of SysML, remove Annex G from the specification.

The Spec needs to be clearer on what keyword text strings

1)       Must be ascii

2)       Must/May be Unicode, but must be the exact string given in the spec

3)       May be translated to other languages 

4)       May be translated to other character sets

 

For non keywords, are the strings (e.g., block name)

1)       Must be ascii

2)       Must/May be Unicode, but the latin character set

3)       May any Unicode character set.

 

Any changes in this area should be reflected in the compliance section also.

 

Resolution:
I can not find a precedent for this level of compliance statement in other UML specifications, and if one was to be added I suspect that it would need to take more into account than this (string literals for example). In any case SysML is probably not the place to address this type of compliance - it should probably apply to all relevant OMG specs.

Revised Text:

Disposition:	Closed, No Change.

In the 1st paragraph of 7.1 you have a partial list of dependencies. The list should be preceded by “e.g.,” because it is an example. 

The “i.e.,” is reserved for a full list.

The submitter is correct. Change as proposed.

It appears that a complex view cannot be structured into packages, because a view can’t own other views. See 7.3.2.4 constraint 1. 

Fix by allowing views to contain views

There was a long discussion within the FTF about the view/viewpoint issue. Probably a fundamental change of the concept is necessary which is outside of the scope of the FTF. 
The requested feature to build complex views is not prohibited by the current SysML version. To emphasize the possibility of building complex views the resolution of this issue adds a statement to the view description.

A viewpoint has a list of stakeholders. It would be more convenient if this could include a list of actors (or associations with actors). Many of the stakeholders will be actors and it shouldn’t be necessary to define them twice. And it is more in keeping with SE thinking to allow for definitions (including generalizations, aggregation) of all the stakeholders, to allow for modeling the stakeholders directly, because of the correct focus on stakeholders’ needs. 

Recommend fix, allow for Viewpoints to be modeled on Use Case diagrams or block diagrams and connected directly to actors

Disposition:	See issue 9786 for disposition

The SI unit defined in Figure 8.9 should be a Newton (the unit of force) as opposed to New ton (a unit of mass ?)

Delete space in middle of Newton.

The reason for the restriction on no more than 1 item property per item flow is unclear to me. 

 

Please consider that transferring a block, e.g., water, could be transferring heat, pressure, liquid (volume) 

Discussion:
Rejected. Michael is misinterpreting the metamodel. He can have water be an item-flow. No change needed. 
Disposition:	Closed, no change

In figure C2, subactivity Add requires two inputs, u(t) and -2x(t). While the logic makes sense, I don’t believe the activity diagram should ever start running, because the 2nd pin is never supplied with data until the Add runs. 

 

It’s difficult to see how this could be fixed, for example, making the 2nd pin optional will allow the Adder to work when the Multiplier hasn’t finished, which is not correct. 


So we only want this to be optional the first time. 

 

In any case,  a fix is needed.

See revised text below.

Fig. 7.3; requirement performance: requirement keyword isn't enclosed in guillemets, but in lesser/greater than angles.

Change as proposed.

The boolean isEncapsulated property of the block element must be shown as {encapsulated} (instead of {isEncapsulated}) if true and not shown if false. That's conform to the UML notation of boolean properties

Accept change

Am studying the adopted sysml spec ptc/06-05-04, noted the following possible bug.
 
IMO,  Annex A needs to plug a gap wrt how to recognize diagrams that come with a default namespace.  I can see no way to know whether a diagram is designating a default namespace.  The <modelElementName> in the header seems to have been intended to do this, but it is not up to the job.
 
One way to plug this gap would be to make modelElementName optional in heading, and specify that, if present, the model element instance it names must be an instance of a namespace metaclass, which is the default namespace.
 
Another way is to add a mandatory <namespace> field in the header, and specify some concretely recognizable value, such as the string "None" or an equivalent in the local language, as a valid value.
 
details:
 
Annex A, A.1 Overview, page 167 of the pdf pagination, states: The frame is a rectangle...The frame can designate a model element that is the default namespace for the model elements enclosed in the frame.  This means the rectangle is a concrete graphic notation which may, optionally, represent a namespace, with the implication that in that case, whatever is shown inside the contents area of the frame, is (unless explicitly represented otherwise) contained within the represented namespace.
 
But how does a user of the diagram know whether this option is being taken?  In any particular case, the frame may not designate a model element that is the default namespace, and yet there must be some value present for modelElementName. 
 
This name could even designate an element of namespace type.    How is that case to be recognized?The modelElementType field is optional.  Is the intent that, if a value is present for modelElementType, and is a specialization of namespace, that this is the default namespace?
 
Was the intent that in that case, the Header would not include a modelElementName?  If so, we need a concrete way to show that the modelElementName in the Header is null.
 
But what if the modelElementName field in the Header is not null, but the model element it names is not a namespace?  A case where one might want to do this is when the focus or point of the diagram revolves around some particular element owned by a namespace.  I am not advocating that, but trying to debug the spec.
 
I suspect we need one of the following:
 
1. either a constraint that requires the value in the <modelElementName> field to refer to a namespace element,
2. or a way to show that the <modelElementName> is intended to name a namespace which applies by default to any element shown within the contents area.
 
 
It also states: The top level "Model" name is the highest level namespace for the model elements.
 
Intuitively the point of this seems to be that what we call "the model" is generally the root of the namespace hierarchy for model elements. .  However, the specification of the frame, contents area, heading, and diagram description, nowhere uses the terminology "Model" name .  So it seems that this sentence is irrelevant in the present context?
 
The text describing the frame says The frame can designate a model element that is the default namespace for the model elements enclosed in the frame. This implies that a model element named in the header may not be the default namespace for the model elements, indeed it may not be a namespace at all.  But in that case, what does it signify? It is not mandatory that the frame designate a model element.
 
I conclude that the spec needs to allow that the modelElementName is  optional, and that, if present, the model element instance it names shall be an instance of a namespace metaclass, and if absent, some concretely recognizable value, such as the string "None" shall be put in that field.

In order to eliminate the ambiguity in the default namespace, a variant of resolution option 1 from the issuer is proposed. This resolution makes the model element name be mandatory in the diagram header to designate the default namespace for the model elements in the diagram content area. If the model elements in the content area are not qualified, then they belong to the namespace designated by the model element name for the model element type.

Include examples of additional feature notations in the diagram elements table for Blocks. Examples of UML notations that have not been excluded by SysML include a "/" for derived features, underline for static features, and optional visibility characters "+" "-" "#" "~".

Add the underlined notation for a static feature to the block definition example in 8.2.1.1. After discussion by the FTF, the "/" notation for derived features and visibility characters "+" "-" "#" "~" are not being included in SysML V1.0.

Part-specific type metamodel. Was reviewing the thread below and there seemed to be agreement that part-specific types needed a metamodel representation. Otherwise, there would be nothing in the repository linking the property to the part-specific type, and it will be lost in XMI interchange. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il Sent: Friday, March 24, 2006 7:06 AM To: 'Moore, Alan'; 'Branislav Selic'; Burkhart Roger M Cc: anders.ek@telelogic.com; 'Laurent L Balmelli'; 'Carolyn B Boettcher'; conrad.bock@nist.gov; 'Cory Bialowas'; Diego.Tamburini@gatech.edu; Dwayne.Hardy@2asc.com; 'Eldad Palachi'; 'Fredrick A Steiner'; 'Baker, James D (US SSA)'; jlow@ilogix.com; 'Chonoles, Michael J'; 'Friedenthal, Sanford'; 'Tim Weilkiens' Subject: RE: Anonymous types I agree. Not sure if a meta-association is needed or a Boolean tag would suffice. -----Original Message----- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com Sent: Monday, March 27, 2006 1:54 PM To: Eran Gery; Moore, Alan; Branislav Selic Cc: anders.ek@telelogic.com; Laurent L Balmelli; Carolyn B Boettcher; conrad.bock@nist.gov; Cory Bialowas; Diego.Tamburini@gatech.edu; Dwayne.Hardy@2asc.com; Eldad Palachi; (Fredrick A Steiner; Baker, James D US SSA); jlow@ilogix.com; Chonoles, Michael J; Friedenthal, Sanford; Tim Weilkiens Subject: RE: Anonymous types In the V1.0 spec, we've kept the notations for the two forms of property-specific "types" for an internal property on an internal block diagram: a type enclosed in square brackets to specialize an existing type, or a name without a colon to indicate a property that has its entire type constructed for the local usage (which Eran correctly pointed out had been included in the SST and post-merge specs.) While we've included these user-visible notations, I agree with Alan that we need more explicit ways in the metamodel to identify the types that are automatically created as a result of these mechanisms, or the properties that hold them. UML refers to these as "anonymous classes" but I agree with Bran that they're not likely to remain implicit as design proceeds, and I wonder if we should consider assigning a default name to them along with any metamodel identification. I had proposed previously that they could be given the same name as the property for which they supply the type, and a stereotype such as <propertySpecific> applied to them (which I think is the same as a boolean tag such as Eran said might be all that's needed). A related issue I think we'll need to raise in the FTF, since it's not in the current spec, is how these property-specific types can be shown in a properties compartment on a block definition diagram. Following the UML spec, which allows for the "name without a colon" case as a presentation option only on a composite structure diagram, we hadn't included the notation in our diagram extensions for a block definition diagram. That's probably an oversight; we should probably allow the same square-bracket qualification for the type of a property on a bdd just like we allow on an ibd. For the case of the entire type constructed from scratch, however, the simple name without a colon case seems to me entirely inappropriate to carry over to a bdd, so perhaps we could still allow the [ ] without a type name inside like we originally had on the ibd as well. Of course, the motivation that Eran (and Michael) have expressed to start building your design on an internal structure diagram prior to a block definition diagram means you may not care at that stage about a bdd at all, but we should adopt some way to show the same properties consistently across the diagrams regardless of likely interest or usage. For now, I just wanted to highlight the status of this issue as reflected in the draft V1.0 spec, so we can switch over to the FTF for any further resolution that may be needed. --Roger 

In the Blocks package, define a stereotype of Classifier named PropertySpecificType, with a constraint that the stereotype may be applied only to a SysML Block, UML DataType, or SysML ValueType constructed from a property-specific type specification of a SysML property.
Add a notation for the type of a property of a SysML Block or ValueType on a block definition diagram which encloses the type in square brackets just as for an internal block diagram.  Also add an option in which no type is shown between two square brackets for the type of a property on a block definition diagram, to be used for the case in which the entire type was constructed to serve as the type of the property, without any specialization from an existing classifier.

   In SysML we decided that Blocks do not have instances if I remember correctly. Therefore, could you confirm or infirm the following statement: "The composition relationship connects a block to other blocks having a role as part in the context of this block. In contrast, the association relationship connects a block to other blocks having a role as part reference in the context of this block (dashed notation)." 

        There is therefore no runtime semantic anymore (i.e. instance deletion) 

        correct or not? 

Discussion:
The issue asks for clarification only.  SysML does not impose instance semantics on composition relationships (SysML part properties) or on reference properties typed by SysML blocks, with the exception of a constraint that requires part properties to be acyclic.  The resolution to Issue 10017 clarifies that blocks define their own domain-specific semantics for part properties.
Disposition:	Closed, no change

The SysML spec says that a BDD can be used for functional decomposition because an Activity is a Class in UML. (see the end of 11.1; 11.3.1.1)

 

 

However, the spec says elsewhere that a BDD can only be for Blocks, Packages, or constraint blocks.

 

For example, Annex A.1 (p 167)

 

The following are the designated model elements

associated with the different diagram kinds.

• activity diagram - activity

• block definition diagram - block, package, or constraint block

• internal block diagram - block or constraint block

 

 

From 8.3.2, it is clear that while a block is a class, a class is not a block.             

 

From this, it is unclear how a block diagram can really (formally) be for an activity.

 

Possible solutions

 

1)       Let a bdd for any classifier 

This has the extra advantage of allowing bdd’s for actors, ports, etc.

2)       Change the annex to allow a bdd to be for activities (and perhaps actors, ports…)

3)       Change the definition of a SysML activity to be both a UML4SysML Activity and a SysML Block (probably too complicated)

 

Also the example diagrams (such as figure 11.1 and the figure in Table 11.3 row 1) should have a complete diagram header. This should at least include the model element type for the diagram (to be consistent with the solution above).

 

They should also have a «diagramUsage» if one is required (as implied by Table 11.3)

The portion of Annex A.1 referred to does not give an exhaustive list of elements allowed on each diagram.  For example, associations are supported on BDD, but these are not listed, nor are actions, control flows and other elements on activities.  The text should be clarified to indicate the list is partial.
The Block stereotype extends Class, so can be applied to any specialization of Class, including Activities.  Clarify that this is the meaning of the activity keyword on block definition diagrams.
The activities chapter should not refer to class diagrams in 11.3.1.1 and 11.3.1.4.

Issue 10031 Constraint [1] 1] A Connector or an Association must exist´between the source and the target of the InformationFlow TimWeilkiens: I think there is another option that should be allowed: An association between the supertypes of the source and the target of the InformationFlow. ConradBock: You're right, this should include inherited associations. It would be good to file an issue that identifies the places where inherited associations are ruled out unnecessarily. 

Change constraint [1] from issue 10031 to include inherited associations.

The description and constraints of the Rate stereotype refer to distributionDefinition which does not exist. can this use the distributionProperty stereotype instead? 

The support fo distribution in SysML is not currently enough to specify a distributed rate.  The semantics of the rate attribute on the Rate stereotype should be changed to indicate that the rate is the expected value.  The type of the rate attribute should be changed to ValueSpecification.

Figure 11.14 uses the value stereotype, which doesn't exist. Should be the valueType stereotype

The figure should use "valueType".

The SysML specification inadvertently omitted the join spec notation from the Diagram Elements Table in the Activities Chapter). The join spec is useful for specifying more complex control flow logic than is available with Join Nodes and Fork Nodes alone.

 

The recommendation is to include join spec notation in the concrete syntax column in JoinNode and ForkNode row of Table 11.1 of the Activities Chapter. The notation is described in Figure 12.102 in the UML Superstructure Spec under the Join Node section 12.3.34. The notation is a constraint notation in curly shown near a Join Node or the Fork Node. A specific example is provided in Figure 12.104.

Update Diagram Elements table in Activities as indicated above.  The graphic is in native frame format.  Use the Graphics ->Tools toolbar to add a text element to it.

On the copyright page (PDF 4), on the line for the National Institute of Standards and Technology 1) Change "Insitute" to "Institute" 2) Remove the word "Copyright, the copyright symbol, and the date range.

Update as described above.