${taskforce.name} Avatar
  1. OMG Task Force

SysML FTF — All Issues

  • Key: SYSML
  • Issues Count: 115
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML-19 Page 36 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-18 What does <> mean? SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-17 references SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-16 "Change ""ISO AP233"" to ISO 10303-233 STEP AP233 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-15 Change UML 2.0 to UML 2.1 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-14 Editorial general issue SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-13 General - Stereotypes SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-12 Appendix E, last column in table SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-11 Include index into the specification SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-115 Section: Copyright page SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-114 Issue – omission of join spec notation in activities diagram element table SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-113 Figure 11.14 uses the value stereotype, which doesn't exist SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-112 Section: Activities SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-111 Section: 9.3.2.8 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-110 SysML:Usiing a BDD for Activities SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-109 composition relationship between blocks SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-108 Part-specific type metamodel - Section: Blocks SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-107 Section: 8.2.1.1 Blocks Diagram Elements Table SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-106 plug a gap wrt how to recognize diagrams that come with a default namespace SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-105 Section: 8.2.1.1 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-104 Section: 7.4 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-103 figure C2 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-102 restriction on no more than 1 item property per item flow is unclear SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-101 SysML: SI units SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-100 SysML: Viewpoint and Actors SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-99 Sysml: Views can own Views SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-98 partial list of dependencies SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-97 SysML: Unicode / Translations SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-96 SysML: Appendix G SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-95 Figure B.35 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-94 figure B.19 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-93 Sysml: SST SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-92 SysML: Instance Diagrams SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-91 SysML: USe Case Diagram SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-90 SysML: The The SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-89 SysML: of of SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-88 SysML: Behavior or Behaviour SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-87 SysML:Requirment-->Requirements SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-86 SysML:table 5.4 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-85 SysML: Copyright page SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-84 SysML: Section 8.3.1.4 Datatye SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-83 SysML: Remaining UML 2.0 references SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-82 Section: Requirements - Backslash typos SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-81 Section: Constraint Blocks - Parameters of constraint properties SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-80 Section: Constraint Blocks - Binding connectors in constraint blocks SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-79 Section: Ports and Flows - Flow property constraint [3]. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-78 Section: Ports and Flows - Flow property values wording SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-77 Section: Ports and Flows - Flow port isAtomic derivation SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-76 Section: Ports and Flows - Flow ports direction for non-atomic ports SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-75 Section: Ports and Flows - Flow ports semantic variation SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-74 Section: Ports and Flows - Relaying to properties SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-73 Section: Ports and Flows - Relaying instances. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-72 Section: Ports and Flows - ItemFlow constraints [1] and [3]. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-71 Section: Ports and Flows - ItemFlow constraint [4]. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-70 Section: Ports and Flows - ItemFlow constraint [2]. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-69 Section: Ports and Flows - ItemFlow constraint [5] SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-68 Section: Ports and Flows - FlowPort constraints [2] and [3]. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-67 Section: Ports and Flows - ItemFlow itemProperty type SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-66 Section: Ports and Flows - Flow Ports overview 9.1.2 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-65 Section: Ports and Flows - the term "Standard Port" is a misnomer SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-64 Section: Blocks - propertyPath definition SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-63 Section: Blocks - DistributedProperty stereotype of stereotype SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-62 Section: Blocks - Aggregation. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-61 Section: Blocks - Definition of part properties SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-60 Section: Blocks - Block constraint [2]. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-59 Section: Blocks - Dimension and Unit Base Class SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-58 Section: Blocks - Unit base class (02) SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-57 Section: Blocks - Unit base class. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-56 Section: Activities - Timing diagram in Activities SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-55 Section: Blocks - Definition of binding connector SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-54 Section: Blocks - Stereotype for binding connector SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-53 Section: Blocks - Internal block diagrams for associations SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-52 Section: Activities SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-51 Section: Appendix B.4.5 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-50 UML Profile-based conformance SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-49 Figure 9.2 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-48 §A.1, page 167 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-47 §15.4.3, page 133 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-46 table 14.2, page 117, Subject should list UML4SysML::UseCase::subject SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-45 table 14.2, page 117, ExtendWithCondition should list UML4SysML::Extend SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-44 table 14.2, page 117, Exclude should list UML4SysML::Exclude SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-43 table 14.2, page 117, Include should list UML4SysML::Include SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-42 §7.3.2, page 28, since View extends Package, it also extends Model SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-41 §7.3.2, page 28 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-40 table 7.2, page 26, PackageContainment SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-39 table 7.2, page 26, PrivatePackageImport SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-38 table 7.2, page 26, PublicPackageImport SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-37 Freeform diagrams in SysML SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-36 Invalid redefinition on stereotype extensions SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-35 Model Elements sub-profile depends only on UML4SYML Level 1, not 3. SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-34 regarding the <> stereotype in the Requirements package SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-33 Section 15.3.2.3 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-32 figure 11-14 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-31 page 137 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-30 page 94 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-29 page 86 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-28 page 44 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-27 page 42, ist paragraph SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-26 Section 7.3.2.5 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-25 Section 7.3.2.4 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-24 Blocks SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-23 Section 10.3.2.1 constraint block SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-22 Section 8.3.2.4 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-21 General Diagram Elements SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-20 Add clarification of how to represent non-depletable stores in ibd as part SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-2 7.3.1.2, last sentence SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-1 chapter 11.3.2.6 Optional SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-7 Section 10.3.2.1 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-6 Section 17.4.1 Fig. 17-5 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-5 Include subsections to sections 2.1 and 2.2 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-10 XMI section SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-9 Section 8.4 - add figure SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-8 Section 1.4 SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-4 Fig. 7.3: SysML 1.0b1 SysML 1.0 Resolved closed
SYSML-3 Fig. 7.2: SysML 1.0b1 SysML 1.0 Resolved closed

