OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Closed Issues

  • Acronym: SysML
  • Issues Count: 205
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSMLR-155 Precise expression of requirements SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-154 Need to define Requirement Relationship compartment SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-208 Satisfy, Verify and DeriveReqt could be used with non-requirement elements SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-278 JTC1 JP3 023 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-270 JTC1 JP18 015 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-271 JTC1 JP20 016 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-269 JTC1 JP19 014 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-324 update constraints to set sourceContext and targetContext of «DirectedRelationshipPropertyPath» SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-330 There is no notation for units on properties and values SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-263 JTC1 JP12 008 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-332 Property path with unnamed properties is unreadable SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-248 ParticipantProperty multiplicity SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-268 JTC1 JP17 013 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-265 JTC1 JP13 010 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-246 Add example of PBR using Block SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-267 JTC1 JP16 012 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-287 TriggerOnNestedPort constraint [5] makes no sense SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-286 TriggerOnNestedPort constraint [6] makes no sense SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-48 SysML 7.3.2.5 Viewpoint SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-258 JTC1 JP8 003 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-262 JTC1 JP10 007 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-266 JTC1 JP15 011 SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-264 JTC1 JP14 009 SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-279 JTC1 JP4 024 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-261 JTC1 JP11 006 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-259 JTC1 JP7 004 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-260 JTC1 JP9 005 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-275 JTC1 JP24 020 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-276 JTC1 JP2 021 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-277 JTC1 JP5 022 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-272 JTC1 JP21 017 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-273 JTC1 JP22 018 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-274 JTC1 JP23 019 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-153 reception compartment not addressed SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-1 SysML: Protocol State Machines needed SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-130 What kind of elements can diagrams be for?. SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-216 Table 8.1 Block compartment header misplaced and other formatting problems and inconsistencies SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-257 JTC1 JP6 002 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-126 Forked association notation ill-formed SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-85 SysML diagrams show only SysML-stereotyped elements SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-231 16.3.2.4 Requirement Operations OCL Inconsistent SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-74 Multiassociation SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-51 Allocate of Actions or of Activities SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-256 JTC1 JP1 001 SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-10 BindingConnector SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-14 SysML: Interaction diagram and Data-based comm of SysML SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-9 Issue: Nested connector ends SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-12 It is not allowed in UML to display stereotypes of related elements SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-13 Parts are added directly into package SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-11 Lack of notation for units and dimensions on values. SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-2 SysML: UML Qualified Associations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-8 Section: 12. Interactions SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-4 Section: 9.3.2.5 FlowPort SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-7 Block namespace compartment: Are external relationships allowed SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-6 Timing diagrams SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-5 Section: Figure 14.2 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-3 SysML: Generalizing Activites SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-18 10.3.1.2 Parametric Diagram SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-22 Annex B / Figure B27 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-24 Annex B / Figure B.38 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-19 Annex B / B.4.8.3 Activity Diagram SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-23 Annex B / Figure B.35 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-26 Section: Generalization of stereotyped elements SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-21 Annex B / Figure B.9 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-20 Annex B / Figure B.10 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-25 Annex B, Figure B.29 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-15 Section: 5.3 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-16 Inferred Allocation on Allocate Activity Partitions SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-17 Item Flows on Activity Diagrams SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-38 Inability to represent dependent, independent parameters on constraint properties SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-36 Support BDD's for State Machines SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-37 AllocateActivityPartition and UML 2 semantics SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-35 Binding Relationships require unit conversions SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-34 Requirement constants should be integrated into Model-centric vision of SysmL SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-32 Representation of nested object nodes in activity diagrams SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-31 Requirements interchange issue SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-33 Section: 8/8.3.2 Inability to efficiently capture datasets SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-27 Figure B.34 and Figure B.35 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-30 SysML: Operations on Activities need to be callable (e.g., start, restart, cancel) SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-29 SysML: Activity Properties should be accessible in Activity diagrams for decision making SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-28 SysML: Align SysML Activities with Foundational UML SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-45 callout notation issues SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-52 Flow properties and activity paramters SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-53 SysML 1.2 Issue Viewpoint referencing other viewpoints properties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-47 Do parametric bindings observe derived and read-only properties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-49 Ability for a binding connector to be typed SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-46 Binding to multiplicity in parametrics SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-50 Inheriting Allocations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-39 Allocations should not generate dependencies SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-41 Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-42 Proposal to have a stereotype for reference nested property SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-40 Parsing Text in Requirements SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-44 Need to have an explicit way to bind flow properties or atomic flow ports to block properties SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-43 Flow port compatibility with behavior SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-56 Continuous flows in non-streaming situations with >1 multiplicities SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-57 SysML 1.2 Issues: Optional with streaming SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-62 SysML primitive value types SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-61 SysML Issue on Multiplicity of Use Case Communication Associations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-59 SysML Issue based on UML 15369 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-60 SysML Issue representation of properties as associations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-58 Figure B.35 object nodes SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-70 Definition of part SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-54 SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-55 SysML 1.2 Issues: DistributedProperties on Activates SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-75 Association owning ends SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-67 SysML Issue on Refine limitations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-71 Incorrect statement about UML n-aries SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-65 IBD notation doesn't distinguish item properties from connector labels SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-64 Blocks cannot own items flows SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-73 parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-72 Where have stereotypes been defined? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-66 Description of Item Flows SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-68 Item flows can have multiple types but item properties cannot SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-69 Compartment labelling rules SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-63 Another issue with allocate SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-84 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-88 Property Based Requirements SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-86 Question about the Activity decomposition in Bloc Definition Diagrams SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-87 Error in pending 1.3 diagram 15.6 and elsewhere SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-89 SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-79 Problems with property-specific types SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-77 Can Enumerations be used on parametric diagrams for typing constraint parameters SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-83 Issue on Block constraint#4 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-82 Lightweight representations of faults, failures, hazards and off-nominal conditions and behavior SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-76 TestCase should use PackageMerge SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-78 Content of Requirement::/tracedTo SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-80 InstanceSpecifications for exactly one instance SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-81 InstanceSpecification equality SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-99 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-95 Callout notation for port-specific types and initial values SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-96 remove figure numbers from diagram frames SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-98 Problems with 1.3 Enumeration Literals SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-101 Interface blocks and protocols SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-100 How to refer to properties of an extension? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-97 SysML: References to CreateEvent incorrect SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-94 Is <> keyword (or stereotype) on binding connectors is part of SysML notation? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-92 9.3.2.9 What is InterfaceBlock? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-90 Section 9.3.1.7 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-93 clarification, what "part property" is SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-91 Port labels inside Port symbol SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-121 Clarification required for Copy relationship SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-113 9.3.2.4 direction of ports and their notation (second issue) SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-112 9.3.2.4 direction of ports SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-108 View and Viewpoint Limitations in support of auto-view generation SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-106 SysML stereotype notation creates ambiguity about to which element is the stereotype applied SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-111 Inability to specify partial allocation and requriements satisfaction SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-110 Constraint [5] should include specializations of Requirement SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-104 Incorrect constraint [2] on InterfaceBlock SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-107 VerdictKind SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-103 Missing type constraints for FullPort SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-109 Figure 15.8 diagram type SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-105 Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-102 Missing ownership constraints SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-127 SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-120 Diagram show inconsistent data SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-125 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-119 Don't use the optional notation for Pins with Allocation SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-124 ProxyPort with FlowProperties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-123 primitive types in SysML Activities SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-115 Figures 15.5 and 15.6 diagram types SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-117 Allocated notation on object nodes missing from diagram elements table SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-118 Libraries package should be named "SysML Model Libraries" SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-122 Semantics of multiple Dependencies SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-116 Allocation tabular notation normative? SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-114 Ports and Flows SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-144 Update to Trace Relationship’ SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-138 Semantics consistency of conjugated behavior ports SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-134 Pull semantics for flow properties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-142 Update SysML references to UML model library StandardProfileL2 SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-135 Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-137 Proxy port “complete” specification (§ 9.3.2.12): SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-143 Convention for enumeration not used for ControlValue SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-136 Flow property description: incorrect wording (§9.3.2.7) SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-132 SysML says nothing about how to deal with multiplicity for flow properties matching SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-128 The SysML classification of properties is incomplete SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-131 Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-129 About Rate, Continuous and Discrete SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-158 More than one View() operation allowed SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-156 ElementGroup cannot be source or target of a dependency SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-157 Table 12.1 has incorrect "int" typed arguments (4x) SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-148 Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-145 Abstract syntax for the initial values SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-141 Deprecate Unit and QuantityKind stereotypes in 1.4 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-140 proxy and full port notation change request SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-147 classifierBehaviorProperty and adjunctProperty notation SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-150 [SysML] Semantic variation points SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-146 URI for the SysML Profile given in section E.3 is wrong SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-139 Semantics clarification for removing a value from an out Flow Property SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-149 Can a SysML Full Port be typed by a ValueType? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-133 SysML Issues on Item Property values in an IBD SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-159 Inherit from a conjugated interface block SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-160 <> should be a reference (dashed box) SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-285 Incorrect multiplicity for base_xxx properties of most SysML Stereotypes SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-281 The XMI file isn't conform to the pdf specification for Refine and Trace stereotypes SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-169 Spec document inconsistent with Normative profile XMI file ptc/2013-12-11 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-334 No support for dot notation in activity and sequence diagrams SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-289 Wrong parameter for Operations in the SysML.xmi SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-243 Dubious UUIDs SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-225 SysML XMI typos in UML StandardProfile XMI references SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-238 Missing comment for some attributes SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-163 RequirementRelated is present in the summary but no more in the document SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-338 Cannot navigate and represent deep nested defining feature in a slot SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-328 Resolve inconsistency concerning restricion of ItemFlow type hierarchy SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-326 Make ItemFlow a specialization of DirectedRelationshipPropertyPath SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-247 specializations of requirement should specialize AbstractRequirement SysML 1.4 SysML 1.5 Deferred closed

Issues Descriptions

Precise expression of requirements

  • Key: SYSMLR-155
  • Legacy Issue Number: 19591
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Property Based Requirements Background Information

    1. Challenge / Needs
    Action: provide a clear statement of the modeling capabilities and end user wants from SysML requirements modeling

    1.1 BASIC NEED as stated in 'criteria for an enhanced text based requirement' document (below): CURRENT USERS OF TEXT BASED REQUIREMENTS NEED AN ENHANCED CAPABILITY TO EXPRESS TEXT BASED REQUIREMENTS MORE PRECISELY, TO REDUCE AMBIGUITY AND FACILITATE VERIFICATION BY ANALYSIS AND OTHER METHODS.

    Amplification: The enhanced text requirement is used in conjunction with the overall system model to assist in specifying and architecting systems. Sometimes, the system model is used as a model-based specification, such as when block instances with specific property values represent the requirement. In this case, the model-based specification further refines the enhanced text based requirements.

    1.2 Primary needs derived from the basic need:
    1.2.1 PROPERTIES OF REQUIREMENTS (see also issue SYSMLR-34): Requirements in SysML need to specify properties with quantitative values. These properties and their values must be relatable to other model elements or properties for the purpose of design refinement, analysis, and verification.
    RATIONALE: The most fundamental way to add precision to requirements is the addition of properties and values.

    1.2.2 MINIMIZING REDUNDANCY and AMBIGUITY: A requirement in SysML should be expressed with the minimum number of model elements and relationships.
    RATIONALE: Refinement of textual requirements into other model elements has the potential to add redundancy and ambiguity. For example, the maximum acceptable weight for a system should appear as a single number within a requirement, and that number should be linked directly to both design values and verification methods. Redundant textual and numerical versions of the weight requirement add redundancy, and requirement relationships at a parent level instead of a value level add ambiguity.

    1.3 Other needs derived from basic and primary need:
    1.3.1 MIXED EXPRESSIONS (see also issue SYSMLR-34): Requirements in SysML should be able to be written as "The top speed of this car shall be greater than <x>. And there be a compartment of the requirement where the current value of <x> is given, such as <x> = 200mph." <x> in this case is a property of a requirement, mentioned in 1.2.1 above.
    RATIONALE: This explicitly and unambiguously ties the numerical/variable property of the requirement (1.2.1) to the textual expression of the requirement. Also, by using this mixed expression as a transformation or replacement for the plain text expression, redundancy and ambiguity are reduced (1.2.2).

    1.3.2 VALUE TYPES: Numerical value/variable properties of requirements in SysML need to have quantity kind and units applied to them. (The implementation of this need leads to Value Properties of requirements)
    RATIONALE: This is consistent with the quantity kind/units need that led to Value Properties of blocks and parts.

    1.3.3 VALUE DISTRIBUTIONS: Numerical value properties of requirements in SysML need to be able to be expressed as distributions, meaning an acceptable distribution of values.
    RATIONALE: Requirements are often expressed as having an acceptable range of values

    1.3.4 DIRECTION/CAUSALITY OF REQUIREMENT PROPERTIES: (this need is controversial) Numerical value/variable properties of requirements in SysML need to be able to have direction associated with them.
    RATIONALE: In order for requirements to specify input/output relationships, direction must be able to be applied to various values or variables in order to indicate if they are inputs or outputs.

    1.3.5 REQUIREMENT RELATIONSHIPS TO PROPERTIES OF REQUIREMENTS: Properties of requirements in SysML need to be able to participate in requirement relationships (satisfy, verify, etc) directly, and not solely through the requirement that types it.
    RATIONALE: This capability removes potential ambiguity (1.2.2) and enables one to reuse requirements in different contexts.

    1.4 Other derived needs from the above needs:
    1.4.1 TEXT PARSING (see also issue SYSMLR-40): There is a need to parse the text string in a SysML requirement and create a reference from the parsed text to other model elements.
    RATIONALE: This capability is a mechanism for transforming pure-text statements into mixed expression statements.

    1.4.2 MATHEMATICAL EXPRESSIONS: There is a need for requirements to own or contain mathematical expressions that elaborate and clarify textual or mixed expressions so they can be evaluated as being satisfied and verified.
    RATIONALE: Mixed and textual expressions can't be evaluated. A slightly more rigorous formalism, such as -

    {constraint}

    , provides a potentially evaluatable format for expressions.

    1.5 Needs that have been discussed but are not directly related to the basic need in issue 19591:
    1.5.1 REQUIREMENT REUSE: A requirement needs to be able to be reused in different contexts. This implies a property can be typed by a requirement so that it can give the requirement context. It also supports the intent of specializing requirements.
    RATIONALE: Treating requirement like other classifiers in SysML adds symmetry to the language and adds modeling efficiencies through reuse.

    1.5.2 RULES FOR HIERARCHICAL REQUIREMENT RELATIONSHIPS: Consider adding precision to the current text based requirement relationships as follows: a) One or more properties are asserted to satisfy a requirement when the input/output parametric relationships and/or constraints are satisfied, b) A test case that verifies a requirement proves the parametric relationship and/or constraint is satisfied through a verification method (e.g., inspection, analysis, test), c) A requirement is derived from another requirement when the parameters of one requirement are derived from the parameters of another requirement typically through some form of analysis, d) A requirement refines one or more other requirements when it expresses the requirement more precisely, e) The requirement can contain other requirements, which reflects the logical AND of those requirements unless stated otherwise
    RATIONALE: When requirement relationships are provided at both the requirement level, and the requirement property level (1.3.5), the relationship between the parent relationship and the property relationships need to be semantically understood.

    2. Current Solution / Workaround
    Action: how are users currently addressing this today and what are the issues with the workarounds?

    This has been demonstrated in various presentations at the PBRWG

    3. Proposed Solution for SysML 1.5
    Action: How are we proposing to do this in SysML 1.5?

    1. Enable the following
    a. include properties in requirements
    b. include expressions in requirements (e.g., derived, constraint, opaque)
    c. enable text to refer to other model elements
    d. enable a property to be typed by a Requirement so that it can be used in context
    e. enable a requirement to be specialized

    2. Ensure users can continue to model requirements as they have in SysML v1.4

    Note 1: For specification consistency, refer to how the constraint block stereotype is specified in the specification, which may have similar characteristics to the requirement stereotype proposal. In particular, the specification of the constraint block stereotype includes the constraint property that is typed by a constraint block. Also, ensure consistency with the diagram extensions for constraint block and constraint property.

    See 'Relaxing Constraints Rationale' document, and most recent

    4. References:
    4.1. Source Document (issue filed by Sandy): http://solitaire.omg.org/secure/attachment/10829/sysml%20issue-precise%20expression%20of%20requirements-sf-c.doc
    4.2. PBRWG meeting minutes (PBRWG wiki): http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf5:groups:require:requirements

  • Reported: SysML 1.4 — Thu, 28 Aug 2014 04:00 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Updated Proposal for PBR

    Rationale for making a change to SysML:
    The current SysML specification inadvertently inhibits the creation of user profiles to extend «requirement». This kind of user profile was envisioned from the inception of SysML to not only be allowed, but encouraged… see the final paragraph in section 16.1 of the SysML 1.0 specification. Annex C.2 in the SysML 1.0 specification provides an example of a non-normative extension to «requirement», the initial intention to be able to add useful properties to requirements (e.g. source, risk, verifyMethod, verifyMethodKind), and add constraints on specific requirement relationships based on the indicated subtype of requirement. See original issue for a more detailed problem statement: http://issues.omg.org/browse/SYSMLR-155

    Priorities in developing the resolution to SYSMLR-155:
    ▪ Retain the current constraints on «requirement» and meaning, and require no change or transformation of existing user models.
    ▪ Provide a capability for user profile development of requirement-related capabilities. This was an oversight in the original specification, and was always an expected capability. Note that extension of requirement capabilities is completely consistent with non-normative Annex E.3, which has extended «requirement» from SysML 1.0 onwards.
    ▪ Make all existing requirement relationships available for any new «requirement» user profile, since it would be confusing to add new relationships with different names to express essentially the same meaning.

    This proposal refactors the «requirement» model element such that it retains all the previous constraints, but creates a new abstract stereotype «abstractRequirement» that retains ID, Text, and the requirement relationships. This new abstract stereotype may be used as a mix-in on new user-defined, non-normative profiles to meet the agreed initial scope of PBR as discussed above. Note that the new «abstractRequirement» model element, being abstract, can only be used in a user profile and NOT directly in a user model.

    Refactoring of this kind is a well-established and accepted method of maintaining software and databases, and the normative change required is well within the authority of the SysML Revision Task Force.

    The proposal consists of two distinct parts:
    1. The normative change to the specification (restricted to Chapter 16) including refactoring of «requirement» into «abstractRequirement», and associated changes to references and paragraph numbers.
    2. A non-normative appendix (Annex E.8) that describes
    a. the purpose and basic guidance for use of «abstractRequirement» in custom user profiles, and
    b. an example of a user profile based on «abstractRequirement» & «constraintBlock», as well as a user model example employing the profile, and
    c. an example of a user profile based on «abstractRequirement» & «constraint», as well as a user model example employing the profile.

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

