OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — All Issues

  • Acronym: SysML
  • Issues Count: 163
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UML22-1105 Profile Structure Diagrams are missing from Annex A SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1104 Missing inheritance in 9.3.12 SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1103 No default value specified for Generalization::isSubstitutable SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1088 A notation for Trigger SysML 1.0b1 UML 2.1.2 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
SYSML11-46 Section: 8.3.2 Unit/Dimension Notation SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-45 Section: Annex A: Diagrams SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-44 Section: 16 Requirements SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-43 Section: 8.3.2.8 ValueType SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-42 Section: 16 Requirements SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-41 Section: 11.3.1.1 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-38 Section: 11.3.2.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-37 Section: Appendix B SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-36 SysML doesn't explicitly support the modeling of alternative models SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-35 Section 16.3.2.3 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-34 15.2.1Representing Allocation on Diagrams SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-33 7.1 Overview SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-32 Constraint parameter stereotype SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-31 Figure 17.4.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-30 Section: figure 17.6 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-29 Section: Annex A SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-28 Section: 17.4.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-27 Section: 11 Activities SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-26 Section: 11 Actibities SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-25 Chapter 8, Blocks, instance specifications for default values SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-24 Section: 6.1 Levels of Formalism SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-23 Section: 9, 16, C SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-22 SysML: nout-->inout SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-21 Section: 7.3.2.5 Viewpoint SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-20 Section: Annex G SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-19 Section: Appendix B.4.5 SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-18 How to use property specific types for atomic flow ports? SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-17 Section: 16.3.2.4 RequirementRelated (from Requirements) SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-16 Section: 9.3.2.8 ItemFlow SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-15 Semantic of default value in the scope of a DistributedProperty SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-14 constraints on viewpoint, 7.3.2.5 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-13 Table 14.1 Use Case Diagram SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-12 SysML:Architecture SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-11 SysML: << and >> vs < and > SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-10 SysML: Missing arrow on figure 16.8 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-9 SysML: Interfaces on Flow Ports SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-8 SysML: Use Cases SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-7 Section: Requirements - Figure 16.1 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-6 Section: Ports and Flows - Behavioral flow ports SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-5 Section: Blocks - BOM properties SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-4 Section 16.3.1.1 SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-3 constraints section 9.3.2.4 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-2 Section 16.4.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-1 Page 16 SysML 1.0b1 SysML 1.1 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-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-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-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-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
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

Issues Descriptions

Profile Structure Diagrams are missing from Annex A

  • Key: UML22-1105
  • Legacy Issue Number: 10044
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 18.4 describes what are called "Structure Diagrams" for depicting profiles, stereotypes and their associated metaclasses.
    However such diagrams are not included in the Normative Appendix A (Figure A.5 does show 'Structure Diagram' but only as an abstract diagram type).

    Proposed resolution:
    For clarity use the term 'Profile Diagram in section 18.4
    Add Profile Diagram to Annex A as a 14th UML2 Diagram Type.

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

    No Data Available

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