Issues Descriptions

Page 36

  • Key: SYSML-19
  • Legacy Issue Number: 9777
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What does <> mean?

  • Key: SYSML-18
  • Legacy Issue Number: 9776
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

references

  • Key: SYSML-17
  • Legacy Issue Number: 9775
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Change ""ISO AP233"" to ISO 10303-233 STEP AP233

  • Key: SYSML-16
  • Legacy Issue Number: 9774
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • 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
    "

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change UML 2.0 to UML 2.1

  • Key: SYSML-15
  • Legacy Issue Number: 9773
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    Change UML 2.0 reference to UML 2.1 throughout the document

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial general issue

  • Key: SYSML-14
  • Legacy Issue Number: 9772
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • 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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

General - Stereotypes

  • Key: SYSML-13
  • Legacy Issue Number: 9770
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

    Separate definition from description

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix E, last column in table

  • Key: SYSML-12
  • Legacy Issue Number: 9769
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Include index into the specification

  • Key: SYSML-11
  • Legacy Issue Number: 9768
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

    Include index into the specification

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Copyright page

  • Key: SYSML-115
  • Legacy Issue Number: 10623
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Thu, 25 Jan 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue – omission of join spec notation in activities diagram element table

  • Key: SYSML-114
  • Legacy Issue Number: 10595
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Tue, 16 Jan 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 11.14 uses the value stereotype, which doesn't exist

  • Key: SYSML-113
  • Legacy Issue Number: 10585
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

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

  • Reported: SysML 1.0b1 — Tue, 9 Jan 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: SYSML-112
  • Legacy Issue Number: 10584
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

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

  • Reported: SysML 1.0b1 — Tue, 9 Jan 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.2.8

  • Key: SYSML-111
  • Legacy Issue Number: 10514
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Mon, 18 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML:Usiing a BDD for Activities

  • Key: SYSML-110
  • Legacy Issue Number: 10447
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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)

  • Reported: SysML 1.0b1 — Thu, 9 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