Need to define Requirement Relationship compartment

  • Key: SYSMLR-154
  • Legacy Issue Number: 19578
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    Requirement relationships were originally intended to be optionally depicted in a compartment notation, in a manner similar to allocation relationships (see Table 15.1 on page 130). Table 16.1 does not depict requirement compartment notation, but it is referenced in section 16.3.1.2 and 16.3.1.4.

    Requirement relationship compartment notation needs to be fully elaborated in the spec, including additional elements in Table 16.1 and section 16.3.1, in a manner consistent with allocation compartment format in Chapter 15.

  • Reported: SysML 1.4 — Thu, 14 Aug 2014 04:00 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Add Requirement Compartments to Table 16.1

    The requirements relationships compartment was mistakenly omitted from Table 16.1. This compartment notation should be added to the Requirement element, consistent both with the callout notations in Table 16.2 and the allocation compartment shown in Table 15,1 (derived, derivedFrom, satisfiedBy, verifiedBy, refinedBy, tracedTo, master, slave; all in italics).

    Additionally, NamedElement should be added to the end of Table 16.1 showing compartment notation for requirement relationships consistent with callout notations in Table 16.2 (satisfies, verifies, refines, tracedFrom; all in italics)

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

Satisfy, Verify and DeriveReqt could be used with non-requirement elements

  • Key: SYSMLR-208
  • Legacy Issue Number: 19857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    SysML specification constraints the usage of Satisfy, Verify and DeriveReqt relationships to requirement model elements.
    When in MBSE approach, textual requirements are most likely to be left aside and non-textual requirements start commonly being used. For example, an Activity can represent a functional requirement, as it has inputs, outputs and a processing that shows how inputs are transformed into outputs.
    When using non-textual requirements, other model elements will start representing requirements. Therefore, those relationships should accept elements that are not SysML::Requirement model elements.

  • Reported: SysML 1.4 — Tue, 24 Nov 2015 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.5
  • Disposition Summary:

    Requirement Relationship Constraints are Appropriate

    Requirement relationships need to be contained to have at least one end be identified as a "requirement" in the model. The resolution to SYSMLR-155 has clarified the scope of requirement properties, which may help address the originator's concern.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP3 023

  • Key: SYSMLR-278
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    The term “system” is very ambiguous.

    Proposed Change: Define or clarify the term “system” in “1 Scope”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:53 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Refer to ISO 15288 for definition of System and Systems Engineering

    Add simple note in Clause 1.1 that refers to ISO 15288 for definition of 'system" and 'system engineering'. Added text is shown in red.

    See also SYSMLR-296 for adding ISO 15288 to the normative references.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP18 015

  • Key: SYSMLR-270
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    The only “PrimitiveTypes” package is extracted on this figure although there are a lot of UML2 packages. Besides, the package “UML” is ambiguous and inaccurate. In case of UML2, it is divided into small packages.

    Recommended Change: Clarify the figure.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:38 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Clarify text

    Add clarifying text to Clause 4.3. Added text in in red.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP20 016

  • Key: SYSMLR-271
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    There are “QUDV” and “ISO-80000” package. However, these material isn’t listed as Normative Reference.

    Proposed Change: Add “QUDV” and “ISO-80000” as Normative Reference.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:40 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Reference Annexes

    Make reference to the annexes of this specification that include QUDV and ISO-80000 profiles. Add text to the final sentence in clause 4.3 as shown in red.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP19 014

  • Key: SYSMLR-269
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    This sentence refers to the RFP. Previously mentioned, this clause is informative. (If it is necessary to describes the requirements, it should list the concrete requirements.)

    Recommended Change: Remove the description which include “RFP”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:37 GMT
  • Disposition: Duplicate or Merged — SysML 1.5
  • Disposition Summary:

    Dupe of SYSMLR-265

    duplicate issue.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

update constraints to set sourceContext and targetContext of «DirectedRelationshipPropertyPath»

  • Key: SYSMLR-324
  • Status: closed  
  • Source: NASA ( Robert Karban)
  • Summary:

    Constraint [2] in 8.3.2.7 DirectedRelationshipPropertyPath, p 55 says that targetContext must be specified when targetPropertyPath has a value.
    There are cases where targetPropertyPath does not have a value but still should be set.

    See attached example and cases P, R, T.

    Case R must have targetContext set to «block»D, and Case P must have targetContext set to «block»A, instead of being empty. For completeness, in Case T, targetContext must be set to «block»D. We believe that this would be technically consistent with the current SysML 1.4 specification.
    Constraint [2] says that targetContext must be specified when targetPropertyPath has a value. In Case R, targetPropertyPath does not have a value.
    But, it would be consistent with Section 8.3.2.7, including Constraint [2], to assign a value even if targetPropertyPath has no value. Constraint [2] uses the term ‘when’ rather than ‘when and only when’.

    Recommendation:
    Update constraints [1] and [2] to say that sourceContext and targetContext must be set when source or target is a property.

  • Reported: SysML 1.4 — Sun, 11 Sep 2016 17:10 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Update constraints [1] and [2]

    in 8.3.2.7 DirectedRelationshipPropertyPath, p55

    replace:
    [6]The type of the property at the last position of the sourcePropertyPath list must own or inherit the source of the stereotyped directed relationship.
    [7]The type of the property at the last position of the targetPropertyPath list must own or inherit the target of the stereotyped directed relationship.

    with:
    [6]The type of the property at the last position of the sourcePropertyPath list must own or inherit the source of the stereotyped directed relationship. The sourceContext must be set when source is a property.
    [7]The type of the property at the last position of the targetPropertyPath list must own or inherit the target of the stereotyped directed relationship. The targetContext must be set when target is a property.

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

There is no notation for units on properties and values

  • Key: SYSMLR-330
  • Status: closed  
  • Source: NASA ( Robert Karban)
  • Summary:

    Issue:
    The specification provides no notation for units on properties and values.
    There is no notation provided to show units on value properties in block definition.
    There is no notation provided to show units on values of slots or default values of value properties.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 19:31 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Create notation to show units on properties and values.

    1) Add optional unit name or symbol for value properties.
    <vpname>:<valueTypename> <unitSymbol | unitName>

    e.g. distance:Length (m)

    2) Add optional unit name or symbol for values:
    <value> <unitSymbol | unitName>
    e.g. 10 m

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP12 008

  • Key: SYSMLR-263
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    This sentences use the “Part II”, “Part III”, etc. However, these “Part”s cannot be found on this document.

    Proposed Change: Get rid of “Part” and change to the Subpart.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:28 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Remove "Part" and "Subpart"

    Remove all reference to "Part" and/or "Subpart" from the table of contents and text, but retain the divider headings (Introduction, Structural Concepts, Behavioral Concepts, Crosscutting Concepts, and Annexes), un-numbered, in both the table of context and as divider pages in the text.

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

Property path with unnamed properties is unreadable

  • Key: SYSMLR-332
  • Status: closed  
  • Source: NASA ( Robert Karban)
  • Summary:

    The property path becomes unreadable when properties are unnamed.
    e.g. car.....length

    when named, the property path looks like this:
    car.e.c.p.length

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 20:16 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Use type names if property names are not set

    Use the property types to construct the property path when property names are not set.

    Assuming that:
    car:Car.
    e:Engine
    c:Cylinder
    p:Piston

    The property path should look like this:
    car.:Engine.:Cylinder.:Piston.length

    Optionally the property name can be displayed:
    car:Car.e:Engine.c:Cylinder.p:Piston.length

  • Updated: Thu, 6 Apr 2017 13:49 GMT

ParticipantProperty multiplicity

  • Key: SYSMLR-248
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    There is a constraint in 8.3.2.12 ParticipantProperty

    [6] The property referred to by end must have a multiplicity of 1.

    What is "property referred to by end??? And why it's multiplicity must be [1]?
    Why it is not set in a profile or metamodel? Why constraint is needed?

    Also, in model example in Figure 8.13 - Internal Block Diagram for WheelHubAssembly

    There is connector typed by AssociationBlock and both ends have multiplicities more than 1.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 21:06 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Apply revision from previously adopted resolution

    Apply revision from http://issues.omg.org/browse/SYSML12-19, as reported in http://doc.omg.org/ptc/09-08-13.pdf (PDF page 75, or search on 13666).

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

JTC1 JP17 013

  • Key: SYSMLR-268
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    What is “UML 2’s StandardProfile”? Is it Profile package? I couldn’t find such materials.

    Proposed Change: Clarify the description.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:35 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Revise text in Clause 4.3

    Insert text into Clause 4.3 per directions below. Inserted text is in red.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP13 010

  • Key: SYSMLR-265
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    This sentence refer to SysML RFP. However, this RFP is not a prescription, besides, this sentence is informative. It is obvious matter to follow the RFP.

    Proposed Change: Remove this sentence which includes such description of RFP. If it is necessary to refer to the RFP, list such materials as the “Normative Reference”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:31 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Update Normative References per SYSMLR-296

    see SYSMLR-296

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Add example of PBR using Block


JTC1 JP16 012

  • Key: SYSMLR-267
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    This clause refers to the RFP. Previously mentioned, this clause is informative.

    Recommended Change: Remove the descriptions which include “RFP”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:34 GMT
  • Disposition: Duplicate or Merged — SysML 1.5
  • Disposition Summary:

    Dupe of SYSMLR-265

    duplicate issue

  • Updated: Thu, 6 Apr 2017 13:49 GMT

TriggerOnNestedPort constraint [5] makes no sense

  • Key: SYSMLR-287
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    9.3.2.13 constraint [5] states "The type of the port at the last position of the onNestedPort list must own or inherit the port port of must own or inherit the port port of". This makes no sense

  • Reported: SysML 1.4 — Wed, 10 Aug 2016 19:03 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Apply revision from previously adopted resolution

    Apply revision from Issue 18407 in http://doc.omg.org/ptc/2013-12-08, page 129, at the bottom, the two edits for constraint [5] of TriggerOnNestedPort, which updates SysML 1.3. This will replace the unapproved constraint in the SysML 1.4 spec.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

TriggerOnNestedPort constraint [6] makes no sense

  • Key: SYSMLR-286
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    9.3.2.13 Constraint [6] states "the stereotyped invocation actionthe stereotyped invocation action." This makes no sense.

  • Reported: SysML 1.4 — Wed, 10 Aug 2016 19:00 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Apply revision from previously adopted resolution

    Apply revision from Issue 18407 in http://doc.omg.org/ptc/2013-12-08, page 130, which updates SysML 1.3 by adding a constraint to TriggerOnNestedPort. This will replace the unapproved constraint added in the SysML 1.4 spec.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML 7.3.2.5 Viewpoint

  • Key: SYSMLR-48
  • Legacy Issue Number: 15018
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysML 2.2 B

    7.3.2.5 Viewpoint

    A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.

    How is this done? There are no examples. I see examples of a Viewpoint with a dependency on another Viewpoint, but no languages referencing languages in another viewpoint.

    Suggest either developing an example or deleting the sentence and adding another one after the next sentence, so it reads.

    A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. A viewpoint may reference another viewpoint to help in the specification.
    SysML 2.2 B

    7.3.2.5 Viewpoint

    A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.

    How is this done? There are no examples. I see examples of a Viewpoint with a dependency on another Viewpoint, but no languages referencing languages in another viewpoint.

    Suggest either developing an example or deleting the sentence and adding another one after the next sentence, so it reads.

    A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. A viewpoint may reference another viewpoint to help in the specification.

  • Reported: SysML 1.4 — Mon, 1 Feb 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Removed criticized sentence - it refers to an older SysML version

    Proposal:
    Remove the sentence as suggested

    „The languages and methods for specifying a view may reference languages and methods in another viewpoint.” from the specification. It is a relic from the view/viewpoint concept in SysML 1.3 and prior versions.

    Viewpoints cannot reuse other viewpoints. Therefore the second suggestion should not be added to the viewpoint description.

    Rationale:

    Now the SysML 1.4 specification clearly states that languages is a URI to a meta-model, profile or other language specifications. The URI could not be a reference to a languages property in another viewpoint.

    Methods is a derived property of type Behavior. The sentence that the methods could reference methods in another viewpoint was valid in pre-1.4 SysML where methods was a property of type String.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP8 003

  • Key: SYSMLR-258
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    UML2.0 should be refers to UML 2.4.1 unless there is inevitable reason, since UML2.4.1 has been standardized as IS.

    Proposed Change: Change the UML2.5 to UML2.4.1 on the Normative Reference list. Or if UML 2.5 is referenced, it is necessary to clarify specific reasons

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:19 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    *Provide rationale for use of UML 2.5 *

    Since UML 2.5 is not the ISO approved version, the reason for it's use as the basis for SysML 1.4 needs to be justified.

    This justification and appropriate reference should be added to the third and fourth paragraph of the introduction. The added/modified text appears in red.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP10 007

  • Key: SYSMLR-262
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    This sentence refers to the “OMG’s Model Driven Architecture (MDA)”. However, there is no prescription for the MDA. The MDA is just informative.

    Proposed Change: This sentence is informative. Therefore, this sentence should be removed.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:27 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Add reference to MDA Guide 2.0

    The entirety of Clause 3.1 is informative. MDA is a key driver of the language architecture of SysML. This statement about MDA is both informative and necessary. Add reference to MDA Guide 2.0, and add guide to normative references section. Added text indicated in red.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP15 011

  • Key: SYSMLR-266
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    According to the first line of the 3rd paragraph, “Table4.1 lists the metaclasses excluded from the UML4SysML subset”. However, only “metaclass” is ambiguous, since it is not sure which metaclass is intended. It is necessary to clarify which metaclass is intended.

    Proposed Change: Add “UML2” prior to “metaclasses”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:32 GMT
  • Disposition: Closed; No Change — SysML 1.5
  • Disposition Summary:

    Context of metaclasses is clear in context.

    Context of the metaclasses as UML 2 is clear from 1) previous paragraphs, 2) reference to the UML4SysML metacalss subset, and 3) UML 2 appearing in title of referred tables.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP14 009

  • Key: SYSMLR-264
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    The term only “UML” is ambiguous. In the previous text, it is designated as “UML 2”.

    Proposed Change: Replace “UML” with “UML2”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:29 GMT
  • Disposition: Closed; No Change — SysML 1.5
  • Disposition Summary:

    Use of "UML" is clear in context.

    The text clearly refers to UML as a language in general. UML 2 is specifically mentioned in the previous paragraph. See also SYSMLR-309, "UML" in this spec refers to UML 2.5.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP4 024

  • Key: SYSMLR-279
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    There is no clause number & heading on the first paragraph right after “Subpart”. It is a hanging paragraph.

    Proposed Change: Add the clause number & heading.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:57 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Remove text from Part/Subpart

    See SYSMLR-293, resolution to SYSMLR-263 and associated duplicate issues.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP11 006

  • Key: SYSMLR-261
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    This sentence refers to the “ISO 10303 STEP AP233”. However, there is no description of this reference on the “Normative References”.

    Proposed Change: Add “ISO 10303 STEP AP233” to the normative references list.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:25 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Update Normative References per SYSMLR-296

    see SYSMLR-296

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP7 004

  • Key: SYSMLR-259
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    The format of normative references doesn't meet ISO format.

    Proposed Change: Designate reference like as other OMG PAS documents.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:21 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Revise Normative References per SYSMLR-296

    See SYSMLR-296

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP9 005

  • Key: SYSMLR-260
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    Don’t separate the “Normative Reference” clause.

    Proposed Change: Remove the heading “2.3 Other Documents”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:23 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Revise Normative References per SYSMLR-296

    See SYSMLR-296

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP24 020

  • Key: SYSMLR-275
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    Terms shall be unity.

    Proposed Change: Change “UML2” to “UML 2”

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:47 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Change "UML2::ActivityPartition" to "UML::ActivityPartition"

    The term “UML2::ActivityPartition” refers to a unique model element in the UML metamodel. Other places in this specification make similar references as “UML::xx”, so the clause in question should be updated for consistency. Modified text is noted in red.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP2 021

  • Key: SYSMLR-276
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    In the ISO standard, "must" is disabled.

    Proposed Change: Use “shall” or “should” adequately instead of “must” based on the intention of “must”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:49 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Change modal verbs throughout specification as indicated in the attached file

    All modal verbs used in constraints and requirements in the pas/2015-08-01 (ISO/DIS 19514) document have been evaluated, and markups made to the pdf version with recommended changes in accordance with ISO/IEC Directives, Part 2, 2016

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

JTC1 JP5 022

  • Key: SYSMLR-277
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    The term “UML 2” suddenly appears without definition. Just “UML2“ is ambiguous, because OMG has some UML 2 versions. (OMG’s UML 2.4.1 is same as ISO/IEC 19505-1,2.)

    Proposed Change: “UML 2” should be defined as ISO/IEC 19505-1,2 or OMG’s specific UML 2 version in “2 Normative References”.
    Also “UML 2” shall be defined as abbreviation.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:50 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Change incorporated in SYSMLR-309

    see SYSMLR-309. Note that this specification has no list of abbreviations.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP21 017

  • Key: SYSMLR-272
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    This sentence designates “Parts II – IV”.

    Proposed Change: Change “PartsII-IV” to “Subparts II - IV”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:41 GMT
  • Disposition: Duplicate or Merged — SysML 1.5
  • Disposition Summary:

    Dupe of SYSMLR-263

    Close as duplicate of SYSMLR-263

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP22 018

  • Key: SYSMLR-273
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    This sentence designates “Parts II-IV”.

    Proposed Change: Change “PartsII-IV” to “Subparts II - IV”.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:43 GMT
  • Disposition: Duplicate or Merged — SysML 1.5
  • Disposition Summary:

    Dupe of SYSMLR-263

    Close as duplicate of SYSMLR-263

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP23 019

  • Key: SYSMLR-274
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    This sentence designates “ sub clause”

    Proposed Change: This sentence designates “ subclause”

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:44 GMT
  • Disposition: Duplicate or Merged — SysML 1.5
  • Disposition Summary:

    Dupe of SYSMLR-263

    Close as duplicate of SYSMLR-263

  • Updated: Thu, 6 Apr 2017 13:49 GMT

