Issues for Mailing list of the SysML Finalization Task Force

To comment on any of these issues, send email to sysml-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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 (sysml-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens@oose.de)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text: In Activities, Section 11.3.2.6 (Optional), Description, second sentence, after "activity" insert "(Or any behavior)".
Actions taken:
May 10, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9757: 7.3.1.2, last sentence (sysml-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens@oose.de)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Chapter 7.3.1.2: Remove sentence: Dependency subtypes that are imported from UML are defined in the respective chapters where they are used.
Actions taken:
May 23, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 9758: Fig. 7.2: (sysml-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens@oose.de)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 23, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9759: Fig. 7.3: (sysml-ftf)

Click here for this issue's archive.
Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens@oose.de)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 23, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9761: Include subsections to sections 2.1 and 2.2 (sysml-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9762: Section 17.4.1 Fig. 17-5 (sysml-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: In Fig 17.5, change the diagram name from "SysML MetaModel" to "User Profile Definition"
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9764: Section 10.3.2.1 (sysml-ftf)

Click here for this issue's archive.
Source: Georgia Institute of Technology (Dr. Russell Peak, russell.peak@gatech.edu)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9765: Section 1.4 (sysml-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: reeived issue
July 30, 2007: closed issue

Discussion:

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

Issue 9766: Section 8.4 - add figure (sysml-ftf)

Click here for this issue's archive.
Source: Georgia Institute of Technology (Dr. Russell Peak, russell.peak@gatech.edu)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9767: XMI section (sysml-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 9768: Include index into the specification (sysml-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Include index into the specification

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

Index to be created

Issue 9769: Appendix E, last column in table (sysml-ftf)

Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Replace all Text for Annex E with the following The OMG SysML requirements traceability matrix traces the requirements from this specification to the original source requirements in the UML for System Engineering RFP (ad/03-03-41). The traceability matrix is included by reference in a separate document (OMG Doc ID)
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9770: General - Stereotypes (sysml-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

Separate definition from description

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9772: Editorial general issue (sysml-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9773: Change UML 2.0 to UML 2.1 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

Change UML 2.0 reference to UML 2.1 throughout the document

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9774: "Change ""ISO AP233"" to ISO 10303-233 STEP AP233 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Changes in D_XMIandAP233.fm Change Section titles D.4, D.4.1, D.4.2, D.4.3.2, D.4.4, D.4.5 From AP2333 To ISO 10303 STEP AP233 Changes in frontmatter.fm Change Section 3, page 5 line from ISO STEP AP233 To ISO 10303 STEP AP233
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

Change to be made in 7 locations

Issue 9775: references (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Revision
Severity:
Summary:

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

Resolution:
Revised Text: Change to be made in front_matter.fm file, Section 2 normative references. Delete completely the following line UML 2.0 Superstructure Specification (OMG document number formal/05-07-04) Change the following line from UML 2.0 Infrastructure Specification (OMG document number ptc/04-10-14) To UML 2.1 Infrastructure v.2.1.1 (OMG document number formal/07-02-06)
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

Changes to be made

Issue 9777: Page 36 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

Added Space as requested

Issue 9780: Add clarification of how to represent non-depletable stores in ibd as part (sysml-ftf)

Source: Ceira Technologies, Inc. (Mr. Michael Allen Latta, mlatta@ceira.com mlatta@cogility.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Update figure B.18 as follows: Add text in B.4.5.5 as follows: "Figure B-19 shows how the parts of the PowerSubsystem block, as defined in the diagram above, are used. It shows "connectors" between parts, "clientServerPorts", "flowPorts", "atomicFlowPorts", and "itemFlows". The dashed borders on FrontWheel and BrakePedal denote the "use-not-composition" relationship depicted elsewhere in Figure B-16 and Figure B-18. The dashed borders on Fuel denote a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in figure B.18." Update figure B.19 as follows: Add the following text to B.4.6.5: "Figure B-25 shows how the connectors fuelDelivery and fdist on Figure B-19 have been expanded to include design detail. The fuelDelivery connector is actually two connectors, one carrying fuelSupply and the other carrying fuelReturn. The fdist connector inside the InternalCombustionEngine block has been expanded into the fuel regulator and fuel rail parts. These more detailed design elements are related to the original connectors using the allocation relationship. The Fuel store represent a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the fuelReturnLine." Update figure B.25 as follows:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 9781: General Diagram Elements (sysml-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: In Section 7.2 Diagram Elements, add the following paragraph: Many of the diagram elements defined in this chapter, specifically comments, constraints, problem, rationale, and dependencies, including the dependency subtypes Conform, Realization, and Refine, may be shown on all SysML diagram types, in addition to the diagram elements which are specific to each diagram type. In Section 15.2 Diagram Elements, add the following paragraph: The diagram elements defined in this chapter may be shown on some or all of the SysML diagram types, in addition to the diagram elements which are specific to each diagram type.
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 9782: Section 8.3.2.4 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

Constraint [1] is not very clear. Please clarify

Resolution:
Revised Text: See resolution for Issue 10015.
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9783: Section 10.3.2.1 constraint block (sysml-ftf)

Click here for this issue's archive.
Source: Deere & Company (Mr. Roger Burkhart, burkhartrogerm@johndeere.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9784: Blocks (sysml-ftf)

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Sanford A. Friedenthal, sanford.friedenthal@lmco.com sfriedenthal@comcast.net)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9785: Section 7.3.2.4 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Change description of 7.3.2.4 View from: A view is a representation of a whole system from the perspective of a single viewpoint. To A view is a representation of a whole system or subsystem from the perspective of a single viewpoint.
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 9786: Section 7.3.2.5 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received isuse
July 30, 2007: closed issue

Discussion:

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.

Issue 9787: page 42, ist paragraph (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9788: page 44 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please add example(s) for NestedConnectorEnd

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9789: page 86 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

Clarify the line style for ControlFlow (last table row)

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9790: page 94 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9791: page 137 (sysml-ftf)

Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe@88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: In Table 16.2: remove the half circles on the elements that have a comment attached. On page 138 rows 3 and 5, on page 139 rows 1, 3 and 5, on page 140 row 1.
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9792: figure 11-14 (sysml-ftf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore@mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Delete last sentence in section 15.4.2, which reads "Independent of the ObjectFlow allocation, it may be valuable to allocate the corresponding ObjectNode to an ItemProperty associated with the ItemFlow."
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9793: Section 15.3.2.3 (sysml-ftf)

Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Section 15.3.2.3 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." 2- Change the Constraints paragraph to read: "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. In the "AllocateActivityPartition" name field, Properties are designated by the use of a fully qualified name (including colon, e.g. "part_name:Block_Name"), and Classifiers are designated by a simple name (no colons, e.g. "Block_Name"). The "AllocateActivityPartition" maintains the constraints, but not the semantics, of the UML2::ActivityPartition. Classifiers or Properties represented by an "AllocateActivityPartition" do not have any direct responsibility for invoking behavior depicted within the partition boundaries. To depict this kind of direct responsibility, the modeler is directed to the UML 2.0 Superstructure specification, OMG formal/05-07-04, section 12.3.10 ActivityPartition, Semantics topic." 3- Replace Figure 15.4 with the following figure: 4 - Replace the following diagram in Table 15.1 Line 5 Line 6
Actions taken:
May 25, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9804: Model Elements sub-profile depends only on UML4SYML Level 1, not 3. (sysml-ftf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore@mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: In table 5.4, 6th row, first column Replace "Model Elements (without View)" by "Model Elements" In table 5.4, remove 7th row. In table 5.5, 9th row, first column Replace "Model Elements (without View)" by "Model Elements" In table 5.5, remove 10th row.
Actions taken:
June 6, 2006: received issue
July 30, 2007: clsoed issue

Discussion:

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

Issue 9836: Invalid redefinition on stereotype extensions (sysml-ftf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text: Modify Figure 9.1 to remove relationship between FlowSpecification and FlowProperty Add Constraint to Section 9.3.2.7 that reads, "Owned Attribute of a FlowSpecification is a FlowProperty."
Actions taken:
June 23, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9837: Freeform diagrams in SysML (sysml-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic@acm.org selicb@ca.ibm.com bran.selic@gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9844: table 7.2, page 26, PublicPackageImport (sysml-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Morgan Bjorkander, morgan.bjorkander@telelogic.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: In Table 7.2, row PublicPackageImport, column Abstract Syntax Reference: Replace "ElementImport" by "PackageImport".
Actions taken:
June 26, 2006: received issue
July 30, 2007: clsoed issue

Discussion:

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

Issue 9845: table 7.2, page 26, PrivatePackageImport (sysml-ftf)

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

Resolution:
Revised Text: In Table 7.2, row PrivatePackageImport, column Abstract Syntax Reference: Replace "ElementImport" by "PackageImport".
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9846: table 7.2, page 26, PackageContainment (sysml-ftf)

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

Resolution:
Revised Text:
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 9847: §7.3.2, page 28 (sysml-ftf)

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:
Revised Text:
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 9848: §7.3.2, page 28, since View extends Package, it also extends Model (sysml-ftf)

  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:
Revised Text:
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 9849: table 14.2, page 117, Include should list UML4SysML::Include (sysml-ftf)

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

Resolution:
Revised Text: n Table 14.2, the first row on page 117 (second row of the table), the Abstract Syntax Reference column Replace Subclass of UML4SysML::Directed Relationship With UML4SysML::Include
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Correct the abstract syntax reference

Issue 9850: table 14.2, page 117, Exclude should list UML4SysML::Exclude (sysml-ftf)

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

Resolution:
Revised Text: In Table 14.2, the second row on page 117 (third row of the table), the Abstract Syntax Reference column Replace Subclass of UML4SysML::Directed Relationship With UML4SysML::Extend
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 9851: table 14.2, page 117, ExtendWithCondition should list UML4SysML::Extend (sysml-ftf)

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

Resolution:
Revised Text: In Table 14.2, the third row on page 117 (fourth row of the table), the Abstract Syntax Reference column Replace Subclass of UML4SysML::Directed Relationship With UML4SysML::Extend
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Correct the abstract syntax reference for Extend With Condition.

Issue 9852: table 14.2, page 117, Subject should list UML4SysML::UseCase::subject (sysml-ftf)

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

Resolution:
Revised Text: In Table 14.1, the fourth row on page 116, the Abstract Syntax Reference column Replace Role Name on Classifier With Role name on UML4SysML::Classifier 06-04-02 page 614 (634 of 772)
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Correct the abstract syntax reference

Issue 9853: §15.4.3, page 133 (sysml-ftf)

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.

Resolution:
Revised Text:
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9854: §A.1, page 167 (sysml-ftf)

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?

Resolution:
Revised Text: In Appendix A.1 on pg 168, Change From: [Note: The use of stereotype for diagram usage is not formally part of UML since a diagram is not currently a model element that can be extended. However, the analogy was considered to be of value and adapted for this use.] Change To: [Note: A diagram is not a metaclass in UML or SysML and therefore cannot be extended by a stereotype. However, the concept of extending a diagram for a particular diagram usage was considered to be of value. The stereotype notation is used to designate this concept without the formal semantics.] Additional Change: In the 3rd paragraph on pg 168 of Appendix A.1, replace the brackets in the two references to <<diagramUsage>> and the single reference to <<ContextDiagram>> with the appropriate stereotype symbol " diagramUsage" and "ContextDiagram".
Actions taken:
June 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 9876: Figure 9.2 (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
June 28, 2006: received issue
September 19, 2007: closed issue

Issue 9880: UML Profile-based conformance (sysml-ftf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 30, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 10002: Section: Appendix B.4.5 (sysml-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: Change "Sybsystem" to "Subsystem"
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 10008: Section: Activities (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution:
Revised Text: Create a new section model libraries section for activities, as there are for some of the other chapters, and move Control Value to it.
Actions taken:
July 29, 2006: received isuse
July 30, 2007: closed issue

Discussion:

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

Issue 10009: Section: Blocks - Internal block diagrams for associations (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution:
Revised Text: In Blocks, Section 8.1 (Overview), last paragraph, next-to-last sentence, Replace "reusable forms of constraints and" with "reusable forms of constraints, " At end of the sentence, add ", participant properties for composite association classes, and connector properties". Table 8.2 (Graphical paths defined by in Block Definition diagrams) after MultibranchShared Association, add two rows as shown below: ParticipantProperty UML4SysML:: Property, UML4SysML:: AssociationClass ConnectorProperty UML4SysML:: Property, UML4SysML:: Connector Section 8.3.1.4 (UML Diagram Elements not Included in SysML Block Definition Diagrams) first paragraph, remove the last three sentences. In the last sentence which remains, change "An "X" on the end of an association" to "An "X" on a single end of an association". Section 8.3.2 (Stereotypes), in Figure 8.3, add ParticipantProperty and ConnectorProperty as shown below: Section 8.3.2 (Stereotypes) add the following two new subsections: 8.3.2.?? ParticipantProperty Description The Block stereotype extends Class, so can be applied to any specialization of Class, including Association Classes. These are informally called "association blocks". An association block can own properties and connectors, like any other block. Each instance of an association block can link together instances of the end classifiers of the association. To refer to linked objects and values of an instance of an association block, it is necessary for the modeler to specify which (participant) properties of the association block identify the instances being linked at which end of the association. The value of a participant property on an instance (link) of the association block is the value or object at the end of the link corresponding to this end of the association. Participant properties can be the ends of connectors owned by an association block. The association block can be the type of multiple other connectors to reuse the same internal structure for all the connectors. The keyword "participant" before a property name indicates the property is stereotyped by ParticipantProperty. The types of participant properties can be elided if desired. They are always the same as the corresponding association end type. Attributes § end : Property [1] A member end of the association block owning the property on which the stereotype is applied. Constraints [1] ParticipantProperty may only be applied to properties of association classes stereotyped by Block. [2] ParticipantProperty may not be applied to properties that are member ends of an association. [3] The aggregation of a property stereotyped by ParticipantProperty must be none. [4] The end attribute of the applied stereotype must refer to a member end of the association block owning the property on which the stereotype is applied. [5] A property stereotyped by ParticipantProperty must have the same type as the property referred to by the end attribute. [6] The property referred to by end must have an upper multiplicity of 1. 8.3.2.?? ConnectorProperty Description Connectors can be typed by association classes that are stereotyped by Block (association blocks, see 8.3.2.??, ParticipantProperty). These connectors specify instances (links) of the association block that exist due to instantiation of the block owning or inheriting the connector. The value of a connector property on an instance of a block will be exactly those link objects that are instances of the association block typing the connector referred to by the connector property. A connector property can optionally be shown in an internal block diagram with a dotted line from the connector line to a rectangle notating the connector property. The keyword "connector" before a property name indicates the property is stereotyped by ConnectorProperty. Attributes § connector : Connector [1] A connector of the block owning the property on which the stereotype is applied. Constraints [1] ConnectorProperty may only be applied to properties of classes stereotyped by Block. [2] The connector attribute of the applied stereotype must refer to a connector owned or inherited by a block owning the property on which the stereotype is applied. [3] The aggregation of a property stereotyped by ConnectorProperty must be composite. [4] The type of the connector referred to by a connector attribute must be an association class stereotyped by Block. [5] A property stereotyped by ConnectorProperty must have the same name and type as the connector referred to by the connector attribute. Renumber Section 8.4.1.1 to 8.4.2, and Section 8.4.1.2 to 8.4.3, promoting the heading style up one level. After Section 8.4.1.2 (Design Configuration for SUV EPA Fuel Economy Test, renumbered to 8.4.3) add a new usage example section as follows: 8.4.4 Water delivery Figure 8-??1 shows an association block Water Delivery between a bank of spigots and a faucet. Figure 8-??2 shows the internal structure of Water Delivery defining connectors between the spigots in the bank and inlets on the faucet. The participant properties identify the spigot bank and faucet being connected. The end property on the stereotype refers to the corresponding association end in Figure 8-??1. The type of participant properties is shown for clarity, but it is always the same as the association end type and can be elided. They are notated as dashed rectangles because they are reference properties. The internal structure connects hot and cold properties of the participants. Figure 8-??1 Figure 8-??2 Figure 8-??3 shows two views of a block House with a connector of type Water Delivery. The connector in the top view "decomposes" into the subconnectors in the lower view according to the internal structure of WATER Delivery. The subconnectors relate the nested properties of :WaterSupply to the nested properties of :WaterClient. Figure 8-??3 The top portion of Figure 8-??4 shows specializations of the block WaterClient into Bath, Sink, and Shower. These are used as part types in the internal structure of the block House 2 shown in the lower portion of the figure. The composite connector for Water Delivery is reused three times to establish connections between spigots on the water supply and the inlets of faucets on the bath, sink, and shower. Figure 8-??4 Figure 8-??4 modifies Figure 8-??1 to add an association block Plumbing for the association between Spigot and Faucet Inlet. Figure 8-??5 shows the internal structure for Plumbing, which includes a pipe and two fittings (the classes and associations for these parts and connectors are omitted for brevity). Figure 8-??6 modifies Figure 8-??2 to use Plumbing as a connector type. The lower connector shows its connector property explicity, enabling the pipe it contains to be connected to a mounting bracket (the additional types and associations are omitted for brevity). Figure 8-??5 Figure 8-??6 Figure 8-??7
Actions taken:
July 29, 2006: received issue
July 30, 2007: closed issue

Discussion:

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.

Issue 10010: Section: Blocks - Stereotype for binding connector (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution:
Revised Text: Replace Figure 8.5 by the following updated diagram and caption: Figure 8-5. Abstract syntax extensions for SysML connectors and connector ends. In Table 8.4 - Graphical paths defined in Internal Block Diagrams, replace the existing contents of the Concrete Syntax Example column in the BindingConnector row by the following: Add a suitably numbered subsection to Section 8.3.2 Stereotypes, with the following contents: 8.3.2.1 Binding Connector Description A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values. If the properties at the ends of a binding connector are typed by a DataType or ValueType, the connector specifies that the instances of the properties must hold equal values, recursively through any nested properties within the connected properties. If the properties at the ends of a binding connector are typed by a Block, the connector specifies that the instances of the properties must refer to the same block instance. Constraints [1] The two ends of a binding connector must have either the same type or types that are compatible so that equality of their values can be defined.
Actions taken:
July 29, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 10011: Section: Blocks - Definition of binding connector (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution:
Revised Text: see resolution to 10010
Actions taken:
July 29, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 10012: Section: Activities - Timing diagram in Activities (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution:
Revised Text: In Activities, Section 11.1.1.1 Continuous Systems, unnumbered subheading Timelines, replace the paragraph under it with: "The simple time model in UML can be used to represent timing and duration constraints on actions in an activity model. These constraints can be notated as constraint notes in an activity diagram. Although UML 2 timing diagram was not included in this version of SysML, it can complement SysML behavior diagrams to notate this information. More sophisticated SysML modeling techniques can incorporate constraint blocks from Chapter 10, "Constraint Blocks" to specify resource and related constraints on the properties of the inputs, outputs, and other system properties. (Note: refer to "ObjectNode" on page 91 for constraining properties of object nodes)."
Actions taken:
July 29, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 10013: Section: Blocks - Unit base class. (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution:
Revised Text: see 10015
Actions taken:
July 29, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 10014: Section: Blocks - Unit base class (02) (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution:
Revised Text: see 10015
Actions taken:
July 29, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 10015: Section: Blocks - Dimension and Unit Base Class (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text: Add the following two rows at the end of Table 8.1, Graphical nodes defined in Block Definition Diagrams: Replace Figure 8.4 by the following diagram: Replace the second paragraph in Section 8.3.2.4 Dimension, which currently reads: Dimension is defined as a stereotype of ValueType, but it may not be used directly to declare the type of any value. The only valid use of a Dimension instance is to be referenced by the "dimension" property of a ValueType stereotype. by the following replacement text: Dimension is defined as a stereotype of InstanceSpecification, but it uses this metaclass only to define supporting elements for ValueType definitions. (The reuse of InstanceSpecification to define another metaclass is similar to the EnumerationLiteral metaclass in UML .) The only valid use of a Dimension instance is to be referenced by the "dimension" property of a ValueType or Unit stereotype Delete the Constraints subheading and text from Section 8.3.2.4 Dimension. Replace the second paragraph in Section 8.3.2.6 Unit, which currently reads: Unit is defined as a stereotype of ValueType, but it may not be used directly to declare the type of any value. The only valid use of a Unit instance is to be referenced by the "unit" property of a ValueType stereotype. Constraints [1]The "unit" attribute inherited from the ValueType stereotype must not contain any value. (The "dimension" attribute may be used to declare the dimension that the unit is declared to measure.) by the following replacement text: Unit is defined as a stereotype of InstanceSpecification, but it uses this metaclass only to define supporting elements for ValueType definitions. (The reuse of InstanceSpecification to define another metaclass is similar to the EnumerationLiteral metaclass in UML .) The only valid use of a Unit instance is to be referenced by the "unit" property of a ValueType stereotype. Delete the Constraints subheading and text from Section 8.3.2.6 Unit. Delete the first two constraints in the Constraints subsection in Section 8.3.2.7 ValueType, and renumber the one remaining constraint.
Actions taken:
July 29, 2006: received issue
July 30, 2007: closed issue

Discussion:

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

Issue 10016: Section: Blocks - Block constraint [2]. (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution:
Revised Text: Change the first sentence of Constraint [2] in Section 8.3.2.1 Block to the following: The number of ends of a connector owned by a block must be exactly two.
Actions taken:
July 29, 2006: received issue
July 30, 2007: closed issue

Discussion:

Change text to indicate this restriction.

Issue 10017: Section: Blocks - Definition of part properties (sysml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Clarification
Severity: Critical
Summary:

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?

Resolution:
Revised Text: In Table 8.3 in Section 8.2.2.1 Graphical nodes and paths, in the row with "BlockProperty" in the Element Name column, replace "BlockProperty" by "Property" and in the Abstract Syntax Reference column of this same row, replace "SysML::Blocks::BlockProperty" by "UML4SysML::Property". Replace Figure 8.3 by a new diagram that eliminates the BlockProperty stereotype. Issues 10009 and 10022 all assume an updated metamodel for stereotypes of Property in SysML. See those issues for updated contents for Figure 8.3. in 8.3.1.3 Internal Block Diagram, which currently reads: Three general categories of properties are recognized in SysML: parts, references and value properties (see 8.3.2.2 Block Property below). 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. replace "8.3.2.2 BlockProperty" by "8.3.2.1 Block". Under the subsection PropertyPathName in 8.3.1.3 Internal Block Diagram, add the following sentence at the end of the first paragraph: If any of the properties named in the path name string identifies a reference property, the property box is shown with a dashed-outline box, just as for any reference property on an internal block diagram. Add the following paragraphs at the end of Section 8.3.2.1 Block: 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. On a block definition diagram, a part property is shown by a black diamond symbol on an association. As in UML, an instance of a block may be included in at most one part property at a time. A part property typically holds instances that belong to a larger whole. Typically, a part-whole relationship means that certain operations that apply to the whole also apply to each of the parts. For example, if a whole represents a physical object, a change in position of the whole could also change the position of each of the parts. A property of the whole such as its mass could also be implied by its parts. Operations and relationships which apply to parts typically apply transitively across all parts of these parts, through any number of levels. A particular application domain may establish its own interpretation of part-whole relationships across the blocks defined in a particular model, including the definition of operations that apply to the parts along with the whole. For software object