composition relationship between blocks

  • Key: SYSML-109
  • Legacy Issue Number: 10445
  • Status: closed  
  • Source: International Business Machines ( Laurent Balmelli)
  • Summary:

    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?

  • Reported: SysML 1.0b1 — Tue, 7 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Part-specific type metamodel - Section: Blocks

  • Key: SYSML-108
  • Legacy Issue Number: 10385
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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

  • Reported: SysML 1.0b1 — Fri, 6 Oct 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2.1.1 Blocks Diagram Elements Table

  • Key: SYSML-107
  • Legacy Issue Number: 10381
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    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 "+" "-" "#" "~".

  • Reported: SysML 1.0b1 — Tue, 3 Oct 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

plug a gap wrt how to recognize diagrams that come with a default namespace

  • Key: SYSML-106
  • Legacy Issue Number: 10378
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Fri, 29 Sep 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2.1.1

  • Key: SYSML-105
  • Legacy Issue Number: 10085
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    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

  • Reported: SysML 1.0b1 — Mon, 7 Aug 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.4

  • Key: SYSML-104
  • Legacy Issue Number: 10078
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure C2

  • Key: SYSML-103
  • Legacy Issue Number: 10075
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

restriction on no more than 1 item property per item flow is unclear

  • Key: SYSML-102
  • Legacy Issue Number: 10072
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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)

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: SI units

  • Key: SYSML-101
  • Legacy Issue Number: 10071
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: Viewpoint and Actors

  • Key: SYSML-100
  • Legacy Issue Number: 10070
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sysml: Views can own Views

  • Key: SYSML-99
  • Legacy Issue Number: 10069
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