reception compartment not addressed

  • Key: SYSMLR-153
  • Legacy Issue Number: 19551
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    The UML 2.5 specification, section 9.2.4, states in part,
    “The compartment named “receptions” contains notation for Receptions. The receptions compartment is mandatory and always appears below the operations compartment, if it is not suppressed. The receptions compartment is used for Classifiers that own Receptions, including Class (see 11.4).”

    The SysML specification is silent regarding this compartment in blocks. I suggest that the compartment be added to the list of compartments and if the label is going to be optional like the other block compartments, then this be explicitly stated in section 8.3 as something that is not included as part of UML4SYSL.

  • Reported: SysML 1.4 — Tue, 29 Jul 2014 04:00 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Proposal: Reception compartment not addressed

    The SysML specification does not mention a notation for receptions. The metaclass Reception is part of UML4SysML (see table 4.2) and in the context of ports receptions are mentioned.

    The notation for receptions like it is defined in the UML 2.5 specification should be added to the SysML specification.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML: Protocol State Machines needed

  • Key: SYSMLR-1
  • Legacy Issue Number: 10047
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The current document eliminates Protocol State Machines on the grounds of simplification. See Section 13

    However, this leaves a hole in the capabilities of SysML. Currently, SysML supports UML interfaces (provided and required), which can’t have state machines to define them.

    It is an important part of designing systems interfaces (SE terminology) to define the details of the (UML/SysML) Interfaces. These details include the allowed ordering of messages. As we are not allowed to use behavior state machines and the standard solution, that of, protocol state machines are not included, we can’t properly do interface engineering within SysML

    If some other solution/work-around is proposed (which I don’t recommend) the explanation of how to accomplish this should be in the spec.

  • Reported: SysML 1.4 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

What kind of elements can diagrams be for?.

  • Key: SYSMLR-130
  • Legacy Issue Number: 18737
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Appendix A there is a list that says:
    The following are some of 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
    ? package diagram - package or model
    ? parametric diagram - block or constraint block
    ? requirement diagram - package or requirement
    ? sequence diagram - interaction
    ? state machine diagram - state machine
    ? use case diagram - package

    Based on my readings, which seems to indicate that the type of element whose namespace contains the elements in the diagram, I would say it should be
    ? activity diagram - activity
    ? block definition diagram - block, package, or constraint block, activity, profile
    ? internal block diagram - block or constraint block
    ? package diagram - package or model, view, modelLibrary, profile
    ? parametric diagram - block or constraint block
    ? requirement diagram - package or requirement, model, view, modelLibrary,
    ? sequence diagram - interaction
    ? state machine diagram - state machine, block, operation, use case
    ? use case diagram ? package, block, view, model, modelLibrary

    ( I left out some cases of profile, when I couldn?t think of what it would show, but profile could be added to any list that covers package)

  • Reported: SysML 1.4 — Wed, 29 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    List of "some of the designated model elements" that can represent a diagram frame has been clarified.

    The text reads 'some of the designated model elements' and not 'all of the designated model elements' in the following introductory sentence. The list does not show all possible elements that can designate a frame in the same way that the diagram elements tables do not identify all possible elements that can be shown in a SysML diagram. In general, this is a broader issue with SysML that we have not rigorously mapped the concrete syntax to the abstract syntax. However, this may be done in the future, at which time we can include the complete list of elements that can designate each frame. In the interim, including or excluding the element in this list does not imply any change to the underlying abstract syntax and semantics, but merely impacts the ability to present this model element as a diagram frame.

    The resolution incorporates some of the proposed changes but not all. A compelling use case should be provided to designate other diagram elements as frames.

    The following should be noted in response to the proposed changes:
    • As of SysML v1.4, view extends class and not package
    • A state machine diagram always designates a state machine

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

Table 8.1 Block compartment header misplaced and other formatting problems and inconsistencies

  • Key: SYSMLR-216
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Table 8.1 2nd row, Block, the compartment header, "parts" is misplaced. It is above the compartment separator but belongs below it.

    In the constraints compartment, there is an extraneous space after the { (left brace). The remainder of the diagram uses no space inside the braces.

    In the operations compartment, operation2 has a parameter q1 of Type 1 (with an embedded space). It is also used with a space in op3. However, Type1 without a space is used in operation1. Generally, no space should appear in a type name. These problems with Type 1 also appear in row 4 showing an example of a valueType. Also in row 4 (showing the valuetype) prop6 and prop7 have extraneous spaces in their types.

    Also, in Row 4 an extraneous space appears in the subsets clause of property2. It says {subsets property 0). It should say

    {subsets property0}

    .

    In both Row 2 and Row 4, operation2 has a return type of Types. Either this is some sort of category operation (which doesn't generally seem possible in UML) or one of the worst possible names for a Type

  • Reported: SysML 1.4 — Sat, 19 Dec 2015 19:34 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Proposal: Table 8.1 Block compartment header misplaced and other formatting problems and inconsistencies

    Changed as proposed by the submitter and changed Block0 to ValueType0 in the redefinition clause for the ValueType since a ValueType can not inherit from a Block.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP6 002

  • Key: SYSMLR-257
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    ISO/IEC standards use specific format as a document reference.

    Proposed Change: Use directive defined reference format as a document refer. (ISO/IEC Directive part2)

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:15 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Changes to Normative References (JTC1 02, 04, 05, 06, 10, 12, 14, 23)

    Remove all subclauses from Clause 2, reformat all references to the approved ISO format, and add references as noted.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Forked association notation ill-formed

  • Key: SYSMLR-126
  • Legacy Issue Number: 18685
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In Table 8.2 (Graphical paths defined by in Block Definition diagrams), rows MultibranchPart Association and MultibranchShared Association shows two association lines sharing one end (property3), implying the end is owned by two blocks (assuming the other ends are different), which isn't possible. Even if the two blocks on the opposite ends redefine property3 using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of property3 should be added to the figure, and some diagram extension text should explain that the "shared" graphical elements refer to three underlying model elements. The notation isn't in 2.4.1 that I can find.

  • Reported: SysML 1.4 — Wed, 24 Apr 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Resolution: Forked association notation ill-formed

    The semantics of multibranch associations are clarified in UML 2.5:

    If there are two or more aggregations to the same aggregate, a conforming tool may as a purely presentational option show them as a tree by merging the aggregation ends into a single segment adorned by the solid or hollow aggregation diamond symbol. Any adornments on that single segment apply to all of the aggregation ends. The absence of an adornment on a merged segment does not imply that the properties corresponding to the suppressed adornment have equal values for all of the aggregation ends.

    The notation depicted in table 8.2 in the SysML specification is misleading.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML diagrams show only SysML-stereotyped elements

  • Key: SYSMLR-85
  • Legacy Issue Number: 16891
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    As discussed in the SysML 1.4 RTF meeting today, it is currently unclear whether all of the elements shown in SysML diagrams have a SysML stereotype applied or not.

    In some cases, there is an explicit mention about the meaning of SysML diagrams, e.g., 11.3.1.1 Activity:

    Activities in block definition diagrams appear as regular blocks, except the «activity» keyword may be used to indicate the Block stereotype is applied to an activity, as shown in Figure 11.1.

    We need a clarification whether the meaning of SysML diagrams is that they show only SysML-stereotyped elements or not and if not which UML elements can be shown on a SysML diagram without any SysML stereotype applied.

  • Reported: SysML 1.4 — Mon, 12 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.5
  • Disposition Summary:

    No Change Required.

    There are many UML elements that are reused in SysML that do not have a SysML stereotype applied. The elements that can appear on SysML diagrams are identified in the diagram element tables and the diagram extensions sections of each specification chapter. Any additional general clarification required should be added to Section 6.3 Conventions and Typography. However, no additional clarification is required at this time.

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

16.3.2.4 Requirement Operations OCL Inconsistent

  • Key: SYSMLR-231
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    Operations paragraph under Requirement are inconsistent in calling base_class vs. base_abstraction. Also, type face is inconsistent.

  • Reported: SysML 1.4 — Wed, 16 Mar 2016 14:54 GMT
  • Disposition: Resolved — SysML 1.5
  • Disposition Summary:

    Update Requirement Operation [1]

    Change requirement operation [1] in section 16.3.2.4 to be consistent with other operations.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Multiassociation

  • Key: SYSMLR-74
  • Legacy Issue Number: 16170
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    In the spec, it is said that : « Notational and metamodel support for n-ary associations and qualified associations has been excluded from SysML.”.

    However, as shownin the extract of the table of the SyML symbol, multibranch association are possible:

  • Reported: SysML 1.4 — Thu, 5 May 2011 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.5
  • Disposition Summary:

    Resolution: Multiassociation

    The reporter confounds n-ary associations with multibranch associations. SysML only support binary associations, i.e. associations with exactly two association ends. The metamodel support for n-ary associations has been excluded from SysML.

    Multibranch associations are a notational variant of two or more binary associations that have each an association end with the same property specification.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Allocate of Actions or of Activities

  • Key: SYSMLR-51
  • Legacy Issue Number: 15132
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    When a swimlane in an activity diagram has the «allocate» stereotype, it means that the actions within the swimlane are allocated to the structural element in question. How come the examples seem to have the structural compartment of allocate from — «activity» xxx intead of «action» xxx

  • Reported: SysML 1.4 — Wed, 10 Mar 2010 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.5
  • Disposition Summary:

    Same as SYSMLR-16

    What Michael describes in SYSMLR-51 is a subset of what was described in SYSMLR-16.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

JTC1 JP1 001

  • Key: SYSMLR-256
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    Japan will approve this DIS if the all TE comments are accepted.

  • Reported: SysML 1.4 — Thu, 7 Jul 2016 20:07 GMT
  • Disposition: Closed; No Change — SysML 1.5
  • Disposition Summary:

    No action required.

    Comment is not actionable by OMG. No change to spec.

  • Updated: Thu, 6 Apr 2017 13:49 GMT

BindingConnector

  • Key: SYSMLR-10
  • Legacy Issue Number: 11333
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    The semantics of the Binding Connector is described as follow :

    “8.3.2.10 Binding Connector

    Description

    A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values. If the properties at the ends of a binding connector are typed by a DataType or ValueType, the connector specifies that the instances of the properties must hold equal values, recursively through any nested properties within the connected properties. If the properties at the ends of a binding connector are typed by a Block, the connector specifies that the instances of the properties must refer to the same block instance.”

    So, I understand that definition if the multiplicity of the properties linked by the binding connector is 0..1 or 1. But what happen is the upper bound of the multiplicity is greater than 1? If for example, it is 0..* ? And moreover, what happen when the multiplicity of both property is different, as for example on one end 0..1 and on the other end 1 ? In this case, as according to the previous definition, the value of both properties has to be equal, what happen to the value of the proiperty which multiplicity is 1 when the other property is not yet defined?

  • Reported: SysML 1.4 — Tue, 28 Aug 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML: Interaction diagram and Data-based comm of SysML

  • Key: SYSMLR-14
  • Legacy Issue Number: 11627
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    Here is a question on the usage of sequence diagrams with SysML, more specially with blocks that communicate via flow ports.

    Within UML, Message is associated with signature of either a Signal or an Operation (see constraint 2 on Message meta class, p. 492 of the UML2 superstructure spec.).

    In SysML, blocks introduce an alternative for communication between blocks w.r.t. to usual UML2 composite structures: flow ports are basically dedicated to support data-based communication between blocks in contrast of UML2 that does not support such kind of communication between composite structures.

    In this case, a Message within an interaction should be able to refer either a DataType, a Block, a ValueType if the communication happen between two atomic flow ports, or to a FlowSpecification if the communication happen between two non-atomic port.

    I did not see anything related this issue within the SysML spec. Do I miss something or is it something missing in the SysML doc?

  • Reported: SysML 1.4 — Mon, 22 Oct 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Issue: Nested connector ends

  • Key: SYSMLR-9
  • Legacy Issue Number: 11276
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Nested connector ends:

    "Connectors may be drawn that cross the boundaries of nested properties to connect to properties within them."

    That's an important feature of SysML.

    "The ability to connect to nested properties within a containing block requires that multiple levels of decomposition be
    shown on the same diagram."

    I think that's a problem in practice. Often I don't want to see the nested properties in the diagram.
    I propose to add a notational feature to show that a connector end is connected with a nested property without
    showing that property.

    For example we could draw the connector to the border of the surrounding property and attach the stereotype <<nested>>
    as a short form of <<nestedConnectorEnd>> and optionally the propertyPath.

    What do you think?

  • Reported: SysML 1.4 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

It is not allowed in UML to display stereotypes of related elements

  • Key: SYSMLR-12
  • Legacy Issue Number: 11496
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Stereotypes, tags and constraints are displayed on elements that can’t have such stereotypes applied. It is not allowed in UML to display stereotypes of related elements (secondary references):
    a) Stereotypes
    i. Block stereotypes are displayed on parts
    ii. Block stereotypes are displayed on object nodes
    iii. Parameter stereotypes are displayed on ActivityParameterNode
    iv. Behavior or operation stereotypes are displayed on CallActions
    b) Tags
    i. Block allocations are displayed on parts
    ii. Units and dimensions shall be possible to show on properties and slots, but these tags are owned in Valuetype
    c) Constraints
    i. Constraints of ConstraintBlock are displayed on constraintProperty (B.30)

  • Reported: SysML 1.4 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Parts are added directly into package

  • Key: SYSMLR-13
  • Legacy Issue Number: 11499
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Parts are added directly into package. B27 - <<moe>> element that is a part is displayed inside of a package <<view>>

  • Reported: SysML 1.4 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Lack of notation for units and dimensions on values.

  • Key: SYSMLR-11
  • Legacy Issue Number: 11493
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Lack of notation for units and dimensions on values. There are no samples at all

  • Reported: SysML 1.4 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML: UML Qualified Associations

  • Key: SYSMLR-2
  • Legacy Issue Number: 10048
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysML currently discards UML 2.1 qualified associations (see 8.3.1.4) as not being of interest to the SE community.

    I contest this on two grounds –

    1) a. Qualifiers are used expressively and meaningfully to explain domain situations that have nothing to do with data modeling. For example, when I say a baseball roster had 9 members and that there are 9 positions to fill, I am not explicitly saying that there is one person per position. Qualifiers allow me to clarify this piece of the real world and would be very useful on a BDD.

    b. Qualifiers are also used idiomatically with generalization discriminators to tie parallel generalization structures together. They are capable of modeling situations, such as when there are many types of missiles, each with their own launcher type.

    c. Qualifiers are also used to indicate addressing schemes and mechanisms. For example, by placing an operation/activity etc that returns a type in a qualifier, one can specify the mapping or prioritization /ordering algorithm. Specifying such algorithms may be the SE’s job, when it part of an equation report, algorithm development. This could fit into SysML and support allocation to functional (target prioritization scheme, best antenna-signal function) and structural components (packet routers). This is fully in the spirit of what practicing SEs do and would round out the capability of SysML.[Note that this capability could be delayed for a later SysML, the other parts should be addressed sooner]

    2) Qualifiers appear to be part of small part of UML that is incompatible with use with a SysML strict profile mechanism. Imagine a model done in strict SysML, then brought into UML, where a qualifier is added to the relationship, changing the multiplicity at one end. If the model is then brought back into (strict) SysML and the qualifier is then dropped, the multiplicity cannot be automatically restored (or determined from the model). Because of this, qualifiers must be forbidden in UML in such contexts

  • Reported: SysML 1.4 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Section: 12. Interactions

  • Key: SYSMLR-8
  • Legacy Issue Number: 11117
  • Status: closed  
  • Source: International Business Machines ( Eldad Palachi)
  • Summary:

    I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario

  • Reported: SysML 1.0 — Wed, 4 Jul 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Section: 9.3.2.5 FlowPort

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

    The relationship between a behavioral flow port and parameters is marked as a semantic variation point. Isn't it possible to specify a concrete relationship here? The specification proposes a binding relationship. What is a binding relationship? It is not known in SysML or UML.

  • Reported: SysML 1.0 — Fri, 13 Oct 2006 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Block namespace compartment: Are external relationships allowed

  • Key: SYSMLR-7
  • Legacy Issue Number: 11011
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The block namespace compartment shows a bdd of the elements that are part
    of the namespace of the block.

    Is it allowed to show relationships from a block inside that compartment to
    a external block? The relationship could be in the model, but can I show it
    in the diagram?

    I think it should be allowed. I don't see any problems.

  • Reported: SysML 1.4 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Timing diagrams

  • Key: SYSMLR-6
  • Legacy Issue Number: 10642
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Timing diagrams are missing in SysML. They are an important diagram for several engineering disciplines. For example I know a project from the automotive/robotic domain that won't use SysML, because of the missing timing diagrams. Timing diagrams will improve the acceptance of SysML in engineering disciplines.

  • Reported: SysML 1.0 — Mon, 5 Feb 2007 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Section: Figure 14.2

  • Key: SYSMLR-5
  • Legacy Issue Number: 10500
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The figure and added text describing the use of <<extend>> is still unclear and inconsistent. As agreed, converting Start the vehicle to an <<include>> and Park to <<extend>> will correct the confusion and make the added text unnecessary.

  • Reported: SysML 1.0 — Mon, 4 Dec 2006 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML: Generalizing Activites

  • Key: SYSMLR-3
  • Legacy Issue Number: 10058
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Section 11 should show an example of generalization/specialization of Activiites when then are being shown in a bdd.

  • Reported: SysML 1.4 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

10.3.1.2 Parametric Diagram

  • Key: SYSMLR-18
  • Legacy Issue Number: 12131
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    10.3.1.2 Parametric Diagram: clarify applicability of square box notation to constraint parameters (or otherwise) SysML1.0, 10.3.1.2 Parametric Diagram: 'Small square box notation for an internal property A value property may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a value property may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of property boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where an internal property box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the innermost property.' It is not clear whether 'value property' here is meant to refer to a constraint parameter. Also, the term 'internal property' does not exclude, for example, nested constraints, leaving open the possibility of drawing nested constraint properties using square box notation, which is surely not intended. The following suggests that only constraint parameters - not value properties - are intended: SysML1.0, , 10.3.2.1 ConstraintBlock: '[1] A constraint block may not own any structural or behavioral elements beyond the properties that define its constraint parameters, constraint properties that hold internal usages of constraint blocks, binding connectors between its internally nested constraint parameters, constraint expressions that define an interpretation for the constraint block, and general-purpose model management and crosscutting elements.' Rewrite SysML1.0, 10.3.1.2 Parametric Diagram, replacing all references to 'value property' and 'internal property' with 'constraint parameter': 'Small square box notation for a constraint parameter A constraint parameter may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a constraint parameter may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of constraint parameter boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where a constraint parameter box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the constraint parameter.'

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Annex B / Figure B27

  • Key: SYSMLR-22
  • Legacy Issue Number: 12147
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    Figure B.27: <<view>> Package "steals ownership" of MOEs, Actor, UseCase and Requirement Severity Critical since there is currently no sensible way to implement <<view>> in tools ! In Figure B.27 - Establishing a Performance View of the User Model It is not at all clear how the MOEs, Actor, UseCase and requirement should be shown as directly within the view without the view package "stealing ownership". Appears to break constraint: '7.3.2.4 View [1] A view can only own element import, package import, comment, and constraint elements.' See also example images in Magicdraw UML SysML Plugin at: http://school.nomagicasia.com/node/127 http://school.nomagicasia.com/files/images/Figure%20B.27%20-%20Establishing%20a%20Performance%20View%20of%20the%20User%20Model.png Note that this relates to:: Issue 11500: <<view>> as Package extension is very bad idea (sysml-rtf), No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus@magicdraw.com nerijus@nomagic.com) '<<view>> as Package extension is very bad idea. Package is used for ownership, so it is not possible to show the same elements in different packages (as different point of view)'

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Annex B / Figure B.38

  • Key: SYSMLR-24
  • Legacy Issue Number: 12154
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    Figure B.38: property names of p:[PowerSubsystem] inconsistent w.r.t. other figures Figure B.38 gives p:[PowerSubsystem] with parts: em: [ElectricMotor] t: [Transmission] ice: [InternalCombustionEngine] Figure 9.3 shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine (ecu:PowerControlUnit) (epc: ElectricalPowerController) Figure 9.6 IBD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine (ecu:PowerControlUnit) (epc: ElectricalPowerController) Figure 15.10 IBD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine emg:ElectricalMotorGenerator (ecu:PowerControlUnit) (epc: ElectricalPowerController) (can:CAN_Bus) Figure B.18 BDD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine em: ElectricalMotorGenerator pcu:PowerControlUnit (epc: ElectricalPowerController) .. For consistency Figure B.38 should show p:[PowerSubsystem] with parts: emg: [ElectricMotor] (not 'em') trsm: [Transmission] (not 't') ice: [InternalCombustionEngine] Also, Figure B.18 should show PowerSubsystem with part: ecu:PowerControlUnit Visit also analysis at: http://school.nomagicasia.com/node/149

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Annex B / B.4.8.3 Activity Diagram

  • Key: SYSMLR-19
  • Legacy Issue Number: 12144
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    B.4.8.3 Activity Diagram (EFFBD): refers to allocations to parts instead of blocks SysML1.0: 'B.4.8.3 Activity Diagram (EFFBD) - Acceleration (detail) Figure B.35 shows the ProvidePower activity, using the decomposed activities and objectFlows from Figure B.34. It also uses AllocateActivityPartitions and an allocation callout to explicitly allocate activities and an object flow to parts in the PowerSubsystem block.' In fact the AllocateActivityPartitions in Figure B.35 represent blocks, not part Properties typed by blocks.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Annex B / Figure B.35