Missing inheritance in 9.3.12

  • Key: UML22-1104
  • Legacy Issue Number: 10000
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Figure 9.2 shows that Property inherits from ConnectableElement - which is not included in the Generalizations section of 9.3.12 (though it is in the metamodel

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

    The submitter is correct; see revised text.

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

No default value specified for Generalization::isSubstitutable

  • Key: UML22-1103
  • Legacy Issue Number: 9963
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    No default value specified for Generalization::isSubstitutable.
    This is the only Boolean attribute in the whole specification without a default value

  • Reported: SysML 1.0b1 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    For consistency and correctness, add a default value as the summary mentions.

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

A notation for Trigger

  • Key: UML22-1088
  • Legacy Issue Number: 9750
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
    In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

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

    This issue is an identical duplicate, submitted by the same author, as issue 10777

  • 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

Section: 8.3.2 Unit/Dimension Notation

  • Key: SYSML11-46
  • Legacy Issue Number: 11275
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    As the issue notes, the notation that SysML defines for Dimension and Unit differs the standard UML notation for InstanceSpecification. Revise the subsection for Unit and Dimension under 8.3.1 Diagram Extensions to describe the specific notation that SysML defines for these two elements. Revise the text for how stereotype properties of Unit and ValueType reference these elements.

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

Section: Annex A: Diagrams

  • Key: SYSML11-45
  • Legacy Issue Number: 11274
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The table and matrix diagram kinds are rarely mentioned in appendix A. To have a complete overview of all diagram kinds they should be added to the bullet lists.

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

Section: 16 Requirements

  • Key: SYSML11-44
  • Legacy Issue Number: 11271
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Issue may be accomplished by modeling style (e.g. use package containment for
    “x-or” instead of requirement containment). No need to encumber SysML with
    Boolean operators for requirement satisfaction or containment.
    Disposition: Closed, no change

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

Section: 8.3.2.8 ValueType

  • Key: SYSML11-43
  • Legacy Issue Number: 11270
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Fix the type of the unit and dimension attributes on ValueType as suggested, and to match that abstract syntax shown in Figure 8.4.

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

Section: 16 Requirements

  • Key: SYSML11-42
  • Legacy Issue Number: 11269
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The desired notation is that a "satisfy" dependency be displayed with an open arrowhead like all the other dependencies between SysML requirements. Rather than specialize Realization, which carries its notation of a closed arrowhead, change the the abstract syntax shown in Figure 16.1 to have Satisfy specialize UML Trace, like all the other dependencies defined in this figure.

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

Section: 11.3.1.1

  • Key: SYSML11-41
  • Legacy Issue Number: 11118
  • Status: closed  
  • Source: International Business Machines ( Eldad Palachi)
  • Summary:

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

  • Reported: SysML 1.0b1 — Wed, 4 Jul 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 11.3.2.2

  • Key: SYSML11-38
  • Legacy Issue Number: 10641
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 3 Feb 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: Appendix B

  • Key: SYSML11-37
  • Legacy Issue Number: 10602
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 20 Jan 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    1.1 spec (“shared AggregationKind” – text update per issue 12142). Updating
    Figure B.16 should be done for consistency. Figure B.26 does not immediately
    lend itself to “shared AggregationKind”, so will remain unchanged.

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

SysML doesn't explicitly support the modeling of alternative models

  • Key: SYSML11-36
  • Legacy Issue Number: 10587
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 11 Jan 2007 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    This issue was previously deferred by the SysML 1.1 RTF with the following
    discussion at that time:
    A full resolution of this issue is beyond the scope of an RTF. The issue is
    being deferred, however, so that additional explanatory material could be
    considered in a future RTF to clarify the scope of modeling supported by
    SysML or to suggest possible workarounds. A full resolution of this issue
    could be considered in an RFP for SysML 2.0.
    Addition of support for modeling of alternative models was considered to be
    beyond the scope of an RTF, so this issue is being closed. Requirements or
    proposals to add such support can be considered under a future RFP.
    Disposition: Closed, no change

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

Section 16.3.2.3

  • Key: SYSML11-35
  • Legacy Issue Number: 10540
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 1 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Agreed. Propagation rule is unnecessary and should be deleted

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

15.2.1Representing Allocation on Diagrams

  • Key: SYSML11-34
  • Legacy Issue Number: 10539
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 1 Dec 2006 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Related to issue 11501 (resolved in RTF 1.1), and 12139, making the spec
    consistent. The arrowhead must always represent the “AllocatedTo” end of
    the dependency, since any other direction would be counterintuitive, and the
    derived property of the model element at the arrowhead end must be
    “AllocatedFrom XXX”, where XXX is the model element at the other end of the
    allocation dependency. Similar concept to “Trace” relationship - see issue 10343.
    Which end of the dependency is client and which is supplier is unimportant in
    practice, and invisible to the user. Allocation is based on Abstraction (UML 2.1.2
    Superstructure Section 7.3.1), which accommodates various directionality and
    mappings. Linguistic merits of directionality may be debated, but at this point
    Table 15.1 and Section 15.2.2 are consistent and no further changes are
    required.
    Disposition: Closed, no change

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

7.1 Overview

  • Key: SYSML11-33
  • Legacy Issue Number: 10538
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 1 Dec 2006 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Lifecycle and access right management is out of scope of SysML. The resolution
    has been discussed with the author of the issue who agrees to close the issue
    without any change.
    Disposition: Closed, no change

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

Constraint parameter stereotype

  • Key: SYSML11-32
  • Legacy Issue Number: 10524
  • Status: closed  
  • Source: ( Fraser Chadburn)
  • Summary:

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

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

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

    To quote again:

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

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

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

  • Reported: SysML 1.0b1 — Wed, 13 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Figure 17.4.2

  • Key: SYSML11-31
  • Legacy Issue Number: 10517
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

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

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

    In Figure 17.6, replace Block symbol with the Block stereotype definition shown in Figure 8.2.
    In the paragraph after Figure 17.6, remove "(in this case none)" from the 4th sentence.

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

Section: figure 17.6

  • Key: SYSML11-30
  • Legacy Issue Number: 10511
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 9 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The best solution is to use package diagrams to describe profiles.

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

Section: Annex A

  • Key: SYSML11-29
  • Legacy Issue Number: 10510
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

  • Reported: SysML 1.0b1 — Sat, 9 Dec 2006 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    The above reference to Annex A (Section A.1 pg 173) is not referring to model
    elements that can appear on a block definition diagram, internal block diagram or
    any other diagram. It is referring to the type of model element that is represented
    by the frame of the diagram. As a result, this is a misinterpretation of the content.
    It is felt that the description is adequately clear, so no change is required.
    The type of model elements that can appear on a diagram are specified in the
    applicable chapter as described in the last paragraph on pg 172 in Annex A.
    Disposition: Closed, no change

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

Section: 17.4.2

  • Key: SYSML11-28
  • Legacy Issue Number: 10509
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 8 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 10517 for disposition

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

Section: 11 Activities

  • Key: SYSML11-27
  • Legacy Issue Number: 10502
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

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

    Use ""block" instead of "class" unless specifically referring to UML.

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

Section: 11 Actibities

  • Key: SYSML11-26
  • Legacy Issue Number: 10501
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

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

    No Data Available

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

Chapter 8, Blocks, instance specifications for default values

  • Key: SYSML11-25
  • Legacy Issue Number: 10473
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 27 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Change the specification of the defaultValue compartment to base its internal metamodel representation on UML InstanceValue, and to decouple the representation of context-specific property values entirely from property-specific types. Also rename the compartment to "initialValues" to more accurately indicate the ability of these compartments to provide values which are assigned in a local property-specific context to override of any existing default or initial values defined on underlying blocks that may type a property.
    As background, this issue was previously deferred by the FTF with the following discussion comments:
    The defaultValue compartment on an internal block diagram does provide at least one available option for assigning default values to structured values, as discussed in the subsection "Default value compartment" under 8.3.1.3 Internal Block Diagram. Creating a graphical compartment on an internal block diagram to assign values to properties defined on a block definition diagram may be more cumbersome than a textual syntax, but tools may be able to streamline the linkage to the default value for usability. In particular, the use of a "structure" compartment on a block definition would allow the default value to be shown next to a properties compartment where a property is defined.
    Other work in OMG is currently underway that may define a standardized form of textual syntax for value specifications. SysML could consider such a textual syntax for property values in future versions.
    The scope of this resolution is to clarify the graphical syntax and internal metamodel for the "initialValues" compartment that may be shown on properties on an internal block diagram. Other issues, such as 12277 and 12353, request additional support for display of context-specific values using forms of concrete syntax for UML InstanceSpecification or else additional forms of compartments on properties on an ibd. These issues are being deferred, but can be reconsidered in the future following this initial step to clarify the initialValues compartment, as included in the scope of this resolution. Other forms of textual syntax for complex values, such as the MARTE Value Specification Language (VSL), could also be considered by future issue resolutions following the current RTF.
    Issue 11502, "PropertySpecificType concept is highly ineffective and suboptimal," has its own resolution of Closed, no change, but this resolution is based partly on the ability of the initialValues compartment to remove one of the major reasons why property-specific types might need to be used. Instead, use of the more complicated property-specific type mechanism can be reserved for cases in which new or redefined features are really needed in a new specialized property-specific type, rather than merely an assignment of local values. See the resolution for Issue 11502 for more information.
    Issues 12361, "defaultValue should be renamed initialValue(s)," and 12363, "Decouple 'values' compartment for a part Property in an IBD from PropertySpecificType" record some of the history of working discussions by the RTF on the defaultValue compartment issue, as well as additional perspective. All specific changes to the specification are being consolidated under this issue, so these two other issues are being closed as having their resolutions merged under this one.

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

Section: 6.1 Levels of Formalism

  • Key: SYSML11-24
  • Legacy Issue Number: 10472
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Add a brief statement to Section 6.1, Levels of Formalism, to clarify that SysML reuses UML instance semantics, adapted as necessary for description of systems. A brief statement of UML instance semantics can be found in the UML Superstructure specification (ptc/06-04-02) under 6.4.2, Semantic Levels and Naming, under the paragraph labeled "Instance level."

  • Reported: SysML 1.0b1 — Mon, 27 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Following is the paragraph labed "Instance level," which now appears in the
    section numbered 6.3.2 in the UML 2.4 Superstructure Specification:
    Instance level – These are the things that models represent at runtime.
    They don’t appear in models directly (except very occasionally as detailed
    examples), but they are necessary to explain the semantics of what
    models mean. These classes do not appear at all in the UML2 metamodel
    or in UML models, but they underlie the meaning of models. We provide a
    brief runtime metamodel in the Common Behavior chapter, but we do not
    formally define the semantics of UML using the runtime metamodel. Such
    a formal definition would be a major amount of work.
    Since SysML already includes the semantics of existing UML elements, except
    as specifically changed or extended by SysML, this existing language (which has
    not changed since UML 2.1) applies to SysML.
    SysML already includes the following statement in Section 6.1, which leaves
    open the option to consider further semantics in the future, but in the meantime
    leaves them open just as does UML:
    SysML is specified using a combination of UML modeling techniques and
    precise natural language to balance rigor andunderstandability. Use of
    more formal constraints and semantics may be applied in future versions
    to further increase the precision of the language.
    Given the generality of both the UML and SysML statements about formal
    semantics, no change is required to the current version of the SysML
    specification. A new issue could be raised if future versions of UML adopt a
    formal specification of semantics that would also need to be adapted or reflected
    by SysML, but such an issue should be raised against specific future changes to
    UML.
    Disposition: Closed, no change

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

Section: 9, 16, C

  • Key: SYSML11-23
  • Legacy Issue Number: 10471
  • Status: closed  
  • Source: edgewater.ca ( Cory Bialowas)
  • Summary:

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

  • Reported: SysML 1.0b1 — Fri, 24 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Change remaining occurrences of "sub-type" to "subtype". The OMG Available Specification for SysML 1.0 no longer contains any occurrences of "sub-type" in Chapter 16, but occurrences do still remain in Chapter 9 and Annex C.

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

SysML: nout-->inout

  • Key: SYSML11-22
  • Legacy Issue Number: 10446
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In SysML 9.3.2.4, the possible flow directions include

    nout

    based on later usage, this is incorrect for

    inout.

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

    No Data Available

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

Section: 7.3.2.5 Viewpoint

  • Key: SYSML11-21
  • Legacy Issue Number: 10427
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

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

    No Data Available

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

Section: Annex G

  • Key: SYSML11-20
  • Legacy Issue Number: 10380
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

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

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

    Annex G no longer exists in the SysML 1.0 specification. Formerly, it held BNF Diagram Syntax Definitions, but this annex was dropped by the FTF. A new Diagram Definition RFP may provide a more complete framework in which to define concrete syntax for SysML and other UML-based languages, but a separate issue should be raised to add such concrete syntax definitions when appropriate
    Disposition: Closed, no change

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

Section: Appendix B.4.5

  • Key: SYSML11-19
  • Legacy Issue Number: 10374
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

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

  • Reported: SysML 1.0b1 — Wed, 27 Sep 2006 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Recommend no change. Fig B.18 & B.19 are consistent. The CAN bus is a
    design refinement introduced after figure B.19,and does not need to be included
    in earlier figures.
    Disposition: Closed, No Change

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

How to use property specific types for atomic flow ports?

  • Key: SYSML11-18
  • Legacy Issue Number: 10371
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I would like to model an atomic flow port at a block "Battery".
    The base type is Volt (value type).
    Now I would like to show that the value is 12,5V in this context.

    If I use a property specific type, I can't show the constant value
    in my diagram. The name of my atomic flow port is:

    out:[Volt]

    Where can I show the value 12,5?

  • Reported: SysML 1.0b1 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This is issue is closed without change because atomic flow ports are deprecated
    in the resolution of issue 13178.
    Disposition: Closed, no change

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

Section: 16.3.2.4 RequirementRelated (from Requirements)

  • Key: SYSML11-17
  • Legacy Issue Number: 10343
  • Status: closed  
  • Source: ( Fraser Chadburn)
  • Summary:

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

  • Reported: SysML 1.0b1 — Mon, 11 Sep 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Table 16.2 is correct, spec is inconsistent. 16.3.2.3 and 16.3.2.4 should be
    updated to correct attributes associated with the trace relationship.

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

Section: 9.3.2.8 ItemFlow

  • Key: SYSML11-16
  • Legacy Issue Number: 10342
  • Status: closed  
  • Source: ( Fraser Chadburn)
  • Summary:

    FlowPorts can be typed by (p64): · Block · DataType · FlowSpecification · Signal · ValueType FlowProperties (which are owned by FlowSpecifications) can be typed by (p65): · Block · DataType · Signal · ValueType Yet ItemFlows can only be typed by (p66): · Block · ValueType Since FlowPorts and associated Flow Specifications define “what can flow” between the block and its environment. Whereas ItemFlows specify “what does flow” in a specific usage context. It therefore proposed that the ItemFlows constraint section is updated to include DataType and Signal, as well Block and ValueType (i.e. same as FlowProperties). Note: It is assumed that having an ItemFlow typed by a flow specification would make no sense, since the item properties have direction on them that would have to be interpreted in relation to the direction of the item flow arrow. Is this assertion correct?

  • Reported: SysML 1.0b1 — Mon, 11 Sep 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Change the constraint on the conveyed classifier of items flows to be the same
    as the constraint on item properties. In answer to the question, item flows can
    convey items that have flow properties, but these flow properties apply to the
    item itself, not the source and target of the flow.

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

Semantic of default value in the scope of a DistributedProperty

  • Key: SYSML11-15
  • Legacy Issue Number: 10143
  • Status: closed  
  • Source: International Business Machines ( Laurent Balmelli)
  • Summary:

    in paragraph 8.3.2.3, the semantic of a default value for a DistributedProperty is not specified. My suggestion is that the default values should be a realization of the random variable following the distribution. It would be nice to have an example in the paragraph too, for instance: <<uniform>>

    {min=0,max=2} p:Real=2 <<uniform>>{min=0,max=2}

    p:Real=1.2 but not: <<uniform>>

    {min=0,max=2}

    p:Real=2.3

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

    Any value assigned to a property must lie within the values having non-zero
    probabilities as defined by an applied DistributedProperty stereotype. These
    constraint semantics are inherent in the concept of a probability distribution, and
    apply to the default or initial value along with all other values.
    How any further patterns of probabilities can expected to be observed, however,
    is currently unspecified by SysML. For example, the probabilities might be seen
    across the property values of different instances, or within a succession of values
    carried by a single instance. A specific user model must specify any such further
    interpretation of its applied property value distributions.
    Until or unless the SysML specification addresses more specific cases of how a
    user model must interpret its property value distributions, it is premature to
    preclude any interpretation that a model might apply. Different interpretations
    may be appropriate for different models, each of which may document any
    specific timing or scope for the values which may occur under the probability
    distribution.
    As referenced by section 8.3.2.3, some initial examples of distributed property
    stereotype definitions and their application in a user model are already provided
    in Annex C.6.
    Disposition: Closed, no change

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

constraints on viewpoint, 7.3.2.5

  • Key: SYSML11-14
  • Legacy Issue Number: 10098
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

    Constraints

    …

    [2]The property ownedOperations must be empty.

    [3]The property ownedAttributes must be empty.

    …

  • Reported: SysML 1.0b1 — Tue, 8 Aug 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The submitter is correct

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

Table 14.1 Use Case Diagram

  • Key: SYSML11-13
  • Legacy Issue Number: 10097
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

  • Reported: SysML 1.0b1 — Tue, 8 Aug 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    While the UML 2.x spec may not yet be consistent, it appears that the term "role name" has been replaced by "association end name".

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

SysML:Architecture

  • Key: SYSML11-12
  • Legacy Issue Number: 10073
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

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

    Discussion:
    This issue was previously deferred by the SysML 1.1 RTF with the following
    discussion at that time:
    A full resolution of this issue is beyond the scope of an RTF. The issue is
    being deferred, however, so that additional explanatory material could be
    considered in a future RTF to clarify the scope of modeling supported by
    SysML or to suggest possible workarounds. A full resolution of this issue
    could be considered in an RFP for SysML 2.0.
    Addition of support for specifying reusable architectural patterns was considered
    to be beyond the scope of an RTF, so this issue is being closed. Requirements
    or proposals to add such support can be considered under a future RFP.
    Disposition: Closed, no change

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

SysML: << and >> vs < and >

  • Key: SYSML11-11
  • Legacy Issue Number: 10061
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Whenever possible, the spec should use the correct symbols « and » which are easily available in Visio

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

    All remaining occurrences of << and >> have already been replaced by « and ».
    Disposition: Closed, no change

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

SysML: Missing arrow on figure 16.8

  • Key: SYSML11-10
  • Legacy Issue Number: 10060
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

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

    Replace figure 16.8 with attached figure. Caption is unchanged

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

SysML: Interfaces on Flow Ports

  • Key: SYSML11-9
  • Legacy Issue Number: 10059
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Interfaces on Flow Ports

    It’s not clear how to model complex ports that partake of both service and physical flow characteristics. For example, I could use communicate in morse code over a hydraulic line. This would be modeled normally as a standard (service) port, except for the medium.

    Or I can use in-band signaling over a communication line (as it used to be on a telephone lines).

    In such cases, I’d like to be able to attach interfaces (with the set of operations) to a flow port.

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

    This is addressed in the resolution of issue 13178 by enabling blocks typing ports
    to have flow properties, where the blocks can support operations and receptions
    or realize interfaces that do the same.

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

SysML: Use Cases

  • Key: SYSML11-8
  • Legacy Issue Number: 10057
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

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

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

    Please clarify with this use at the SE level

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

    Instead of a long discussion on the differences between SW and SE perspectives
    on use cases, we add some words to clarify the SE goal/requirement-oriented
    perspective, trying to avoided use of UCDs as flow charts. This approach leaves
    open the possibility of compatibility with SW approaches.
    In addition, a minor grammatical error is fixed.
    Revised Text:

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

Section: Requirements - Figure 16.1

  • Key: SYSML11-7
  • Legacy Issue Number: 10042
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

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

    Discussion:
    Stereotypes as property types are permitted as part of associations to stereotypes. Section 18.3.6 Profile of the UML 2.1.2 Superstructure spec contains the following paragraph:
    Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass.
    Disposition: Closed, no change

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

Section: Ports and Flows - Behavioral flow ports

  • Key: SYSML11-6
  • Legacy Issue Number: 10033
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

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

    Change the following paragraph in section 9.3.2.3:
    "Flow ports relay items to/from the associated connector to/from properties of the owning block or parameters of the block behavior if the port is not connected to an internal link that may relay the items to an internal part of its owner. This means that every flow property contained within a flow port is bound to a property owned by the block or a parameter of the block behavior."
    To:
    "Flow ports relay items to their owning block or to a connector that connects them with their owner's internal parts (internal connector).
    The isBehavior attribute inherited from UML port is interpreted in the following way: if isBehavior is set to true, then the items are relayed to\from the owning block. More specifically, every flow property within the flow port is bound to a property owned by the port's owning block or to a parameter of its behavior. If isBehavior is set to false, then the flow port must be connected to an internal connector which in turn related the items via the port. The need for isBehavior is mainly to allow specification of internal parts relaying items to their containing part via flow ports"
    Add the following constraint:
    [5] If a flow port is not connected to an internal part then isBehavior should be set to true.

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

Section: Blocks - BOM properties

  • Key: SYSML11-5
  • Legacy Issue Number: 10020
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

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

    The referenced section no longer exists in SysML 1.0. The BlockProperty stereotype was removed and its descriptive material incorporated in 8.3.2.2 Block. The previous text referenced by issue is no longer included in the resulting text. The referenced paragraph in the Final Adopted Specification, ptc/06-05-04, previously read:
    Parts may be used to show all the components from which a larger system is built. Consistent with UML, however, SysML currently does not provide any means to indicate whether all the parts which make up a larger system are either shown on a particular diagram or contained within a model. Various forms of diagram or model annotation, such as a Diagram Description note as shown in Annex A, may be used to communicate completeness of a diagram or model to a user.
    Since this text no longer exists in the 1.0 specification, this issue no longer applies. If there is a need to define a concept of Bill of Material properties within SysML, either by description or by additional metamodel elements, a new issue requesting changes to the current text could be raised and considered within future revisions of SysML.
    Disposition: Closed, no change

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

Section 16.3.1.1

  • Key: SYSML11-4
  • Legacy Issue Number: 9779
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

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

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    SysML should not specify the layout and format of tables. There has never been
    any intent to standardize them in SysML 1.x. Legibility of example tables will be
    improved as each is modified in response to other changes.
    Disposition: Closed, no change

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

constraints section 9.3.2.4

  • Key: SYSML11-3
  • Legacy Issue Number: 9778
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

    Specify matching rules that enable flow ports and client server ports to be connected.

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

    Following is the discussion from a previous deferred resolution by the SysML
    FTF:
    It was felt that there is a need for experience in SysML prior to making
    such a change or extension. Deferred for future consideration.
    This issue is being deferred because no proposed resolution was voted on during
    the schedule of the SysML 1.3 RTF.
    Disposition: Deferred The new proxy ports and full ports defined in SysML 1.3 allow a mixture of
    inputs/outputs (using flow properties) and services (using directed features and
    provided/required interfaces). Flow ports have been deprecated. As a result there is
    no need for matching rules between flow ports and ports anymore.
    Disposition: Closed, no change

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

Section 16.4.2

  • Key: SYSML11-2
  • Legacy Issue Number: 9771
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

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

    .

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

    Considerable improvement was made to the diagrams included in the OMG Available Specification for 1.0, produced after the FTF Convenience Document was completed. Issues of uniformity and consistent quality to diagrams are expected to continue as part of ongoing editorial cleanup of the spec. Since the issue refers to the now-completed FTF, it should be closed. Further fixes can be completed either by ongoing editorial work or by issues raised against specific diagrams.
    Disposition: Closed, no change

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

Page 16

  • Key: SYSML11-1
  • Legacy Issue Number: 9763
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

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

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

    The primary readers intended by this chapter are tool vendors responsible for implementations that comply with the SysML specification and user specialists responsible for evaluating compliance of tools. This audience is expected to have extensive familiarity with the other OMG specifications which SysML extends.
    Additional explanatory material could be added either to this chapter or elsewhere, but edits would best be driven by specific suggestions after greater experience with the compliance levels and their UML dependencies has been gained.
    Disposition: Closed, no change

  • 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

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

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

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

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

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