partial list of dependencies

  • Key: SYSML-98
  • Legacy Issue Number: 10068
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: Unicode / Translations

  • Key: SYSML-97
  • Legacy Issue Number: 10067
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: Appendix G

  • Key: SYSML-96
  • Legacy Issue Number: 10066
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure B.35

  • Key: SYSML-95
  • Legacy Issue Number: 10065
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure B.19

  • Key: SYSML-94
  • Legacy Issue Number: 10064
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sysml: SST

  • Key: SYSML-93
  • Legacy Issue Number: 10063
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: Instance Diagrams

  • Key: SYSML-92
  • Legacy Issue Number: 10062
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Section G.5.3 Diagram Elements defined in Instance Diagram

    What Instance Diagram?

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: USe Case Diagram

  • Key: SYSML-91
  • Legacy Issue Number: 10056
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: The The

  • Key: SYSML-90
  • Legacy Issue Number: 10055
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: of of

  • Key: SYSML-89
  • Legacy Issue Number: 10054
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Duplicate “of of” in figure 11.11 (hmm)

    In guard condition in upper right

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: Behavior or Behaviour

  • Key: SYSML-88
  • Legacy Issue Number: 10053
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Behaviour appears 4 times

    Behavior appears 209 times.

    Pick one

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML:Requirment-->Requirements

  • Key: SYSML-87
  • Legacy Issue Number: 10052
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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)

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML:table 5.4

  • Key: SYSML-86
  • Legacy Issue Number: 10051
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Table 5.4 second line

    probability -> probability

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: Copyright page

  • Key: SYSML-85
  • Legacy Issue Number: 10050
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Insitute à Institute

    Misspelling

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: Section 8.3.1.4 Datatye

  • Key: SYSML-84
  • Legacy Issue Number: 10049
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    DataTyeàDataType

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: Remaining UML 2.0 references

  • Key: SYSML-83
  • Legacy Issue Number: 10046
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Requirements - Backslash typos

  • Key: SYSML-82
  • Legacy Issue Number: 10043
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Constraint Blocks - Parameters of constraint properties

  • Key: SYSML-81
  • Legacy Issue Number: 10041
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Constraint Blocks - Binding connectors in constraint blocks

  • Key: SYSML-80
  • Legacy Issue Number: 10040
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - Flow property constraint [3].

  • Key: SYSML-79
  • Legacy Issue Number: 10039
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - Flow property values wording

  • Key: SYSML-78
  • Legacy Issue Number: 10038
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - Flow port isAtomic derivation

  • Key: SYSML-77
  • Legacy Issue Number: 10037
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - Flow ports direction for non-atomic ports

  • Key: SYSML-76
  • Legacy Issue Number: 10036
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - Flow ports semantic variation

  • Key: SYSML-75
  • Legacy Issue Number: 10035
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - Relaying to properties

  • Key: SYSML-74
  • Legacy Issue Number: 10034
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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?

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - Relaying instances.

  • Key: SYSML-73
  • Legacy Issue Number: 10032
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - ItemFlow constraints [1] and [3].

  • Key: SYSML-72
  • Legacy Issue Number: 10031
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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?

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - ItemFlow constraint [4].

  • Key: SYSML-71
  • Legacy Issue Number: 10030
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - ItemFlow constraint [2].

  • Key: SYSML-70
  • Legacy Issue Number: 10029
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - ItemFlow constraint [5]

  • Key: SYSML-69
  • Legacy Issue Number: 10028
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - FlowPort constraints [2] and [3].

  • Key: SYSML-68
  • Legacy Issue Number: 10027
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - ItemFlow itemProperty type

  • Key: SYSML-67
  • Legacy Issue Number: 10026
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - Flow Ports overview 9.1.2

  • Key: SYSML-66
  • Legacy Issue Number: 10025
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Ports and Flows - the term "Standard Port" is a misnomer

  • Key: SYSML-65
  • Legacy Issue Number: 10024
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - propertyPath definition

  • Key: SYSML-64
  • Legacy Issue Number: 10023
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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)

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - DistributedProperty stereotype of stereotype

  • Key: SYSML-63
  • Legacy Issue Number: 10022
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - Aggregation.

  • Key: SYSML-62
  • Legacy Issue Number: 10021
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - Definition of part properties

  • Key: SYSML-61
  • Legacy Issue Number: 10017
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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?

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - Block constraint [2].

  • Key: SYSML-60
  • Legacy Issue Number: 10016
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - Dimension and Unit Base Class

  • Key: SYSML-59
  • Legacy Issue Number: 10015
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - Unit base class (02)

  • Key: SYSML-58
  • Legacy Issue Number: 10014
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - Unit base class.

  • Key: SYSML-57
  • Legacy Issue Number: 10013
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Timing diagram in Activities

  • Key: SYSML-56
  • Legacy Issue Number: 10012
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - Definition of binding connector

  • Key: SYSML-55
  • Legacy Issue Number: 10011
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - Stereotype for binding connector

  • Key: SYSML-54
  • Legacy Issue Number: 10010
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Blocks - Internal block diagrams for associations

  • Key: SYSML-53
  • Legacy Issue Number: 10009
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: SYSML-52
  • Legacy Issue Number: 10008
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix B.4.5

  • Key: SYSML-51
  • Legacy Issue Number: 10002
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Profile-based conformance

  • Key: SYSML-50
  • Legacy Issue Number: 9880
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • 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

  • Reported: SysML 1.0b1 — Fri, 30 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 9.2

  • Key: SYSML-49
  • Legacy Issue Number: 9876
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • 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.

  • Reported: SysML 1.0b1 — Wed, 28 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

§A.1, page 167

  • Key: SYSML-48
  • Legacy Issue Number: 9854
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

    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?

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

§15.4.3, page 133

  • Key: SYSML-47
  • Legacy Issue Number: 9853
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

table 14.2, page 117, Subject should list UML4SysML::UseCase::subject

  • Key: SYSML-46
  • Legacy Issue Number: 9852
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

table 14.2, page 117, ExtendWithCondition should list UML4SysML::Extend

  • Key: SYSML-45
  • Legacy Issue Number: 9851
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

table 14.2, page 117, Exclude should list UML4SysML::Exclude

  • Key: SYSML-44
  • Legacy Issue Number: 9850
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

table 14.2, page 117, Include should list UML4SysML::Include

  • Key: SYSML-43
  • Legacy Issue Number: 9849
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

§7.3.2, page 28, since View extends Package, it also extends Model

  • Key: SYSML-42
  • Legacy Issue Number: 9848
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

§7.3.2, page 28

  • Key: SYSML-41
  • Legacy Issue Number: 9847
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

table 7.2, page 26, PackageContainment

  • Key: SYSML-40
  • Legacy Issue Number: 9846
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