Section: Generalization of stereotyped elements

  • Key: SYSMLR-26
  • Legacy Issue Number: 12255
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The generalization of model elements, e.g. blocks, does only affect the instances (from Generalization definition: Each instance of the specific classifier is also an indirect instance of the general classifier.). Doesn't that mean that stereotypes of a block and it's properties are not inherited by sub-blocks? If yes all informations about flow ports, units and so on get lost. They are not inherited by the sub-blocks.

  • Reported: SysML 1.0 — Sun, 2 Mar 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Annex B / Figure B.9

  • Key: SYSMLR-21
  • Legacy Issue Number: 12146
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    Figure B.9: clarify turnIgnitionToStart message on driver:Driver Is it supposed to be a message to self ? If so please include message to self path, otherwise explain,

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

Annex B / Figure B.10

  • Key: SYSMLR-20
  • Legacy Issue Number: 12145
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    Figure B.10: justify/clarify 'StartVehicle' from outside in terms of UML Please clarify how UML4SysML supports the drawing of a 'StartVehicle' message from the boundary of a ref Interaction.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Annex B, Figure B.29

  • Key: SYSMLR-25
  • Legacy Issue Number: 12160
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

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

  • Reported: SysML 1.0 — Sun, 6 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Section: 5.3

  • Key: SYSMLR-15
  • Legacy Issue Number: 11653
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    SysML needs the capability to interchange diagrams in addition to model data. The concrete syntax complliance should include a requirement to comply with diagram interchange in a similar way that the infrastructure specifciation does. The following is included in section 2.3 of the Infrastructure Spec under Concrete Syntax Compliance: - the ability to output diagrams and to read in diagrams based on the XMI schema defined by the Diagram Interchange specification for notation at that level. This option requires abstract syntax and concrete syntax compliance. The proposal is to add the same requirement as above to section 5.3 as a second bullet under the concrete syntax compliance.

  • Reported: SysML 1.0 — Mon, 19 Nov 2007 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Inferred Allocation on Allocate Activity Partitions

  • Key: SYSMLR-16
  • Legacy Issue Number: 12123
  • Status: closed  
  • Source: Raytheon ( Rick Steiner)
  • Summary:

    When an allocation relationship is depicted on an activity diagram using Allocate Activity Partitions, it is unclear if the allocation relationship is from the Action Node to the Part represented by the partition (direct allocation), or from the Activity typing the Action Node to the Block typing the Part (Inferred allocation). Since in practice it has become necessary to represent both conditions, this portion of the SysML specification should be modified to incorporate some graphical indication to distinguish them.

  • Reported: SysML 1.4 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Item Flows on Activity Diagrams

  • Key: SYSMLR-17
  • Legacy Issue Number: 12125
  • Status: closed  
  • Source: Raytheon ( Rick Steiner)
  • Summary:

    Since ItemFlow is a stereotype of InformationFlow, it can be related to an ActivityEdge and depicted on an Activity Diagram. At least one tool has provided this capability. Clarify the use of ItemFlows on Activity Diagrams in the specification: If this is not desirable, then an additional constraint must be added to ItemFlows to prevent it. Personally, I like the idea of representing ItemFlows on ObjectFlows, but the semantic meaning of this representation is unclear. If this is retained, then it should be discussed in both chapter 9 and chapter 11.

  • Reported: SysML 1.4 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Inability to represent dependent, independent parameters on constraint properties

  • Key: SYSMLR-38
  • Legacy Issue Number: 13348
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Parametrics provide a powerful capability for representing constraints on properties. However, they currently do not allow a modeler to specify or notate dependent and independent parameters on a usage of a constraint property. This will enable the modeler to better express the nature of the constraint in many usage situations. The recommendation is to stereotype constraint parameters so that they can be designated as in, out, or in-out if desired. They can also be left unspecified as they are in the current parametric diagram. Proposed Solution. Add a stereotype called constraint parameter that extends property, with a stereotype property that can be in, out, in-out, or unspecified. Consider including the desctiption in the diagram extension for the parametric diagram in 10.3.1.2, adding the stereotype in 10.3.2, the diagram elements in Table 10.2, and updating the usage example in Fig 10.3.

  • Reported: SysML 1.1 — Mon, 26 Jan 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Support BDD's for State Machines

  • Key: SYSMLR-36
  • Legacy Issue Number: 13263
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    One very powerful organizational technique of SysML is the pairing of definitional diagrams with usage diagrams

    BDD (for Blocks) IBDs

    BDD (for Activities) ACTs

    BDD (for Constraint Blocks) PARs

    The BDD form identifies the elements (structural, functional, constraint) and the 2nd form assembles the elements using detailed design techniques suitable for the element form.

    It would be convenient and symmetric to support a similar diagram for for State Machines

    BDD(for States) STMs

    In the past, Class diagrams for States (in UML 1.x) were used. However, it appears that UML 2.x has deleted the ability to use inheritance relationships among states. Though we could look to UML to fix this, I believe it is possible to model state->substate relationships as compositions without a change to UML to produce a satisfactory conclusion.

  • Reported: SysML 1.4 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

AllocateActivityPartition and UML 2 semantics

  • Key: SYSMLR-37
  • Legacy Issue Number: 13342
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In Allocations, AllocateActivityPartition, Constraints, the second paragraph says the AllocateActivityPartition stereotype does nopt preserve the semantics of of UML 2 ActivityPartition, and that partitions with AllocateActivityPartition do not have responsibility for invoking the actions in them. I think there is no conflict with UML 2 semantics, because UML 2 ActivityPartition only requires performing the actions to be the responsibility of the element represented by the partiion, not the invoking of the action. This seems compatible with allocation.

  • Reported: SysML 1.1 — Mon, 26 Jan 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Binding Relationships require unit conversions

  • Key: SYSMLR-35
  • Legacy Issue Number: 13261
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Binding relationships are used between model element properties and parameter in the constraint blocks, similarly they are used between constraint blocks.

    These constraint blocks are intended to be reusable.

    However connecting constraint blocks from different sources does not usually work unless the units are the same. Model element values may also not be using tehehe same units.

    A reasonable solution is to indicate the scaling factor on the binding relationship. This could be done in several ways. One way would be to indicate a simple assignment equations between the two parameter names.

    Currently

    x----------------------------------Y

    Proposed

    Y=100*x

    x-----------------------------------------Y

    Instead of using a constant 100, we could used a named constant such as cmPm

    If both ends of the binding relationship were identically named, we need to add an arrow to indicate the souce and target sidel

    à

    X=cmPM*X

    X-----------------------------------------X

    This would indicate that the left side X must be multipled by the cmPm to give the left side x

    This approach allows us to handle more complex conversions by including the ability to add/sub constants

    C=5/9*(F-32)

  • Reported: SysML 1.4 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Requirement constants should be integrated into Model-centric vision of SysmL

  • Key: SYSMLR-34
  • Legacy Issue Number: 13259
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysML requirements are now pure text and not completely integrated in to
    the model-centric approach

    Currenltly requirements are written as

    The top speed of this car shall be greater than 100 mph.

    Instead, it should be written as

    The top speed of this car shall be greater than <x>.

    And there be a compartment of the requirement where the current value of
    <x> is given

    <x> = 200mph.

    This <x> should be integrated as a design value throughout SysmL and
    should be connectable to parmetrics. It should also support dependencies
    so that other requirements value's (and block's features) can be
    dependent on the value of <x>. Then I can determine all the places in my
    system where there is a dependency on <x> and my equations and
    constraints are automatically updated. Which in many cases would allow
    me to automatically rerun my simulations.

    This is an improvement in integrating the model. Currently, with pure
    text requirements constants in the requirements are often repeated in
    equations, parametrics, constraints, algorithms. This repeating defeats
    some of the advantages of model-approach, as they are identical or
    related elements that need to be synchronized by hand.

  • Reported: SysML 1.4 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Representation of nested object nodes in activity diagrams

  • Key: SYSMLR-32
  • Legacy Issue Number: 13197
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: Representation of nested object nodes in activity diagrams. Discussion: It is desirable to be able to represnt nesting of object nodes on activity diagrams to reflect one or more levels of nested properties of the classifier that types the object node. For example, if water is shown as an object node, and it is desired to refer to the temperature of water, then it should be possible to reflect this property on the activity diagram using the notations that are used on ibd's. In particular, one may want to use either a nested rectangle to represent the property, or the dot notation. Proposed update. In the diagram extensions for activity diagrams in Section 11.3.1.4, add a clarifying statement that nested properties of the classifier that types an object node can be represented on activity diagrams either using the nested rectangle notation or the dot notation similar to the use of nesting on ibd's and parametric diagrams.

  • Reported: SysML 1.1 — Wed, 31 Dec 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Requirements interchange issue

  • Key: SYSMLR-31
  • Legacy Issue Number: 13177
  • Status: closed  
  • Source: ProSTEP iViP Association ( Steven Vettermann)
  • Summary:

    Information for facilitating the partner integration within the specification and requirements definition process (requirements interchange) are missing (e.g. meta information like version, access rights).

    Remark: There is a specification already addressing this topic, the Requirements Interchange Format (RIF). It is available for download as ProSTEP iViP Recommendation PSI 6 at www.prostep.org. This specification was introduced to the SE DSIG by Rupert Wiebel from HOOD (a paper is available) and presented by Dr. Steven Vettermann from ProSTEP iViP and discussed at the ManTIS meeting on December 11th.

  • Reported: SysML 1.4 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Section: 8/8.3.2 Inability to efficiently capture datasets

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

    There is currently limited ability to capture datasets for selected property values. A simple example is the difficulty in capturing the time histories for the position, velocity, and acceleration properties for two different instances of a vehicle, where the vehicle is a block, and the position, velocity, and acceleration are value properties of vehicle. Another example is the need to capture data such as environmental loads data (e.g. temperature, vibration as a function of freq) which is referenced as part of a requirement.

  • Reported: SysML 1.1 — Mon, 12 Jan 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Figure B.34 and Figure B.35

  • Key: SYSMLR-27
  • Legacy Issue Number: 12366
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    FigureB34 shows an Activity decomposition with: * an <<activity>> ControlElectricPower owning part Property 'elecDrivePower:ElecPower'. * an <<activity>> ProvideElectricPower without any owned part Properties. FigureB35 shows: * an Action 'a3:ControlElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> driveCurrent' * an Action 'a4:ProvideElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> elecDrivPower' The translation of ObjectFlows in FigureB35 to part Properties in the Activity decomposition FigureB34 is thus inconsistent.

  • Reported: SysML 1.0 — Tue, 1 Apr 2008 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML: Operations on Activities need to be callable (e.g., start, restart, cancel)

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

    SysM:L: Operations on Activities need to be callable (e.g., start, restart, cancel)

  • Reported: SysML 1.4 — Thu, 11 Dec 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML: Activity Properties should be accessible in Activity diagrams for decision making

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

    SysML: Activity Properties should be accessible in Activity diagrams for decision making

  • Reported: SysML 1.4 — Thu, 11 Dec 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML: Align SysML Activities with Foundational UML

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

    SysML: Align SysML Activities with Foundational UML

  • Reported: SysML 1.4 — Thu, 11 Dec 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

callout notation issues

  • Key: SYSMLR-45
  • Legacy Issue Number: 14575
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    I'm trying to prepare requirements for "callout" notation changes in MagicDraw SysML diagrams and trying to remove tool-specific notation.

    The SysML spec says that each allocatedTo or allocatedFrom property will be expressed as «elementType» ElementName.
    It looks simple at a first glance, but later SysML spec is a total mess:

    "For uniformity, the «elementType» displayed for the /allocatedTo or /allocatedFrom properties should be from the following list, as applicable. Other «elementType» designations may be used, if none of the below apply.

    «activity», «objectFlow», «controlFlow», «objectNode» «block», «itemFlow», «connector», «port», «flowPort», «atomicFlowPort», «interface», «value»

    Note that the supplier or client may be an Element (e.g., Activity, Block), Property (e.g., Action, Part), Connector, or BehavioralFeature (e.g., Operation). For this reason, it is important to use fully qualified names when displaying / allocatedFrom and /allocatedTo properties. An example of a fully qualified name is the form (PackageName::ElementName.PropertyName). "

    So, looking at the predefined list it is clear that:
    For the Activity or other "clean" UML element it is an metaclass name in lowercase.
    for let's say ItemFlow or FlowPort is is an stereotype name in lowercase.
    That's ok.

    But what is <<atomicFlowPort>> ? Port with <<flowPort>> stereotype applied which has isAtomic=true.
    What is <<value>> ? Property which has Type with <<ValueType>> stereotype applied.

    In the example below (Figure 15.4) it has allocation of actions to parts and it uses another one <<elementType>> which is not described - <<part>>.
    What is <<part>> ? The Property with AggregationKind = composite?

    Also, full qualified names and <<elementTypes>> are used incorrectly in this Figure or I don't understand how it should be used.
    For example:
    <<block>> Block4.Part5 - why it is <<block>>, but not <<part>> ???
    <<part>> Part2:Block1 - why part name is before block name? It should be displayed as (PackageName::ElementName.PropertyName) as described above.

    I believe, all these rules and exceptions should be described somewhere

  • Reported: SysML 1.4 — Thu, 22 Oct 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Flow properties and activity paramters

  • Key: SYSMLR-52
  • Legacy Issue Number: 15176
  • Status: closed  
  • Source: Françse ( Caron)
  • Summary:

    The SysML flow properties specify elementary flows (nature and direction) that can cross the boundary of a block through a port.

    According to the functional approaches of systems engineering, an entering flow when getting over the boundary of a block is handled as an input by at least one function of the block. An outgoing flow getting out the boundary of the same block is produced as an output by at least one function.

    Activity diagrams are used for carrying out functional graphs with SysML. Inputs and outputs of SysML activities are specified by parameters. Nevertheless SysML does not seem to provide any mean to relate activity input / output parameters to the flow properties. This entails that the unfortunate SysML developers, after having made careful and strenuous efforts for specifying the block interfaces with flow properties and ports, have no other solution than to redo exactly the same work for specifying the inputs / outputs of the functional architecture as activity parameters (or vice-versa). Moreover, there is no mean to ensure consistency in the SysML model between the flow properties and the activity parameters and neither between the ports and the activity pins.

    A solution would be to enable to use flow properties like parameters as activity inputs / outputs.

  • Reported: SysML 1.4 — Fri, 16 Apr 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML 1.2 Issue Viewpoint referencing other viewpoints properties

  • Key: SYSMLR-53
  • Legacy Issue Number: 15293
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 26

    Original Text

    7.3.2.5 Viewpoint

    Description

    A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases

    Comment

    How is the highlighted sentence done? There are no examples. I see examples of Viewpoint with a dependency on another Viewpoint, but no references for the individual fields (e.g., language and methods). Are the fields populated in an inheritance manner. Can they be overridden? Does it only work if the fields are blank on the dependant Viewpoint?

    Type: Clarification

    Add example and clarify rules

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Do parametric bindings observe derived and read-only properties

  • Key: SYSMLR-47
  • Legacy Issue Number: 15003
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Do parametric bindings observe derived and read-only constraints on properties?

    .

    In SysML if I bind a read-only property value to a parameter, I would expect that any evaluation of the parametric model would not be able to update the property value. If I wanted to have such a value calculated, I would expect to take off the read-only constraint

    Similarly, if I bind a derived property value to a parameter, I would expect that any evaluation of the parametric model would not use that value as an input, but only as an output.

    However, this is answered (and I hope it is answered positively), the SysML specification should clarify this behavior

  • Reported: SysML 1.4 — Fri, 22 Jan 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Ability for a binding connector to be typed

  • Key: SYSMLR-49
  • Legacy Issue Number: 15079
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    A binding connector used in parametrics should allow for decomposition via association blocks in a similar way that other connectors support decomposition. The specification currently includes a constraint on Block that precludes this as follows: “The number of ends of a connector owned by a block must be exactly two. (In SysML, a binding connector is not typed by an association, so this constraint is not implied entirely by the preceding constraint.)”

  • Reported: SysML 1.1 — Sat, 20 Feb 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Binding to multiplicity in parametrics

  • Key: SYSMLR-46
  • Legacy Issue Number: 14998
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    In parametrics, one cannot currently bind a constraint parameter in a constraint expression to a multiplity. For example, one may need to include the number of tires in the constraint expression that constraints braking force. However, if the model includes a Vehicle, composed of Tire with multiplicity 4, one must be able to access the number of tires (i.e. the multiplity) in the expression.

  • Reported: SysML 1.1 — Thu, 21 Jan 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Inheriting Allocations

  • Key: SYSMLR-50
  • Legacy Issue Number: 15112
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The allocated stereotype includes properties «allocatedTo» and «allocatedFrom». Since these properties are stereotype properties, they are not inherited by the classifiers that they are applied to. A constraint could be applied to either the allocate or allocated stereotype which would impose that it is automatically applied to all subclasses of the classifier. The issue to be resolved is whether a subclass of a classifier with «allocatedTo» and/or «allocatedFrom» properties should inherit those properties

  • Reported: SysML 1.4 — Tue, 22 Dec 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Allocations should not generate dependencies

  • Key: SYSMLR-39
  • Legacy Issue Number: 13840
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Allocations should not generate dependencies The Allocate stereotype extends the Abstraction UML meta-class, which is a Dependency. It is in contradiction with the following description (cf. p133: "This concept requires independent models if “function” (behavior) and “form” (structure)") If we refere to EIA-632 the logical solution that will be allocated to the physical solution only depends from upstream requirements. In some cases, one may have some (upstream) requirements to use a given implementation platform, but this cannot be considered generic and anyway the dependendcy is still on the requirement not directly on the platform. A logical solution makes abstraction of the implementation to focus on issues strictly related to the missions of the system. Then, by definition a logical solution is semantically dependent from the need and not from the implementation. In most times, several logical solutions are possible. Their are more or less effective against each of their requirements, that's why the design work includes tradeoff activities. Saying that a given logical solution is not convenient to be implemented on a given platform doesn't mean that it's not a logical solution to the need. More, the current stereotype implementation biases the impact analysis. The objective of this analysis is to parse the model and to report what model elements should be reviewed (i.e. are potentially impacted) in case of modification of a given model element to preserve the model integrity and consistency. If the platform is modified, what has first to be checked is whether or not the modified elements of the platform can still play the role they have been assigned by the allocation (with the required QoS, etc...). If the answer is "yes", then nothing to do. If the answer is "no", then they are several potential choices: a) if possible modify the allocations only, b) select another logical solution (i.e. modify it) and define the new allocations, b) select another platform and define the new allocations. This is matter of tradeoff. The only point that has always to be checked is the allocations. Then the only "thing" that actually depends on the "from" and "to" sides of an allocation is the allocation itself.

  • Reported: SysML 1.1 — Fri, 27 Mar 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect

  • Key: SYSMLR-41
  • Legacy Issue Number: 13942
  • Status: closed  
  • Source: NASA ( Jeff Estefan)
  • Summary:

    Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect. Replace <<requirement>> Client with Named Element (no stereotype). Figure 16.1 (top of pg. 148): Recommend adding Refine stereotype (as specialization of Trace stereotype); otherwise note that it comes directly from UML metaclass rather than as a UML extension. Recommend reordering specializations of trace in alphabetical order on UML class diagram (e.g., Copy, DeriveReq, [Refine], Satisfy, Verify). Section 16.3.2: Should reintroduce Refine relationship description and contraints, even though a UML metaclass and not an extension. It is an important relationship with respect to requirements. Perhaps introduce prior to Sect 16.3. Section 16.3.2.3 (middle of pg. 150): Change cardinality of /derived: Requirement attribute from [0..1] to [*]. Also, add right bracket to cardinality of /master: Requirement attribute. Currently shows as [0..1 with not closing right bracket.

  • Reported: SysML 1.1 — Fri, 29 May 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Proposal to have a stereotype for reference nested property

  • Key: SYSMLR-42
  • Legacy Issue Number: 14055
  • Status: closed  
  • Source: International Business Machines ( Eldad Palachi)
  • Summary:

    When one needs to reference a value of a specific property of part in a composition hierarchy in order to bind it to a constraint parameter, one uses the dot notation shown in section 8.3.1.2. (Example: a box labeled myCar.myEngine.currentTemp in a parametric diagram). When such a box is binded to a constraint parameter a nested connector end may be used to reference this property in the context of the composition hierarchy. However this poses a serious implementation issue for tools since until the box is binded it has no real model element behind it, also if one copies this box or the diagram to another hierarchy in the model then the tool has to complicated analysis. We propose to have a stereotype for reference nested property similar to nested connector end in which the path in the composition hirerchy is specified (i.e. propertyPath: Property [1..*] (ordered) - like in section 8.3.2.6). This will make it easier for tools to implement backed by the standard meta-model.

  • Reported: SysML 1.1 — Sun, 5 Jul 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Parsing Text in Requirements

  • Key: SYSMLR-40
  • Legacy Issue Number: 13939
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Parsing Text in Requirements: There is a need to parse the text string in a SysML requirement and create a reference from the parsed text to other model elements or perhaps to a URI. This will enable one to associated additional meaning to selected portions of the text string, such as a particular value, property name, function, or some other feature. A parsed text string which can refer to other elements could be generalized to support other uses within SysML where text is used. In this sense, the proposal could treat this in another chapter such as model elements to make it more generally applicable. One possible approach is to consider a net type called "ParsedText" that has some structure to it, so that the text can be parsed and a reference can be made from the parsed text. The Requirements text property would then be typed by ParsedText instead of String as it currently is.

  • Reported: SysML 1.1 — Wed, 27 May 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Need to have an explicit way to bind flow properties or atomic flow ports to block properties

  • Key: SYSMLR-44
  • Legacy Issue Number: 14059
  • Status: closed  
  • Source: International Business Machines ( Eldad Palachi)
  • Summary:

    Need to have an explicit way to bind flow properties or atomic flow ports to block properties. Currently section 9.3.2.3 lacks such rules. Such rules would allow a consistent way to relay data via flow ports to the properties of blocks and also would allow a convenient way to transmit values via flow port by changing a value of a property owned by the block.

  • Reported: SysML 1.1 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Flow port compatibility with behavior

  • Key: SYSMLR-43
  • Legacy Issue Number: 14058
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Flow port compatibility with behavior. Semantics of flow ports need to be clarified as they relate to behavior. In particular, need to clarify how flow properties are passed to behavior (classifier behavior, owned behavior) including to the parameters of operations and activities.

  • Reported: SysML 1.1 — Tue, 7 Jul 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Continuous flows in non-streaming situations with >1 multiplicities

  • Key: SYSMLR-56
  • Legacy Issue Number: 15298
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysML 1.2 Issues: Continuous flows in non-streaming situations with >1 multiplicities

    11.3.2.1 Continuous

    It’s a bit unclear how continuous flows work in non streaming situation, especially with high multiplicities.

    If a continuous flow arrives at a pin with a multiplicity of 2, it would appear that the 1st and 2nd value arriving at the pin would be captured. If the flow is also continuously valued, the two values would be same. The difference between two adjacent samples goes to zero if the delta time between samples goes to zero (assuming differentiability).

    Type: Fix

    To make this capability useful, we’ll need to add a sampling rate to be able to use continuous with >1 multiplicity. If we don’t the specification should have a caveat for >1 multiplicity and differentiable input values.

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML 1.2 Issues: Optional with streaming

  • Key: SYSMLR-57
  • Legacy Issue Number: 15299
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Sysm 1.2 Optional with «streaming»

    Page 92

    11.3.2.6 Optional

    Does optional on an input mean optional to start the activity or optional for the activity to finish? Consider an «optional» streaming input.

    Does optional on an output mean optional to appear at the end of the activity or optional for it ever to appear? Consider an «optional» streaming output..

    We need to have all the possibilities for streaming; it probably should have two multiplicities for each streaming parameter

    Starting Multiplicity: number of tokens that must appear for the activity to start

    Total Multiplicity: number of tokens that must appear over the lifetime of the activity

    Ending Multiplicity: number of tokens that must appear at the end of the activity

    Total Multiplicity: number of tokens that must appear over the lifetime of the activity

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML primitive value types

  • Key: SYSMLR-62
  • Legacy Issue Number: 15882
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    We have issues with SysML primitive value types - Real, Integer, Boolean, String etc.

    The problem is that these types are not inherited from corresponding UML primitive types - Real, Integer, Boolean, String.
    That means, UML tool can't understand, what kind of ValueSpecification should be created for values of properties typed by these value types.
    Should it be LiteralString or LiteralInteger or OpaqueExpression?
    Constraints can't check if slot values are compatible with property types, as it is not clear what kind of value specification it should be also.
    There are issues in parametrics solving also, as values must be compatible with property types.

    I think, SysML primitives must be directly inherited from UML primitives - Real subtype of UML Real, String subtype of UML String etc.

  • Reported: SysML 1.4 — Wed, 8 Dec 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML Issue on Multiplicity of Use Case Communication Associations

  • Key: SYSMLR-61
  • Legacy Issue Number: 15875
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysMl does not give any example of using multiplicity on the relationships between actors and use cases. This is part of UML as shown in Figure 16.11.

    Apparently, the "official" interpretation of SysML is that if there is no example, it is not part of SysML. This incompatibility means that standardize training, books, etc, on Use Cases can not be applied to SysML. And the notation is of value.

  • Reported: SysML 1.4 — Mon, 6 Dec 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML Issue based on UML 15369

  • Key: SYSMLR-59
  • Legacy Issue Number: 15728
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A new keyword was added for attributes in UML,

    {id}

    . This concatenation of all such attributes within a class (block) for an instance must be unique.

    While this will mostly be used by database developers, it’s also a domain model analysis property, e.g, Social Security Number for a US citizen, Mac Address, etc. As such, it may be useful to some SysML modelers.

  • Reported: SysML 1.4 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML Issue representation of properties as associations

  • Key: SYSMLR-60
  • Legacy Issue Number: 15730
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In UML, there appears to be consistent representing of attributes as regular associations from the owning class. SysML, in similar circumstances, represents value properties as composite associations. We should try to understand what UML is saying (and perhaps push back on them) and consider the value of consistency.

  • Reported: SysML 1.4 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Figure B.35 object nodes

  • Key: SYSMLR-58
  • Legacy Issue Number: 15683
  • Status: closed  
  • Source: International Business Machines ( Eldad Palachi)
  • Summary:

    Annex B, Figure B.35, the object nodes after the decision and before the merge should be removed and the names/types moved to the ProportionPower pins / output parameter node.

  • Reported: SysML 1.4 — Tue, 5 Oct 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Definition of part

  • Key: SYSMLR-70
  • Legacy Issue Number: 16058
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The current definition of "part" includes
    ports. Is that intended?

  • Reported: SysML 1.2 — Fri, 11 Mar 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal

  • Key: SYSMLR-54
  • Legacy Issue Number: 15295
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 36, 8.3.1.1 Default «block» stereotype on unlabeled box is not always optimal

    Original Text

    Default «block» stereotype on unlabeled box
    If no stereotype keyword appears within a definition box on a block definition diagram (including any stereotype property compartments), then the definition is assumed to be a SysML block, exactly as if the «block» keyword had appeared before the name in the top compartment of the definition.

    Comment

    I question whether this is always desirable, e.g.,

    1) if the diagram had the «functional hierarchy» diagram usage stereotype applied, wouldn’t the default be «activity»,

    2) if the containing block is an activity block, wouldn’t «activity» be the right default

    Type: Clarification/Fix

    Add sentences that say: If the bdd diagram has a «diagram usage» specified (such as «functional hierarchy»), a different default (such as «activity») can be used.

    If the bdd diagram is for an activity block, the default stereotype elements is «activity»

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML 1.2 Issues: DistributedProperties on Activates

  • Key: SYSMLR-55
  • Legacy Issue Number: 15296
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 45 Distributed Properties on Activities

    Original Text

    8.3.2.4 DistributedProperty

    Constraints

    [1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.

    Comment

    As I read this, on a BDD, if we have activities, the properties of the activities cannot be distributed properties, because activities are not stereotyped as block

    Type: Fix

    Rewrite this constraint,

    [1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block, Activity, or ValueType.

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Association owning ends

  • Key: SYSMLR-75
  • Legacy Issue Number: 16263
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Associations in SysML should be able to own their ends. Otherwise modelers can't add an association between blocks in model libraries they do not have permission to modify. They also cannot create association that are non-navigable in both directions, which might be useful for directing flows across them into flows contained by the association as a block.

  • Reported: SysML 1.2 — Wed, 25 May 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML Issue on Refine limitations

  • Key: SYSMLR-67
  • Legacy Issue Number: 16016
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The text description of how the refine relationship can be used disagrees with formal restrictions.

    On page 126, 2nd paragraph, the text says.

    “The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.”

    This allows a refine relationship to be

    [Requirement] ß1..*[Model element]

    Or

    [Requirement] à [Model element]

    However, Figure 16.1 only has

    /refinedBy:Named Element[*] as property for a Requirement

    Thus it is not possible to have a requirement refine a model element.

    This is confirmed by Figure 16.2, which in showing the tags for a NamedElement

    Has /refines Requirement [*]

    This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around).

    So problem 1.

    The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence:

    The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.

    Problem 2

    The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word “diagram” from the text

    Final wording

    The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement.

    Additional comment.

    It’s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement.

  • Reported: SysML 1.4 — Wed, 9 Feb 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Incorrect statement about UML n-aries

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

    Section 8.3.1.3 (UML Diagram Elements
    not Included in SysML Block Definition
    Diagrams) says "N-ary associations,
    shown in UML by a large open diamond
    with multiple branches, can be modeled
    by an intermediate block with no loss in
    expressive power." An intermediate
    block cannot capture multiplicities that
    would be on an the ends of an n-ary
    association. These multiplicities are
    for the links from end to end, rather
    than from intermediate object to end, as
    they would be with an intermediate
    object. However, intermediate blocks
    can specify the number of links each end
    might participate in for any of the
    other n-1 ends, which is not possible
    with n-ary associations. The
    expressiveness of n-aries and
    intermediate blocks is overlapping,
    rather than equivalent.

  • Reported: SysML 1.2 — Tue, 22 Mar 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

IBD notation doesn't distinguish item properties from connector labels

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

    Item properties and connector labels both appear in colon notation near the center of an assocation. How do you tell the difference?

  • Reported: SysML 1.2 — Tue, 25 Jan 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Blocks cannot own items flows

  • Key: SYSMLR-64
  • Legacy Issue Number: 15982
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Blocks cannot own items flows, because UML NameSpace abstractly owns NamedElement. Consider specializing on blocks to own item flows.

  • Reported: SysML 1.2 — Tue, 25 Jan 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete

  • Key: SYSMLR-73
  • Legacy Issue Number: 16113
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    the parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete w.r.t. to figure B.30. Is it ok?

  • Reported: SysML 1.4 — Mon, 28 Mar 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Where have stereotypes been defined?

  • Key: SYSMLR-72
  • Legacy Issue Number: 16112
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    in some figures of the examples provided in Annex, some stereotypes are displayed: <<domain>>, <<external>>, <<diagramDescription>>, … and so on. Can someone tell me where these stereotypes have been defined?

  • Reported: SysML 1.4 — Mon, 28 Mar 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Description of Item Flows

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

    Description of item flow and its attributes should explain that "assign" means "realization", change "usage" to "instance", and convey items rather than classifiers.

  • Reported: SysML 1.2 — Tue, 25 Jan 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Item flows can have multiple types but item properties cannot

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

    Item flows can have multiple types but item properties cannot

  • Reported: SysML 1.2 — Wed, 23 Feb 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Compartment labelling rules

  • Key: SYSMLR-69
  • Legacy Issue Number: 16057
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Suggest these compartment rules:

    • Italics
    • Plural
    • All lower case
    • Words separated by spaces
  • Reported: SysML 1.4 — Fri, 11 Mar 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Another issue with allocate

  • Key: SYSMLR-63
  • Legacy Issue Number: 15884
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that’s ok according to the current SysML specification.

    However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context

    and not be valid in another context.

    I’ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn’t work. MagicDraw doesn’t allow blocks to be owner of a allocate.

    I’m not sure whether it is a tool issue or if I’ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I’m not sure if that’ll solve

    my problem.

    Any ideas?

  • Reported: SysML 1.4 — Thu, 9 Dec 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML's PrimitiveValueTypes library is missing "value" properties everywhere

  • Key: SYSMLR-84
  • Legacy Issue Number: 16876
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    For SysML 1.3, has anyone tried to specify the value of a SysML::ValueType ?

    If you haven't done so, please try to do this carefully – i.e., don't just assume that Real x = "42.0" is enough!

    You'll realize then that the SysML 1.3 spec doesn't provide the capability to specify the actual value for any of the SysML::Libraries::PrimitiveValueTypes

    SysML::Libraries::PrimitiveValueTypes::Boolean
    SysML::Libraries::PrimitiveValueTypes::Integer
    SysML::Libraries::PrimitiveValueTypes::Real
    SysML::Libraries::PrimitiveValueTypes::String

    Since we can't specify the actual real value of a SysML Real, we can't specify the realPart or the imaginaryPart of a SysML Complex number either!

    SysML::Libraries::PrimitiveValueTypes::Complex::realPart :
    SysML::Libraries::PrimitiveValueTypes::Complex::imaginaryPart

    What is missing is an actual "value" attribute whose type then must be from the UML PrimitiveTypes library since it's the only capability in UML/SysML we have to specify an actual "value" via the Literal[X] metaclasses in UML.

    SysML::Libraries::PrimitiveValueTypes::Boolean::value : PrimitiveTypes::Boolean – an actual value can be specified as a UML::LiteralBoolean
    SysML::Libraries::PrimitiveValueTypes::Integer::value : PrimitiveTypes::Integer – an actual value can be specified as a UML::LiteralInteger
    SysML::Libraries::PrimitiveValueTypes::Real::value : PrimitiveTypes::Real – an actual value can be specified as a UML::LiteralReal
    SysML::Libraries::PrimitiveValueTypes::String::value : PrimitiveTypes::String – an actual value can be specified as a UML::LiteralString

    SysML::Libraries::PrimitiveValueTypes::Complex can remain as-is since it inherits the capability
    to specify an actual value for its realPart & imaginaryPart attributes thanks to SysML::Libraries::PrimitiveValueTypes::Real::value : PrimitiveTypes::Real

    I also realized that the QUDV library inconsistently uses in a few places SysML::Libraries::PrimitiveValueTypes when in fact it should use UML's PrimitiveTypes.

    I believe that this is a new issue for SysML 1.3.

  • Reported: SysML 1.4 — Mon, 5 Dec 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Property Based Requirements

  • Key: SYSMLR-88
  • Legacy Issue Number: 17016
  • Status: closed  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    In SysML today requirements can be represented in a model only in a textual form. Being textually based these requirements often introduce ambiguity, are often redundant with other model element properties, and lack a formally making it difficult to leverage directly in parametric and other analysis efforts.
    This issue suggests an alternative means of representing requirement in the model environment without using a pure text string. The alternative means is referred to as Property Based Requirement (PBR). PBR defines a requirement mathematically and defines a set of requirement properties. The goal is declare other types of model elements as requirements and apply these properties to those model elements.

    A PBR theory is described in a paper called “Toward a Property Based Requirements Theory: System Requirements Structured as a Semilattice” by Patrice Micouin. This technique is further elaborated in a paper called “Requirements Management within a Full Model-Based Engineering Approach” by Yves Bernard

  • Reported: SysML 1.3 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Question about the Activity decomposition in Bloc Definition Diagrams

  • Key: SYSMLR-86
  • Legacy Issue Number: 16945
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.).

    For example I use that extensively in the FAS methodology (Functional Architectures for Systems).

    I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that.

    When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the

    activities in the model? I think it must do that. Unfortunately tools seems to have a different behavior.

  • Reported: SysML 1.4 — Sun, 8 Jan 2012 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Error in pending 1.3 diagram 15.6 and elsewhere

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

    In Figure 15.6 in pending SysML 1.3, on the left side of the diagram, the object-flow, labeled objectflow3 is a dashed line. From table 11.2, object flows always use solid lines (though control flow can use either solid or dashed).

    This was also wrong in SysML 1.2, though the diagram number was then 15.5.

    Thanks to Geoffrey Shuebrook who pointed this out to me,.

  • Reported: SysML 1.4 — Mon, 9 Jan 2012 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML

  • Key: SYSMLR-89
  • Legacy Issue Number: 17210
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML. Furthermore they are not even defined as instances of PrimitiveType despite their XMI id.

    For example we have:

    <packagedElement xmi:type="uml:DataType"
    xmi:id="_OMG_SysML_20110919_SysML_Libraries-PrimitiveValueTypes-String"
    name="String"/>

  • Reported: SysML 1.4 — Sat, 3 Mar 2012 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Problems with property-specific types

  • Key: SYSMLR-79
  • Legacy Issue Number: 16636
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Definition of a property-specific type cannot be shown on a bdd. This would require, at least, a defined name for the block or value type that types the property, such as one based on the property name.

    No runtime semantics is given. Presumably all instances of a property-specific type are values of the property it types, but this isn't said anywhere. It the property it types is an end of an association, this could be expressed by a lower multiplicity greater than zero on opposite end.

    No examples of property specific types are given.

    The requirements for property-specific types to be anonymous, singly generalized, and owned by the owner of the property they type don't appear to be necessary. Naming is useful for managing PSTs, multiple generalization is useful for reusing property defaults and other characteristics on multiple PSTs, and package ownership enables the same PST to be used on multiple properties that have the same type.

    The description of the property-specific types refers to:

    "local specializations of referenced typed" (Section 8.3.1.1 Block Definition Diagram) and

    "starting classifier of the property-specific type." (Section 8.3.2.7 PropertySpecificType)

    The terms "local", "referenced type", "starting classifier nof the property specific type" are undefined and not deducible from other text.

    The following sentence is a tautology (ie, adds nothing to the spec):

    "The PropertySpecificType stereotype is automatically applied to the "classifier that types a property with a propertyspecific type. (Section "8.3.2.7 PropertySpecificType)"

    because a property with a property specific type is one where the property type has the PropertySpecificType applied.

    Section 8.3.1.1 (Block Definition Diagram) at the end says the name of the property specific type can be included in brackets, but constraint [2] of PropertySpecificType says they are anonymous.

    The discussion of compartments on internal properties in Section 8.3.1.2 (Internal Block Diagram) can be simplified by removing the discussion of property-specific types.

  • Reported: SysML 1.3 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Can Enumerations be used on parametric diagrams for typing constraint parameters

  • Key: SYSMLR-77
  • Legacy Issue Number: 16304
  • Status: closed  
  • Source: PTC ( Andreas Korff)
  • Summary:

    when participating in the discussions on the draft ballot 3 on the SysML 1.3 spec, we observed that there is a need for clarification. The question was about whether Enumerations can be used on parametric diagrams for typing constraint parameters. The spec defines:

    From 8.3.2.10

    SysML defines ValueType as a stereotype of UML DataType to establish a more neutral term for system values that may never be given a concrete data representation. … A SysML ValueType may define its own properties and/or operations, just as for a UML DataType. See Section 8.3.2.2, “Block” for property classifications that SysML defines for either a Block or ValueType.

    ValueTypes can be used to type constraint parameters. Since ValueTypes extend UML DataTypes, and Enumerations are a subtype of DataType, Enumerations might be used. Since Blocks could be used as types of constraint parameters as well, the implication that any subtype of a UML datatype might lead to the implication that any subtype of UML classifier could be used here as well (e.g. activity or StateMachine), which is of course not meant.

    We need to constrain this definition better

  • Reported: SysML 1.4 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Issue on Block constraint#4

  • Key: SYSMLR-83
  • Legacy Issue Number: 16726
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    In SysML v1.3, §8.3.2.2 Blocks, the constraint #4 states:

    [4]In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association. (An inverse end of this association, whether owned by another block or the association itself, must always be present so there is always a metamodel element to record the inverse multiplicity of the reference.)”

    No such constraint exists in the UML specification which conversely says the following (UML v2.4, §7.3.45):

    “A property related to a classifier by ownedAttribute represents an attribute, and it may also represent an association end. It relates an instance of the class to a value or collection of values of the type of the attribute”

    The SysML Block constraint #4 has no clear justification and should be removed.

  • Reported: SysML 1.4 — Mon, 28 Nov 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Lightweight representations of faults, failures, hazards and off-nominal conditions and behavior

  • Key: SYSMLR-82
  • Legacy Issue Number: 16657
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    There is a critical need to model off nominal conditions and behavior associated with faults, failures, and hazards. However, there currently is no standard way to represent this in the SysML model. This issue is intended to provide some lightweight and standardized and light-weight capability for this type of modeling, such as a trigger on a state machine with the stereotype failure or a fault stereotype to represent a fault condition. There is a separate profile (not standardized) that was developed by Bruce Powell Douglass that provides a broader more comprehensive capability that could be leveraged as source material.

  • Reported: SysML 1.2 — Thu, 10 Nov 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

TestCase should use PackageMerge

  • Key: SYSMLR-76
  • Legacy Issue Number: 16286
  • Status: closed  
  • Source: KnowGravity Inc. ( Markus Schacher)
  • Summary:

    The stereotype «TestCase» is primarily specified in the UML Testing Profile (UTP) and should not be defined by SysML redundantly (or even inconsistently). Rather it should be separated in a dedicated package in SysML and a PackageMerge be specified. This would properly add the properties of a «TestCase» specified in SysML to the "base" «TestCase» specified in UTP.

  • Reported: SysML 1.2 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Content of Requirement::/tracedTo

  • Key: SYSMLR-78
  • Legacy Issue Number: 16373
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Yann Tanguy)
  • Summary:

    In the specification the content of the derived property “Requirement::tracedTo” is defined as follows:

    • /tracedTo: NamedElement [*]

    Derived from all elements that are the supplier of a «trace» relationship for which this requirement is a client.

    As «copy» «deriveReqt» «verify» and «satisfy» inherit from “Trace”, does this means that /tracedTo also list all elements that are the supplier of a «copy» «verify» «satisfy» «deriveReqt» relationship for which this requirement is a client ?

  • Reported: SysML 1.4 — Mon, 18 Jul 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

InstanceSpecifications for exactly one instance

  • Key: SYSMLR-80
  • Legacy Issue Number: 16652
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    InstanceSpecifications describe sets of instances, including the empty set, but some applications need to describe exactly one instance. SysML should have InstanceSpecifications that are constrained to describe exactly one instance, like the owlIndividual stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

InstanceSpecification equality

  • Key: SYSMLR-81
  • Legacy Issue Number: 16653
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Multiple InstanceSpecifications can describe overlapping sets of instances, and some application need to specify whether the sets overlap. For InstanceSpecifications that specify exactly one instance, this indicates whether they describe the same instance, like the sameAs stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Contradiction regarding allowed use of the derived indicator for constraint parameters

  • Key: SYSMLR-99
  • Legacy Issue Number: 17546
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Lenny Delligatti)
  • Summary:

    There is a contradiction in the SysML spec. regarding whether constraint parameters-as properties of constraint blocks-may use the derived indicator, "/".

    Pg. 84 of the spec. clearly states the original intent of the SysML Development Team with respect to constraint blocks: "The block constraints are non-causal and do not specify the dependent or independent variables. The specific dependent and independent variables are often defined by the initial conditions, and left to the computational engine."

    On pg. 86, however, the spec. states textually that constraint parameters are properties of constraint blocks: "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks."

    There is no metamodel fragment in the spec. that shows that the stereotype SysML::ConstraintParameter extends the metaclass UML4SysML::Property. The text on pg. 86 (quoted above) conveys this.

    As a result of this (implied) extension relationship, we would have to conclude that a constraint parameter could use the derived indicator, "/", to convey that it is a dependent variable in the constraint expression.

    This stands in contradiction, however, to the intended non-causal, non-directional nature of constraint blocks as expressed on pg. 84.

    Proposed Resolutions:

    1) Add a metamodel fragment to the spec. that clearly shows the extension relationship from SysML::ConstraintParameter to UML4SysML::Property.
    2) Add a constraint to the SysML::ConstraintParameter stereotype disallowing the use of the derived indicator, "/", on constraint parameters.

  • Reported: SysML 1.3 — Wed, 8 Aug 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Callout notation for port-specific types and initial values

  • Key: SYSMLR-95
  • Legacy Issue Number: 17406
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification allows property-specific types and property-specific initial values. Ports are just a special kind of property. Thus it would be possible to model port-specific types and values. The only problem is, that it is not possible to show the specifics of these types or the initial values within an internal block diagram, as would be the case for a property.

    Suggested addition to the spec

    • property-specific types and initial values also apply to ports [would not be forbidden now, but just to clarify this point]
    • A callout notation can be used in an ibd for ports with a port-specific type or initial value. It shows the same information as the compartments for properties.
    • Table 8.3: Example for call-out notation

    Maybe this notation could also be used on block definition diagrams, and in this case for properties as well. Then there should be a sentence in chapter 8.1.1.1 and an example in Table 8.2.

  • Reported: SysML 1.3 — Tue, 5 Jun 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

remove figure numbers from diagram frames

  • Key: SYSMLR-96
  • Legacy Issue Number: 17423
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Remove figure numbers where they still exist within the SysML diagram frame tab. As content is reshuffled in the document, figure numbers inside the diagrams can become out-of-sync with the figure numbers in the document, as is currently the case for figures C.35 and C.37. Maintain the figure number only in the figure caption, not redundantly within the diagram itself.

    Diagrams that include figure numbers in the diagram frame tab include 4.2, 4.3, 17.5, C.35, C.36, and C.37.

  • Reported: SysML 1.3 — Tue, 12 Jun 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Problems with 1.3 Enumeration Literals

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

    In section 6.3 ,the convention is given that indicates that enumeration literals within SysML are named with the suffix of Kind.

    Enumeration types: always end with “Kind” (e.g., “DependencyKind”).

    Several of the SysML enumeration literals are correctly named, but the following do not follow the convention:

    Section 9.3.2 Figure 9.1 FlowDirection --> FlowDirectionKind

    Section 9.3.2 Figure 9.4 FeatureDirection --> FeatureDirectionKind

    Section 11.3.3 Figure 11.9 ControlValue --> ControlValueKind

  • Reported: SysML 1.4 — Tue, 12 Jun 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Interface blocks and protocols

  • Key: SYSMLR-101
  • Legacy Issue Number: 18169
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The practical usage of port implies the ability to specify a protocol, especially when operations or receptions are provided but not only (this can be true with flow properties too).

    The UML::Interface metaclass (at L3) has a specific property to define a protocol. Note that this protocol is not an owned behavior but only a specification of conformance characteristics.

    I believe we should add something similar to our InterfaceBlock stereotype, even if we do not include UML protocol state machines.

  • Reported: SysML 1.4 — Fri, 27 Jun 2014 11:16 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

How to refer to properties of an extension?

  • Key: SYSMLR-100
  • Legacy Issue Number: 18168
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    For a practical usage it is required to be able to refer to a property of a stereotype application, for instance as target or source of an allocation relationship. This need is somewhat similar to that of referencing a nested property but we shall make sure the solution selected for the Common Reference Path will be able to address this case too.

  • Reported: SysML 1.4 — Mon, 2 Apr 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML: References to CreateEvent incorrect

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

    In UML 2.4.1, the equivalent to createEvent and desturctionEvent are now called messages. This should be followed in SysML. This changes the text in the 1st row of Table 12.1 on page 116, but it may impact other places also.

  • Reported: SysML 1.4 — Sat, 7 Jul 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Is <> keyword (or stereotype) on binding connectors is part of SysML notation?

  • Key: SYSMLR-94
  • Legacy Issue Number: 17373
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Is <<equal>> keyword (or stereotype) on binding connectors is part of SysML notation? Figure 9.7 Usage example of proxy and full ports

  • Reported: SysML 1.4 — Thu, 17 May 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

9.3.2.9 What is InterfaceBlock?

  • Key: SYSMLR-92
  • Legacy Issue Number: 17255
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    9.3.2.9 What is InterfaceBlock? Where is description? Description is the same as constraint [1] text now.
    InterfaceBlock is kind of Block, so, can it be used everywhere Block is used? e.g. part of the FullPort.

    Constraint [2]. Does it mean Interface block can't have value properties and e.g. constraint properties?
    Constaint [3] - does it mean "proxy ports" ? if so, it could be more clear text to say "InterfaceBlock can own proxy ports only"
    constraint [4] - it must be constraint[4] for FullPort???

  • Reported: SysML 1.4 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Section 9.3.1.7

  • Key: SYSMLR-90
  • Legacy Issue Number: 17248
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    9.3.1.7. The keyword “full” before a property name indicates the property is stereotyped by ProxyPort . Copy/paste bug? <<full>> is for FullPorts.

    What is the type of FullPort? Spec says nothing.

    What are possible owned properties of the InterfaceBlock? Values, FlowProperties? other? In 9.1 InterfaceBlock it is not flow nor value.

  • Reported: SysML 1.4 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

clarification, what "part property" is

  • Key: SYSMLR-93
  • Legacy Issue Number: 17307
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    The NEW issue - clarification, what "part property" is, as new port types typed by Blocks changed everything, they fit into "part properties" definition.
    SysML 1.3, Page 43 : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. "

  • Reported: SysML 1.4 — Fri, 13 Apr 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Port labels inside Port symbol

  • Key: SYSMLR-91
  • Legacy Issue Number: 17251
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Port labels inside Port symbol. Is it new notation, not supported in UML? One more nightmare for tools?Where it is described?
    What information can be inside port? Name, type? How about stereotype label, tags, etc? E.g. <<full>> - should it be inside or not?

  • Reported: SysML 1.4 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Clarification required for Copy relationship

  • Key: SYSMLR-121
  • Legacy Issue Number: 18525
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    There's a few issues with the Copy relationship as described in the specification.

    1. It's unclear what constraint 3 means. What are subrequirements (nested or derived)?

    2. How do you match subrequirements in the slave to subrequirements in the master?

    3. There's no constraint on the number of Copy relationships that a slave Requirement can be involved in (e.g. one Requirement could be the slave of two different master Requirements). What happens to the "text" tag if there are multiple masters?

    4. There's no constraint stopping a Requirement from being directly or indirectly a master of itself. Shouldn't there be?

  • Reported: SysML 1.3 — Mon, 4 Mar 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

9.3.2.4 direction of ports and their notation (second issue)

  • Key: SYSMLR-113
  • Legacy Issue Number: 18441
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Constraint [1] - properties that have no FlowProperty applied. does it include ports, association ends, value properties???

    More specifically – can port be stereotyped as directed feature/flow property, what types of properties can be stereotypes with these stereotypes?

    This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

  • Reported: SysML 1.4 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

9.3.2.4 direction of ports

  • Key: SYSMLR-112
  • Legacy Issue Number: 18439
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    9.3.2.4 What does it mean "the meaning of direction"?? how direction is visible on port?
    This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

  • Reported: SysML 1.4 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

View and Viewpoint Limitations in support of auto-view generation

  • Key: SYSMLR-108
  • Legacy Issue Number: 18391
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications.

    At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions.
    The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows:
    Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.
    View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint.
    Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification.
    Some of the limitations that have been identified include the following:
    a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.)
    The viewpoint method does not include provisions for specifying the language for the methods. Adding the ability to designate the language would clarify viewpoint.
    b) Viewpoint description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application.
    c) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders.
    d) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information.
    A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is described below.
    In a simple example, different subviews may correspond to different sections of a document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata ).
    In this example, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents.
    e) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others.
    f) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking.
    g) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group).

  • Reported: SysML 1.3 — Mon, 28 Jan 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML stereotype notation creates ambiguity about to which element is the stereotype applied

  • Key: SYSMLR-106
  • Legacy Issue Number: 18268
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The SysML notation allows a stereotype <<S>> applied to an element E1 to be shown as the notation for a different element E2 related to E1 in some way.

    Example: 11.3.1.2 CallBehaviorAction and Figure 11.2:

    Stereotypes applied to behaviors may appear on the notation for CallBehaviorAction when invoking those behaviors, as

    shown in Figure 11.2.

    What this means is that if a CallBehaviorAction shows a stereotype <<S>>, then it is unclear whether <<S>> is applied to the CallBehaviorAction itself or to the behavior that the CallBehaviorAction calls.

    This ambiguity is problematic for users reading SysML diagrams as indicated by SysML issue 17549:

    Table 11.1 on pg. 93 shows that the «controlOperator» stereotype can be applied

    to a call behavior action (when that call behavior action calls an activity that also

    has the «controlOperator» stereotype applied).

    More generally, the SysML spec needs to be reviewed where this stereotype notation can result in this kind of ambiguity.

  • Reported: SysML 1.4 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Inability to specify partial allocation and requriements satisfaction

  • Key: SYSMLR-111
  • Legacy Issue Number: 18434
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The allocate and requirements relationships (e.g., satisfy, verify, derive) do not explicitly state the degree to which these relationships apply. For example, a satisfy relationship may imply a model element may fully satisfy, partially satisfy, or not satisfy at all a particular requirement at a point in the design process. However, there is no standard way to refer to this partial vs complete satisfaction. A similar issue applies to the verify and derive relationships.

    Note: Similar issues apply to allocate relationships where the allocate may indicate that the element is fully or partially allocated to another element.

    The SysML spec should consider incorporating a tagged value to indicate 0, partial or complete on these relationships.

  • Reported: SysML 1.3 — Fri, 8 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Constraint [5] should include specializations of Requirement

  • Key: SYSMLR-110
  • Legacy Issue Number: 18410
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Constraint [5] states:

    "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement»."

    This would seem to stop Requirements from owning Classes stereotyped by specializations of Requirements (for example, ExtendedRequirement from D.2.2 Stereotypes), which seems too limiting. I'd suggest this is reworded to:

    "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement» or one of its specializations"

  • Reported: SysML 1.3 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Incorrect constraint [2] on InterfaceBlock

  • Key: SYSMLR-104
  • Legacy Issue Number: 18183
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Constraint [2] specifies that "Interface blocks cannot have composite properties that are not ports". However, in order to show FlowProperties, typed by ValueTypes and owned by InterfaceBlocks, you need to be able to have composite properties.

    The constraint at the moment is too strict and needs to be changed to allow certain composite properties.

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

VerdictKind

  • Key: SYSMLR-107
  • Legacy Issue Number: 18312
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    I just realized that Requirements::VerdictKind enumeration in SysML profile is NOT a ValueType, so I can't use it in SysML model to type my values.

    Does everyone agree that it shall have ValueType stereotype applied?

    We should make sure all datatypes we provide are ValueTypes.

  • Reported: SysML 1.4 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Missing type constraints for FullPort

  • Key: SYSMLR-103
  • Legacy Issue Number: 18182
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Ports stereotyped as FullPort can currently be typed by anything a normal Port can be typed by. This isn't the intent of the specification, so constraints should be added.

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Figure 15.8 diagram type

  • Key: SYSMLR-109
  • Legacy Issue Number: 18409
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Figure 15.8 (Example of Structural Allocation) is an ibd, but has blocks instead of parts in it. Is it supposed to be a bdd?

  • Reported: SysML 1.3 — Fri, 27 Jun 2014 11:16 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

  • Key: SYSMLR-105
  • Legacy Issue Number: 18193
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

  • Reported: SysML 1.4 — Mon, 22 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Missing ownership constraints

  • Key: SYSMLR-102
  • Legacy Issue Number: 18181
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    The FlowProperty stereotype can current be applied to any Property in SysML. However, this leaves it open to applying the stereotype to Ports (inc. extensions of Ports) and Properties owned by non-Blocks. This doesn't seem to match the intent of the specification so constraints need to be added

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are

  • Key: SYSMLR-127
  • Legacy Issue Number: 18705
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    SysML 1.3 section 9.1.3 Proxy Ports and Full Ports states:

    Full ports cannot be behavioral in the UML sense of standing in for the owning object, because they handle features themselves, rather than exposing features of their owners, or internal parts of their owners.

    This is incorrect; see UML 2.5, section 11.3.3 Structured Classifier Semantics:

    A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. If there is no Behavior defined for this EncapsulatedClassifier, any communication arriving at a behavior Port is lost.

    Based on the UML 2.5 semantics of behavioral ports, there is no legitimate reason to exclude a SysML 1.3 FullPort to be behavioral in the UML sense.

    This is inconsistent with SysML 1.3, section 9.3.2.7 FlowProperty:

    Items going to or from behavioral ports (UML isBehavior = true) are actually going to or from the owning block. (See “Block” on page 66 for definition of owning block of proxy ports in this case.)

    The above is consistent with the UML 2.5 semantics but it is inconsistent with the SysML 1.3 semantics of FullPort above.

    Finally, SysML 1.3 section 9.3.2.8 FullPort states:

    They cannot be behavioral ports, or linked to internal parts by binding connectors, because these constructs imply identity with the owning block or internal parts.

    The notion that a behavioral port implies identity with the owning block or internal parts is incorrect and does not make sense.

    It would require that a behavioral port to be typed by its owning block or internal part.

    It would be impossible for a block A to have a behavioral port typed by B for example.

  • Reported: SysML 1.4 — Thu, 9 May 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Diagram show inconsistent data

  • Key: SYSMLR-120
  • Legacy Issue Number: 18503
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Diagrams C.35, C.36 and C.37 show inconsistent allocation between the displayed items, yet the text would seem to imply that they're supposed to show the same relationships.

    In C.35, the allocation is from an ObjectNode symbol called "DriveCurrent" (which I believe equates to an ObjectFlow - name unknown) to an ItemFlow called "i1".

    In C.36, the allocation is from an ObjectNode called "DriveCurrent" to a Connector (name unknown).

    In C.37, the allocation is from an ObjectFlow called "o6" to a Connector called "epc-emg.1".

    There are a number of issues:

    1. ObjectNode is an abstract specialization of ActivityNode and as such you can't have any instances of them in a model. Any reference to an ObjectNode should be removed.

    2. The allocation should consistently be from ObjectFlow "o6" to either ItemFlow "i1" or Connector "epc-emg.1".

    3. In order to make it clear that the same items are being related, the names of the ObjectFlow and the Connector/ItemFlow should be shown on all diagrams. Currently the ObjectFlow and the Connector names are not shown.

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Unclear is StructuredActivityNode owned Actions should be Allocated

  • Key: SYSMLR-125
  • Legacy Issue Number: 18678
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    In the Constraints section the specification states the following:

    'An Action appearing in an “AllocateActivityPartition” will be the /client (from) end of an “allocate” dependency. The element that represents the “AllocateActivityPartition” will be the /supplier (to) end of the same “allocate” dependency.'

    For Actions owned by an Activity and shown inside the partition, this constraint is clear. However, if you have a StructuredActivityNode inside a partition and that StructuredActivityNode owns an Action, how many Allocate dependencies should there be? Should there be:

    a) One allocate from the StructuredActivityNode only?
    b) One allocate dependency from the StructuredActivityNode and one from the Action inside the StructuredActivityNode?

    To make things clearer, instead of the constraints section saying:

    'An Action appearing IN an "An Action appearing in an “AllocateActivityPartition”'

    It should say something along the lines of:

    'An Action referenced in the "node" role of an “AllocateActivityPartition”'

    This would remove the ambiguity of what "in" means and allow users to decide when Allocate dependencies are created.

  • Reported: SysML 1.3 — Fri, 19 Apr 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Don't use the optional notation for Pins with Allocation

  • Key: SYSMLR-119
  • Legacy Issue Number: 18502
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Figure C.35 uses the optional notation for Pins (i.e. >[]> instead of []->[]). The allocation callout note is anchored to the object node symbol which makes it ambiguous as to which dictionary item(s) are being allocated. It could be one of the following:

    + the origin and destination pins
    + the object flow
    + the common type of the pins

    Since it's unclear what is being allocated, it would make more sense to show the Pins on the diagram and link the callout note to the relevant item(s) (I believe it's supposed to go to the ObjectFlow).

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

ProxyPort with FlowProperties

  • Key: SYSMLR-124
  • Legacy Issue Number: 18676
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I struggle to use proxy port with flow properties. One idea is to use a behavioral port and to bind the flow properties with the behavior parameters. In chapter 9.3.2.7 about FlowProperties the spec states:

    The binding of flow properties on ports to behavior parameters can be achieved in ways not dictated by SysML. One approach is to perform name and type matching. Another approach is to explicitly use binding relationships between the ports properties and behavior parameters or block properties.

    What are port properties? A port has no properties, but the type of the port, e.g. a InterfaceBlock. And these properties are the same for any usage of the InterfaceBlock and I can’t use context-specific binding relationships.

  • Reported: SysML 1.4 — Thu, 18 Apr 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

primitive types in SysML Activities

  • Key: SYSMLR-123
  • Legacy Issue Number: 18659
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    In SysML, value property types are restricted to be a ValueType.
    I see the problem with incompatible and inconsistent types in customer models, as Activities have no restrictions and still use UML primitive types as pin and parameter types.

    Did I miss something in the spec, or types used in Activity are not restricted to be ValueTypes?

    Also, did we fix VerdictKind to be a ValueType? I don't remember.

  • Reported: SysML 1.4 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Figures 15.5 and 15.6 diagram types

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

    Figures 15.5 (Example of flow allocation from ObjectFlow to Connector) and 15.6 (Example of flow allocation from ObjectFlow to ItemFlow) have ibds on the right, but those ibds have blocks instead of parts in them. Are they supposed to be a bdds? The blocks show parts, but the compartment doesn't say "structured" (same for Figure 15.8).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Allocated notation on object nodes missing from diagram elements table

  • Key: SYSMLR-117
  • Legacy Issue Number: 18461
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In Allocations, the Diagram Element table is missing the notation for allocated object nodes shown in Figure 15.7 (Example of flow allocation from ObjectNode to FlowProperty).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Libraries package should be named "SysML Model Libraries"

  • Key: SYSMLR-118
  • Legacy Issue Number: 18462
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The spec headings refer to model libraries using the adjective "model", so the package name should include it also. The name should start with "SysML" since it is separate from the SysML package.

  • Reported: SysML 1.3 — Sun, 17 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Semantics of multiple Dependencies

  • Key: SYSMLR-122
  • Legacy Issue Number: 18623
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    SysML defines or uses some relationship based on the UML Dependency metaclass. It is possible to specify multiple dependencies having with the same client or supplier. The user can rely on this capability for various purposes. The point is that there is no standard semantics for such constructs. This must be clarified.

  • Reported: SysML 1.4 — Mon, 8 Apr 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Allocation tabular notation normative?

  • Key: SYSMLR-116
  • Legacy Issue Number: 18460
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The clause Allocations, Usage Example, Tabular Representation is in the normative part of the spec, but refers to a tabular notation in Annex C, which isn't normative. Is the tabular notation normative?

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Ports and Flows

  • Key: SYSMLR-114
  • Legacy Issue Number: 18458
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The title of section 9.4.2 includes the term "Flow Ports", which is deprecated. I think it should be "Flow properties". Maybe an editing instruction for a 1.3 issue exists for this, not sure.

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Update to Trace Relationship’

  • Key: SYSMLR-144
  • Legacy Issue Number: 19284
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I potentially found a mistake in the latest SysML specification. It can be found on page 144. The “Trace Dependency” and the “TraceCallout” are introduced on this page. Usually these two visualizations should show the same aspect of a SysML model. Unfortunately the “Trace Dependency” is only introduced between two requirements whilst the “TraceCallout” is shown between a requirement and a more general NamedElement. I think the named element should be allowed in both cases in the client role of the trace dependency. ADDITIONAL TEXT

    The trace stereotype as defined in 16.3.2.7 does not constrain either end of the trace relationship than the having one client and one supplier.

    16.3.2.7 Trace
    Description
    The Trace stereotype specializes UML4SysML Trace and DirectedRelationshipPropertyPath to enable traces to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.
    Constraints
    [1] The Trace stereotype may only be applied to dependencies.
    [2] Dependencies with a Trace stereotype or one of its specializations applied must have exactly one client and one supplier.

    From the UML 2.5 Standard Profile, the UML4SysML::Trace extends Abstraction, which subclasses Dependency. Dependencys are directed relationships between Named Elements. Therefore, the SysML::Trace can have any Named Element as its ends.

    The diagram elements Table 16.2 on pg 144 should be clarified.

    Also, in section 16.3.2.7, the trace relationship has specific definitions for Requirements:

    Operations
    [1] The query getTracedFrom() gives all the requirements that are clients (from end of the concrete syntax) of a Trace
    relationship whose supplier is the element in parameter. This is a static query.
    Trace::getTracedFrom(ref : NamedElement) : Set(Requirement )

    {query, static}

    getTracedFrom=Requirement.AllInstances()>select(traceTo>includes(ref))

    The query getTracedFrom() could be more general and query all NamedElements and not only Requirements.

  • Reported: SysML 1.4 — Fri, 14 Mar 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Semantics consistency of conjugated behavior ports

  • Key: SYSMLR-138
  • Legacy Issue Number: 18952
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Per the definition of behavior proxy ports, they have their owner for value. This implies that a classifier typing a port is a classifier for the owner of the port as well. However, when that classifier specifies directed features or flow properties, these feature specifications shall be interpreted so that their directions are reverted if the port is conjugated (isConjugated=true). The point is that, if the owner is not itself a port, there is no means to specify that such an interpretation applies. Thus, assuming one needs to refer to the owner as the instance realizing the port, it will be required to explicitly use (and then model) a classifier specifying the corresponding feature in the opposite direction. This makes the useful conjugation concept unusable in practice.

    The implementation of the conjugation concept should be modified so that it is not limited to port and applicable to block definitions as well.

  • Reported: SysML 1.4 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Pull semantics for flow properties

  • Key: SYSMLR-134
  • Legacy Issue Number: 18876
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Currently in SysML, flow properties have “Push” semantics (cf. sub-clause 9.3.2.7): writing to a flow property with direction out, propagates value to matching flow property at opposite end of the connector. This implies that there is a behavior running on the part from the “out” side.

    “Pull” semantics could be useful as well: the value propagation is the result of a read made on the flow property with direction in to the matching property at the opposite end of the connector.
    This implies that there is a behavior running on the part from the “in” side.

    SysML should introduce a semantic variation point on this topic, and/or some specific notations/abstract syntax

  • Reported: SysML 1.4 — Mon, 19 Aug 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Update SysML references to UML model library StandardProfileL2

  • Key: SYSMLR-142
  • Legacy Issue Number: 19123
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The UML model library "StandardProfileL2" is called "StandardProfile" since UML 2.5. The new library also include the StandardProfileL3 library.

    Update the references in the SysML specification (chapter 4.2, 5.1.1, 17) and check whether SysML should also include the StandardProfileL3 stereotypes that are now part of the StandardProfile library.

  • Reported: SysML 1.3 — Mon, 25 Nov 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties

  • Key: SYSMLR-135
  • Legacy Issue Number: 18877
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    For “regular” properties, UML semantics in UML is “non-depletive”: the ability to read their value does not depend on the number of time they have been read previously. A “depletive” semantics would implies that a value is no more available once it has been read

    SysML does not say anything about this for flow properties.

  • Reported: SysML 1.4 — Mon, 19 Aug 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Proxy port “complete” specification (§ 9.3.2.12):

  • Key: SYSMLR-137
  • Legacy Issue Number: 18909
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    if a proxy port P1 has a nested proxy port P1::P2 and both are non-behavioral, does it mean that both P1 and P1::P2 must be explicitly connected to internal parts? If P1 is just a logical group of nested proxy ports, there may be no sense to connect P1 per se internally (but it makes sense to connect P1 externally).

  • Reported: SysML 1.4 — Thu, 12 Sep 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Convention for enumeration not used for ControlValue

  • Key: SYSMLR-143
  • Legacy Issue Number: 19134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The convention

    Enumeration types: always end with “Kind” (e.g., “DependencyKind”)

    is not used for the ControlValue enumeration. It should be named ControlValueKind.

  • Reported: SysML 1.3 — Thu, 5 Dec 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Flow property description: incorrect wording (§9.3.2.7)

  • Key: SYSMLR-136
  • Legacy Issue Number: 18907
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The description of the semantics related to the direction (in, ou, inout) incorrectly refers to contained “blocks” instead of properties and the description for “inout” is inconsistent (cannot be instantiated )

  • Reported: SysML 1.4 — Thu, 12 Sep 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML says nothing about how to deal with multiplicity for flow properties matching

  • Key: SYSMLR-132
  • Legacy Issue Number: 18783
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    SysML says nothing about how to deal with multiplicity for flow properties matching

  • Reported: SysML 1.4 — Thu, 20 Jun 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

The SysML classification of properties is incomplete

  • Key: SYSMLR-128
  • Legacy Issue Number: 18709
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    SysML 1.3 section 8.3.2.2 Block says:

    SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType.
    …
    A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation.

    In SysML, we also have Signals.
    In UML, Signals can have properties.

    How does SysML then classify properties defined in a Signal?

    A very strict reading of the SysML spec would suggest that a Signal cannot have any kind of SysML property because a Signal is neither a SysML Block nor a SysML ValueType.
    However, this is clearly too restrictive in practice.

    I propose expanding SysML's classification of properties to include SysML Blocks, ValueTypes and Signals.
    This leads to another question:

    What are the legal types of a property belonging to a Signal?

    I propose restricting such properties to be typed by SysML ValueTypes only. This corresponds to the practical situation where a Signal carries a data payload – I.e., it is a message with some data content.
    Allowing a property belonging to a Signal to be typed by a SysML Block or Signal leads to semantic problems — what would it mean to send / receive such signals?

  • Reported: SysML 1.4 — Mon, 13 May 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors

  • Key: SYSMLR-131
  • Legacy Issue Number: 18758
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Table 8.4 in SysML 1.3 defines the notation for a SysML BindingConnector in terms of an "<<equal>>" keyword. This notation is very expensive in terms of diagram footprint.
    Without displaying the "<<equal>>" keyword, SysML BindingConnectors become visually indistinguishable from bidirectional SysML assembly connectors.

    Suggest providing an alternate notation for SysML BindingConnectors in Table 8.4 based on an elegant solution that some SysML tools and SysML RTF members already use, that is, a single "=" symbol without the keyword guillemets, that is, "=", not "<<=>>".

  • Reported: SysML 1.4 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

About Rate, Continuous and Discrete

  • Key: SYSMLR-129
  • Legacy Issue Number: 18735
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    In the figure shown below, Continous and Discrete stereotypes seems to be applied an ActivityParameterNode of an Activity. However, those aforementioned stereotype do not extend ActivityParameterNode but only Parameter and ActivityEdge. Is it an error?

    In the same order, <<continuous>>, <<discrete>> and <<rate>> are also applied on something called “Object Node”? However, <<Rate>> seems not to extend any node.

  • Reported: SysML 1.4 — Thu, 23 May 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

More than one View() operation allowed

  • Key: SYSMLR-158
  • Legacy Issue Number: 19623
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The viewpoint constraint about the View() operation allows more than one View() operation:

    [2] The property ownedOperation must include at least one operation named “View” with the UML Create stereotype
    applied.

    It is not specified what happens if there is more than one View() operation. For example:

    • In which order are they performed? If only one View() operation is performed it is not defined which one.
    • The wording of the derived property method is only about one operation ("of the operation").

    As long no one has a good use case to have more than View() operation I propose to change constraint [2] to:

    [2] The property ownedOperation must include exactly one operation named “View” with the UML Create stereotype
    applied.

  • Reported: SysML 1.4 — Sat, 27 Sep 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

ElementGroup cannot be source or target of a dependency

  • Key: SYSMLR-156
  • Legacy Issue Number: 19595
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The stereotype ElementGroup extends the base class comment which is not a NamedElement. Therefore a ElementGroup can't be source or target of a dependency and it is not possible to use an ElementGroup for instance with a trace or satisfy relationship.

  • Reported: SysML 1.4 — Sun, 7 Sep 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Table 12.1 has incorrect "int" typed arguments (4x)

  • Key: SYSMLR-157
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    1) SysML convention is to use Capitalized types. These use lower case

    2) There is no "int" within SysML. The correct type is "Integer". While it is possible that an "Int" was defined in a model, in this case it is misleading readers to think that SysML uses Int as opposed to Integer.

  • Reported: SysML 1.4 — Thu, 11 Sep 2014 04:46 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics

  • Key: SYSMLR-148
  • Legacy Issue Number: 19328
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Background:

    SysML 1.3 introduced significant changes to SysML ports
    MBSE methodologies based on SysML 1.2 need to be updated for SysML 1.3 and
    later

    A summary of syntactic and semantic variations for SysML 1.4 ports is an
    important component for tailoring an MBSE methodology as an extension of
    SysML 1.4
    Independent of a particular MBSE methodology, such a summary is an
    important guide for users and tool implementors.
    For users, such a summary would help understand the capabilities and
    limitations of a particular SysML tool implementation
    For tool implementers, such a summary would help understand what
    capabilities need to be implemented to support SysML

    Issue:

    The SysML 1.4 specification lacks a compact summary of the range of
    syntactic variations allowed for SysML 1.4 ports
    and the corresponding semantics for these syntactic variations

    The SysML RTF should provide a catalogue of the syntactic factors that
    induce the syntactic and semantic diversity of SysML ports

    As of SysML 1.4, known factors include, but are not necessarily limited to:

    1) SysML Port Kind

    ­

    {proxy, full, uncommitted}

    2) SysML Port Type

    ­

    {InterfaceBlock, Block, ConstraintBlock}

    3) UML Interaction modality

    ­(UML::Port::isService, UML::Port::isBehavior)

    4) SysML Port Features & nesting

    ­Behavioral features:

    {operation, reception}

    ­Structural features:

    {value, flow, reference, part, constraint, binding, participant, connector, distributed, endPathMultiplicity, boundReference, adjunct, classifierBehavior} {property, port}

    5) Nested SysML Ports (kind, type, modality, features)

    6) Optional feature direction

    {provided, required, provided+required}

    7) SysML Port Connectivity

    ­Internal vs. external connectors
    ­UML Connector kind (assembly, delegation)
    ­SysML Connector kind (binding, non-binding)
    ­SysML Connector type

    {none, UML::Association, SysML::Block + UML::AssociationClass}

    ­SysML Association Block-typed Connector features & nesting
    (same as SysML Port Features & nesting)

    8) SysML ItemFlow

    ­Distinguishing what may flow in general vs. what actually flows in a
    context

  • Reported: SysML 1.4 — Thu, 3 Apr 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Abstract syntax for the initial values

  • Key: SYSMLR-145
  • Legacy Issue Number: 19286
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The abstract syntax supporting the specification of initial values for properties of SysML block has to be clarified and aligned with the intended semantics.

    In SysML 1.4, §8.3.1.2.8 says: “A compartment with a label of “initialValues” may be used to show values of properties belonging to a containing block.

    These values override any default values that may have been previously specified on these properties on their originally

    defining block”

    While §8.3.2.3 says: “An entire tree of context-specific values can be specified on a containing block to carry values of nested

    properties as shown on an internal block diagram”, then: “If a property belonging to a block has a specification of initial values for any of the properties belonging to its type, then

    the default value of that property must be a UML InstanceValue element. This element must reference a UML

    InstanceSpecification element created to hold the initial values of the individual properties within its usage context. The

    instance specification must be unnamed and owned by the same package that owns the outermost containing block for

    which the initial values are being specified”

    If the specification of an initial value is “context specific”:

    · It cannot be specified using the default value of a property

    · It should be possible to distinct initial value depending on the context, i.e. we need a resolution mechanism to know which initial value has to be used

  • Reported: SysML 1.4 — Fri, 21 Mar 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT
  • Attachments:

Deprecate Unit and QuantityKind stereotypes in 1.4

  • Key: SYSMLR-141
  • Legacy Issue Number: 19062
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Instead of deleting the Unit and QuantityKind stereotypes according to the 18269 resolution in SysML 1.4 ballot 4, I suggest moving these stereotypes to the SysML::DeprecatedElements package.

    Without doing this, a SysML 1.4 tool that opens a SysML 1.3 model will have to convert InstanceSpecifications stereotyped by SysML 1.3 Unit or QuantityKind into InstanceSpecifications classified by SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind respectively.

    Even if a SysML 1.4 tool alerts the user that this migration has happened, it will not be possible to discern InstanceSpecifications classified by SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind due migration from SysML 1.3 vs. deliberate choice.

    A better migration strategy would be to convert SysML 1.3 Unit/QuantityKind-stereotyped InstanceSpecifications into SysML 1.4 InstanceSpecifications that are both:
    stereotyped by SysML::DeprecatedElements::Unit/QuantityKind
    Classified by SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind
    The former leaves a persistent indication that the InstanceSpecifications have been partially migrated.
    The latter represents a partial migration to SysML 1.4 Units/QuantityKinds; that is, the user can complete the migration by classifying these InstanceSpecifications with concrete SysML Blocks that specialize SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind respectively.

  • Reported: SysML 1.4 — Fri, 1 Nov 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

proxy and full port notation change request

  • Key: SYSMLR-140
  • Legacy Issue Number: 18993
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    After ˜1 year of using new proxy and full ports, our customers are not happy with using <<proxy>> and <<full>> keywords/labels for port kind identification.

    In real life, multiple labels on ports makes modeling a nightmare (see image below).

    In MagicDraw, we use different colors - full port has the same color as part, when proxy port is different, but it is not enough. Diagram may be printed in B&W too.
    What do you think about the idea to change proxy port graphical notation, by adding some special icons or using a dashed line for example?

  • Reported: SysML 1.4 — Wed, 9 Oct 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

classifierBehaviorProperty and adjunctProperty notation

  • Key: SYSMLR-147
  • Legacy Issue Number: 19326
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    I cannot find new SysML 1.4 ClassifierBehaviorProperty and AdjunctProperty notation details, such as :

    1. what keyword should be used? <<classifierBehaviorProperty>> which is very long, or maybe shorter version <<classifierBehavior>> ? <<adjunctProperty>> ?

    2. In what block compartments should it appear? Under generic “properties” or maybe should have their own new compartments?

    3. Should we show “principal” value on adjunctProperty box? If so, showing only the name is not so useful as showing an element kind too, like <<callBehaviorAction>> or <<parameter>>, so user can understand what it represents.

  • Reported: SysML 1.4 — Wed, 2 Apr 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

[SysML] Semantic variation points

  • Key: SYSMLR-150
  • Legacy Issue Number: 19489
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Kind: Clarification

    Description:

    The current specification of SysML allows, in some places, variations on the semantics. For a part of them it is intentional because the standard does not want to enforce a specific one among others possible, for another part it is not and may result from ambiguities in the text which will have to be fixed.

    It would be useful to explicitly and exhaustively identify the list of intentional semantic variation points so that users can easily see the choices they have to make and state them clearly.

  • Reported: SysML 1.4 — Thu, 26 Jun 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

URI for the SysML Profile given in section E.3 is wrong

  • Key: SYSMLR-146
  • Legacy Issue Number: 19321
  • Status: closed  
  • Source: PTC ( Simon Moore)
  • Summary:

    At the end of section E.4 on page 245:
    "The namespace for the standard profile is: http://schema.omg.org/spec/SysML/20090817/SysML-profile.xmi."

    Should this be referred to as a URI, not the namespace? Perhaps should simply reference the cover page of the spec since the one given here is out of date.

  • Reported: SysML 1.4 — Mon, 31 Mar 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Semantics clarification for removing a value from an out Flow Property

  • Key: SYSMLR-139
  • Legacy Issue Number: 18953
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The specification should clarify the semantics from removing a value from an “out” Flow Property. Since “removing” something is considered to be a “write”, can we assume that it is propagated to a connected and matching “in” Flow Property, if any?

  • Reported: SysML 1.4 — Mon, 30 Sep 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Can a SysML Full Port be typed by a ValueType?

  • Key: SYSMLR-149
  • Legacy Issue Number: 19412
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Several users at JPL have been asking me about this particular combination.
    I can't find anything in the 1.4 spec precluding typing a full port by a value type.

    Have I missed anything?

  • Reported: SysML 1.4 — Mon, 12 May 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

SysML Issues on Item Property values in an IBD

  • Key: SYSMLR-133
  • Legacy Issue Number: 18805
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The SysML spec does not give any notation for (or example of) specifying the values of an item property participating in an item flow. For example, if water flows in multiple places in the distiller, each should be able to have a specified temperature and dissolved matter % (perhaps as distributions).

    Perhaps a variant of a property specific type would work, perhaps a callout approach would work.

    It possible, it would be desirable to allow for multiple item properties:item flows to have the same name within an ibd, as this would be a natural modeling approach (e.g., all the pipes covey the same thing, but with different values).

  • Reported: SysML 1.4 — Tue, 9 Jul 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Inherit from a conjugated interface block

  • Key: SYSMLR-159
  • Legacy Issue Number: 19644
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Figure 9.7 shows that the types of parts that are connected with binding connectors with proxy ports inherit from the proxy port types. That assures that all the features of the interface block type of the proxy port are implemented by the part.

    However in practice you typically have for most proxy ports also a connected conjugated proxy port. You can't inherit from a conjugated interface block and therefore must manually define a conjugated version of the interface block. In summary that supersedes the concept of conjugation.

  • Reported: SysML 1.4 — Fri, 17 Oct 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

<> should be a reference (dashed box)

  • Key: SYSMLR-160
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In figure 9.9, the <<participant>> ends are in solid boxes. This appears to be incorrect. Please check the surrounding association class ibd's for similar problems

  • Reported: SysML 1.4 — Tue, 9 Dec 2014 23:08 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Incorrect multiplicity for base_xxx properties of most SysML Stereotypes

  • Key: SYSMLR-285
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    In the current version of SysML.xmi, all the stereotype properties referring to the element to which the stereotype is applied (the so-called "base_xxx" ones) have [0..1] multiplicities, except for the following stereotypes: FlowSpecification (deprecated), FlowPort (deprecated) and TriggerOnNestedPort.

    Basically, these multiplicities shall be [1..1] except for stereotypes that may be applied to more than one metaclass. That is for SysML: TestCase, Rate, Probability and ControlOperator

  • Reported: SysML 1.4 — Wed, 10 Aug 2016 11:01 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

The XMI file isn't conform to the pdf specification for Refine and Trace stereotypes

  • Key: SYSMLR-281
  • Status: closed   Implementation work Blocked
  • Source: Commissariat a l Energie Atomique-CEA ( Benoit Maggi)
  • Summary:

    The pdf is that Refine and Trace have 2 specializations but have only one generalization in the xmi file
    (http://www.omg.org/spec/SysML/20150709/SysML.xmi)

    Some elements extracted from the pdf and the xmi

    16.3.2.3 Refine
    Description
    The Refine stereotype specializes UML4SysML Refine and DirectedRelationshipPropertyPath to enable refinements to
    identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and
    targets.

    <name>Refine</name>
    <generalization
    xmi:id="SysML.package_packagedElement_Requirements.stereotype_packagedElement_Refine._generalization.SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_Requirements.stereotype_packagedElement_Refine._generalization.SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath" xmi:type="uml:Generalization">
    <general xmi:idref="SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath"/>
    </generalization>
    <ownedAttribute ....

    16.3.2.7 Trace
    Description
    The Trace stereotype specializes UML4SysML Trace and DirectedRelationshipPropertyPath to enable traces to identify
    their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.

    <name>Trace</name>
    <generalization
    xmi:id="SysML.package_packagedElement_Requirements.stereotype_packagedElement_Trace._generalization.SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_Requirements.stereotype_packagedElement_Trace._generalization.SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath" xmi:type="uml:Generalization">
    <general xmi:idref="SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath"/>
    </generalization>
    <ownedAt

    For information, the bug has been raised for the Papyrus SysML implementation
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=497650

  • Reported: SysML 1.4 — Mon, 11 Jul 2016 13:16 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

Spec document inconsistent with Normative profile XMI file ptc/2013-12-11

  • Key: SYSMLR-169
  • Legacy Issue Number: 19817
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Spec document says:
    7.3.2.6 Stakeholder

    Description

    A stakeholder represents a role, group or individual who has concerns that will be addressed by the View of the model.

    Attributes

    • concernList: Comment [*]

    The interests of this stakeholder.

    • /concern: String [*]

    The interests of this stakeholder displayed as the body of the comments from concernList.


    XMI file says something completely different

    Stereotype Stakeholder
    concern: Comment [1..*]
    /concernlist : Comment

  • Reported: SysML 1.4 — Fri, 17 Jul 2015 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

No support for dot notation in activity and sequence diagrams

  • Key: SYSMLR-334
  • Status: closed  
  • Source: NASA ( Robert Karban)
  • Summary:

    The SysML notation does not provide a way to display nested properties as life lines on sequence diagrams or swimlanes/partitions on activity diagrams.

    Supporting dot notation would enable the user of sequence diagrams to reference nested properties and facilitate the construction of swimlanes on activity diagrams where the user now has to construct nested swimlanes.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 20:42 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

Wrong parameter for Operations in the SysML.xmi

  • Key: SYSMLR-289
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    In the current version of SysML.xmi, none of the operation parameter is serialized with its direction. Which means that they all have the default direction, i.e.: "in". This is of course wrong for all the return parameters. By the way, as serialized, the operations have no return parameter and so no type.

  • Reported: SysML 1.4 — Thu, 11 Aug 2016 13:53 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

Dubious UUIDs

  • Key: SYSMLR-243
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    http://www.omg.org/spec/SysML/20150709/SysML.xmi, unlike its predecessors and UML 2.5, defines both xmi:uuid and xmi:id.

    This is a monumental bloat.

    The UUIDs are of dubious utility since the constructive algorithm does not incorporate anything specific to SysML 1.4. Therefore all future SysML serializations must use a different constructive algorithm that guarantees never to repeat the 1.4 UUIDs. (Simplest, never to bloat with UUIDs ever again.)

  • Reported: SysML 1.4 — Sat, 4 Jun 2016 08:12 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

SysML XMI typos in UML StandardProfile XMI references

  • Key: SYSMLR-225
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    http://www.omg.org/spec/SysML/20150709/SysML.xmi, I think when SysML specializes UML's standard profile, uses "_base" instead of "-base" in the reference. Here are a couple examples, might be more:

    1) <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Refine_base_Abstraction"/>
    should be :
    <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Refine-base_Abstraction"/>

    2) <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Trace_base_Abstraction"/>
    should be:
    <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Trace-base_Abstraction"/>

  • Reported: SysML 1.4 — Sun, 21 Feb 2016 15:01 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

Missing comment for some attributes

  • Key: SYSMLR-238
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Benoit Maggi)
  • Summary:

    There are some elements that don't have any comment in the SysML.xmi file.
    (The list can be found at the end of the description)

    Our tooling is using these comments to automatically generate documentation

    Small question: Is the xmi file available for contribution? Maybe on a GitHub repository?

    Here is the list
    SysML.package_packagedElement_Activities.stereotype_packagedElement_Probability_ownedAttribute.probability
    SysML.package_packagedElement_Activities.stereotype_packagedElement_Rate_ownedAttribute.rate
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.sourceContext
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.sourcePropertyPath
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.targetContext
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.targetPropertyPath
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_QuantityKind_ownedAttribute.definitionURI
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_QuantityKind_ownedAttribute.description
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_QuantityKind_ownedAttribute.symbol
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.definitionURI
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.description
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.quantityKind
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.symbol
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.criterion
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.member
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.name
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.size
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Stakeholder_ownedAttribute.concern
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Stakeholder_ownedAttribute.concernList
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_View_ownedAttribute.stakeholder
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Viewpoint_ownedAttribute.concern
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Viewpoint_ownedAttribute.presentation
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_ChangeStructuralFeatureEvent_ownedAttribute.structuralFeature
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_DirectedFeature_ownedAttribute.featureDirection
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_InvocationOnNestedPortAction_ownedAttribute.onNestedPort
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_TriggerOnNestedPort_ownedAttribute.onNestedPort

  • Reported: SysML 1.4 — Mon, 9 May 2016 15:51 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

RequirementRelated is present in the summary but no more in the document

  • Key: SYSMLR-163
  • Legacy Issue Number: 19757
  • Status: closed  
  • Source: Anonymous
  • Summary:

    RequirementRelated is present in the summary (16.3.2.4) but no more in the document

    => The problem put all the section 16.3.2 in disorder

    Also RequirementRelated is still present (as Deprecated) in the profile I'm working with
    (The one that will be used in eclipse-Papyrus).

  • Reported: SysML 1.4 — Mon, 11 May 2015 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

Cannot navigate and represent deep nested defining feature in a slot

  • Key: SYSMLR-338
  • Status: closed  
  • Source: NASA ( Robert Karban)
  • Summary:

    As discussed in the RTF plenary on Sep 12 2016 the ability to
    navigate and represent deep nested defining feature not directly owned in the classifier of that instance would largely simplify the construction of instances specification trees.

    Consensus was reached in the plenary.

    There is a potential problem with UML which says that slot defining feature is a feature of that classifier.
    Michael Chonoles volunteered to work on this on the UML RTF side.

  • Reported: SysML 1.4 — Thu, 15 Sep 2016 14:44 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

Resolve inconsistency concerning restricion of ItemFlow type hierarchy

  • Key: SYSMLR-328
  • Status: closed  
  • Source: NASA ( Robert Karban)
  • Summary:

    Issue:
    The descriptions in the specification are inconsistent regarding the constraints of what can actually flow over a connector.
    The ItemFlow is used to constrain what actually flows w/r/t the flow properties which specify what can flow.
    In other sections the specifications suggest that the ItemFlow actually loosening the constraint by allowing more general types to be flowing.

    Description:
    These are the inconsistent parts in the specification:

    9.3.2.11 ItemFlow, p86 states:
    An ItemFlow describes the flow of items across a connector or an association. It may constrain the item exchange between blocks, block usages, or ports as specified by their flow properties.

    9.3.2.11 ItemFlow, p87 states:
    Each classifier of conveyed items on an item flow must be the same as, a specialization of, or a generalization of at least one flow property type on each end of the connected block usages.

    9.4.6 Item Flow Decomposition, p95
    Item flows can also be more general than the actual flow, as shown by the connector on the right. The water distiller produces distilled water, but the item flow is for any kind of fluid. The connection to the water heater is
    compatible because it accepts any kind of water, including distilled. The item flow does not require the heater to accept any kind of fluid, because the source of flow is still producing water, regardless of the generality of the item flow.

    Figure 9.15, p95 - Usage example of item flows in internal block diagrams
    Item Flow is Fluid.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 19:14 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

Make ItemFlow a specialization of DirectedRelationshipPropertyPath

  • Key: SYSMLR-326
  • Status: closed  
  • Source: NASA ( Robert Karban)
  • Summary:

    Issue:
    When ItemFlow connects (deeply) nested or inherited properties (e.g. ports or parts) we cannot uniquely identify the sources and targets in its context.

    Description:
    This is similar to other relationships which specialize DirectedRelationshipPropertyPath, e.g. "The Allocate stereotype
    specializes DirectedRelationshipPropertyPath to enable allocations to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets."

    The DirectedRelationshipPropertyPath stereotype based on UML DirectedRelationship.
    Stereotype <<ItemFlow>> extends UML metaclass UML4SysML::InformationFlow which specializes DirectedRelationship.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 18:48 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT

specializations of requirement should specialize AbstractRequirement

  • Key: SYSMLR-247
  • Status: closed  
  • Source: NASA ( Robert Karban)
  • Summary:

    They specialize requirement and therefore do not allow to have properties.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 19:51 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 3 Jan 2017 13:36 GMT