table 7.2, page 26, PrivatePackageImport

  • Key: SYSML-39
  • Legacy Issue Number: 9845
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

table 7.2, page 26, PublicPackageImport

  • Key: SYSML-38
  • Legacy Issue Number: 9844
  • Status: closed  
  • Source: International Business Machines ( Morgan Bjorkander)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Freeform diagrams in SysML

  • Key: SYSML-37
  • Legacy Issue Number: 9837
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • 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.

  • Reported: SysML 1.0b1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid redefinition on stereotype extensions

  • Key: SYSML-36
  • Legacy Issue Number: 9836
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • 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.

  • Reported: SysML 1.0b1 — Fri, 23 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Model Elements sub-profile depends only on UML4SYML Level 1, not 3.

  • Key: SYSML-35
  • Legacy Issue Number: 9804
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

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

  • Reported: SysML 1.0b1 — Tue, 6 Jun 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

regarding the <> stereotype in the Requirements package

  • Key: SYSML-34
  • Legacy Issue Number: 9794
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    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.

  • Reported: SysML 1.0b1 — Fri, 26 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 15.3.2.3

  • Key: SYSML-33
  • Legacy Issue Number: 9793
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • 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).
    "

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure 11-14

  • Key: SYSML-32
  • Legacy Issue Number: 9792
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • 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.
      "
  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 137

  • Key: SYSML-31
  • Legacy Issue Number: 9791
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 94

  • Key: SYSML-30
  • Legacy Issue Number: 9790
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • 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.
    "

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 86

  • Key: SYSML-29
  • Legacy Issue Number: 9789
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    Clarify the line style for ControlFlow (last table row)

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 44

  • Key: SYSML-28
  • Legacy Issue Number: 9788
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    Please add example(s) for NestedConnectorEnd

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 42, ist paragraph

  • Key: SYSML-27
  • Legacy Issue Number: 9787
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.2.5

  • Key: SYSML-26
  • Legacy Issue Number: 9786
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.2.4

  • Key: SYSML-25
  • Legacy Issue Number: 9785
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Blocks

  • Key: SYSML-24
  • Legacy Issue Number: 9784
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • 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.

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.3.2.1 constraint block

  • Key: SYSML-23
  • Legacy Issue Number: 9783
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • 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.

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3.2.4

  • Key: SYSML-22
  • Legacy Issue Number: 9782
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    Constraint [1] is not very clear. Please clarify

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

General Diagram Elements

  • Key: SYSML-21
  • Legacy Issue Number: 9781
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • 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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add clarification of how to represent non-depletable stores in ibd as part

  • Key: SYSML-20
  • Legacy Issue Number: 9780
  • Status: closed  
  • Source: Ceira Technologies, Inc. ( Michael Latta)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.1.2, last sentence

  • Key: SYSML-2
  • Legacy Issue Number: 9757
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • 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."

  • Reported: SysML 1.0b1 — Tue, 23 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

chapter 11.3.2.6 Optional

  • Key: SYSML-1
  • Legacy Issue Number: 9620
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • 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."

  • Reported: SysML 1.0b1 — Wed, 10 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.3.2.1

  • Key: SYSML-7
  • Legacy Issue Number: 9764
  • Status: closed  
  • Source: Georgia Institute of Technology ( Russell Peak)
  • 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.

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 17.4.1 Fig. 17-5

  • Key: SYSML-6
  • Legacy Issue Number: 9762
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Include subsections to sections 2.1 and 2.2

  • Key: SYSML-5
  • Legacy Issue Number: 9761
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI section

  • Key: SYSML-10
  • Legacy Issue Number: 9767
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.4 - add figure

  • Key: SYSML-9
  • Legacy Issue Number: 9766
  • Status: closed  
  • Source: Georgia Institute of Technology ( Russell Peak)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 1.4

  • Key: SYSML-8
  • Legacy Issue Number: 9765
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fig. 7.3:

  • Key: SYSML-4
  • Legacy Issue Number: 9759
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Tue, 23 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fig. 7.2:

  • Key: SYSML-3
  • Legacy Issue Number: 9758
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Tue, 23 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT